So, you're trying to learn JavaScript. You have just gotten a bit fluent with JavaScript in the browser. Then all of a sudden, you come across Deno...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Thank you for explaining this so well! I have a well-documented hatred of Javascript, and Node beyond that, but you've just made me genuinely interested — and yes, a little excited — in seeing what happens with Deno and the JS landscape now. At last I understand what the hype with Deno is about!
I still won't use any of it. JS gives me hives, though I own that as largely my subjectivity. But now I care about this, and that's a miracle in and of itself, ha ha.
So happy that you liked it!
I haven't tried deno yet but it seems like it doesn't have a single place where all of your dependencies are defined? That used to be package.json but they didn't replace it with anything? It's useful information to see a list of all dependencies of a project instead of having to check through each file to get this information.
Yes, Deno does not mandate a single file to list all your dependencies because that would require something like npm to assist that standard. But Deno tries to stay away from the idea of a single entity having control of all of the ecosystem. Deno is a javascript runtime and only a runtime.
For more info, check out this section of deno manual:
But this creates a problem for package authors who don't have a single place to distribute their packages. Deno authors have a system in place to make up for that, deno.land/x which is just a proxy to GitHub. If you want a more decentralised and immutable (you don't want another left-pad incident, do you?) platform to publish your packages, there is nest.land which is a platform independent package registry.
I would highly suggest you try out Deno. It's a step in the right direction. Deno actually prioritises using browser APIs instead of creating custom ones. This unifies the javascript ecosystem to some extent as now it is divided in server-side and client-side javascript, which look and work differently.
Awesome post I read every line
I did the same. Thank you for taking the time to fix the issues that node and the patches to node to make it work "better" introduced by creating deno
Thank you so much!
Uh... leaving aside the fact that the actual JS execution is done by V8, which is a) the same as Node and b) written in C++, so really there'll be very little meaningful speed difference - I think it's highly implausible to say Rust is "much faster" than C++, and I say that as a big Rust fan.
Agreed and fixed.
From what I have learned so far, Rust is more secure and throws error in compile time unlike C++ which does so in the runtime. This results in developers writing less explicit checks and achieving the same results.
It takes time to perform a check and also increases the binary size when compiled. Rust eliminates such cases while compiling so you don't have to perform any checks at runtime. The speed that comes from reduced runtime checks is what I was talking about, not the raw performance.
Please correct me if this is wrong.
Rust still performs runtime checking -
(vec![0, 1, 2])[3]will throw an error at runtime (even in release mode!), so it doesn't remove all checks. Rust's claim to fame is memory correctness; if the code compiles, the executable is free of memory and concurrency bugs without any garbage collection, however there is still a runtime to Rust (like C and C++).You don't choose Rust because it's fast. You choose Rust because you want to get as close to the "if it compiles, it works" utopia. Which is paramount for critical software like Deno.
Every piece of line is so informative. Well written!!
I now believe in DENO = Destroy Node :D
I still don't get it. You get rid of node modules, and replace it with... Global folder for cached modules? So, basically you just moved node modules folder out of your project folder.
Next, module reusability between projects. Why? Every modern project I've used relies on docker containers or something similar, so there's no reusability, ever. And if you run the app in the cloud, it will, most likely, use a dedicated compute unit for that one app, which just takes this "killer feature" and throws it out the window.
Making deno require access to everything seems cool at first, annoying at second thought. Like, why? Why do you want to limit it to a local folder only? It looks like a sandbox. My little private sandbox... Because js is so unsafe you have to build a bunker to run it?
By the way if it needs permissions to access anything, how many permissions does it need to grab a url with an external module? One, to connect to internet? One, to connect to locally cached file or two, to do both?
To me de-no so far seems not like "destroys node" but more like "node backwards". Hopefully it will grow from this point into something i can pick up and use for a corporate environment because it provides some killer features node simply doesn't have, instead of just trying to be different.
There's one killer feature i see so far - running type script natively. But, at the same time, I don't use TS. Not yet, at least.
I wonder which one happens sooner - deno getting some great use cases or node getting native TS support with debugging out of the box, with no transpiling necessary.
I also wonder if deno can be used as a sandbox for resources that run your js code for testing purposes, like jsfiddle or leetcode. You write your TS code in a web page and it executes elsewhere. Seems interesting to me personally - I won't have to install it locally and will have a chance to run the fiddle without transforming TS to js. Can it be used like that?
Exactly. Yes it doesn't help with deployment but it does help while development.
The fact that Deno allows you to run and install scripts from anywhere on the internet makes it necessary. This probably wasn't the main reason it was made for. Yes it is annoying but you can eliminate that with makefiles or velociraptor (Deno's solution to npm scripts).
One other use case would be if you are working on a project that handles sensitive information, you want to have control over what the project can do. This ensures you don't leak anything during development and you can work with more confidence.
Deno doesn't need permissions to download and cache modules or to access the project folder. To do anything outside project folder, you need to give explicit permissions.
There are already online Deno playgrounds popping up. I can't recall at the moment but check out the discord server, they will definitely know many of them.
Thanks for spending time reading my article.
Indeed informative, thanks for sharing!
You're welcome!
I'm hopeful the ecosystem will grow like it must for this to really thrive, still the core reason to use Node. Super exciting, thanks for the full explanation!
If you're looking for a web server framework for Deno that is well tested and documented, try Pogo.
github.com/sholladay/pogo
Thanks you for this nice post.