Deno, introduced by Ryan Dahl, the creator of
Node during JSConf 2018 has been growing into a major alternative to Node.js. Deno is similar to Nod...
For further actions, you may consider blocking this person and/or reporting abuse
Deno looks quite interesting, but I really don't like the way you need to import packages from URL's. I still think there should be a package management system as it makes handling and updating packages easier.
URLs are more flexible, and it may be a good idea in the long run. But package management systems make stuff easier to use.
Deno has a section in its docs on Managing modules. One of the conventions is to place all imports in a single
deps.tsfile. Functionality is then exported out ofdeps.tsfor use by local modules. This makes it easier to manage dependency versions and stuffYou don't have to worry about network problems though – once you run it, Deno caches all the modules required.
Agree on this a little, because sometimes I just want to download all packages and go code somewhere without the internet. Or a situy may happen when a dev does not have access to internet, but while having all the packages he can still do some work. With urls it becomes impossible until the caching mechanism is created(which is almost node modules). + Yoully need to always specify the needed version directly, because the package may change a lot(like react router does) and your app won't work after that.
And also as well as I understand we'll need to specify the version in all urls in all files where it is imported, not in one config.
Caching is not like
node_modules, as far as I understand. Deno caches in a directory somewhere at~/. So, once a package is cached, it may not have to be cached again, even for a seperate programYou misunderstand how url imports work you need to read more about it... nothing will break because version are kept in the url. And also No internet No problem if it is cached/downloaded you can work just like with npm if there is no internet it behaves the same as npm if your internet is dead you cant do npm install what do you think npm has under the hood? Correct there are a bunch of web urls who get requested. I have no idea why people always assume you can't work without internet when using url imports all you can't do is cache new packages same with npm you can't npm install without internet but you can work with whats in the node_modules or in case of Deno whats in the cache.
Funny that you mention this. A few months ago I did a silly experiment, I manage to use npm packages in
denousing vite. It is totally possible to usenpmto manage some packages of yourdenoapp.You might be interested in Deno's import maps which could be generated by a package manager like Trex.
The only caveat is that the import map file has to be specified explicitely as opposed to node's package.json which gets picked up automatically. That is unless you use somthing like Denon.
This is how the web works. Try to learn more about it.
Maybe you haven't worked a lot with the web. Python, Ruby, Rust and Node all work with the same philosophy.
What I mean this is ECMA standard.
ECMA standards, just because someone dictate a worst way to work doesn't make it law
I mean they dictate how JS works Deno just implements it correctly.
I think that if people are dissatisfied with URLs, people will come up with new, better ways to import modules.
This has happened before, for example, in Vim. There was no standard way to load plugins, other than by cloning them via git, but third party plugin manager were created to make it simpler. This even led to vim introducing their own plugin system.
Siddharth makes a fantastic point. It is not like Deno does not bring along a way to manage your packages/dependencies. With that in mind, just because a method of doing something in one place works well, does not make it the superior method in another environment. It makes total sense for JS to have packages be imported via urls. Functionality can always be added on top to make it work like you are used to after the fact. People tend to think that a method of doing something is superior or the best just because they are used to it and not necessarily because it IS the better method.
My only concern is dependency management with URL imported packages. How would one go about changing the version of the package if it is been imported in 10 different places. Also solving resolution conflicts that package managers like
yarnandnpmperform when one package depends on several is quite handy. Having URL's is fine as long as there's a central way of managing the dependencies.vs
I personally find the former easier to read and write. Also for autocomplete and intellisense, the dependencies need to be downloaded anyway.
As I said here, Deno has a convention of putting all imports in a
deps.tsfile. This makes it easier to change versions, as there is only a single import.Deno has no "magical" module resolution. Instead, imported modules are specified as files (including extensions) or fully qualified URL imports. This makes it harder to mess up.
If you use the
deps.tsconvention, you could have this:deps.tsmain.tsor wherever you use itDeno caches modules once they are required once, so intellisense can work at that time.
Yup
deps/tsis a much better way :)Great to know! Will try this out with
deps.ts. Thanks!BTW there is a deno registry
Used Deno in production and recently ported everything back to Node.
Tbh Deno is great and I love it, would like to use it a lot more. The only downside at the moment is the lack of libraries available. The deal breaker for me is there aren't any mature Database ORM Library for Deno right now. Aside from that, Deno is great and a pleasant to work with.
Putting my Deno project in archive and looking forward to get back to it in the future.
Deno was hyped as the Node killer when it released 1.0, quicky after no one talked about it any more when they figure out that it would be too much work convert Node apps too Deno, without that hype people not create packets for it what really is key to Node's success. It will take years to catch on again and likey the lead dev that got a history of exit projects will leave before it will be....
Demo should make its own package manager with restricted uses of control to the package or they have to implement a system like if I import package from "react" or "any package name" it should under the hood converts it into the url or import it from local cache.
I think if it is implemented we can save lot of space in hard disk. As it is first party implementation unlike pnpm.
Nice, thank you.
The code example has an error though. I think it needs an "async" before file, and ".path" after fileExpansion as:
// mycat.ts
import { expandGlob } from "deno.land/std@0.102.0/fs/expand_gl...";
// no need to remove the path to deno, etc.
const files = Deno.args;
files.forEach(async file => {
for await (const fileExpansion of expandGlob(file)) {
const contents = await Deno.readTextFile(fileExpansion.path);
console.log(contents);
}
});
Nice catch in the
.pathThe async is not needed, as deno supports top level await. It could be added though.
Would be cool if web browsers can make use of deno in a way so we can directly reference
.tsscript files in HTML and actually run them.security to the max.
clone or fork and host the lib
import into coding
any bad changes won't effect your coding.
I am glad that TS support is encouraged but not mandatory. In a few months I might get into Deno as well.