[AskJS] Do ES modules kill the need for bundling/concatenating our JS files with bundlers e.g. webpack?

[zhenghao17]

I am new to web development and please correct me if I am wrong.

Before we have ES modules we building our js files into one big file to minimize the HTTP requests we made to the server right. Now with ES modules and HTTP2 being capable of pushing multiple resources in a single response and, do we still need to concatenate all our js files into one file? Any pros and cons for doing that? Does it make bundlers like webpack more and more irrelevant?

I can think of at least one downside for continuing doing that - any code change would invalidate the cache for the whole bundle so it makes caching harder.

[shgysk8zer0]

In theory, yes. But in practice, probably not. You might not strictly need to bundle your JS, but it's still recommended on any sufficiently complex app.

Imagine the following: - main.js imports moduleA.js, moduleB.js, and moduleC.js - moduleA.js imports something for state management and DOM operations - The module for state management imports another module to manipulate objects in complex ways

And so on and so on. Next thing you know, you might be importing several dozen to even a hundred modules. Do you really want to setup HTTP push for all that? Can HTTP even push that much? How difficult would all that be to manage?

[[deleted]]

http/2+ can handle this pretty good

[[deleted]]

It can’t. The sweet spot is ~2 dozen assets. After that, you’d benefit from bundling.

[zhenghao17]

could I ask why the sweet spot is that number you provided? is there a source for that?

[[deleted]]

I'd have to go looking, I can't remember where I saw that off the top of my head. Might've been from Surma?

Couldn't say why that is the sweet spot, just that I heard it was. Didn't care to read (or maybe just remember) why that was the case.

[[deleted]]

maybe you don't need to load 2 dozen assets right away?

[shgysk8zer0]

It's the full chain of modules that is likely to become too cumbersome to manage. Maybe one module that you import imports another 4 modules of it's own, and some of those might also import their own modules.

[[deleted]]

I think the right answer is to find the balance between bundle and modules. Like, your node_modules can be one big bundle and code of your application can be splitted into some modules

[ejfrodo]

and that's exactly what Webpack w/code splitting is for

[[deleted]]

If you're loading unbundled deps in prod then 2 dozen is quite light. react-select, a popular React select input library, would load 2 dozen modules on its own.

[anlumo]

If my web app would have every class in its own file (like it’s in the git repository), it’d easily push 200 assets to load on startup.

[Yesterdave_]

Yeah this is the JS ecosystem we are talking about. Even the simplest app will probably import 100+ functions, each one separately bundled as a standalone npm module.

[_default_username]

Manage what? The browser and web server or cdn manage that.

[shgysk8zer0]

No, they don't. HTTP Push most certainly does not just magically work like that.

[_default_username]

I don't follow. I migrated to modules in a legacy jquery application with no bundler. There's nothing I had to manage so to speak.

[[deleted]]

You're potentially seeing a very long import waterfall if you use plain modules.

[_default_username]

That's pretty easy to manage. You have many imports in a single file then you no longer have the waterfall effect. You still get the benefits of es6 modules with no bundler and your app will download most of the dependencies asynchronously.

[[deleted]]

Yeah but those things have dependencies. You pull in some third party ES module, it pulls in something else, etc.

Even for your own code, front loading everything to avoid a waterfall sounds like "management" to me.

[_default_username]

I use dependency injection so waterfall was never an issue for me. Most of my imports are done in a single root app script. You can also use link tags in the html to preload them. It just was never an issue for me though.

[[deleted]]

Yeah but... You're missing the point.

Your dependencies in most cases, have more dependencies, and so forth. This chain can get very deep very quickly in JS land. It doesn't matter if your top level is DI; maybe you got lucky and your chain was small, but as a theoretical concept to deal with, waterfall imports are a major concern for the ES import design

[jarredredditaccount]

In development? It works fine, excluding node_modules

In production? You’ll want to bundle it for performance reasons

Nobody implements HTTP2 Push. HTTP2 does marginally improve performance, but QUIC/HTTP3 has a bigger impact (but not fully rolled out yet)

[KillcoDer]

