6 ms·

One thing I don't understand about the JS ecosystem in general is the focus on minified size. This article does the same thing: preact is 6k or so whereas react

One thing I don't understand about the JS ecosystem in general is the focus on minified size. This article does the same thing: preact is 6k or so whereas react is 36k. This comparison seems entirely pointless when the first page load downloads multiple megabytes of assets and, additionally, a lot of users would have React in their browser cache anyway.

Klonoar 5y ago
The likelihood of anyone having React in their browser cache is lower than it ever was with jQuery. (and it was low with jQuery)
Reimersholme 5y ago
whateveracct 5y ago
You optimize what you measure
zimmerx 5y ago
Speaking from building both react and Preact sites serving millions of customers - the difference is noticeable when you add everything up. Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets. Downloading, parsing and then executing a larger bundle size will impact performance and we've been able to see time to interactive impact conversion on e-commerce sites. However you are right that there are many other factors at play here that will make the site better and I think the post misses the point about "bundle size". The important differentiation for us with Preact is two things: native support for web components, and a significantly faster library when it comes to transformations and dealing with vdom - see here https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... On your comment about browser cache, also true but it really depends - if you haven't appropriately split out your bundle then returning users will probably be redownloading react again and again with app updates. Also new users are super important because if you are trying to get new traffic you care about their experience not just returning users.
- KronisLV 5y ago
  > Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets. If this were true, wouldn't it apply in equal measure to other resources? And if that's true, then why do we still see multiple MB large pages that are full of images or even videos? Personally, the arguments expressed in "The Website Obesity Crisis" back in 2015 still hold up today in my eyes: https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm In short, for me to agree with your argument, i'd have to see websites in general take the path of using less images when not necessary, or optimize them better and use slightly lower resolutions etc. Opening the first random news site that came to mind, BBC, yields over 5 MB of data and almost 100 network requests: https://www.bbc.com/ https://www.bbc.com/ Opening Reddit means almost 15 MB of data and has around 235 network requests: https://www.reddit.com/ https://www.reddit.com/ Opening YouTube means almost 12 MB of data and has around 90 network requests: https://www.youtube.com/ https://www.youtube.com/ Sure, there are techniques to minimize this impact and compression that everyone should be using for their content, but if the big companies are doing something like this, then clearly the majority of people don't really care. To me, it feels like the thing that we should be doing is just putting less content in pages, less functionality, less widgets etc. Case in point: https://old.reddit.com/ https://old.reddit.com/ It needs less than 3 MB of data to load and while around 90 network requests is still bad, as a consequence of the smaller size, it loads more quickly! (note: the imporance of compression cannot be overstated, but at the end of the day even if your 15 MB compresses down to 5 MB, your browser still needs to handle all of that stuff locally, process the JS, CSS and HTML and display all of your media anyways, as well as keep it in memory, so i'd say that both the full size and the compressed size matters, decreasing the former obviously being good for the latter as well) On a similar note, there is a really interesting site called "What Does My Site Cost", which allows to further illustrate the bloat, for example: https://whatdoesmysitecost.com/index.php?testID=220205_BiDc8S_589#gniCost https://whatdoesmysitecost.com/index.php?testID=220205_BiDc8... Back on topic, i think that Preact, Svelte and even Vue are all pretty cool lightweight options for front end development!
  - kilburn 5y ago
    > If this were true, wouldn't it apply in equal measure to other resources? No. On sites that buy in to react/preact, there are parts of the site that won't work until react/preact has loaded. In contrast, the site will work perfectly fine without having loaded those large beautiful images. If done correctly, images won't even affect the layout of the page. Likewise, it doesn't matter if google analytics and the 10 thousand myriad tracking pixels take a minute to load: users shouldn't notice any difference here. > but if the big companies are doing something like this, then clearly the majority of people don't really care. Companies are complicated beasts. Using react or preact is entirely a predicament of the technical team. Nobody from marketing, sales, business could care less about it. However, marketing _needs_ (that's how they put it) those myriad tracking pixels because otherwise they can't track the effectiveness of their campaigns. Corporate wants those custom fonts and beautiful, large images because real people have said the site looks much better with them in usability tests (done using enterprise-level network connectivity of course). Sales people will go to war over having analytics, as otherwise they don't know how effective their campaigns are, and business loves the nice dashboards there so they back them up. The tech team decides that given the pace at which complicated interactive features are coming in going the plain html + sprinkle of vanilla javascript is untenable (partly due to whats-cool-today syndrome). In the end you get these big, "bloated" sites as a result. What users actually want is just a small factor in all this.
janjones 5y ago
> the first page load ... a lot of users would have React in their browser cache anyway Not on the first load. If you mean that it will be cached from other sites through the same CDN, then that's also unfortunately not true anymore since cache partitioning [1]. [1] https://www.peakhour.io/blog/cache-partitioning-firefox-chrome/ https://www.peakhour.io/blog/cache-partitioning-firefox-chro...
easrng 5y ago
As sibling comments mention, cache partitioning means there's no way for react to be shared, but even without cache partitioning react apps are usually bundled into 1 file with all the dependencies inlined, which stops caching from being useful across sites anyway.
trog 5y ago
Yeh, I read most of the article looking for more advantages of Preact other than just reduced bundle size but that seems to be basically it, or at least all that the write up covers. Did I miss something?
franciscop 5y ago
The way people bundle React with the rest of the user code on its own domain, 0% of the users would have React on their browsers already. It was already not true for the vast majority of jquery and this is a myth that should die/a reality that never happened (I cannot seem to find the article with the study now to prove it though...).
capableweb 5y ago
The other comments hit some spots (although today with the use of bundling, I'm not sure caching matters as much as people make it out to), but something that is currently missing from the conversation: parsing performance. Not the speed that the browser fetches the .js file (which depends on network quality) but rather the speed the browser parses the actual code, which can sometimes become the bottleneck. Larger projects adds more code for the browser to parse, and that will make the initial page-load performance worse. Smaller scripts === faster page-load, which improves user-experience and all metrics related to that.
Jenk 5y ago
> a lot of users would have React in their browser cache anyway. Do browsers share cache across domains? Seems like an easy vector to poison.
- cuu508 5y ago
  Nope https://news.ycombinator.com/item?id=30136221 https://news.ycombinator.com/item?id=30136221
eyelidlessness 5y ago
> a lot of users would have React in their browser cache anyway Not cross-origin, anymore. Every major browser now has cache partitioning (cache indexes are keyed by the requesting domain and the resource) for privacy reasons. Which means, for instance, the old optimization of using dependencies from a CDN is now suboptimal.
- anamexis 5y ago
  I'm guessing almost no one benefitted from cross-origin caching with React anyways, since it is almost always bundled up with Webpack. It's not like jQuery or Font Awesome.
  - eyelidlessness 5y ago
    I’m not sure I could quantify it, but CDNs were a prominent recommendation for React at least until CRA was pervasive. Another thing worth mentioning, and another point in Preact’s favor, is ESM and tree-shaking. React still doesn’t officially ship ESM, and the ability to strip unused functionality at build time is hampered by that because ESM is more amenable to static analysis. Whereas Preact, which is already much smaller on the wire, can become smaller still because it supports ESM.
brundolf 5y ago
A couple things: - It definitely shouldn't be downloading multiple megabytes of assets, at least not blocking assets. A reasonable primary JS bundle size (including the framework and other dependencies) is around 150kb; 30kb would be 20% of that. Images, marketings scripts, etc. are excluded because they don't block rendering/interactivity; the browser generally knows to defer those until after the main experience has loaded. The core bundle, on the other hand, blocks rendering content (if it's all rendered client-side) or at least interactivity (if content is rendered server-side and then hydrated client-side). And on top of just the download time, there's the time it takes the browser to parse and compile the code. So yeah, every few kilobytes matter. - Virtually nobody would have React in their browser cache from a re-usable URL. That was common in the jQuery days, but that's not how things are done today. For better or worse, a modern JS app bundles all of its dependencies statically in a self-sufficient bundle (possibly "chunked" into multiple files, but all domain-local). You could technically do things the old way, but you'd be fighting the tooling and ecosystem at every step. And anyway, your users probably wouldn't benefit from cache hits because no other sites are doing it. There's a hypothetical future where ES modules take off enough that dynamically loading dependencies becomes feasible and popular again, though even then, there are benefits to static bundling (like tree-shaking) that some probably wouldn't want to give up.

Klonoar 5y ago

The likelihood of anyone having React in their browser cache is lower than it ever was with jQuery. (and it was low with jQuery)

Reimersholme 5y ago

whateveracct 5y ago

You optimize what you measure

zimmerx 5y ago

Speaking from building both react and Preact sites serving millions of customers - the difference is noticeable when you add everything up. Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets. Downloading, parsing and then executing a larger bundle size will impact performance and we've been able to see time to interactive impact conversion on e-commerce sites. However you are right that there are many other factors at play here that will make the site better and I think the post misses the point about "bundle size". The important differentiation for us with Preact is two things: native support for web components, and a significantly faster library when it comes to transformations and dealing with vdom - see here https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we... On your comment about browser cache, also true but it really depends - if you haven't appropriately split out your bundle then returning users will probably be redownloading react again and again with app updates. Also new users are super important because if you are trying to get new traffic you care about their experience not just returning users.

KronisLV 5y ago
> Minification or not, starting with a 6x bundle size puts you in a precarious position to have to care more about how it grows over time adding other assets. If this were true, wouldn't it apply in equal measure to other resources? And if that's true, then why do we still see multiple MB large pages that are full of images or even videos? Personally, the arguments expressed in "The Website Obesity Crisis" back in 2015 still hold up today in my eyes: https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm In short, for me to agree with your argument, i'd have to see websites in general take the path of using less images when not necessary, or optimize them better and use slightly lower resolutions etc. Opening the first random news site that came to mind, BBC, yields over 5 MB of data and almost 100 network requests: https://www.bbc.com/ https://www.bbc.com/ Opening Reddit means almost 15 MB of data and has around 235 network requests: https://www.reddit.com/ https://www.reddit.com/ Opening YouTube means almost 12 MB of data and has around 90 network requests: https://www.youtube.com/ https://www.youtube.com/ Sure, there are techniques to minimize this impact and compression that everyone should be using for their content, but if the big companies are doing something like this, then clearly the majority of people don't really care. To me, it feels like the thing that we should be doing is just putting less content in pages, less functionality, less widgets etc. Case in point: https://old.reddit.com/ https://old.reddit.com/ It needs less than 3 MB of data to load and while around 90 network requests is still bad, as a consequence of the smaller size, it loads more quickly! (note: the imporance of compression cannot be overstated, but at the end of the day even if your 15 MB compresses down to 5 MB, your browser still needs to handle all of that stuff locally, process the JS, CSS and HTML and display all of your media anyways, as well as keep it in memory, so i'd say that both the full size and the compressed size matters, decreasing the former obviously being good for the latter as well) On a similar note, there is a really interesting site called "What Does My Site Cost", which allows to further illustrate the bloat, for example: https://whatdoesmysitecost.com/index.php?testID=220205_BiDc8S_589#gniCost https://whatdoesmysitecost.com/index.php?testID=220205_BiDc8... Back on topic, i think that Preact, Svelte and even Vue are all pretty cool lightweight options for front end development!
- kilburn 5y ago
  > If this were true, wouldn't it apply in equal measure to other resources? No. On sites that buy in to react/preact, there are parts of the site that won't work until react/preact has loaded. In contrast, the site will work perfectly fine without having loaded those large beautiful images. If done correctly, images won't even affect the layout of the page. Likewise, it doesn't matter if google analytics and the 10 thousand myriad tracking pixels take a minute to load: users shouldn't notice any difference here. > but if the big companies are doing something like this, then clearly the majority of people don't really care. Companies are complicated beasts. Using react or preact is entirely a predicament of the technical team. Nobody from marketing, sales, business could care less about it. However, marketing _needs_ (that's how they put it) those myriad tracking pixels because otherwise they can't track the effectiveness of their campaigns. Corporate wants those custom fonts and beautiful, large images because real people have said the site looks much better with them in usability tests (done using enterprise-level network connectivity of course). Sales people will go to war over having analytics, as otherwise they don't know how effective their campaigns are, and business loves the nice dashboards there so they back them up. The tech team decides that given the pace at which complicated interactive features are coming in going the plain html + sprinkle of vanilla javascript is untenable (partly due to whats-cool-today syndrome). In the end you get these big, "bloated" sites as a result. What users actually want is just a small factor in all this.

janjones 5y ago

> the first page load ... a lot of users would have React in their browser cache anyway Not on the first load. If you mean that it will be cached from other sites through the same CDN, then that's also unfortunately not true anymore since cache partitioning [1]. [1] https://www.peakhour.io/blog/cache-partitioning-firefox-chrome/ https://www.peakhour.io/blog/cache-partitioning-firefox-chro...

easrng 5y ago

As sibling comments mention, cache partitioning means there's no way for react to be shared, but even without cache partitioning react apps are usually bundled into 1 file with all the dependencies inlined, which stops caching from being useful across sites anyway.

trog 5y ago

Yeh, I read most of the article looking for more advantages of Preact other than just reduced bundle size but that seems to be basically it, or at least all that the write up covers. Did I miss something?

franciscop 5y ago

The way people bundle React with the rest of the user code on its own domain, 0% of the users would have React on their browsers already. It was already not true for the vast majority of jquery and this is a myth that should die/a reality that never happened (I cannot seem to find the article with the study now to prove it though...).

capableweb 5y ago

The other comments hit some spots (although today with the use of bundling, I'm not sure caching matters as much as people make it out to), but something that is currently missing from the conversation: parsing performance. Not the speed that the browser fetches the .js file (which depends on network quality) but rather the speed the browser parses the actual code, which can sometimes become the bottleneck. Larger projects adds more code for the browser to parse, and that will make the initial page-load performance worse. Smaller scripts === faster page-load, which improves user-experience and all metrics related to that.

Jenk 5y ago

> a lot of users would have React in their browser cache anyway. Do browsers share cache across domains? Seems like an easy vector to poison.

cuu508 5y ago
Nope https://news.ycombinator.com/item?id=30136221 https://news.ycombinator.com/item?id=30136221

eyelidlessness 5y ago

> a lot of users would have React in their browser cache anyway Not cross-origin, anymore. Every major browser now has cache partitioning (cache indexes are keyed by the requesting domain and the resource) for privacy reasons. Which means, for instance, the old optimization of using dependencies from a CDN is now suboptimal.

anamexis 5y ago
I'm guessing almost no one benefitted from cross-origin caching with React anyways, since it is almost always bundled up with Webpack. It's not like jQuery or Font Awesome.
- eyelidlessness 5y ago
  I’m not sure I could quantify it, but CDNs were a prominent recommendation for React at least until CRA was pervasive. Another thing worth mentioning, and another point in Preact’s favor, is ESM and tree-shaking. React still doesn’t officially ship ESM, and the ability to strip unused functionality at build time is hampered by that because ESM is more amenable to static analysis. Whereas Preact, which is already much smaller on the wire, can become smaller still because it supports ESM.

brundolf 5y ago

A couple things: - It definitely shouldn't be downloading multiple megabytes of assets, at least not blocking assets. A reasonable primary JS bundle size (including the framework and other dependencies) is around 150kb; 30kb would be 20% of that. Images, marketings scripts, etc. are excluded because they don't block rendering/interactivity; the browser generally knows to defer those until after the main experience has loaded. The core bundle, on the other hand, blocks rendering content (if it's all rendered client-side) or at least interactivity (if content is rendered server-side and then hydrated client-side). And on top of just the download time, there's the time it takes the browser to parse and compile the code. So yeah, every few kilobytes matter. - Virtually nobody would have React in their browser cache from a re-usable URL. That was common in the jQuery days, but that's not how things are done today. For better or worse, a modern JS app bundles all of its dependencies statically in a self-sufficient bundle (possibly "chunked" into multiple files, but all domain-local). You could technically do things the old way, but you'd be fighting the tooling and ecosystem at every step. And anyway, your users probably wouldn't benefit from cache hits because no other sites are doing it. There's a hypothetical future where ES modules take off enough that dynamically loading dependencies becomes feasible and popular again, though even then, there are benefits to static bundling (like tree-shaking) that some probably wouldn't want to give up.