4 ms·

Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the cu

by Detrus 11y ago

Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the culture of the developers. In the Flash vs HTML5 iPhone wars, people argued that if Flash was hated because of the developers who abused it, what's going to stop the same thing happening to HTML5/JS/canvas? It's happening. Usually not on some interactive visualization game but on simple articles. And the response are things like Facebook Instant that introduce a babysitter against ambitious developers and dysfunctional organizations. But it's really something that should be built into the web. Sites that eat up a lot of bandwidth and CPU can be marked. Sites that legitimately require more resources, are experimental in some way, can be marked by the developer as such, warning users. An article would rarely be one of those. If no centralized measures are taken against poor UX, only relying on culture to maintain UX across the board, the web stack will meet the same fate as Flash. Competitors like Facebook Instant will route around it.

olalonde 11y ago
On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site-speed-in-web-search-ranking.html http://googlewebmastercentral.blogspot.nl/2010/04/using-site...
- userbinator 11y ago
  I understand the reasoning but I don't agree with their implementation, because it essentially favours large sites run by those who can afford the faster infrastructure, while penalising the small ones that may actually have more relevant and detailed content but not very fast servers. Sites which load much faster get a ranking advantage even if they offer only superficial lower-quality content. Maybe if they didn't look at server response time, and only counted things like JS execution time, it would be a fairer ranking to those looking for substantive content. I'm quite willing to wait a lot longer, if it means I will spend more time reading a lengthy page once it loads, than to find a fast-loading page with little content. That article was written 5 years ago, and while speed might not have been a huge factor back then, they could've changed it since --- certainly there is no evidence to suggest otherwise, and my experience with how Google's results have changed over time agree.
  - anilgulecha 11y ago
    Interesting take. I'd hedge that 95-99% of alexa top 1000 sites could be delivered under 30kb -- just content+ css. (assuming ajax/video/fonts are asyncronous in google's algo and not counted towards load time). In which case it's easy even for the cheapest AWS server to host and server instantaneously. I think the bigger sites have a distinct disadvantage -- they have so many tracking and ad resources, that it kills their load time.
    - jakobegger 11y ago
      Yup. For my company website I made sure that most pages require just a single request to render: CSS is inlined and (small) scripts are loaded at the bottom of the page. This means that even when hosting it on a crappy host, without a CDN, you get stellar page load performance.
  - billmalarky 11y ago
    Infrastructure is incredibly cheap these days. Hell there's even a free, high quality, CDN small organizations can take advantage of (cloudflare). Software architecture has a lot more to do with app speed these days than expensive infrastructure does.
    - userbinator 11y ago
      Hell there's even a free, high quality, CDN small organizations can take advantage of (cloudflare). Cost is only part of the equation. What about those who don't want to use a CDN for, among other things, privacy reasons?
- tedunangst 11y ago
  Ironic, since blogspot is a prime offender for showing a blank page while the js gears turn and grind until the article text finally appears.
  - jwr 11y ago
    It also breaks scrolling and zooming. I was hoping someone would mention that. "Do as I say, not as I do".
- dspillett 11y ago
  That isn't going to catch sites that load reasonably but behave slowly afterwards (eating CPU time so potentially slowing other apps down too). There are a couple of sites I visit that do this. If I leave a few tabs of imgur open in Chrome they'll consume a pile of CPU time (this doesn't always happen, so perhaps it depends which ads are on the page?). IFLS pages eat CPU and memory too (again, almost certainly due to the ad content). In both cases it can be noticeable on a powerful desktop machine, so it must be a significant drain on low powered laptops and such.
tl 11y ago
> Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the culture of the developers. That's one reason. The other reason is that all Flash runtimes other than the heavily-optimizied primary implementation for Windows universally suck. That ends up being a rather large pain point when developers are more likely than average users to be running Mac or Linux.
- est 11y ago
  To be fair, in Linux, X window GUI sucks in general. For Mac system, everything besides Quicktime sucks. Also NPAPI sucks compared with ActiveX. Flash in its original popularity was its vector animation streaming capability, think SVG withe a timeline with streaming. Plus a decent ECMA scripting environment, and later hardware accelerated 3D apis and C++ compilation support. It's a good platform past its prime time and caught in a marketing controversy in an unfortunate mobile age.
  - bottled_poe 11y ago
    > "caught in a marketing controversy in an unfortunate mobile age." I understand this argument, but I don't believe that this was primarily a marketing war. Browser plugins are dirty, they always have been. It is not surprising that the latest web standards are attempting to plug this gaping security hole. Furthermore, all of the features you have listed were only implemented because Adobe had a huge financial monopoly on the technology.
    - est 11y ago
      No, abused and over-powered browser plugins are dirty. Quicktime is a plugin, do you feel its presence? Yet WWDC video pages were not HTML5 compatible and using Quicktime plugin. The same applies to Canvas or SVG, yes they are standards, but their performance will suck worse than Flash if advertisers start abuse animations with canvas. Best part, you can not disable canvas like you can with Flash.
  - xorcist 11y ago
pavlov 11y ago
This was posted the other day: https://news.ycombinator.com/item?id=9599905 https://news.ycombinator.com/item?id=9599905 It's an animated company logo in HTML5. The standout "feature" is that the page pegs a CPU core at 100%. Turns out that this is because the developer wanted to update the page favicon at 60fps. In the post, the developer explained this decision: "I got this idea in my head that it'd be really slick to animate the FavIcon to stay in sync with the logo. I love little moments like that. Others might feel that's frivolous or unneccessary but I disagree - details like that are the little moments that make the difference." Nothing (short of taking away APIs) will stop developers from coming up with these "little moments" that will burn CPU time and battery to oblivion.
- booleanbetrayal 11y ago
  glad i'm not the only one who found that feature to be gratuitous!

by Detrus 11y ago

olalonde 11y ago

On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site-speed-in-web-search-ranking.html http://googlewebmastercentral.blogspot.nl/2010/04/using-site...

userbinator 11y ago
I understand the reasoning but I don't agree with their implementation, because it essentially favours large sites run by those who can afford the faster infrastructure, while penalising the small ones that may actually have more relevant and detailed content but not very fast servers. Sites which load much faster get a ranking advantage even if they offer only superficial lower-quality content. Maybe if they didn't look at server response time, and only counted things like JS execution time, it would be a fairer ranking to those looking for substantive content. I'm quite willing to wait a lot longer, if it means I will spend more time reading a lengthy page once it loads, than to find a fast-loading page with little content. That article was written 5 years ago, and while speed might not have been a huge factor back then, they could've changed it since --- certainly there is no evidence to suggest otherwise, and my experience with how Google's results have changed over time agree.
- anilgulecha 11y ago
  Interesting take. I'd hedge that 95-99% of alexa top 1000 sites could be delivered under 30kb -- just content+ css. (assuming ajax/video/fonts are asyncronous in google's algo and not counted towards load time). In which case it's easy even for the cheapest AWS server to host and server instantaneously. I think the bigger sites have a distinct disadvantage -- they have so many tracking and ad resources, that it kills their load time.
  - jakobegger 11y ago
    Yup. For my company website I made sure that most pages require just a single request to render: CSS is inlined and (small) scripts are loaded at the bottom of the page. This means that even when hosting it on a crappy host, without a CDN, you get stellar page load performance.
