Echo JS 0.11.0

<~>
tracker1 1621 days ago. link parent 2 points
You do realize that when node started, there was no clear package mangager, and beyond that it was local only at the start.  Also, there is absolutely nothing stopping you from creating a build system that separately pulls resources.  Most modern package managers are http.  Also, git ui offers something more immutable.  And Deno caches remote modules, so you can still build, much like any other package manager when offline.

Personally, I'd like to see one of the package managers offerred so far rise to the top... but there's nothing wrong with creating something that works and letting people use it.  Don't let perfect stand in the way of good.

As it is, I'm not actively using Deno at the moment, but have considered looking deeper into it.  I'm curious how light of a containerized app I can get with Deno vs. Node.  As it stands, the points of integration can get wonky.

I'm also hoping that FFI gets baked into Deno as it never was with Node (node-ffi notwithstanding is not baked in). There are very few reasons to use FFI in practice, especially with good wasm support.  Multi-process SQLite access probably the most prominent example of a clear need for FFI, but I struggle to find more.

While I don't agree with all of the choices with deno, it's clearly developed with the hindsight from node's shortcomings, and there are many.  NPM in particular has one massive shortcoming, in that it's very easy to create bloated use.  Multi-tiered versions of packages combined with module vs commonjs entry points gets very bad.

On the one hand, I get it, npm won in the node sphere and in JS overall... it's what allowed the massive growth of the JS ecosystem as a whole.  That doesn't mean it needs to be carried forward.  Of course, if you look at the Python 2-3 migration, this is probably going to be a similar shift, if it happens at all.  Node and Deno will coexist for at least a decade most likely.

Replies