Deno was the new hotness a little while ago. Basically every JS post was Deno for a while.
... How are things going now that things have settled down? Who's using Deno?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (25)
I see some things about deno vs node, but they are fairly wrong. Basically because node has a lot of large gaps that by definition can’t be closed. While deno solves those.
I have been using it since February everyday. It is wonderful. No need for a package manager. The industry has created immutable modules so they can never be removed. Can’t say the same about NPM.
A lot of tooling is actually done in Rust instead of Javascript. This is transparent to the user, but makes it so things like formatting or lint it are blazing fast. That being said they have some work to do, since they are basically recreating prettier and eslint. But the community is well on its way.
The best thing I can day is this.
I don’t have to use a package manager, it just works. This is amazing with dynamic imports.
No need to setup tools or download a boilerplate. It just works and comes with what I need.
The module repository is really a proxy with added immutability. It is really nice. Forced to tag modules which solves some minor dependency issues with NPM. For example a lock file is optional if all sources come from a repository with immutability. And it’s optional, you can get package from MANY places.
Because most people use deno fmt and deno lint, code is super easy to read across projects. Conventions are nice.
First party support for WAM.
First party zero tooling typescript.
Coming soon is rust plugins so you can run native code with custom bindings to deno.
The community is one of the best. Only second to vue in my honest opinion. Core team is amazing. Super helpful.
Many node packages just work through unpkg, pika, skypack. Though not as ideal as a real deno mod.
Basically the node vs deno thing is kinda BS. They both run on v8. The difference is in resolution of files, the baked in Dev experience, package management.
Deno also has a more stable runtime in the sense that requests perform more consistent than node. Responses from a app through deno and the same app in node is very interesting. I run benchmarks of 10,000 times, and you will get a dozen outliers and everything else will fall into the same time. Node on the other hand will be all over the place.
This seems to be the only valuable comment here. Thanks!
Comments are now immutable. :P
I often use Deno for my small automation scripts / local tools.
I like that I can use TypeScript based on the V8 JavaScript engine and modules without using third-party tools like Babel. It also comes with its own bundler and tester. No more
npm install whatever --save-dev. Deno handles packages by itself just from code. Deno gives me free hands when I want to write a small script without any configuration and that's why I personally like it. I also like its permission policy.I am currently looking for esbuild or esbuild wrapper (like snowpack) that doesn't need node or npm.
I am not sure if deno's native can minify yet?
Do you have some tutorial for creating modules with Deno?
lyty.dev/deno/deno-module.html
I tried it a bit for a while and can’t really see its appeal for me to move from node.
I‘d like to be proven wrong though but it seems to me deno is just another huge effort to solve workable problems that exist on node.
I guess only time will tell whether it will replace node or die because of insignificant userbase.
Many issues can’t be solved in node that deno solves.
I don’t think you want to migrate, as much as when you do a new project, check it out.
I think it depends on how much it can replace frontend tool set.
For backend, I think it works well, but cannot replace Node, not to mention other languages' competitors.
There should be some bridge, to move Node projects to Deno projects.
I understand that it's not possible, taking consideration that they are two different environments. But there should be away to handle this.
Taking NPM packages as url based package like in Deno.
If we have this bridge to build Node projects to Deno, I believe won't take more than a 3-4 years for Deno to prevail.
Pika package, skypack, and unpkg.
Basically those services take NPM package and wrap a module around it. Most of them work today.
Node has module support. If the NPM package has it, it works in deno.
Node specific calls that can’t be emulated in deno, or dependencies that won’t work through the services I said above won’t work. But many things just do.
Deno also has Node's commonjs and module's compatibility layer.
github.com/denoland/deno/blob/mast...
Deno seems cool and it has the potential to replace Node in the future. However it's still in its initial phase and I think it's just better in personal test projects at the moment. Not many people have even mastered Node yet and obviously there won't be any Deno jobs for years.
I'm still waiting for package management to become stable.
There is no package management. It’s not ideal.
Create a deps.ts file and export any thing you need to import.
If you want to use a interface in your code similar to node where you regency the “module”, then use the import map feature.
Not sure what you are waiting on. The package managers for deno, just make it easier to create a import map. It’s not like NPM by design.
not touching deno until it is atleast 4 yrs mature, i have done this mistake of migrating to an emerging framework in the past, and almost always regretted it, there is always something missing which maybe secondary tertiary or even quarter nary priority to the dev team and you the developer ends breaking your head all over stackoverflow
v1 is too early to predict its future, so, for now, its still node
Interesting question. I'm also intrigated. Personally I used Deno only on dummy side-projects, but not yet in a real one.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.