loading...
Cover image for Deno is coming

Deno is coming

omenlog profile image Omar E. Lopez Updated on ・2 min read

The creator of Node.js from some time has been working in a new project called Deno, the first stable version of this project should be published in 3 days on May 13.

The project is defined as

Deno is a JavaScript/TypeScript runtime with secure defaults and a great developer experience.

From the official repo we can summarize some of the main features:

  1. Supports TypeScript out of the box.
  2. Has built-in utilities.: It include a dependency inspector(deno info), code formatter(deno fmt), test runner(deno test), bundler(deno bundle), documentation generator(deno doc), debugger
  3. Ships a single executable.
  4. Scripts can be bundled into a single javascript file.
  5. Secure by default: This mean that unlike Node when we run our applications they by default don't have access to the file system, network or enviroment, for that we need enable them using some flags as command line options to allow access for example deno --allow-read=/etc

Some difference with Node are:

  1. Deno doesn't use npm, it uses modules referenced as URLs or file paths
  2. Deno doesn't use package.json in its module resolution algorithm.
  3. All async actions in Deno return a promise. Thus Deno provides different APIs than Node.
  4. Explicit permissions.
  5. Deno always dies on uncaught errors.
  6. Uses ES Modules and doesn't support require().

This and more information can be found on the official repo I expose it here just in order to show a quick resume. So now that we know main features, and differences what are your thoughts regarding it.

Will you give a try it in upcoming projects ?
Do you think it will cause a huge change in the Node community
In your opinion what is the best feature
What your dislike most about it

Above I share some of the main question that I hear when I talk about it with some fellows at work. I'll be glad to read your opinions in the comments.

Thanks in advance

Posted on May 23 by:

omenlog profile

Omar E. Lopez

@omenlog

Programmer by default, lover of JavaScript and interested in functional programming

Discussion

markdown guide
 

I'm pretty excited by the premise

 

That's seems promising.
But i can see a massive problem if deno take the lead:
How the JS community will be able to argue about the "better" bundler to use , or which test runner you should add to your project ? Even, the war commonjs,amd,umd,es2015 will be over ? I mean let's be serious this not js anymore if you don't have to choose between a shit load of options to finally change everything a month later :D

 

lol very funny your comment

 
 

It sounds like deno is going to be npm incompatible (just by its name!); not sure if yarn would support it. So my larger question, what would be the options for deno in terms of:

  • Managing package dependencies
  • Managing the version of deno installed (on your dev system)
  • deno & webpack, how would this work?

I also hope folks picked up on the fact that deno is node switched around 😏

Thanks!

 

I think that we won't need some dependencies management basing in the fact that they are defined at the import statements using urls, which serves to identify them.

As deno has a bundler out of the box the intention should be that developers use this bundler and not third party options (Webpack, Parcel, Rollup), the same principle can by applied for testing , linting and formatting

Good question about different versions in the system, but the platform is shipped as a single executable so isn't hard build some tool like nvm

Thanks for your comment

 

Well, if you want to see a resource for ES6 import-compatible libraries (compatible with Deno), Pika looks like the best option right now.

 
 

I am pretty much in agreement with Ben Awad's opinion in his video. Technically Deno is pretty cool, and I like TypeScript and Rust, but unless Deno has a blessed dependency management strategy and a good compatibility story with Nodejs and npm, I don't see it growing out of the niche easily.

Unfortunately, Deno is born out of Ryan Dahl's regrets about Nodejs, which means it would be hard for him to accept the same perceived warts back in.

EDIT: Or, if some huge communities decide to migrate to Deno entirely such as Angular, React or Vue, then that would boost Deno right out of niche too.

 

I saw the video and I also agree with him , mainly the fact about the incompatibility between existing libraries and the new deno apis, it seem that this can be a issue in which the community will play a huge roll

 

Apparently, some people think it's enough that it was written in Rust! I had one such idiot arguing with me the other day, and it was hard to respond. 😅

 

"node" was brilliant from a marketing standpoint, I'm not so sure about "deno". I get it, deno is the letters in node rearranged. deno sounds friendly to me. When you have to convince devops to uptake a tool, "deno" sounds like a toy compared to "node" which sounds like it just belongs.

You'd be surprised how much naming really matters.

FWIW I like deno a lot. I appreciate some of the problems it solves and with Microsoft acquiring npm I want to move on. I honestly hope deno is the future.

 

It's great for software itself; it's moving the ecosystem forward with new ideas. I like that.

Now, if this picks up, it'll certainly take 3 or 4 years for serious adoption - no company will be willing to switch their entire engineering to a whole new platform.

 

If this picks up pace, then, it will really be - one language for everything. With Node.js, you always had Node.js specific things (like their callback style for async actions, require(), exports etc.).

Promises for async methods - the best difference IMO.

 

This mean that unlike Node when you we run our applications they by default don't have access to the file system, network or enviroment, for that we need enable them using some flags as command line options to allow access for example deno --allow-read=/etc

Explicit permissions.

Deno always dies on uncaught errors.

Less silly name

I have to admit, if the above pan out, there's a good chance I might hate it less than I hate Node.js/Node.JS/Node/NodeJS/justStopALready.

 

Dependency by url is nice because there doesn't need to be a central repository, but it feels pretty cumbersome to use. URLs are long and hard to remember.

It gets worse if you want to use one dependency in multiple files. You have to copy the url across and upgrading a dependency means searching your entire code base for imports. This is worse than npm, imo

 

In order to avoid this issue they defined imports maps you can check this video for a more detailed explanation , also the official repo has information about this topic.

 

Most of DENO's features are completly bullshit. e.g : Sandboxing.

RY said : "We can't enforce permissions for native code. Once you load a .so file, all security promises are gone."
So, the first major argument is... not true.
Because sandboxing needs to be done at an OS level not at the runtime level.

Dependencies via URLs are..., well, awful.
If the code change, it will either break your program because of these changes or because the integrity hash won't be the same. Remember go dependencies management system ?

To conclude, only beginners or external to the node environment could be hyped by such a project.

 

I really like to think Deno will become the next big thing in the JS ecosystem....

 

Great Post! I'm really excited for this project .

 

Looks interesting! I have a question (Haven't read manuals yet), are Deno executables compiled? Or they are like zipped packages?

 

It was implemented in Rust, so it should be compiled

 

Deno must have a large community to really grow up. but I very excited about its feature.