Re: Why mobile web apps are slow

Posted on by

This content is over 11 years old. It may be obsolete and may not reflect the current opinion of the author.

Although the title broadly and vaguely referring to “mobile web apps”, Why mobile web apps are slow is actually a lengthy breakdown of JavaScript performance on mobile. tl;dr: too slow, and will stay relatively slow in feasible future.

Regretfully, because I was not formally trained as a computer scientist, I don’t have the necessary knowledge to judge whether or not the analysis of hardware architecture, garbage collection, or even interrupter development trends, are genuine or not. Nor I will try to be an web fanboy to pin the arthur as an Apple fanboy to repudiate what he just wrote. The question I would like to bring up is: Supposedly all of the analysis (and the conclusion) are true, what would the future holds for the Open Web, in post-PC world?

For the web to move away from JavaScript, there are currently two active proposals: Google Native Client (NaCl) and asm.js. NaCl comes with some trade-offs, like interpretability; asm.js on ARM is still in active development, and we will not know whether or not it would bring the same performance boost on x86.

Obviously, without JavaScript, the web as we (the front-end web developers) know it will cease to exist. It’s not necessary a bad thing though — while the web moving a way from a place I grew up, where everyone can find out the layout or logic of any website with view source, it had also involved to something much useful and powerful, embedded into everyone’s digital life more deeply. Yet, working on Mozilla payroll means there is no excuse to give up on the Open Web — even though I am not the person who make these decisions, thought experiments is always a fun thing to do.

So, maybe 10 years from now, website, or web apps would do this: Probe the CPU architecture of your hardware, drop the corresponding optimized asm.js or NaCl bytecode to your device, and render the entire screen with WebGL. There might even be Flash-like authoring tool for that, or even WebHAL — a library to abstract CPU/GPU differences. Think about what the Open Web gain or loose at that future.

As for JavaScript, in that future, people would have conversation like this comic (spooler alert below; thanks Kanru for the link):

— … Can’t remember its name. Today it’s mostly used just as a target language for compilers, but back in [the professor]’s days people actually used to write in it directly!

— Oh, that must be JavaScript!

Perhaps, just like Lisp at the time, a dynamic-typing language is still too advanced for hardware circa 2013.

7 thoughts on “Re: Why mobile web apps are slow”

  1. I wouldn’t say asm.js is in any way a move away from using JS to power the web – it is, after all, a subset of JS that happens to be particularly performant. And as has been stated in various locations by the developers involved, there is no fundamental reason why the more generally applicable full JIT compilers can’t catch up with asm.js’ performance – it’s just harder to get there.

    Mind you, what *might* happen is that compilers targeting JS (like Emscripten and Mandreel) become the standard for web-based applications that need to be performant. But getting that working for all applications seems like it would be hard and unnecessary.

  2. You forgot about Dart/Dash it was actually intended to replace Javascript.

    Anyways the problem with performance in Web Apps doesn’t all have to do with Javascript. Much of it has to do with the relationship between Javascript and the DOM. In truth the DOM wasn’t designed to be used by languages like Javascript or Dart. It’s really all an exploit in browser engines that allow the Web to support dynamic applications instead of just documents.

    There are a few projects I know of that are trying to fix the DOM’s relationship with Javascript. The Servo project, Chromium’s/Blink’s oilpan project and DOM.js.

  3. “Emscripten/asm.js” is probably the more accurate to describe what I have in mind here.

    Yes, asm.js is a subset of JavaScript, which make it portable and backward-compatible, but it is not the JavaScript that people is going to write it directly. There are maybe, maybe, future project like CoffeeScript/LiveScript/TypedScript to asm.js compiler which could make this happen (even JavaScript to asm.js!), but until then asm.js is inaccessible to regular web JavaScript programmers just like any other bytecode, except for a few cases.

  6. Thanks for commenting. I read the post yesterday and I was considering update the post to give the counter argument an equal presence.

Comments are closed.