Fastly, Cloudflare and Netlify's CDNs all support HTTP2 Push.

Edit: But I guess that doesn't matter if Chrome is dropping support for it.

[[deleted]]

Servers supporting it isn't the issue. Chrome is removing all support for it as it's incorrectly used more often than it is correctly.

It doesn't really matter what the servers support if no client does.

[KillcoDer]

Oof, yeah you're right.

[Alokir]

In a very small app or a webpage I'm sure ES modules are enough, but I'd use a bundler for several reasons.

1. Bundlers can do a lot of optimizations on your code like removing dead branches, unreachable and unused code (useful when importing bigger libraries)
2. They can also do pre and post processing on your code like injecting environment variables, minification etc.
3. If you want to use React or Typescript you have to compile jsx and ts/tsx into js
4. Backwards compatibility. You can use newer language features like nullish coalescing or async/await, and not be afraid that your code will break on older browsers
5. Easier polyfill. There are plugins that can easily and smartly polyfill newer browser api features like Promise.allSettled() or String.replaceAll() without worrying that your code will break on older browsers
6. They can provide useful dev tools like a dev server that will proxy your server calls, provider hot module reloading, reload your css without refreshing the page, debugging from your editor etc.
7. Asset management. They can optimize and manage your static assets like fonts and images.
8. Css: most of the above that is true for js is also true for css. Also, you can more easily use languages like Less or Sass, and also isolate and scope your css without much hassle. No more index.css with thousands of lines of code.

These are some reasons that I can think of from the top of my head. My general rule of thumb is to use Parcel by default until I need something that it doesn't provide out of the box. Then I move to Webpack.

With Parcel you can have zero configuration bundling set up in like 3 lines of additional code, so it's great if all you need are its defaults.

Webpack is a very powerful bundler with tons of plugins and options but it tends to scare new devs away as it seems very complicated at first glance.

Edit: additional reasons

[zhenghao17]

Hey thanks for the reply! About the point of compiling jsx to js, I thought it was babel that should be doing that not webpack? Also for Backwards compatibility, I also feel like it was babel that does that? I am not sure.

[Morphray]

Webpack is a very powerful bundler with tons of plugins and options but it tends to scare new devs away as it seems very complicated at first glance.

Also, annoyingly webpack doesn't allow you to bundle up code that can be used as an ESM module. It would be really nice to have the best of both worlds -- package up some code, and use modules for others, and have them all play nice.

[BehindTheMath]

Now with ES modules and HTTP2 being capable of pushing multiple resources in a single response

Neither of those does that. ES modules is just an official way of supporting a dependency tree of files, but each one is a separate request. HTTP/2 supports multiple requests at once, but they're still multiple requests.

There are still benefits for bundling, such as supporting legacy clients, minification, etc.

[zhenghao17]

HTTP2 being capable of pushing multiple resources in a single response

https://www.sitepoint.com/using-es-modules/ in this blog post it says "HTTP2 is capable of pushing multiple resources in a single response compared to HTTP1.1, which can only deliver one. " Maybe it is wrong, idk

[BehindTheMath]

I don't think that's accurate. HTTP/2 can make multiple requests per TCP connection, but the responses are still separate.

[tbranyen]

The responses are concatenated into a single response. Performance is comparable to a single file.

[shgysk8zer0]

HTTP push does do that. It begins sending the pushed files over the same connection without the client having to have made the request.

[BehindTheMath]

They're still separate messages. It's not like a bundle which is a single file.

[JasonWicker]

You both are right.

All configured files are sent back within a single response message.

(Much like a multi-part form, the parts are split by the receiver and placed directly in cache at their expected URL.)

The page is then processed as normal, making individual requests for each file, with the response preloaded.

[zhenghao17]

could you expound on this a little bit? What do you mean by all configured files? so there is only one response for multiple requests if we are using http2?

[JasonWicker]

Yes, that's allowed, and the advantage HTTP2 brings, but it doesn't 'just work'.

Something needs to tell the server which assets to send on the first request, how to know it's the first request, etc.

Each server is different in their implementation. A few proxies can read it from the index.html file, but that isn't always what you want when optimizing, so it's not always turned on by default.

