Earlier quoted context omitted.
To be fair, the "low-end" devices Firefox OS were targeting were miles more powerful than what Opera Platform targeted a decade prior, and JS VMs are far quicker than they were a decade prior… I'm not sure it's so obvious that low-end devices doomed it to failure (of course, you actually worked on this stuff unlike me!). I think it's worthwhile to remember at the time Firefox OS launched much of Android ran on the Da…
(Hi Geoffrey, ltns! :) ) The execution of the code, be it javascript on some modern engine or Java/Dalvik bytecode - that isn't typically the performance bottleneck. It is fast enough now. I'm not an expert on this (this is where I thread on thin ice), but my understanding is that the HTML/CSS logdoc/layout tree model is inherently non-performant compared to a more traditional hierarchical windowed object oriented mo…
It depends a lot on what you're doing, and how much data you're processing. If we go by the premise that you're processing more data locally than you would in a web app (because you don't need to worry about the latency and you don't have a server to do the pre-processing and filtering of the data before it reaches the client), then actual VM performance is more significant. The last time I looked at any profiles of browsers on Gmail or FB, JIT'd code actually accounts for several of the most expensive functions (and you will notice if you disable the JIT). JS performance does matter—even if DOM performance dominates in the case of the common website (and note that Mozilla has actually been doing quite a lot of interesting work around teaching the JS VM more about the DOM, including rewriting parts in JS, which allows JIT optimisation to happen).
It's definitely true that it's easier to write non-performant code using HTML/CSS (and and WebGL don't really help here—because it's hard to ensure data gets correctly passed to accessibility layers), but I think that the majority of mobile apps are simple enough for it to not be a concern.