4 ms·

I think it's good and important that people occasionally call this out. Same as https://news.ycombinator.com/item?id=39315585 https://news.ycombinator.com/item?

I think it's good and important that people occasionally call this out. Same as https://news.ycombinator.com/item?id=39315585 https://news.ycombinator.com/item?id=39315585 I don't understand why you'd consider this "low hanging fruit". What could the author have done to make it a high quality submission in your eyes? The alternative is to have more awareness of the amount of dependencies you really need, of when you actually need a framework with a runtime, and so on. He mentioned a fair share of essentially static landing pages that really have no reason to ship so much crap. And even though it's not explicitly mentioned: this isn't just a potential issue for end users. This code likely makes life hard for the developers as well. With every dependency you get more potential for breaking changes. With every layer it gets harder to understand what's going on. The default shouldn't be to just add whatever you want and figure it out later, the default should be to ask yourself what really needs to be added. Both in terms of actual code, but also layers, technologies, frameworks, libraries.

guappa 3y ago
> This code likely makes life hard for the developers as well. Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.
matthewhammond 3y ago
It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?). Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?). Or maybe compare these web application sizes to mobile or desktop equivalents too (where it's surely easier to optimise amount of code shipped). The article is just a lot of vague pointing at sites and insinuating (not even asserting) that they're too bloated or not. I don't get a sense of whether it's worse that Medium ships 3mb of code or Soundcloud ships 12. There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.
- troupo 3y ago
  > It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. No. No it wouldn't. It's not the job of strangers on the internet to do the job of incompetent developers. > Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?) How does being a landing page for a web app excuse downloading 6-10 MB of javascript to show two pages of static text and images? > Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?). Here's a holistic overview of performance: The Performance Inequality Gap, 2024 https://infrequently.org/2024/01/performance-inequality-gap-2024/ https://infrequently.org/2024/01/performance-inequality-gap-... > There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too. Not clearly. Not clearly at all. --- Edit: note on the incompetence. If you embed Youtube player in your website, Lighthouse will scream at you for being inefficient and loading too many resources. Nearly all of those issues will come from youtube. Lighthouse will helpfully provide you with a help page [1] listing wrappers developed by other people to fix this. Chrome's "performance lead" even penned an article[2] on lazy loading iframes and linked to a third-party youtube wrapper which promises 224x speed up over the official embed. They know. They either are so incompetent that they cannot do the job themselves, or they don't care. [1] https://developer.chrome.com/docs/lighthouse/performance/third-party-facades/ https://developer.chrome.com/docs/lighthouse/performance/thi... [2] Over at webdev: https://web.dev/articles/iframe-lazy-loading https://web.dev/articles/iframe-lazy-loading pointing to https://github.com/paulirish/lite-youtube-embed https://github.com/paulirish/lite-youtube-embed BTW. web.dev is created by web devs at Google. Promoting web development best practices. It takes it ~3 seconds to display a list of articles and the client-side only navigation is broken https://web.dev/articles https://web.dev/articles

guappa 3y ago

> This code likely makes life hard for the developers as well. Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.

matthewhammond 3y ago

It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?). Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?). Or maybe compare these web application sizes to mobile or desktop equivalents too (where it's surely easier to optimise amount of code shipped). The article is just a lot of vague pointing at sites and insinuating (not even asserting) that they're too bloated or not. I don't get a sense of whether it's worse that Medium ships 3mb of code or Soundcloud ships 12. There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.

troupo 3y ago
> It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. No. No it wouldn't. It's not the job of strangers on the internet to do the job of incompetent developers. > Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?) How does being a landing page for a web app excuse downloading 6-10 MB of javascript to show two pages of static text and images? > Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?). Here's a holistic overview of performance: The Performance Inequality Gap, 2024 https://infrequently.org/2024/01/performance-inequality-gap-2024/ https://infrequently.org/2024/01/performance-inequality-gap-... > There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too. Not clearly. Not clearly at all. --- Edit: note on the incompetence. If you embed Youtube player in your website, Lighthouse will scream at you for being inefficient and loading too many resources. Nearly all of those issues will come from youtube. Lighthouse will helpfully provide you with a help page [1] listing wrappers developed by other people to fix this. Chrome's "performance lead" even penned an article[2] on lazy loading iframes and linked to a third-party youtube wrapper which promises 224x speed up over the official embed. They know. They either are so incompetent that they cannot do the job themselves, or they don't care. [1] https://developer.chrome.com/docs/lighthouse/performance/third-party-facades/ https://developer.chrome.com/docs/lighthouse/performance/thi... [2] Over at webdev: https://web.dev/articles/iframe-lazy-loading https://web.dev/articles/iframe-lazy-loading pointing to https://github.com/paulirish/lite-youtube-embed https://github.com/paulirish/lite-youtube-embed BTW. web.dev is created by web devs at Google. Promoting web development best practices. It takes it ~3 seconds to display a list of articles and the client-side only navigation is broken https://web.dev/articles https://web.dev/articles