Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES modules are terrible

gist.github.com

Post reply on HN
Print view View original

121–130 of 175 posts

Re: ES modules are terrible

#121

Post by tolmasky »

spankalee wrote: post #116
tolmasky wrote: post #62

Earlier quoted context omitted.

This isn’t a real concern, and yes I’ve written a static analyzer for requires (as have many build tools). The fact of the matter is no one is trying to trick the analyzer by passing variables to require, or even more mischievously trying to rename require or something (there aren’t a lot of “(a => a)(require)(path + “/x.js”)” out there). In practice, it is used like a static feature, and when it isn’t, it’s for a go…

> to accommodate a set of restrictions designed with the browser in mind That's the whole point, and a very good thing.

That was not the whole point, the whole point was to have a feature that could work in a variety of different environments. That’s why this language feature is in the ECMAScript spec and not in the W3C or whatwg, unlike something like “fetch” which is defined by the whatwg and thus has every right to not take other environments into consideration. There is a tremendous amount of subtlety that results from this fact, like how the spec can thus only define a small portion of this feature (syntax and basic semantics), but ultimately needing to leave everything related to fetching, resolving, and executing the code up to the environment (in HTML’s case, the whatwg HTML spec). This really complicates things and creates an unfortunate mismatch in expectations, where most users who have only a passing understanding of this feature and have been sold on the promise of something that will finally “just work” everywhere discover that this isn’t the case at all. There’s a reason why despite being introduced in ECMAScript over 5 years ago it still barely has support in node (and not great support in browsers either btw, but certainly better)— it’s because the reality is that this feature is supremely complicated to implement (despite providing very little tangible benefit), especially in the context of the unrealistic expectations users have developed for it as it continues to be pitched as being the magic tool that will make your code work everywhere without a build tool.

Re: ES modules are terrible

#122

Post by alerighi »

spankalee wrote: post #110

This post is terrible, actually. CommonJS was never going to be natively supported in browsers. The synchronous require semantics are simply incompatible with loading over a network, and the Node team should have known this and apparently (according to members of TC39 at the time) were told their design would not be compatible with future a JS module standard. So the primary thing that JS modules fix is native suppor…

Yes but who cares of native support in the browser? I mean, most JS stuff nowadays is transpiled, written in TypeScript, or if written in plain JS still transpiled anyway to support older browsers, and bundled in a single optimized file.

Loading all the dependencies over the network to me is just inefficient, you will have hundreds of requests instead of a single one, you will load the full source not a minified and optimized one, I just don't see the point.

Re: ES modules are terrible

#123

Post by alerighi »

TekMol wrote: post #46

ES Modules are great. Building JS applications is so much speedier, leaner and more fun now that they are supported widely. One fallacy the author falls for is that they think one needs a build step "anyway" because otherwise there would be too many requests to the backend. Loading an AirBnB listing causes 250 requests and loads 10MB of data. With a leaner approach, using ES Modules, the same functionality can be don…

