What would Node look like if it was written today? In one word: Deno. The JS runtime has Typescript build in and simplifies module resolution. On t...
For further actions, you may consider blocking this person and/or reporting abuse
I heard a talk about deno and looked into it a bit. The first thing that stand out to me was there import system. Using urls for import doesn't seem to me a great idea. I cannot imagine anything other than the bad dev experience it would bring. They are using rust for there backend which have a powerful package manager and is one the reason why people prefer rust over any other systems level lang.
I think they have to introduce a package manager sometime in the future and as the ecosystem/community will grow around it, a package manager would play very important role in supporting that.
The idea behind this is that we are already using URLs as imports in the browser all the time. Why not in backend applications? There is also the case of simplifying build and compile processes by eliminating dependencies.
When looking at Deno we must keep in mind it is designed to replace bash scripts with js. That was the original problem to solve. As the community picked it up it seems like is growing to be much more than that.
But aren't we moving away from that by using frontend frameworks? Today at most we use urls for importing images or css. That too we do mostly for internet reasons. At backend it is unnecessary and doesn't make any sense.
I listened the talk by one of the founders and he was kind of clear that they were trying to make a better node And even if it was designed to replace bash script then why compare with node?
"At backend it is unnecessary and doesn't make any sense" -- I would say as things are today, you are probably right. However, with serverless and services getting smaller and smaller I see a strong case for URL imports.
The comparison with Node is natural as they are bot JS runtimes. And both written by the same persona. Ryan Dahl based Deno on what he would like Node to be/have back in 2018.
I think you have a strong point but I am trying to imagine how things will be in five to ten years. And there I see a strong tendency towards decentralized and smaller but independent applications. Some of them which can perfectly run on Deno.
Well in five to ten years it will be used for more than just serverless and services. That's where the problem will start.
Deno is in early stages so I am pretty much sure that they will change some things for good.
Using Deno does not mean you can't use tools like NPM, it means that you are not restricted by it. Currently all code used in Node must be in this central repo, with Deno, no more.
This imports can be manual if you want to, the reality is, we should know what are we importing and not just blindly installing cause the tutorial say so.
EDIT: Something like NPM will probably be implemented by the community after v1.0, just hoping it moves towards Linux package management(repos), its cleaner this way.
Thanks for the writeup. I really admire Ryan Dahl and am rooting for him and for Deno. It is hard for me to see how it will gain mainstream adoption without a "killer feature". While all of these features are good (maybe even great) incremental improvements I am afraid they won't be enough.
The article is well written and polished but looks like you forgot to add a source that you wanted to add:
Spot on Isaac: Deno is still missing that one "killer feature" that would make up for the cost of switching. At the same time, it does offer a glimpse of what the future will look like.
Maybe it will just end up as a "research" space fo the community in order to improve Node.
Thx for the tip adding the source. Cheers!
Deno Compile, that's probably the feature that will pay off the investment.
Admittedly I haven't looked into Deno a great deal yet, but I'm having trouble imagining production level software at this point given that a lot of proven and tested open source frameworks and tools such as express, create-react-app, electron, webpack, and their hundreds of dependencies, assume the use of npm or CJS modules require syntax. Would these packages and their dependencies have to be rewritten?
I hope not, but if so I do feel like we'd be seeing yet another split in the javascript ecosystem and a whole new world of compatibility concerns that would not be a "great developer experience." I've already noticed a number of people creating their own versions of popular packages for Deno and I can't help but feel they might not get the same support as the originals. I wonder if Deno could perhaps add some kind of compatability layer.
A node polyfill is currently under development in the Deno std library. You can see the docs and progress here: github.com/denoland/deno/tree/mast.... Still in it's infancy but growing. Supporting node packages would certainly ease the transition for developers.
Looks like the way to go. Thanks Chris!
That's a really good point. The code amount of code relying on Node is right now huge and the added features do not pay off for now(my opinion).
"I wonder if Deno could perhaps add some kind of compatibility layer." -- I really wonder how that would work. If one could translate the calls to the Node APIs to Deno APIs that might just work as long as we keep performance in mind.
Maybe that's even a project worth pursuing.
In your section "Typescript with Zero Setup": Didn't you want to say that you can execute typescript directly with ts-node?
Since node-ts is something related to TeamSpeak...
Although you can execute typescript code out of the box
ts-nodeyou still need config files for a proper dev to production flow.On the other hand with
denois out of the box. How ists-noderelated to TeamSpeak?I just tried to give you a hint regarding a "typo"/error in your post.
node-tsis not about typescript at all, butts-nodeis.ts-nodeis not related to TeamSpeak, butnode-tsis.if you search for
node-tsin your article and replace all occurrences withnode-tsthe error would be fixed.Thx a lot for spotting that and for the feedback!!!!
I'm not sure that the lack of a package manager is something I consider a feature or benefit. Npm is one of the single greatest things to come out of node. I'm sure living without it in Deno has its advantages, but I could definitely imagine some disadvantages that I'm not sure why I would have to live with
Npm standardized package management for Node. But that itself is the problem.
I see your point, however. As applications grow one wants to be able to understand dependencies easy and for the better or worse package.json was fulfilling that function really well.
Personally I think URL imports can become really important when one builds a service containing several serverless functions. In the case of stateless services, you do not want to write a REST API. So they can just be replaced with a script hosted on S3. Publishing to npm would be in that case too much of an overhead.
Node.js never had promises, not until native came in with V8.
What was called promises in few old versions (last one was v0.1.29) was purely a simple extension to event emitter, nothing more (no
then, no nested resolution, it had nothing to do with promises which we work with now)You may confirm that at still available documentation: nodejs.org/docs/v0.1.29/api.html#_...
Still, it's true, core Node.js members didn't believe in promise interface even when Promise A+ started to be really popular. It's only after it became a part of a standard, things changed. async/await was delivered in Node.js on par with browsers, soon after we also got
fs.promises.Anyway to this day (as lighter, and not introducing artificial ticks) callbacks are faster than promises, but for most of real world scenarios difference can be safely ignored.
Thanks for the suggestion. And thanks a lot for the reference to the
v0.1docs. I will take a closer look and update where appropriate. Much appreciated!You mention
"The setup for development [with node + typescript] can be complicated, especially together with other features like hot code reloading."
Last I checked, Deno has no answer for hot reloading yet. Has that changed?
Great remark Alex! I just run into this file watcher but never tested it. A file watcher should be enough to reproduce what we on
nodewithnodemon.This seems cool. However, I'm looking forward to NodeJS deprecating old APIs and growing. If it's all JS and TS for either runtime, I'd rather stick with something mature.
Deno will be future after Node.
Thanks for the article.
you are welcome Nitin!
Newer dev here looking to future proof his skills by paying attention to Deno. Mind ELI5 some of the benefits? Some of the terminology is confusing. Super interested in the future of this!