JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you

JS does indeed suck on mobile; since it's single-threaded by design, all those blocking operations (you already mentioned some examples) add up. Hence where you get both issues you mentioned - those refreshes are only necessary because the single-threaded nature of JS causes a few dozen event handlers in your framework to fire on every change you make. It also doesn't help that most mobile devices aren't exactly pushing the envelope on single-threaded performance. And let me be clear: JS being single-threaded isn't a bad thing in itself (the thought of a multi-threaded language in the browser gives me nightmares). It just makes the user experience of JS suck on mobile. And that's not going to change any time soon given the glacial pace of patch/update deployment on Android. > It basically involved treating the browser as an OpenGL canvas, where certain combinations of CSS + HTML would render text and boxes into a texture and then other combinations would let you move textures around and fade them together in the window. That approach -- while interesting from a technical standpoint -- kind of defeats the purpose of a browser :) I mean, you're basically building another browser inside the OpenGL window...