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.