5 ms·

> Per-script max size: 50KiB That is quite small actually... My application (internal use, not consumer facing, so no panic) has a single packed script file, t

> Per-script max size: 50KiB That is quite small actually... My application (internal use, not consumer facing, so no panic) has a single packed script file, that is around 100KB.

Gaelan 8y ago
I imagine they’re trying to encourage code splitting.
- tanilama 8y ago
  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.
  - tadfisher 8y ago
    On the other hand, with advancements such as HTTP/2, there's not a substantial reason to pack multiple scripts.
    - jimrandomh 8y ago
      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.
      - setr 8y ago
        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
        kartickv 8y ago
        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.
  - pnevares 8y ago
    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-splitting https://facebook.github.io/create-react-app/docs/code-splitt...
    - tanilama 8y ago
      > 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.
josephg 8y ago
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.
rakoo 8y ago
"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 ?
- ijpoijpoihpiuoh 8y ago
  Workers impose non-trivial architectural overheads vs. ordinary scripts. It's not at all a drop-in replacement for ordinary scripts.
- tanilama 8y ago
  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.
mfer 8y ago
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.
- Sammi 8y ago
  And moment.js is 68 and luxon 64.
  - TheCoelacanth 8y ago
    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.
    - Sammi 8y ago
      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.
- slightlyoff 8y ago
  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.

> Per-script max size: 50KiB That is quite small actually... My application (internal use, not consumer facing, so no panic) has a single packed script file, that is around 100KB.

Gaelan 8y ago

I imagine they’re trying to encourage code splitting.

tanilama 8y ago
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.
- tadfisher 8y ago
  On the other hand, with advancements such as HTTP/2, there's not a substantial reason to pack multiple scripts.
  - jimrandomh 8y ago
    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.
    - setr 8y ago
      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
      - kartickv 8y ago
        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.
- pnevares 8y ago
  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-splitting https://facebook.github.io/create-react-app/docs/code-splitt...
  - tanilama 8y ago
    > 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.

josephg 8y ago

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.

rakoo 8y ago

"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 ?

ijpoijpoihpiuoh 8y ago
Workers impose non-trivial architectural overheads vs. ordinary scripts. It's not at all a drop-in replacement for ordinary scripts.
tanilama 8y ago
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.

mfer 8y ago

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.

Sammi 8y ago
And moment.js is 68 and luxon 64.
- TheCoelacanth 8y ago
  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.
  - Sammi 8y ago
    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.
slightlyoff 8y ago
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.