The Beginning of the End ? Deno vs Node.Js
Creator of Node.js regretted !
Yes you heard that right , But WHY ?
Ryan Dahl creator of Node.js thinks he made number of mistakes while designing Node.js
Lets see what are those mistakes
- Not sticking to promises: Promises are the necessary abstration for async / await
- Security: In Node.js program you have access to all sorts of system calls
- The Build System GYP: Which was later dropped by Chrome but Node continued using it.
- package.json:That made Node.js dependent on NPM ( Privately controlle repository) and Concept of modules directory of files to look into
- node_modules: Heaviest object in the Universe It complicated module resolution algorithm
- require("module"):without .js extension Not a JS type of thing index.js,this Needlessly complicated Module loading system just to look fancy.
Ryan Dahl came up with a solution to Node.js Problems
DENO: A SECURED runtime for JavaScript and TypeScript
- Built in Rust language
- Uses V8 Engine
- Tokio
- Supports TypeScript out of the box.
Ships as a single executable file with no dependencies.Yup, No dependencies to be installed
Secured by default. No file, network, or environment access (unless explicitly enabled).
Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).
Bundled into a single JavaScript file.
Node.js vs Deno
Lets see how it fairs against Node.js
- Deno does not use npm
- It uses modules referenced as URLs or file paths
- Deno does not use package.json in its module resolution algorithm.
- All async actions in Deno return a promise. Thus Deno provides different APIs than Node.
- Deno requires explicit permissions for file, network, and environment access.
- Deno always dies on uncaught errors.
- It uses "ES Modules" and does not support require(). Third party modules are imported via URLs: For eg:
import * as log from "https://deno.land/std/log/mod.ts";
Remote code is fetched and cached on first execution, and never updated until the code is run with the --reload flag. so this will allow it to run later even if you are offline
Modules/files loaded from remote URLs are intended to be immutable and cacheable.
Deno Installation
Now lets see how easily we can install Deno
Run following command on terminal
Shell (Mac, Linux):
$ curl -fsSL https://deno.land/x/install/install.sh | sh
PowerShell (Windows):
> iwr https://deno.land/x/install/install.ps1 -useb | iex
ref: Deno.land website
Now lets build the HelloWorld !
Create a welcome.ts file and add basic javascript code
console.log('Hello World!');
Run from command line
$ deno run welcome.ts
Hello World!
You can run programs from URL directly without even downloading it.
$ deno run https://deno.land/std/examples/welcome.ts
Isn't it that simple ?
Would you like to have a detailed video on React + Deno with a functional CRUD Operation ?
Please comment.
You can find video on this Deno vs Node.js: The Beginning of the End of Node.js
Also you can more tutorials on Deno
Deno js Tutorial: Installation, HTTP Server, Deno Routing, Deno MySQL & Deno Rest API with MySQL
Deno Installation
How to Run HTTP Server on Deno ?
How to do Routing using Oak Middleware on Deno ?
How to connect to MySQL Database in Deno ?
How to build REST API with MySQL on Deno ?
Top comments (14)
Deno is cool, but after playing with webassembly and working a webdev internship with a python backend Im curious if the future of JS will come to expiration soon
Python, no doubt is a great language but it is more like what is more suitable for your requirements ? and which defers case to case.
The decision not to support npm and the existing huge collection of npm packages makes it seem unlikely it will be a serious choice for some time to me. Feels like it lacks a killer feature - the closest it has is native TypeScript support - but hmmm, not sure that's actually very compelling.
heh, your evaluation criteria seems freelancer focused. Node/NPM is a black hole security wise; Typescript shouldn't optional (though I dislike Angular's approach) and have I mentioned the security problems (cause they're a big deal)?
Well I'm not a freelancer and I spend a great deal of time on security considerations and pen tests as it sounds like you do :) I'm happy with the balance we have now between security and accessibility of modules to speed development. If deno becomes a thing then the security is a significant improvement I grant you, but not sure how having potentially multiple versions of different modules sub referenced is going to help?
Typescript - already doable is my point. Out of the box is nice.
By me,this is the bigest improvement in security,npm registry allows to much unchecked modules.
I'm very intresting by the technology behind Deno and the learning of TypeScript, but I think package.json and the NPM library is not a very bad thing, it's very helpfull when you need something and you don't want to loose 5 hours to search about it!
me too, problem being "we have a security department" and "I work at a power utility". Ain't no flippin way anyone wants that black hole on our internal network (interns do bring it up, often .. like we don't know it exists :-).
Yeah of curse it's understandable!
I think it's good to start track this tech from it's birth I will say in the next 5 years it will be a thing.
Absolutely right, its in early stage but has great potential.
The differences you've pointed out are almost entirely "require" vs "include".
The latest node supports es6 modules natively, which mostly closes this gap.
So, other than typescript, it's hard to see any illustration here of any difference that actually matters.
I'd work on making those differences which matter more clear, to support your argument.
The npm eco system is a poisonous snake in the grass next to the poppy fields of free software.
Makes me love the Laravel backend ecosystem even more! Would never build a backend for a web app on Node or Deno for that matter!