6 ms·

Ugh.. does anybody else have this feeling that no matter how fast JavaScript gets, average web app performance will not change at all? Kind of like with risk co

Ugh.. does anybody else have this feeling that no matter how fast JavaScript gets, average web app performance will not change at all? Kind of like with risk compensation principle - the safer your gear, the more risks you take on, we’re in the same spot with web/electron apps. JavaScript vms got so much faster than 10 years ago and yet all the web sites are much worse. Memory and cpu hogs. This is not something improving the vm can fix. There just is no competition so that customers could send a feedback signal saying that performance is unacceptable.

snek 7y ago
As they get faster, people use that as an excuse to stuff more code into their sites. It's a very sad pattern.
Spivak 7y ago
What do you mean there's no competition? This feels like such a weird statement when there's competition in just about every market segment on the web. If you mean there's no competition where the differentiating feature between competitors is performance then well sure, that's a lot rarer. For user-facing applications performance only really matters in human time, and is pretty far down on the list of how people choose software over things like features, price, ease of use, etc.. Until performance becomes a big problem because the app/site becomes unusable it's basically no problem. Hackers might not like it but we're such a weird market to sell to. Not necessarily that performance is a weird preference but that by in large hackers are perfectly fine with woefully inefficient feature-packed apps for their "primary" apps like their IDE but then want super lightweight skeleton-featured experiences for everything secondary.
- jcelerier 7y ago
  > large hackers are perfectly fine with woefully inefficient feature-packed apps for their "primary" apps like their IDE well, even the most feature-bloated IDE loads faster than GMail on my computer (before anyone asks, I'm on gigabit fiber)
- keymone 7y ago
  > For user-facing applications performance only really matters in human time, and is pretty far down on the list of how people choose software over things like features, price, ease of use, etc.. There was a study that has shown correlation between revenue drop and milliseconds that page takes to load. It’s not only hackers that respond to performance. As for competition - due to network effects there are very few competitors to things like Facebook, Amazon and other big tech. If these were federated services participating in communication built around some gigantic independent social graph - that would enable more competition in terms of UI performance, features, etc. Not going to happen anytime soon though.
  - hombre_fatal 7y ago
    The e-commerce revenue example is different from the point of the apps people choose to use in general. Also, HNers always circlejerk over how fast and federated IRC is yet Slack and Discord ate IRC's lunch despite IRC's decades of head start and the bloatedness of the new arrivals. So you don't make a very convincing point that people really do care. Another example is email: gmail.com is super slow, there are a lot of competing email clients, yet I'm sure the vast majority of users don't care and just use gmail.com. I use the web interface.
- Silhouette 7y ago
  Performance is crucially important for a lot of applications. It profoundly affects the usability of a site if performance is too slow, and many studies over the years suggest direct losses on the bottom line as a result. It may be a controversial opinion, but I think part of the problem today is that young web developers look to people who work at high-profile places like Facebook and Google as role models and for examples of best practice. And yet, a lot of Google's and Facebook's own web properties are... less than exemplary... in terms of performance, usability, design, and other factors that are important in most situations, and have been getting steadily worse rather than better over time. I humbly submit that the reasons for the runaway success of these giants have really very little to do with the quality of their sites any more, and that up to a point they can get away with things because of their dominant positions and lock-in effects that simply wouldn't be acceptable for most of the rest of us.
  - watsocd 7y ago
    I think a lot of this is technical debt. They built the feature/page/whatever code and it works "good enough". Now a future programmer three years later tells the business manager that they can do this much better now for $x. It will improve nothing as far as the user in concerned. Maybe the page will load faster but the user may not even notice. Maybe they will save some money on hosting and bandwidth costs. In most cases, the business person will most likely tell the programmer to keep working on to new feature z2021 project and leave the old code alone. This is until there is a security problem or the old code effects the z2021 project.
- chrisweekly 7y ago
  Performance _is_ a feature. In fact it's the most important feature.
  - hedora 7y ago
    Well, correctness / security are probably more important than performance. (Spoiler alert: If your system is well-enough implemented to be correct, it is well on the way to being secure and performant too)
  - nameiscubanpete 7y ago
    It's better that "Hello, world" take 5 seconds to print than 1 second to crash and print nothing.
vturner 7y ago
Something I've wondered is if consumers have forgotten what fast, responsive UI feels like or that because so many people used bargain desktops/laptops, they never knew. Thus, slow visually cumbersome software is the norm for them...
- keymone 7y ago
  I bet there are consumers that never even experienced it.
- hedora 7y ago
  Studies have shown that current UI is much, much less responsive than 1980’s teletypes. I’m not sure if those were peak UI performance. It wouldn’t surprise me. I’m guessing at least a generation of people haven’t actually experienced reasonably responsive computing environments.
  - TheAceOfHearts 7y ago
    Could you cite or link to some of these studies?
    - nobleach 7y ago
      I think the poster might be referring to: https://danluu.com/input-lag/ https://danluu.com/input-lag/
JustSomeNobody 7y ago
Years ago when the debate was natively compiled apps vs java/c# apps, hardware was still slow enough that you could reasonably justify using c++ or c or something instead. Then, hardware got "fast enough" that, generally, that didn't matter. We are fast approaching a time when hardware will not be able to save us so I believe we'll eventually see devs have to slow down and optimize better.
save_ferris 7y ago
Yep. Unless a company actively engages clients to get product feedback, it's unlikely that the end users even have the clout to complain about app performance until a vendor improves it. There are times that I perceive the community trying to convince itself that web devs can have their cake and eat it too. That it's not just possible but easier to built performant, accessible and maintainable apps in React/Angular/Vue, when that's just not a universal truth. Sure, those tools may make certain aspects of development easier through the abstractions they leverage, but those also come with a cost (i.e. breaking API changes seem to be in vogue these days). Ultimately, this part in parcel of the JS community. Aspects of the ecosystem feel so fragile (NPM, framework/lib churn, etc.) that it's easy to be cynical about web app performance.
AbrahamParangi 7y ago
I feel like this is similar to the induced demand argument: "If you provide more supply then people will just (mis)use it and you won't have excess anymore so it's not really worth it" And the implicit response is that people using available resources for whatever they want is fundamentally a good thing.
- fiddlerwoaroof 7y ago
  In the context of computers, though, I want to decide what to spend the RAM on, it’s not great when random third parties decide to take advantage of my RAM just because it’s there.
seanwilson 7y ago
> Ugh.. does anybody else have this feeling that no matter how fast JavaScript gets, average web app performance will not change at all? Kind of like with risk compensation principle - the safer your gear, the more risks you take on, we’re in the same spot with web/electron apps. > This is not something improving the vm can fix. There just is no competition so that customers could send a feedback signal saying that performance is unacceptable. I think that's part of the reason Google made AMP: they don't allow arbitrary JavaScript scripts because it's not practical to get all websites and all developers to optimise JavaScript usage. Likewise, the amount of CSS code allowed is strictly limited.
- pbhjpbhj 7y ago
  Whenever I test website optimisation (basic websites, no fancy-shmancy stuff, not web-apps) the slowest parts, least accessible too, are advertising and tracking, and social. Google tells me the code to add to my page (for G+, advertising, analytics), then things like Google Lighthouse tell me don't do X, Y, Z that are all done by the code Google told me to use. Minimise request size, leverage browser caching, defer parsing, ... they don't even minify? At least they enable gzip, Amazon ads don't even do that. Load show_ads.js asynchronously ... well why not tell me to do that up front rather than after the fact in PageSpeed? Eg: https://gtmetrix.com/reports/alicious.com/RyJ575Jd https://gtmetrix.com/reports/alicious.com/RyJ575Jd
  - seanwilson 7y ago
    > Load show_ads.js asynchronously ... well why not tell me to do that up front rather than after the fact in PageSpeed? Google is a huge company and not every team has the same priorities is the most likely answer. It's not realistic to expect they're going to optimise the loading speed of literally everything they release. Web best practice checks will always have some degree of false positives as well as websites are so complex. I wrote my own Chrome extension that checks websites for best practices (https://www.checkbot.io https://www.checkbot.io) and had to weigh up how generally useful a test was compared to its typical false positives rate. The website for the product does pass the vast majority of the tests though, but I've only got a single website to manage compared to Google. > Eg: https://gtmetrix.com/reports/alicious.com/RyJ575Jd https://gtmetrix.com/reports/alicious.com/RyJ575Jd By the way, isn't some of this advice outddated? "This page has 25 external Javascript scripts. Try combining them into one." "This page has 3 external stylesheets. Try combining them into one." This is obsolete with HTTP/2 because files can be downloaded in parallel. Combining the files will also increase the weight of pages that don't need every file.
kolme 7y ago
As VMs get faster, people will stuff more JS in pages, just because it's doable. Some things were not even possible and were "unlocked" by browser optimizations. For example: writing games or complex animations with JS and the DOM was nearly impossible (that gap was filled with flash). As browsers got faster, the need for flash just went away. Also the more APIs the browsers ship, the more is possible to do with JS, and so the pages ship more JS to use these new featuers. [1] For example: after browser notifications became broadly available, almost _all_ pages ship now a snippet of JS code to annoy the user with notifications. I'm sure such fads blow up the average size of bundled JS across all web pages. [1] Look at this! https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API
collyw 7y ago
What I have seen in many SPA apps is a lot more requests over the network, instead of one bigger page that contains everything.

snek 7y ago

As they get faster, people use that as an excuse to stuff more code into their sites. It's a very sad pattern.

Spivak 7y ago

What do you mean there's no competition? This feels like such a weird statement when there's competition in just about every market segment on the web. If you mean there's no competition where the differentiating feature between competitors is performance then well sure, that's a lot rarer. For user-facing applications performance only really matters in human time, and is pretty far down on the list of how people choose software over things like features, price, ease of use, etc.. Until performance becomes a big problem because the app/site becomes unusable it's basically no problem. Hackers might not like it but we're such a weird market to sell to. Not necessarily that performance is a weird preference but that by in large hackers are perfectly fine with woefully inefficient feature-packed apps for their "primary" apps like their IDE but then want super lightweight skeleton-featured experiences for everything secondary.

jcelerier 7y ago
> large hackers are perfectly fine with woefully inefficient feature-packed apps for their "primary" apps like their IDE well, even the most feature-bloated IDE loads faster than GMail on my computer (before anyone asks, I'm on gigabit fiber)
keymone 7y ago
> For user-facing applications performance only really matters in human time, and is pretty far down on the list of how people choose software over things like features, price, ease of use, etc.. There was a study that has shown correlation between revenue drop and milliseconds that page takes to load. It’s not only hackers that respond to performance. As for competition - due to network effects there are very few competitors to things like Facebook, Amazon and other big tech. If these were federated services participating in communication built around some gigantic independent social graph - that would enable more competition in terms of UI performance, features, etc. Not going to happen anytime soon though.
- hombre_fatal 7y ago
  The e-commerce revenue example is different from the point of the apps people choose to use in general. Also, HNers always circlejerk over how fast and federated IRC is yet Slack and Discord ate IRC's lunch despite IRC's decades of head start and the bloatedness of the new arrivals. So you don't make a very convincing point that people really do care. Another example is email: gmail.com is super slow, there are a lot of competing email clients, yet I'm sure the vast majority of users don't care and just use gmail.com. I use the web interface.
Silhouette 7y ago
Performance is crucially important for a lot of applications. It profoundly affects the usability of a site if performance is too slow, and many studies over the years suggest direct losses on the bottom line as a result. It may be a controversial opinion, but I think part of the problem today is that young web developers look to people who work at high-profile places like Facebook and Google as role models and for examples of best practice. And yet, a lot of Google's and Facebook's own web properties are... less than exemplary... in terms of performance, usability, design, and other factors that are important in most situations, and have been getting steadily worse rather than better over time. I humbly submit that the reasons for the runaway success of these giants have really very little to do with the quality of their sites any more, and that up to a point they can get away with things because of their dominant positions and lock-in effects that simply wouldn't be acceptable for most of the rest of us.
- watsocd 7y ago
  I think a lot of this is technical debt. They built the feature/page/whatever code and it works "good enough". Now a future programmer three years later tells the business manager that they can do this much better now for $x. It will improve nothing as far as the user in concerned. Maybe the page will load faster but the user may not even notice. Maybe they will save some money on hosting and bandwidth costs. In most cases, the business person will most likely tell the programmer to keep working on to new feature z2021 project and leave the old code alone. This is until there is a security problem or the old code effects the z2021 project.
chrisweekly 7y ago
Performance _is_ a feature. In fact it's the most important feature.
- hedora 7y ago
  Well, correctness / security are probably more important than performance. (Spoiler alert: If your system is well-enough implemented to be correct, it is well on the way to being secure and performant too)
- nameiscubanpete 7y ago
  It's better that "Hello, world" take 5 seconds to print than 1 second to crash and print nothing.

vturner 7y ago

Something I've wondered is if consumers have forgotten what fast, responsive UI feels like or that because so many people used bargain desktops/laptops, they never knew. Thus, slow visually cumbersome software is the norm for them...

keymone 7y ago
I bet there are consumers that never even experienced it.
hedora 7y ago
Studies have shown that current UI is much, much less responsive than 1980’s teletypes. I’m not sure if those were peak UI performance. It wouldn’t surprise me. I’m guessing at least a generation of people haven’t actually experienced reasonably responsive computing environments.
- TheAceOfHearts 7y ago
  Could you cite or link to some of these studies?
  - nobleach 7y ago
    I think the poster might be referring to: https://danluu.com/input-lag/ https://danluu.com/input-lag/

JustSomeNobody 7y ago

Years ago when the debate was natively compiled apps vs java/c# apps, hardware was still slow enough that you could reasonably justify using c++ or c or something instead. Then, hardware got "fast enough" that, generally, that didn't matter. We are fast approaching a time when hardware will not be able to save us so I believe we'll eventually see devs have to slow down and optimize better.

save_ferris 7y ago

Yep. Unless a company actively engages clients to get product feedback, it's unlikely that the end users even have the clout to complain about app performance until a vendor improves it. There are times that I perceive the community trying to convince itself that web devs can have their cake and eat it too. That it's not just possible but easier to built performant, accessible and maintainable apps in React/Angular/Vue, when that's just not a universal truth. Sure, those tools may make certain aspects of development easier through the abstractions they leverage, but those also come with a cost (i.e. breaking API changes seem to be in vogue these days). Ultimately, this part in parcel of the JS community. Aspects of the ecosystem feel so fragile (NPM, framework/lib churn, etc.) that it's easy to be cynical about web app performance.

AbrahamParangi 7y ago

I feel like this is similar to the induced demand argument: "If you provide more supply then people will just (mis)use it and you won't have excess anymore so it's not really worth it" And the implicit response is that people using available resources for whatever they want is fundamentally a good thing.

fiddlerwoaroof 7y ago
In the context of computers, though, I want to decide what to spend the RAM on, it’s not great when random third parties decide to take advantage of my RAM just because it’s there.

seanwilson 7y ago

> Ugh.. does anybody else have this feeling that no matter how fast JavaScript gets, average web app performance will not change at all? Kind of like with risk compensation principle - the safer your gear, the more risks you take on, we’re in the same spot with web/electron apps. > This is not something improving the vm can fix. There just is no competition so that customers could send a feedback signal saying that performance is unacceptable. I think that's part of the reason Google made AMP: they don't allow arbitrary JavaScript scripts because it's not practical to get all websites and all developers to optimise JavaScript usage. Likewise, the amount of CSS code allowed is strictly limited.

pbhjpbhj 7y ago
Whenever I test website optimisation (basic websites, no fancy-shmancy stuff, not web-apps) the slowest parts, least accessible too, are advertising and tracking, and social. Google tells me the code to add to my page (for G+, advertising, analytics), then things like Google Lighthouse tell me don't do X, Y, Z that are all done by the code Google told me to use. Minimise request size, leverage browser caching, defer parsing, ... they don't even minify? At least they enable gzip, Amazon ads don't even do that. Load show_ads.js asynchronously ... well why not tell me to do that up front rather than after the fact in PageSpeed? Eg: https://gtmetrix.com/reports/alicious.com/RyJ575Jd https://gtmetrix.com/reports/alicious.com/RyJ575Jd
- seanwilson 7y ago
  > Load show_ads.js asynchronously ... well why not tell me to do that up front rather than after the fact in PageSpeed? Google is a huge company and not every team has the same priorities is the most likely answer. It's not realistic to expect they're going to optimise the loading speed of literally everything they release. Web best practice checks will always have some degree of false positives as well as websites are so complex. I wrote my own Chrome extension that checks websites for best practices (https://www.checkbot.io https://www.checkbot.io) and had to weigh up how generally useful a test was compared to its typical false positives rate. The website for the product does pass the vast majority of the tests though, but I've only got a single website to manage compared to Google. > Eg: https://gtmetrix.com/reports/alicious.com/RyJ575Jd https://gtmetrix.com/reports/alicious.com/RyJ575Jd By the way, isn't some of this advice outddated? "This page has 25 external Javascript scripts. Try combining them into one." "This page has 3 external stylesheets. Try combining them into one." This is obsolete with HTTP/2 because files can be downloaded in parallel. Combining the files will also increase the weight of pages that don't need every file.

kolme 7y ago

As VMs get faster, people will stuff more JS in pages, just because it's doable. Some things were not even possible and were "unlocked" by browser optimizations. For example: writing games or complex animations with JS and the DOM was nearly impossible (that gap was filled with flash). As browsers got faster, the need for flash just went away. Also the more APIs the browsers ship, the more is possible to do with JS, and so the pages ship more JS to use these new featuers. [1] For example: after browser notifications became broadly available, almost _all_ pages ship now a snippet of JS code to annoy the user with notifications. I'm sure such fads blow up the average size of bundled JS across all web pages. [1] Look at this! https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API

collyw 7y ago

What I have seen in many SPA apps is a lot more requests over the network, instead of one bigger page that contains everything.