Web App Speed

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.<p>In the Flash vs HTML5 iPhone wars, people argued that if Flash was hated because of the developers who abused it, what&#x27;s going to stop the same thing happening to HTML5&#x2F;JS&#x2F;canvas?<p>It&#x27;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.<p>But it&#x27;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.<p>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.

The root of all evils, as you commented: &quot;People don’t want to learn JavaScript&quot;.<p>However, I think it&#x27;s because DOM&#x2F;BOM API sucks. JavaScript, namely the language itself, doesn&#x27;t even specify any event driven or asynchronous things. Not to mention why NodeList horribly isn&#x27;t an array, or the need to write the long and annoying &#x27;getElementsByClassName&#x27; rather than a simple $( ).<p>(Yes I know things like &#x27;querySelectorAll&#x27; are much better, but it&#x27;s too late for most of prejudices)

People are using the canvas now to achieve fast speeds on mobile web. See Flipboard&#x27;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.<p>1. <a href="http:&#x2F;&#x2F;engineering.flipboard.com&#x2F;2015&#x2F;02&#x2F;mobile-web&#x2F;" rel="nofollow">http:&#x2F;&#x2F;engineering.flipboard.com&#x2F;2015&#x2F;02&#x2F;mobile-web&#x2F;</a> 2. <a href="https:&#x2F;&#x2F;github.com&#x2F;Flipboard&#x2F;react-canvas" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Flipboard&#x2F;react-canvas</a>

1. Regarding native complexity: surely, using CoreGraphics is just as easy as canvas?<p>2. That game looks like it&#x27;s running at about 15fps. I&#x27;m not sure that constitutes very good proof of the argument. The best apps and games run at 60.<p>3. I&#x27;m not sure who&#x27;s using web MVC frameworks en masse and to what end, but I would NOT want to write a data-driven web app like Discourse from scratch.

Absolutely 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&#x27;t improve the loading time, it does help to shift the disruption to a time when it is less likely to be noticed.<p>1. <a href="https:&#x2F;&#x2F;www.1dash1.com" rel="nofollow">https:&#x2F;&#x2F;www.1dash1.com</a>

Sunspider does next to no processing, it&#x27;s really not a good benchmark for judging computation speed of a device. Arguably, it&#x27;s not a good benchmark, period. Kraken or Octane are more interesting benchmarks for compute-heavy workloads such as games.

Reading this article was a fresh breeze.<p>The Canvas is very easy to work with. You can forget about JQuery and everything else concerning the DOM and just write pure JavaScript. I&#x27;ve even started working on a canvas based text editor.

There are issues however with the way that some browsers render canvas, particularly stock browsers. I&#x27;ve had wildly different fps on different browsers.

But how would one implement e.g. progressive rendering in the background?