Node.js is certainly not dead, but the hype is over. As of 2019, all of Node’s innovations (non-blocking I/O, same language on front-end and backen...
For further actions, you may consider blocking this person and/or reporting abuse
Interesting article! I must say, I'm on the other side of the fence though. Whilst I think it's interesting and worth developing, I really don't think that it's worth getting too excited about just yet. Yes there are some things, such as native TypeScript support and a secure runtime, but I personally don't think that there's enough features that differentiate itself from NodeJS.
NodeJS also has an exorbitant amount of modules behind it, that won't work out of the box with Deno. There is such a reliance on these modules, and it's impossible to expect developers to rewrite their modules for Deno. Module development won't be at the same rate of Node modules, as Deno is directly competing with Node, no matter how you put it. When NodeJS was coming about, there was no JavaScript runtime that runs on the command line, which allowed it to fill a hole and gain support very quickly. Deno on the other hand doesn't have the same advantage.
Deno does, however, have such an advantage in terms of Information Security. And, in that case, it has not so much a hole to fill as a gaping, Nietzchean abyss, complete with the staring back at you if you stare at it too long.
Would you be able to elaborate on the information security point? As far as I'm aware, Node is relatively good when it comes to security, aside from the permission aspect, which isn't a feature in many programming languages
Looks like you don't need me to expand on it. It's the permissions aspect. It's telling of the broken state of the modern web, and just general incompetence of engineers, that this is all it needs to be "ground breaking." And I'd like to get in touch with the Deno creators for ways to expand on it based on some more such "ground breaking" (does the obvious thing no one is doing) research in security focused languages like those used in Secrets Management, Encryption as a Service, and CryptoCurrency scripting.
"The hype is gone" - hehehe, like hype was important in my decision making process. ;-)
Deno doesn't have official semver support. I can only imagine the headaches that will happen on large Deno applications. Semver reduces problems. Deno is behind in that regard (similar to Go). Sure some people are trying to make semver tools, but these are community-based and non-standard, so things will be fragmented within Deno in terms of dependency management.
The example literally showed semver being used, I have no idea what you have against deno.
The URL used in the examples has some numbers in it that look like semver, yes. But Deno itself does not have any notion of semver; it does not have a tool that reconciles dependency versions based on version ranges like Node.js has (npm and npmjs.com).
Npm has algorithms that automate the process of handling version mismatches. Deno does not.
Any semver-related tooling that currently exists for Deno, is not official and not baked into the foundation of what Deno is in the way that NPM's version handling has been baked into the foundation of Node.js since the beginning with forethought of the problems it would solve.
In Deno, a developer is going to eventually indirectly import dependencies that are the same library, but from different URLs (maybe only the "semver" numbers in the URL will differ) and end up with unnecessary duplicates of the dependency with no clear way on how to handle the situation. That won't scale as well as an official versioning system would. GoLang has had the same problems.
I proposed in Deno's chat room that perhaps Deno's package registry (deno.land/x) should officially support semver in some way, similar to how unpkg.com has support for semver ranges, but the idea was taken lightly by the team (at least it didn't seem like something important to them).
Permissions are really an obvious thing in hindsight and often ignored or missing. So this is really great to see.
I have a hunch that it'll supersede Node eventually given a better foundation for a runtime.
I also wonder how this could affect Electron or a future Electron-like.
I mean, this is going to be fun when webpages go down and apps stop working (new deployments). That aside, Deno looks good
Why? The same could happen to GitHub or NPM if they go down as well.
Mind that:
Yeah I know, about the reload, that's why I said new deployments. Concerning the NPM going down, yes, it would happen, but it's more probable that an individual shutdowns their website (for any reason) than a corporation
What are your Thoughts About Deno???
Deno is still not production ready :( I think so
Nice article!