Deno just hit 1.0, for anyone out of the loop can we summarize what it is and what it means?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Plain Javascript Refresher for those feeling left behind or not knowing where to start w/ Functions, Arrays, Loops, JSON & NoSQL
Rick Delpo -
5 reasons why I love Daisy UI
Anjan Shomodder -
react-native duplicate class problem
mzakk -
The mysterious supply chain concern of string-width-cjs npm package
SnykSec -
Top comments (39)
A javascript runtime that essentially restricts all access unless explicitly provided by the user. Also, it has typescript support out of the box. Also, it essentially decentralizes package sharing by using URLs for retrieving javascript codes (just like we do by using script tags in the browser).
It seems, and apparently is (based on Ryan Dahl's presentations), like a do-over of Node by learning from its mistake.
However, there are large code bases written in Node, and since Deno does not try to be compatible with node, it would be interesting to see how or if the transition will happen.
I wondered about that last point myself. No doubt there will be projects that can take advantage of Deno, but the Node ecosystem and market share are huge. It would take a long time for this kind of transition to happen.
The above is from the introduction page of Deno. So, maybe Node and Deno won't compete but co-exist. Deno seems, at the moment, focused to make CLI apps generation easier, or at least that is what I gather from the above quote.
That sounds interesting.
Also, I realize you have to explicitly give Deno certain permissions at runtime, but I'm skeptical of the idea of using ES module imports with third-party URLs for server-side code. Maybe I just need to read up on that...
Yes, I think that will be addressed in some way as the platform matures. However, researching before using a third party package/URL is a must. So, we need to ensure that we only use those packages that we absolutely trust.
The other issues have been solved by the Deno team already. Mainly, importing the packages and exporting them; this ensures that we know the packages that we are using and that we use only single version of any library/package. Next, the Deno automatically caches code the first time we install dependencies, so our software won't break because of change in code from the URL. We could also version control our dependency if we want.
Chill.
Yeah. Interesting times. Can’t wait to see how it all plays out.
Ryan Dahl (the creator of Node.js) did a talk about thing he regrets about Node.js. The post and comment below summarize the talk.
Deno was created to help address those issues. Since Ryan Dahl is a proven creator and the issues it is trying to address are things that have caused problems in the Node ecosystem, it has organic word-of-mouth around it as a real successor to Node.js.
10 Things I Regret About Node.js
Nick Taylor ・ Jun 7 '18 ・ 1 min read
The goal of Node was event driven HTTP servers.
5:04
1 Regret: Not sticking with Promises.
* I added promises to Node in June 2009 but foolishly removed them in February 2010.
* Promises are the necessary abstraction for async/await.
* It's possible unified usage of promises in Node would have sped the delivery of the eventual standartization and async/await.
* Today Node's many async APIs are aging baldly due to this.
6:02
2 Regret: Security
* V8 by itself is a very good security sandbox
* Had I put more thought into how that could be maintained for certain applications, Node could have had some nice security guarantees not available in any other language.
* Example: Your linter shouldn't get complete access to your computer and network.
7:01
3 Regret: The Build System (GYP)
* Build systems are very difficult and very important.
* V8 (via Chrome) started using GYP and I switched Node over in tow.
* Later Chrome dropped GYP for GN. Leaving Node the sole GYP user.
* GYP is not an ugly internal interface either - it is exposed to anyone who's trying to bind to V8.
* It's an awful experience for users. It's this non-JSON, Python adaptation of JSON.
* The continued usage of GYP is the probably largest failure of Node core.
* Instead of guiding users to write C++ bindings to V8, I should have provided a core foreign function interface (FFI)
* Many people, early on, suggested moving to an FFI (namely Cantrill) and regrettably I ignored them.
* (And I am extremely displeased that libuv adopted autotools.)
9:52
4 Regret: package.json
* Isaac, in NPM, invented package.json (for the most part)
* But I sanctioned it by allowing Nod's require() to inspect package.json files for "main"
* Ultimately I included NPM in the Node distribution, which much made it the defacto standard.
* It's unfortunate that there is centralized (privately controlled even) repository for modules.
* Allowing package.json gave rise to the concept of a "module" as a directory of files.
* This is no a stictly necessary abstraction - and one that doesn't exist on the web.
* package.json now includes all sorts of unnecessary information. License? Repository? Description? It's boilerplate noise.
* If only relative files and URLs were used when importing, the path defines the version. There is no need to list dependencies.
12:35
5 Regret: node_modules
* It massively complicates the module resolution algorithm.
* vendored-by-default has good intentios, but in practice just using $NODE_PATH wouldn't have precluded that.
* Deviates greatly from browser semantics
* It's my fault and I'm very sorry.
* Unfortunately it's impossible to undo now.
14:00
6 Regret: require("module") without the extension ".js"
* Needlessly less explicit.
* Not how browser javascript works. You cannot omit the ".js" in a script tag src attribute.
* The module loader has to query the file system at multiple locations trying to guess what the user intended.
14:40
7 Regret: index.js
* I thought it was cute, because there was index.html
* It needlessly complicated the module loading system.
* It became especially unnecessary after require supported package.json
15:28 Talks about Deno.
I wrote this a while back, but I think it needs to be said:
I can't support Deno until the project adds an explicit Code of Conduct and address the problems they seem to be having with diversity and inclusion.
What are these problems you speak of?
There have been multiple attempts to add a Code of Conduct to the deno core repo.
This one, in particular, has some incredibly egregious anti-diversity rhetoric. The core maintainer (Ryan Dahl) has basically taken the approach that a CoC isn't needed outside of a link to what "being professional" means, where the README links to the Rust CoC. The general lack of enthusiasm for a CoC and the attitude that "unnecessary" files clutter the core repo (with a CoC being unnecessary) does not inspire confidence that they would be willing to enforce a CoC at any point.
Until there is a serious change in that policy and clear examples of them enforcing a CoC, I can't recommend the project in good faith.
My lack of experience with an open source project may be a handicap for me here but what does having a CoC have to do with a piece of software being good and a good fit for someone's project?
If a piece of software solves a problem well, what does any of this other stuff matter?
This is common anti-diversity rhetoric and a common point of confusion for a lot of folks. Let me try to explain it.
There is a real, tangible question as to whether a piece of software can solve a problem well if the people who built it are a homogenous group. Diversity breeds innovation and lack of diversity leads to products that usually cause more harm than good.
Having a CoC protects people who are typically minoritized and abused by the majoritized group. Enforcing a CoC ensures that everyone can contribute to a piece of software, which in turn creates better software.
In the same way a linter is essential to keep up code quality standards, a CoC is essential for enforcing quality standards on human interactions.
This is goobledygook.
There are no "real, tangible" questions about the ability of software to solve problems aside from the software actually solving the problem. The software offered either provides a solution or it doesn't. Being an all-female software team, say, developing a framework like Deno has no bearing on whether it can be used by men.
What exactly would be the code paradigms used in such a framework, written by an homogeneous group like women, that would prevent men from fully implementing the framework?
I'm going to admit I'm not following the logic with that.
Now, if when you say "homogeneous" you're talking about the whole team having very similar thoughts and ideas, I could see the logic. However, unless you got very good evidence to validate the claim that the whole team has the same train of thought and values, this sounds like baseless assumptions.
If you mean "homogeneous" in the sense of arbitrary physical and personal traits (gender, romantic preferences, etc), I don't get what that would have to do with the team having a diverse spectrum of views and values.
I'm still not sure I understand the real significance of a CoC. Its not like its law, nothing holds ANYBODY to uphold it.
I don't really see what would be wrong with, I guess, a simple CoC that just says something like:
Yes. Some common sense.
It's a pity that we bring our own personal hurt and pain, and cover it in pretend help.
Not to get too meta here, but is there, like, a Code of Conduct for Codes of Conduct?
Oh boy, oh boy. I explicitly signed up, just to say, that I support this project BECAUSE it doesn't add that seed of political correctness, that can infect a project.
I mean, you're wrong and this comment proves exactly why a CoC is important.
I'm unfamiliar with the CoC in OSS. Please explain why it's needed
Some guy made a toy for kids who like playing in the "back". It became so popular and widely played that when he realized the flaws in the first version of his toy, he moved on to make another toy instead. This one is more secured so kids don't get hurt while playing. It uses the same mechanism used in toys for kids who like playing in the "front" yard, to connect toys together. It comes with other cool features and now kids who have the first version are questioning themselves should they move on too.
Now, this is someone explaining it like he's doing so to a 5 year old.
None of the explanations are 5 years old kid friendly 😆
Browser Compatibility
Deno's API is built to follow the browser's API. This means that developers can easily go between the two. It's also a big gesture to align with the Web Standards. Rather than invent something different. Deno supports the web community by building on top of it
Decentralized Packages
Using URLs for packages also aligns with the web. URLs are what the web is built upon. So it makes sense to align with that also. Plus the GoLang community uses this method. So it's battle-tested.
Breaking Change From Node
Deno offers a similar development experience but with the opportunity to start fresh. The community has matured a lot since Node.js was created. All that experience can be brought into Deno to make better decisions for the future.
Mascot
Deno the Dinosaur is cute. That's +1 over Node.js ;)
Also, just to be clear. I love using Node.js. Just excited that Deno builds on what was amazing about Node.js and makes it even better.
One problem with using url for importing package is that it mix the concept of package location and package name (where it being referenced in the code). You'll start discover this problem when you want to change where the package come from (for example you have to fork some package into your own repo) but don't want to change the source code to refer to the new location.
In Python for example, where package name and package location is distinct, I just need to tell the package manager the new location of the package. In the code that referencing the package I don't have to change anything as it still the same package name.
Go has been suffering this since the beginning and only recently came out with mechanism on how to handle this.
This seem to be solved with import map but for now it still unstable feature.
deno.land/manual/linking_to_extern...
"OK Johnny we all had a talk and decided to take the bullets out of your toy gun. Because they are sharp and you were hurting the other kids with them, you see? Now please hand it over. Johnny, no, don't point it that way. You put that down right now."
I like to think Deno is the answer to the question "what if new versions of node didn't have to be backward compatible?" and just a tiny pinch of the "let's rewrite it in Rust" trend.
And it was done in Rust. As should be considered for all performance sensitive green-field "system" software.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.