Hacker News Reader

Comment by pavlov | Hacker News Reader

ES modules work natively in browsers, which are the slow-moving ships of the ecosystem. Changing course for them is completely unrealistic.

There’s a billion browser clients out there. That ensures that whatever API they ship, an increasing amount of code will be written directly against it. Everybody else just needs to adapt or be seen as incompatible with the baseline of JavaScript.

View on HN

Show me a real product on the web that does not compile or bundle and uses native modules for code delivery. It's a dead technology that only fragments the ecosystem and makes life harder.

The web is not just for "real products". It's also a platform with tens of millions of hobbyists and dabblers writing HTML and JavaScript.

I promise you they will use any feature that's documented on MDN as being available in all browsers. And ES modules do make life easier for someone who's just writing HTML and JS and doesn't know anything about build tools.

IMO, it's the wrong attitude that we should focus on the professional ecosystem and forget about this use case. Probably most people writing front-end code got their start by creating a HTML file in Notepad (or equivalent) and loading it via file:// into the browser.

Well, that's what I'm talking about. These web standards are not for real use, but for idealists who do not develop real products. And because of their idealistic desires, we ended up with a fragmented ecosystem and made the life of developers more difficult. Good job.

By 'real product' you mean yet another generic 'web app' that does the same as other hundred generic 'web apps' but its marketing team says differently?

By 'real product' I mean real existing product in real world, not in the fantasies of native_js witnesses.

It's a great development experience today: no waiting for bundlers, easy inner dev loop, let the Browser do all the loading just like Web 1.0 and JS development was maybe supposed to feel.

It will become more common in products. There are going to be startups that see that great development experience and long for some returns towards "just FTP it to the web server as-is" CI/CD processes. There are going to be more product owners everywhere (startups, Enterprise) that think that HTTP/2+ adoption (or even HTTP/1.1 properly configured) is acceptable in the real world and that they are done with most of the needs for bundling.

Ah, no bundlers, no minification, no types, a dream! So, real product example pls? And how you templating your html? Not JSX, obviously, so, string literals?

Personally, I'm doing no bundlers (of my own code) and no minification in my development loop, but still using types with tsc --watch. Typescript is faster the closer it gets to just "type stripping" (where the target and module formats are both something like `es${currentYear - 2}`, especially in the default emit pattern where the JS files just get output side-by-side the TS files they input). TSX to JS transformation, with Typescript (as the only tool in that chain [0]), isn't much extra work to slow it down. (TSX is a pretty easy transformation from its syntax to simple function calls. The hard part of TSX is getting types right.)

[0] So no Babel, only Typescript. You probably don't need Babel in 2024.

(ETA: I've even documented this development pattern for a library I built: https://worldmaker.net/butterfloat/#/getting-started)

I was also reminded that I blogged about all of this back in March, too: https://blog.worldmaker.net/2024/03/13/node-packaging/

Web components.

So, mix of HTML, inline html strings and bunch of .querySelector() with DOM manipulation? I see.

Many bundlers output module format - it makes features like code splitting (chunking into separate files) convenient.

ES modules mean you don't need to bundle your code; you just include your index.js in HTML, and all 30,000 JS files of your project come to the user's browser without trouble or delay (let's wish them luck, lol). Since you're bundling, it doesn't matter which module type you use; CJS has worked with code splitting perfectly for over 10 years. However, it's a pain every time you try to import a CJS library in your ESM or vice versa. The truth is, you can't just drop all legacy CJS packages in most real-world projects.

> “all 30,000 JS files of your project come to the user's browser without trouble or delay (let's wish them luck, lol)”

If only there was something in the HTTP protocol to make it more efficient to load multiple requests from the same server. Alas that must be a pipe dream, and every little image and script is loaded separately.

Oh wait, it’s not 1996 anymore…?

Oh, tell me how your browser will load all files simultaneously when your dependency tree looks like A->B->C->D->E->...

I hear there's this new HTTP 2 spec that might be able to do something like that... but obviously we need to wait on browser support

I more or less agree, though I could get used to just about anything.

( see also: ES modules are terrible https://news.ycombinator.com/item?id=29137663 )

To suggest deprecating CommonJS so as to reduce fragmentation seems so bizarre to me. Audacious.

Reply on news.ycombinator.com