DEV Community

loading...
Cover image for Is Deno the future of JavaScript?

Is Deno the future of JavaScript?

hanna profile image Hanna ・5 min read

Over approximately this past year a "new" JavaScript runtime has been gaining attention. Made by the same person who made NodeJS, Deno is a JavaScript runtime that is in a lot of ways better in terms of compatibility, and among other things. There's plenty of articles out there on this topic, but this is going to be my personal take on where it's going.

Compatibility

One thing that has been in Node for quite a while is backwards compatibility functionality, things like require which was originally created by RequireJS, among other small things are an issue as not only does this not make it compatible in the browser (for use in both front and backend development), but it also in some cases is highly against the ECMAScript specifications.

This is one of the areas Deno succeeds in, in my opinion. Deno does not use anything like require, it uses things from the ECMAScript specifications such as import, but not only this, Deno aims to quite strictly follow the specifications and has as far as I have known even deny feature requests as they have gone against the specifications before. While this can be limiting in some cases, this also means it's extremely compatible with some things as it follows the specs, on top of this Deno also aims to be compatible in the browser excluding their builtin APIs.

Small footprint

One thing about Node is the install has many, many files and that's entirely okay and normal! I'm not hating on Node by any means. However due to this it takes up more space than necessary in my opinion, and could probably save some space in some cases, I'm not going to nitpick here as I'm not well versed in C++ development and libraries, nor the NodeJS code base, I just use it.

Now onto Deno, this was something that shocked me personally, given I've used Node for so many years before even hearing about this project. Deno is a single executable, that's all it is. When you install via their command line installer, or just simply downloading the latest release from their GitHub, it's literally a single executable file. This is partly due to the project being made in Rust, which has some other benefits, but we'll be going into that later on in this article.

Package Management

One thing that has always irked me about node is how much space package management uses. Don't get me wrong NPM is a great package manager for what it is, it does what it does well. However, one thing it doesn't do well is saving storage space, there is alternatives such as Yarn, PNPM, and probably others, and they do save space, as they cache packages previously downloaded, even PNPM goes out if it's way to use symlinks to save as much space as possible.

Deno's package management is a bit more interesting on the other hand to me, instead of a per-project module/package folder, such as node's node_modules folder, Deno stores and caches all modules used in folder(s) inside of your DENO_DIR directory. On top of this, there is no meta files in a "stock" deno project, only the source code for your project, as instead of using a package registry or something similar (besides their third party module listings), you simply import modules via a remote url, for example

import {} from "https://deno.land/std@0.73.0/log/mod.ts";
Enter fullscreen mode Exit fullscreen mode

TypeScript

I love TypeScript, ever since I found about it around the first time it released I've used it as the pseudo-type safety is an amazing feature, as well as using import and other ECMA features by default, and sometimes even getting new language features before normal Node does. However, what I do not love is the fact I have to install a package or module to use it, on top of this having to compile my source manually every single time if I want to use it as Node doesn't support running typescript. There are some projects that help alleviate this to an extent such as TSNode, which gives you a TypeScript REPL on node, but you still have to have both it, and typescript installed.

One of my favorite features of Deno is TypeScript is supported out of the box, the TypeScript compiler is built into the runtime, so running TypeScript files with it just simply works. There's no need for me to install a module or package, everything just simply works. On top of this the Deno standard library is also written in TypeScript, meaning everything has proper types, and documentation and that's lovely when you want your code to be working as expected, especially as it's a standard library!

Ecosystem

The one thing I find personally lacking in the Deno world is the package ecosystem. There is certainly packages, but due to the project being so early in development (at least compared to Node), there is not many packages in comparison to how many there is for NPM/Node. If we take a look at their 3rd party listing page, there is as of writing this 1049 packages, while as on NPM there is roughly 1,402,796 packages according to this website. That is a very large difference. This is probably the main downside I can see currently for Deno.

Rust vs C++

This section is going to be smaller than most, as I'm not the most well versed in C++ development. However I am somewhat experienced when it comes to Rust. One thing I quite love about Deno is the fact it's made in Rust, as Rust grants quite a few benefits compared to C family languages, such as immutability by default, thread and memory safety, among other things. This being said, all these checks probably do have overhead, in the end the runtime is still pretty fast in my experience, you can checkout their benchmarks for more information and data.

Is it the future?

While I can definitely see Deno rising up and becoming a popular runtime, the sheer amount of libraries and technologies using Node is massive, switching runtimes no matter what runtime it is, is a lot of work, and on top of this Deno's node compatibility layer isn't fully completed just yet making switching away from node even more of a hassle. In the end Deno is still very small, and for now most projects will most likely stick with Node. So I think it won't be for at least a few years before Deno starts getting used more often than it is.

Discussion

pic
Editor guide
Collapse
alekseiberezkin profile image
Aleksei Berezkin

Managing deps is hard 😐 With NPM the problem is a disk space and package-lock.json which noone likes; with Deno it's having quite weird long imports:

import { add } from 'https://x.nest.land/ramda@0.27.0/source/index.js'

