Mobile web apps may be slow because Moore's law is ending

The article is right about Javascript, but wrong about why mobile web apps are slow. Most mobile web apps are not games nor image processing apps, they are simple content sites or form-driven applications that are not CPU bound and don&#x27;t use a lot of JS. These apps are subjectively slower because of browser layout engine performance.<p>Even on &quot;heavy&quot; JS apps, I&#x27;ve heard it said they only use 30% CPU. So if 70% time is not spent in JS, even if you run that 30% 50 times faster, at best you get a 42% speedup from 50 times better CPU performance.<p>I feel the author has caused many to have the wrong take-away message, and the anti-web contingent are lapping it up. Mobile Wep Apps can be made to perform fast today, but it takes way way too much effort to tweak the CSS&#x2F;DOM manipulations to avoid jank. Consider for example the need to manually &quot;hint&quot; you want GPU compositing by using identity CSS3 transforms.<p>The rendering engines need to get better with leveraging the GPU and avoiding work when they don&#x27;t need to.<p>If you want to see what a herculean effort can achieve, see Sencha&#x27;s FastBook.<p>Basically, the author is right, but I think it&#x27;s a red herring given that when people talk about &quot;slow mobile web apps&quot;, 99% of the time, they are not talking about an Instagram written in JS, or AngryBirds in Javascript, but some basic news feed app.

Even if you accept that giving web apps 10x more CPU than today they&#x27;d be equal to today&#x27;s native apps (I don&#x27;t accept this), you must acknowledge you&#x27;ve given 10x more CPU to the native apps too. And clever people will find impressive ways to use that CPU in native&#x27;s advantage (witness all the neat physics stuff in IOS7).

&gt;So Moore’s Law might be right after all, but it is right in a way that would require the entire mobile ecosystem to transition to x86. It’s not entirely impossible–it’s been done once before. But it was done at a time when yearly sales were around a million units, and now they are selling 62 million per quarter. It was done with an off-the-shelf virtualization environment that could emulate the old architecture at about 60% speed, meanwhile the performance of today’s hypothetical research virtualization systems for optimized (O3) ARM code are closer to 27%.<p>Why do you need virtualization if the code is Java bytecode? Sure, this doesn&#x27;t work for iPhone, but Android should be able to easily change the processor architecture. (If I&#x27;m not missing something here). There&#x27;s already Android-x86 project.

The original title is more accurate. This edited one doesn&#x27;t do the piece justice. He really is talking about the end of an age.<p>I was expecting some kind of snark, but not this. I&#x27;m glad I suffered through the page crashing my iOS browser once.

Moore&#x27;s law won&#x27;t necessarily be progressing in a steady line. We will probably see more jumps and spikes as technology advances. Do you think computing power will only merely double once we take advantage of quantum computing? No, it will go up orders of magnitude in a short period of time.<p>Our current progression with silicon based computing is slowing because we&#x27;re reaching the physical limitations of that technology.

One additional point is that even if .js doesn&#x27;t improve much, mobile browsers can get a lot faster. iPhone&#x27;s webview is a lot faster than Android&#x27;s webview, so there&#x27;s plenty of progress to be made especially with rendering.

Ok dudes, enough is enough.<p>What actual proof does this dude have that pocket-sized computers have reached their limits of performance and memory?<p>All I see are some carefully selected quotes from some &quot;hardware engineers&quot; who are doing nothing more than offering up their opinion.<p>An &quot;ex-Intel engineer&quot; and a &quot;robotics engineer&quot; have a single paragraph. Really, this is your research? Some anonymous quotes, probably taken out of context?<p>&gt; I have consulted many such qualified engineers for this article, and they have all declined to take the position on record. This suggests to me that the position is not any good.<p>Really.<p>Do I have to go on?

Mobile web apps are slow because of layers upon layers of leaky abstractions and algorithms at each layer that still have a lot of room to be optimized.<p>If you want a consistent 60 frames a second, you need to architect systems that complete the work that needs to render each frame within 16.6ms. If you can&#x27;t complete all your computations within 16.6ms, you need to prioritize computations and spread them across frames.

It is my experience that the biggest reason for why things are slow is that they need to fetch content from outside it&#x27;s environment.<p>I don&#x27;t know if this affects JS ability to render it but it is at least my experience that JS based apps are simply not able to give me the same non-interupted feel as natively build ones, this includes even apps like RSS readers.

Even if this is true, this only spells the end of exponential growth in hardware performance and the start of the more efficient software era. Engineering is all about finding the right compromises to get the job done given a set of restraints. When the HW performance becomes the major restraint then you just have to design around that.

Maybe the slowing of this Law, which I am not convinced of per this article, will slow new hardware introduction. If this happens, perhaps this will allow closer optimization of applications to a small, relatively static hardware complement.

Phones should be thin clients anyway, the cloud provides the muscle. What use is packing compute into it. You just want it get smaller and zero energy use (using ambient energy for charging).

I think it&#x27;s a favour. Coders shouldn&#x27;t settle for a mediocre language and a dated platform just because they are ubiquitous.

<i>“in a memory constrained environment garbage collection performance degrades exponentially.” The obvious solution, then, is to throw memory at the problem, no?</i><p>Isn&#x27;t the obvious solution to avoid garbage collection whenever possible? Just consider &#x27;Date.now()&#x27; vs &#x27;new Date().getTime()&#x27; - are we even trying? Shouldn&#x27;t we start considering unnecessary garbage a bug, like a memory leak? That might not change everything, but it surely would help, no?

Performance anxiety for a whole class of devices that DIDN&#x27;T EVEN EXIST a few years ago, enabling GIANT NEW MARKETS.<p>&#x27;Our world is coming to an end.&#x27; Gotta love it.

I think we have another 10 years or so until 2-3nm chips.