Hacker News Reader

Comment by keymone | Hacker News Reader

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.

View on HN

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

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.

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...

I bet there are consumers that never even experienced it.

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.

Could you cite or link to some of these studies?

I think the poster might be referring to: https://danluu.com/input-lag/

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.

> 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.

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

> 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) 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

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.

>It's not realistic to expect they're going to optimise the loading speed of literally everything they release. //

How about just the things that get duplicated on more than 10Million websites?

>By the way, isn't some of this advice outddated? //

Yes, the link was just supposed to be broadly indicative. Google signpost Lighthouse as the primary tool now rather than PageSpeed I think but you can't link to that on the web. [And even Lighthouse has false positives, but that's not the issue here.]

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.

> 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)

> 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.

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.

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.

Performance _is_ a feature. In fact it's the most important feature.

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)

It's better that "Hello, world" take 5 seconds to print than 1 second to crash and print nothing.

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

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.

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.

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

Reply on news.ycombinator.com