Web App Speed
ignorethecode.net
Web App Speed
1–10 of 38 posts
Re: Web App Speed
#2People are using the canvas now to achieve fast speeds on mobile web. See Flipboard's post on this [1]. The big issue ppl brought up was that using canvas instead of DOM meant losing accessibility. Btw Flipboard released an interesting framework called React-Canvas[2] based on their efforts.
1. http://engineering.flipboard.com/2015/02/mobile-web/ 2. https://github.com/Flipboard/react-canvas
Re: Web App Speed
#3Flash 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.
Re: Web App Speed
#4Flash 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 visuali…
On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site...
Re: Web App Speed
#5People are using the canvas now to achieve fast speeds on mobile web. See Flipboard's post on this [1]. The big issue ppl brought up was that using canvas instead of DOM meant losing accessibility. Btw Flipboard released an interesting framework called React-Canvas[2] based on their efforts. 1. http://engineering.flipboard.com/2015/02/mobile-web/ 2. https://github.com/Flipboard/react-canvas
Flipboard assumed DOM is slow. I don't even think they created a prototype to see how slow DOM is.
I implemented this in few hours. Works on iOS, Android 4+ and WP
- Demo for mobile: http://premii.com/play/flipboard-style-news/
- I am using it in real app here. http://reddit.premii.com/#/r/news/
Re: Web App Speed
#6Flash 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 visuali…
> 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.
Re: Web App Speed
#7Absolutely agree with respect to ads. While the steady state performance of most banner ads is fine, loading new ads often force large javascript files to be fetched and parsed as well as needless reflows. On our game building site [1], we try to refresh ads only during natural breaks in gameplay (level changes). While this doesn't improve the loading time, it does help to shift the disruption to a time when it is less likely to be noticed.
Re: Web App Speed
#8Flash 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 visuali…
On a related note, Google penalises websites with longer load times. http://googlewebmastercentral.blogspot.nl/2010/04/using-site...
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.
Re: Web App Speed
#9The root of all evils, as you commented: "People don’t want to learn JavaScript".
However, I think it's because DOM/BOM API sucks. JavaScript, namely the language itself, doesn't even specify any event driven or asynchronous things. Not to mention why NodeList horribly isn't an array, or the need to write the long and annoying 'getElementsByClassName' rather than a simple $( ).
(Yes I know things like 'querySelectorAll' are much better, but it's too late for most of prejudices)
Re: Web App Speed
#10Flash 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 visuali…
> 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 a…
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.