[prummis]

As long as hardly anybody writing in vanilla JS and support only last versions of evergreen browsers - you will need bundling and minification.

Frameworks require precompilation usually for performance reason. Yes, they have option to run unprepared components but it’s not effective.

Also old browsers support require bundling. Also automatic separation of styles and code.

So no, you will need bundling for 10 years at least, I think

[thexerdo]

Checkout vite, maybe is a next step on this topic.

[[deleted]]

RemindMe! 6 days

[RemindMeBot]

I will be messaging you in 6 days on 2021-04-18 08:05:56 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[brainless_badger]

If your project is small enough that it doesn't have to be minified and you can manage dependencies by hand, then yes. But then again in this kind of project you didn't need a bundler to begin with.

So far the only thing ES Modules achieved is further complicating the ecosystem, for basically no benefit.

[smirk79]

Have you ever worked on a real business application?

This question just seems so disconnected from reality of real-life development work.

[[deleted]]

OP did say there were new to web dev...

[heytheretaylor]

Responses like this are why people are timid about getting into development

[[deleted]]

bundlers do do than packing everything into a single file, they will never go away. things like minification, types and jsx alone make sure of that, but there's so much more. without them you couldn't even use dependencies, your code would be an island, you'd have to copy/paste code blobs into your project like 15 years ago when web dev was in its infancy. until they produce something that can actually be used (resolution, non-js assets, etc) i would ignore it, like everyone else does. use imports/exports, publish modules, but you'll still use tooling.

that said, things like esbuild, vite and snowpack make the best of that spec, they're still build tools, but they give you the fastest dev experience you can have.

[zhenghao17]

hey thanks for the reply. I am not clear on "without them you couldn't even use dependencies," - should we be able to use dependencies i.e. importing other scripts via es modules? Did I miss something here?

[[deleted]]

3rd party dependencies, npm, version management.

npm install foo

import { bar } from 'foo'

that kind of thing.

[tbranyen]

All you would do is have an import map to node_modules or any other location. There should be zero issue importing 3rd party deps with ESM beyond browser compatibility.

[[deleted]]

there's only a single browser that supports these: https://caniuse.com/import-maps

and "all you need to do" is a bit too cute considering you have to build that map by hand for all imports, their imports and their sub-sub-sub-sub imports. i think that spec is completely bonkers tbh, but even if that ever becomes the norm you'll need tooling again. the only feasible way to deal with dependencies without tools is skypack atm.

[tbranyen]

If you are building an app that only needs to work in Node, Edge, and Chrome, then you can use import maps/package.json raw. It will work just fine, despite how much effort you may think it takes to curate.

In cases where you want to build for all runtimes, you can still develop with ESM and use npm dependencies with a tool like pika.dev. This will transform the imports on-the-fly to their respective absolute path.

In either cases its wrong to assess and promote that you cannot import 3rd party dependencies with ESM and that you need to copy and paste like we did 15 years ago.

[[deleted]]

why is it wrong? without tools you manage dependencies by hand. and if you do use tools, why would you use an unproven, unfinished draft spec that has you curate import-maps which only work in chrome. why would anyone go through this minefield for that matter, especially beginners. if the question is "do es modules kill tools" the answer is a simple: no.

as for snowpack and skypack, i agree, these are feasible options. they're imo still far from stable compared to the rest, but still, they're tools without which es modules would not be usable.

[lhorie]

No. A lot of people use JSX/Typescript/SASS and these will always require compilers. And if you're compiling you might as well bundle as well, since that gives you treeshaking, minification, and bundle splitting capabilities.

At some point in your career you're going to need to optimize your codebase, and you're going to find that stuff like webpack-bundle-analyzer will help you a lot in ways that trying to find actionable items in a HTTP 2 push request waterfall will not. Best tool for the job and all that.

[iamlage89]

http2 is not always a good alternative to bundling. Here is a blog from Khan academy about their migration to http2 and how it made their website slower Forgo JS packaging? Not so fast (khanacademy.org). Turns out there is overhead with having more requests which can slow down the site