That’s transfer (compressed with gzip or whatever) size. So its a bit more than it sounds; but yeah - still tiny.

If this is the future, I know a lot of web apps that will need retooling. That is just enough space for react (+react-dom). We’ll have to split up react and web apps themselves in future apps if chrome goes this route; although I suppose that’s marginally better for caching performance.

A per-script max size of 50 KiB isn't realistic in the wild today.

For example, non-minified bootstrap.js is more than that. Just as a data point.

This will break a bunch of the web. I'll be curious to see how this gets worked out as the work progresses.

Hey, author of the patch here.

The restrictions are wire size. `bootstrap.min.js` is ~10KiB on the wire, which means it comfortably fits (as do jQuery, most analytics packages, etc.).

That said, the prototype does break a lot of the web, but that's not a crisis. The intent isn't to have this rolled out everywhere against unwitting content, but rather (like TLS), to let developers opt-in to a single set of rules when they see value. There are also places (e.g. PWAs) where the browser-imposed quality bar needs to be high. Blocking PWA install for sites that don't send the opt-in header seems like a reasonable place to start.

And moment.js is 68 and luxon 64.

Moment.js is 16.7k. Moment.js plus locale data for every single locale in the world is 68k. There is no justifiable reason to ever load every single locale in the world at once except for a few extremely niche cases. Real world use cases typically need one locale at a time, occasionally two or three, never hundreds.

Luxon, I believe, is a similar story.

The whole reason I use a date formatting library is so that I can localize dates into whatever locale the user is on. I can't just assume one locale and only load that.

"Caps do not apply to workers". I have a limited understanding of them but I understand that if your scripts are fat then you have something closer to an application than a document, and it would be better served with service workers that can run in the background and keep most of your application structure in place ?

Workers works pretty differently than regular script. The way it is being loaded, how to import other scripts into worker and have it communicate with your main thread (window) is quite a standard on its own, it is just that it happens to use javascript as its language.

Workers impose non-trivial architectural overheads vs. ordinary scripts. It's not at all a drop-in replacement for ordinary scripts.

I imagine they’re trying to encourage code splitting.

Which is what popular setup like create-react-app and alikes are against. It doesn't make too much sense for more heavy application like interactive editors to have multiple artificially split files just to conform with this limit.

I don't think it's correct to claim CRA and its peers are against code splitting. Dynamic import is a well-documented way to achieve this:

https://facebook.github.io/create-react-app/docs/code-splitt...

> Instead of downloading the entire app before users can use it, code splitting allows you to split your code into small chunks which you can then load on demand.

You need to make a business case that your whole application is modularly composable.

Some application might fit under this umbrella, but there are other stuff that don't, like a pdf-render, or something like google slides, which as I just checked, the core editor js is bundled in a single js file and as large as 1.4MB.

On the other hand, with advancements such as HTTP/2, there's not a substantial reason to pack multiple scripts.

The main reason you pack scripts is because you're compiling, and your compiler is checking and optimizing your cross-file interactions. For example, you need to merge scripts to be able to detect and delete unused functions, because otherwise some unmerged script might call the function without the compiler being able to detect it.

It seems like it would be trivial for your compiler to go ahead and split the files up again afterwards. Its not like you cared about file organization on the client side anyways if you were packing them, so its free to split however it feels.

And ofc you’d naturally just attribute this as an artifact of optimization, just as single-file packing was. Which it is, given http 2/3

No, because if you split it into two pieces, common utility functions will be called from both pieces, at which point you have to duplicate them.

Splitting probably makes sense only for an infrequently used feature, like video chat in an app like Gmail or Slack.