Not sure what's worse πŸ€·πŸ»β€β™‚οΈ Anybody has an idea?

Collapse
jfemia profile image
Jamie Femia

My problem with versioned url imports in source files is that for all but the smallest projects, you probably have to use those imports in several files.

I'd probably want to abstract that somehow, which then ends up looking a lot like a dependency spec file like package.json...

Collapse
alekseiberezkin profile image
Aleksei Berezkin

So you replace package.json with its js (ts) analogue... What's the point? No sarcasm, I just don't get it πŸ˜•

Thread Thread
jfemia profile image
Jamie Femia

It's clearly possible to do this. Perhaps it's just a misunderstanding as a result of how articles like this are worded when it comes to dependency management. Talking about 'not having a package.json and instead uses URL imports' is kind of a moot point when in many cases you'd use one anyway, just not JSON.

It seems weird to make the point of calling it out as a difference between node and deno, but is it really any different?

Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt

You can indeed use simply import_map.json.

The point of Deno is further adherance to web standard, even forced sometimes.

Another point is security of Node.js can be better.

Thread Thread
hanna profile image
Hanna Author

Yes as there isn't any package/meta files in a project using Deno. That's kind of the point I'm trying to make. The directory and file structure is a lot cleaner as the formatter, linter, package manager, etc is all built into the executable.

Thread Thread
bias profile image
Tobias Nickel

i think as time goes bye, node.js modues will also change. node.js already moves to esm modules.

Thread Thread
hanna profile image
Hanna Author

They haven't moved to them completely, but they are supported. The main issue with them moving to ES modules is a lot of people still use require and other CommonJS features.

Collapse
hanna profile image
Hanna Author

some people have a deps.ts file exporting everything:

export {} from "";
export {} from "";
export {} from "";
export {} from "";
Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt

You can also

export * from "xxx";

Also, this is possible

export * as xxx from "xxx";
Collapse
emjimadhu profile image
Em Ji Madhu

This where import_maps deno.land/manual/linking_to_extern... comes to rescue!

Its simple as create a import.json (ex)

{
  "imports": {
    "alosaur/": "https://deno.land/x/alosaur/"
  }
}

and import like this in .ts

import { App } from "alosaur/mod.ts";

and pass the imports.json with --unstable flag when you run deno.

Take look at this example github.com/alosaur/alosaur-schematics

Collapse
mcartoixa profile image
Mac

I use npm without package-lock.json: I make my build package all dependencies at the time of build so that they won't change on different platforms (integration, test, qa, production...).

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

import_map.json, which is also web compatible.

If you need more features, try deps.ts

Collapse
andreespirela profile image
andreespirela

It's long but not because of deno rather than the nature of using web urls. if the script is http://google.com/script.ts then that would be the url, if the url is large then it's large...

Collapse
nektro profile image
Collapse
hanna profile image
Hanna Author

There's some websites that help shorten it

Collapse
shadowtime2000 profile image
shadowtime2000

I'd prob use it if they support CommonJS. using static import statements feel weird especially on server side.

Collapse
hanna profile image
Hanna Author

At least import follows the ECMAScript specifications!

Collapse
shadowtime2000 profile image
shadowtime2000

Well, technically, require does follow ECMAScript specifications because it is a valid Javascript function. But, I see your point on that.

Thread Thread
hanna profile image
Hanna Author

Require isn't part of the ECMA specifications, it's part of CommonJS. As read here when you enable ES modules for your package.

Thread Thread
qm3ster profile image
Mihail Malo

I think they mean that is syntactically/semantically looks like just a global function (even it if is not implemented as such in node).
In fact, that's what it was in web commonjs.

Collapse
andreespirela profile image
andreespirela

It does support it. Deno standard library has support for β€œrequire”, deno.land/std@0.73.0/node

Collapse
vonheikemen profile image
Heiker

About the package ecosystem issue, a CDN like jspm.dev can help you with that. This is the description jspm has on their site.

jspm provides a module CDN allowing any package from npm to be directly loaded
in the browser and other JS environments as a fully optimized native JavaScript module.

So the packages that you could use with deno increases dramatically.

Collapse
bias profile image
Tobias Nickel

i really worry, that deno could split the community, and we end up again having to support multiple platform.

deno is a nice demonstration of how node could be better. faster script startup, better security model.

but when my first point comes true, this downsite will be much bigger.

Collapse
andrewbaisden profile image
Andrew Baisden

In a few years maybe it will see a higher adoption. But in the short term no because even now many companies are still learning how to integrate Node into their tech stack. The MERN stack is still fairly modern by todays standards.

Collapse
maxdevjs profile image
maxdevjs

Hopefully will not be the case, but I wonder if they will manage, at some point, to do something as with io.js.

Collapse
qm3ster profile image
Mihail Malo

What do you mean?

Collapse
qm3ster profile image
Mihail Malo

How can you make portable modules for web and deno with ES modules?
Only using the async dynamic import?

export default (amBrowser ? import('peepee') : import('poopoo')).await

Some comments have been hidden by the post's author - find out more