Hacker News Reader

Comment by mircerlancerous | Hacker News Reader

Sounds like the presenters are assuming that everyone must be using JS in the same way they are. As someone who prefers to work in VanillaJS, I'm already frustrated by all the language changes being forced upon me. So maybe I agree with them that fewer changes should be made, but for completely different reasons. I'd rather them work on API improvements so that web apps get closer to parity with native apps. All this other talk is pointless while web apps remain second class IMO

View on HN

What do you mean forced upon you? There is no requirement for you to use new features. If you do, it’s because you or your team thinks it’s more convenient — and it really is! map, filter, arrow functions, scope improvements with const/let, etc. are major language improvements. So is null coalescing and optional chaining. You don’t have to use them, but they do make JS more straightforward to work with.

I think "forced upon" could also read as:

- at work they expect me to write code with the latest features

- my colleagues write code with the latest features and I have to review/extend/build upon using the same style

- the community, books, copilots, LLMs, libraries, tooling are "forcing" all that new stuff upon me

- etc.

As a dabbler in JS, it jumps out to me that a lot of tools are trying to force ESM, despite the fact that they lack many essential features that other module systems have.

Which features?

Conditional imports (e.g. depending on browser-version, browser-vs-server) is the big one. This does not inhibit the alleged static analysis goal at all, but the specification is pointlessly hostile to it. I would've expected the "import assertions" proposal to cover this obvious problem, but no, it's just another useless thing that will always have to be transpiled into nonexistence.

Transparent polyfills (or anything that really needs to be loaded "first") also don't work, since async means you can't specify the order to load things. This means that every single module you write has to explicitly mention which exact polyfill it's going to end up using (hope you don't accidentally skip one or specify a conflicting polyfill) ... or you just abandon modules and load your polyfills with a normal script (which means that now your source is a bastard mixture).

Lazy imports are technically possible via dynamic imports, but unnecessarily annoying and break in all sorts of places. Granted, the standardization of the "leaky browser abstraction" makes this pretty awful regardless.

I think the proposal is actually good for people like you.

You can choose to just work with the core and maybe a minimal sugar library. Which will probably be faster and don't include "all the language features that were forced upon you".

This is not what happened in C vs C++.

Reply on news.ycombinator.com