[osrec]

I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring.

I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment.

I'll be watching Deno very closely these next few months!

[tannhaeuser]

The set of core libraries like express (fka connect) + dependencies is the stdlib. It was developed in early node.js days as part of CommonJS, which was an initiative for a portable/modular server-side JavaScript runtime with many implementations besides node.js (RingoJS, Narwhal, Helma, TeaJs/v8cgi). The existence of a community-driven lib effort, the portable nature of JavaScript, and the existence of choice was the entire reason I even looked into node.js.

[jfkebwjsbx]

Other languages had all that, plus a better standard library, plus a type system, for years before Node was a thing.

Node got popular because it enabled frontend devs that only knew JavaScript to move easily to backend, not any technical reason.

[Lunrtick]

I definitely agree, the insane dependency chains really make me uncomfortable.

However, not every project will involve pulling in such crazy stacks. I recently experimented with Hapi + TypeORM. Hapi's core goal is to use only what they directly maintain, and I think it works really well! Node_modules is still not tiny, but it's at least an order of magnitude better than what I'm used to.

[brabel]

Deno is great ! It makes it possible for us to write TypeScript and execute it really fast, without a build system to worry about!

The only thing that, to me, is a big problem, is that, even though you have types in your TS code, you're basically throwing them away at runtime, wasting huge opportunities for optimisation that even the V8 can't recover. If V8 had support for strictly typed TS code, can you imagine how fast it could get it to run?! I think that's the next stage in the evolution of JavaScript/Node/Deno: Node -> Deno -> Done.

[osrec]

I'm no expert on compilers/interpreters, but wouldn't the added overhead of type checking cause things to slow down (genuine question)?

[brabel]

No, because it does the type checking already: it just fails to keep the type data into the runtime, which could be highly optimized if it had types. V8 apparently "generates" types on-the-go to make JS run fast, so if it had pre-built types it could already run the faster version of the code from the start.

[osrec]

Ah, understood. So, almost like Java compiling a class to bytecode before running in the JVM?

[brabel]

Yes, something like that. Interestingly enough, Dart has a mode to compile to the AST, so that when you run it, the interpreter does not need to parse the text again and check the types, it just starts straight off an AST. The TS compiler and V8 could definitely do something similar.