Any moderately complex frontend application already has to have some sort of build system. One common example is using TypeScript (and these days I don't see the point of using JavaScript and spending hours to fix bugs generated by its missing type safety), or using JSX syntax that must be transpiled, or even if you use plain JS, to transpile it to support older browsers (yes, there is still too much people using Internet Explorer to ignore it).

If you already have a build system, the most sensible thing to me is letting the build system do their stuff and not worry about it. When I write a web application in React with TypeScript (the setup that I usually use) I don't worry about dependencies, and I use the ES modules import syntax (that is better than the CommonJS one) that gets transpiled to CommonJS without I even notice. So why bother changing that? It works, it produces a minified and optimized single .js file that is easy to serve from a webserver, I don't see points against it.

Re: ES modules are terrible

#124

Post by spankalee »

tolmasky wrote: post #121
spankalee wrote: post #116

Earlier quoted context omitted.

> to accommodate a set of restrictions designed with the browser in mind That's the whole point, and a very good thing.

That was not the whole point, the whole point was to have a feature that could work in a variety of different environments. That’s why this language feature is in the ECMAScript spec and not in the W3C or whatwg, unlike something like “fetch” which is defined by the whatwg and thus has every right to not take other environments into consideration. There is a tremendous amount of subtlety that results from this fact,…

It really is the whole point. TC39 was not going to define a feature that didn't work in browsers, full stop.

That Node has to take browser into consideration is a very good thing for universal JavaScript. We can now write code that works in browsers, Node and Deno and that's a great thing.

The support in browsers is excellent btw. All current browsers support standard JS modules now. Chrome is leading the way with import maps, import assertions, and JSON and CSS modules, but the other browsers will get there and CJS had nothing comparable to those anyway.

Re: ES modules are terrible

#125

Post by axismundi »

crooked-v wrote: post #37
axismundi wrote: post #35

Don't bundle. The only reason for bundling is too many requests to the server. Use HTTP/2 instead.

If you do that you're stuck with round trip times all the way down the dependency tree. HTTP/2 reduces the overhead of that, but doesn't eliminate it, so now you've added a bunch of loading time to your site.

I thought that as well, until I read this:

https://www.sitepoint.com/file-bundling-and-http2/

https://medium.com/@asyncmax/the-right-way-to-bundle-your-as...

Re: ES modules are terrible

#126

Post by spankalee »

alerighi wrote: post #122
spankalee wrote: post #110

This post is terrible, actually. CommonJS was never going to be natively supported in browsers. The synchronous require semantics are simply incompatible with loading over a network, and the Node team should have known this and apparently (according to members of TC39 at the time) were told their design would not be compatible with future a JS module standard. So the primary thing that JS modules fix is native suppor…

Yes but who cares of native support in the browser? I mean, most JS stuff nowadays is transpiled, written in TypeScript, or if written in plain JS still transpiled anyway to support older browsers, and bundled in a single optimized file. Loading all the dependencies over the network to me is just inefficient, you will have hundreds of requests instead of a single one, you will load the full source not a minified and…

Native support matters so that we're not eternally required to use tools for even the simplest of cases. Being able to write two files with one importing the other with no npm or bundler in sight should absolutely be a feature of the native platform.

And yes, in production you probably will want to bundle, but you probably also want to minify. Does that imply that we should require a minifier to even run any code at all, even in dev? No, of course not.

By adding a standard and native support we allow for sites that work without bundling and bundling that can adhere to the standard and not have to even be configured because the input is standard and the output must preserve those standard semantics. That gives tool independence and simplifies usage of the toolchains, and that's a great goal to shoot for.

Re: ES modules are terrible

#127

Post by tolmasky »

spankalee wrote: post #124
tolmasky wrote: post #121

Earlier quoted context omitted.

That was not the whole point, the whole point was to have a feature that could work in a variety of different environments. That’s why this language feature is in the ECMAScript spec and not in the W3C or whatwg, unlike something like “fetch” which is defined by the whatwg and thus has every right to not take other environments into consideration. There is a tremendous amount of subtlety that results from this fact,…

It really is the whole point. TC39 was not going to define a feature that didn't work in browsers, full stop. That Node has to take browser into consideration is a very good thing for universal JavaScript. We can now write code that works in browsers, Node and Deno and that's a great thing. The support in browsers is excellent btw. All current browsers support standard JS modules now. Chrome is leading the way with i…

It is absolutely not excellent, unless you restrict yourself solely to whether there is a checkmark next to the browser name in mdn. It is very buggy, very difficult to debug, and as I mentioned in another comment, missing serious features (like no subresource integrity which, means we’re encouraging people to use a much less secure system of importing scripts in many cases!)

> It really is the whole point. TC39 was not going to define a feature that didn't work in browsers, full stop.

No one is saying they shouldn’t have considered the browser! We’re saying they should have also considered other major environments, like node! That’s the way to design a language feature and absolutely what they wanted to do. There were a number of reasons it was rushed out the door, but they’re pretty upfront about the fact that they would do things differently now and basically no other feature would be allowed into the spec in the state ESM made its way in then. I am currently a TC39 delegate and can assure you that it’s OK to admit when things aren’t great so that we can learn from it. It’s how we’ve gotten JS to such a better state than where we were 20 years ago, not by bending over backwards to defend the with() statement.

Re: ES modules are terrible

#128

Post by spankalee »

tolmasky wrote: post #127
spankalee wrote: post #124

Earlier quoted context omitted.

It really is the whole point. TC39 was not going to define a feature that didn't work in browsers, full stop. That Node has to take browser into consideration is a very good thing for universal JavaScript. We can now write code that works in browsers, Node and Deno and that's a great thing. The support in browsers is excellent btw. All current browsers support standard JS modules now. Chrome is leading the way with i…

It is absolutely not excellent, unless you restrict yourself solely to whether there is a checkmark next to the browser name in mdn. It is very buggy, very difficult to debug, and as I mentioned in another comment, missing serious features (like no subresource integrity which, means we’re encouraging people to use a much less secure system of importing scripts in many cases!) > It really is the whole point. TC39 was…

I've been using almost exclusively standard modules for years and they work quite well. Old crashers and cache problems I was aware of have been fixed for many years now.

I don't know what debugging problems there are that wouldn't exist in CJS. At least with native modules you can see individual requests in the network panel while you're working and individual files in the sources panel while debugging. That alone is a huge increase in debuggability to me.

SRI really should be done out of band. Inline SRI would require far to frequent cache invalidation and isn't compatible with package manager workflows where you don't know the exact version of a file you'll depend on. A tool rather should build up an SRI manifest similar to a package lock. This has been discussed several times in module and import map threads.

And I don't think JS modules were actually rushed. They were languishing for years with an overly complex loader API and cut down to an MVP with the core agreed upon semantics and that's what finally got everyone to ship. They're really fine, and with import maps, CSS modules, and eventually web bundles, will be far, far superior to any previous alternative. They already are.

The fact that Node has some JS module / CJS interop issues (and really only when you try to use JS modules from CJS, the other way is fine) is Node's problem, not TC39's. There's really nothing that TC39 could have done here because synchronous require() is the fundamental problem. It was a bad design from the start and we shouldn't burden ourselves with that bad decision forever. The sooner CJS goes away the better.

Re: ES modules are terrible

#129

Post by spankalee »

devmunchies wrote: post #100
andrew_ wrote: post #88

I really, really loathe how major packages in the ecosystem are "We're ESM now, deal with it, sorry about your luck," and forcing the issue. It's arrogant as hell. A hard fork of Node for ESM would have been a much better path (e.g. Deno) That said, the OP's rant is more emotion than fact. > And then there's Rollup, which apparently requires ESM to be used, at least to get things like treeshaking. Which then makes pe…

> loathe how major packages in the ecosystem are "We're ESM now, deal with it, sorry about your luck," and forcing the issue I wasn’t able to use the latest version of node-fetch in a node.js script since it doesn’t support commonjs. The project literally has “node” in the name and doesn’t support default node.js.

Were you not able to convert the script to a module, or dynamically import() node-fetch?

Since you're using it for an async operation anyway, dynamic import should have worked quite well.

Re: ES modules are terrible

#130

Post by TheCoelacanth »

unilynx wrote: post #85
somehnacct3757 wrote: post #36

I keep thinking how QUIC / HTTP/3 would go nicely with ESM in the browser (via script tags with type=module) for simple sites. A webmaster could totally avoid the complexity of learning a JS tool chain. Right now even 1000 lines of JS has you reaching for a bundler. It would make shipping a small html+css+js site again as simple as dragging files to your webserver.

QUIC / HTTP3 does not fix the roundtrip wait times caused by dependencies - if 'a.mjs' imports 'b.mjs' which in turn imports 'c.mjs'... you still need two roundtrips to load all three. only a bundler can fix that (or a hypothetical process which would set up preloads for all required libraries, but that would just be a bundler without the actual bundle creation step)

An ES module-aware server can avoid that problem by using HTTP Server Push[1], but I haven't seen a production-quality implementation of that, only proof-of-concepts.

[1] https://medium.com/@nikita.malyschkin/the-future-of-web-depl...

Post reply on HN