Echo JS 0.11.0

<~>
cojack 1588 days ago. link -2 points ▲ ▼
Focus on Deno? Are you serious? The ridiculous idea behind importing packages by http(s) resources is not acceptable to any statement. This is not predictable, in any case, you don't have control over what you have, there is no possibility to build it and run without access to the internet. You have to base on 3rd party external resources like github private accounts that can be deleted. Totally pointless.

Even more, because Deno take a path to not be compatible with node core packages, everything put in one "namespace", it's even more pointless to put your effort to write yet another piece of code to support another platform.

For now, definitely NOT. If author will change his mind about package manager and core packages grouping, I will might consider it as something to take a look.

Replies

tracker1 1583 days ago. link 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.
Soremwar 1588 days ago. link 2 points ▲ ▼
The fact that you can rely on non-immutable sources in Deno doesn't mean that you should. There are services like nest.land or NPM that provide immutable access to the modules that you need, so registry is not a concern (which is a dumb concern nonetheless, you download thousands of modules everyday through you browser and I guarantee you that less than 000.1% of the time this process results in a failed request, in fact I'd say NPM is just as reliable).

Second, we have multiple ways of using modules written for Node. Node modules are just JavaScript modules ofuscated by CommonJS syntax, and there are services like JSPM and PIKA that transform this syntax directly from NPM (versions, notes and TS types included) into JavaScript for our use anywhere.

Overall I'd say you have a big misconception of how Deno works and that's why you declare it as a loss of time. Perhaps trying it out first before shouting out statements like that?
cojack 1588 days ago. link -1 point ▲ ▼
This is lost of time to talk it here about it. Like yet another internet war between foo and bar. Im out.