Hacker News Reader

Comment by z3t4 | Hacker News Reader

Node.js module system (kinda like CommonJS) is what made Node.js popular. ES modules while taking away features like scoped module support and dynamic import, it's very complicated and allows bad practices like include files.

Promises are very complicated compared to first class functions. What makes JS/Node hard to grasp is that it's async. Async is an (often unnecessary) optimization, with tradeoffs.

Loading modules from URL's is a cool concept! ES modules helps here, but you could also have a package-list file that lists all dependencies of dependencies as well as download mirrors, or hashes with peer-to-peer distribution.

A permission system is nice, modules should not have system access by default.

Not everyone wants to use TypeScript. It will probably become obsolete once optional type annotations gets added to JavaScript.

An opinionated toolchain is nice, but should be optional IMHO.

View on HN

ES Modules have dynamic imports (https://github.com/tc39/proposal-dynamic-import). The proposal is at stage 4 and is available from Typescript 2.4. We're on version 4 now so I'd expect Deno to have it.

I'm not sure what you mean by "bad practices like include files" so I can't comment on that.

I've found most Javascript developers prefer the await syntax with promises to using callbacks. It gives the code the appearance of being synchronous with the ability to do things more asynchronously if you need. I haven't encountered many who actively prefer the callback style. It gets unruly fairly quickly.

I can't see optional type annotations ever being added to Javascript. They would have to be checked at runtime which isn't something I'd imagine browser vendors wanting to implement.

The feeling that I get is that the standards committee is trying to bring Javascript to be the best dynamic language it can be and if people want more comprehensive guarantees then there are excellent tools like Typescript which give that option.

The fact there have to be multiple implementations of the standard in the various JS runtimes makes it a hard sell to evolve Javascript too far.

Really like async await. The only case ive found for callbacks is for the top level function call in a script. Calling ".then()" is useful since top level await is still not a thing, and may never be.

Top level await is at stage 3: https://github.com/tc39/proposal-top-level-await

Its in Typescript 3.8, Node 14.8 and probably in your Babel setup. I probably wont get to use Node 14 in prod for a while but I get by with a `main` function that has everything in that gets called at the bottom.

It's important to remember that while, yes, CommonJS made Node popular, it did so because it filled a void in the Javascript syntax and specs. There was nothing to formalize the concept of a "package" back then.

That's not true any more, ES Modules have made it into the spec, so that's what Deno is using.

As for package-lists, the current convention in the community at the moment if you have a decently sized library is to have a `deps.ts` file where you re-export all of your dependency, making it an equivalent to package.json and helps with upgrading dependencies across a codebase.

TypeScript is already optional in Deno! it will run any .js file just fine, and you even skip the compilation part.

> Not everyone wants to use TypeScript.

You don't have to use TS. Deno runs plain JS, too.

> [TypeScript] will probably become obsolete once optional type annotations gets added to JavaScript.

What makes you think that type annotations will be added to JS? I think it's far more likely that browsers and other runtimes will natively support TS as a separate language rather than JS evolving to become TS.

> An opinionated toolchain is nice, but should be optional IMHO.

It is optional. You don't have to run deno lint, deno fmt, deno test, etc. But at the same time, they are pretty good tools so you might want to try them.

> What makes you think that type annotations will be added to JS? I think it's far more likely that browsers and other runtimes will natively support TS as a separate language rather than JS evolving to become TS.

It has already been tried with Dart. Dart was made because JS lacked a type system, preventing further optimisations. Support for Dart was added in Chrome.

Another popular JS transpiler is CoffeeScript, most of it's syntax is now in JavaScript.

I have no data to prove this, but I feel like TS is far more widely used than CoffeeScript and Dart have ever been.

Support for Dart in Chrome was added before Dart was popular (if you can even consider it popular at all). Since TypeScript is already popular now, I think if Chrome added support for stripping the types and running TS code as JS, most devs would welcome that.

Reply on news.ycombinator.com