- billmalarky 11y ago
  Infrastructure is incredibly cheap these days. Hell there's even a free, high quality, CDN small organizations can take advantage of (cloudflare). Software architecture has a lot more to do with app speed these days than expensive infrastructure does.
  - userbinator 11y ago
    Hell there's even a free, high quality, CDN small organizations can take advantage of (cloudflare). Cost is only part of the equation. What about those who don't want to use a CDN for, among other things, privacy reasons?
tedunangst 11y ago
Ironic, since blogspot is a prime offender for showing a blank page while the js gears turn and grind until the article text finally appears.
- jwr 11y ago
  It also breaks scrolling and zooming. I was hoping someone would mention that. "Do as I say, not as I do".
dspillett 11y ago
That isn't going to catch sites that load reasonably but behave slowly afterwards (eating CPU time so potentially slowing other apps down too). There are a couple of sites I visit that do this. If I leave a few tabs of imgur open in Chrome they'll consume a pile of CPU time (this doesn't always happen, so perhaps it depends which ads are on the page?). IFLS pages eat CPU and memory too (again, almost certainly due to the ad content). In both cases it can be noticeable on a powerful desktop machine, so it must be a significant drain on low powered laptops and such.

tl 11y ago

> Flash sites, apps and games also earned a bad reputation for eating up CPU, loading too long, doing too much and running poorly. And it was mostly due to the culture of the developers. That's one reason. The other reason is that all Flash runtimes other than the heavily-optimizied primary implementation for Windows universally suck. That ends up being a rather large pain point when developers are more likely than average users to be running Mac or Linux.

est 11y ago
To be fair, in Linux, X window GUI sucks in general. For Mac system, everything besides Quicktime sucks. Also NPAPI sucks compared with ActiveX. Flash in its original popularity was its vector animation streaming capability, think SVG withe a timeline with streaming. Plus a decent ECMA scripting environment, and later hardware accelerated 3D apis and C++ compilation support. It's a good platform past its prime time and caught in a marketing controversy in an unfortunate mobile age.
- bottled_poe 11y ago
  > "caught in a marketing controversy in an unfortunate mobile age." I understand this argument, but I don't believe that this was primarily a marketing war. Browser plugins are dirty, they always have been. It is not surprising that the latest web standards are attempting to plug this gaping security hole. Furthermore, all of the features you have listed were only implemented because Adobe had a huge financial monopoly on the technology.
  - est 11y ago
    No, abused and over-powered browser plugins are dirty. Quicktime is a plugin, do you feel its presence? Yet WWDC video pages were not HTML5 compatible and using Quicktime plugin. The same applies to Canvas or SVG, yes they are standards, but their performance will suck worse than Flash if advertisers start abuse animations with canvas. Best part, you can not disable canvas like you can with Flash.
- xorcist 11y ago

pavlov 11y ago

This was posted the other day: https://news.ycombinator.com/item?id=9599905 https://news.ycombinator.com/item?id=9599905 It's an animated company logo in HTML5. The standout "feature" is that the page pegs a CPU core at 100%. Turns out that this is because the developer wanted to update the page favicon at 60fps. In the post, the developer explained this decision: "I got this idea in my head that it'd be really slick to animate the FavIcon to stay in sync with the logo. I love little moments like that. Others might feel that's frivolous or unneccessary but I disagree - details like that are the little moments that make the difference." Nothing (short of taking away APIs) will stop developers from coming up with these "little moments" that will burn CPU time and battery to oblivion.

booleanbetrayal 11y ago
glad i'm not the only one who found that feature to be gratuitous!