3 ms·
(Hi. :)) 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
by gsnedders 11y ago
(Hi. :))
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 <canvas> 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.
- johansch 11y agoI haven't done profiling of firefox os on a crappy device... but my suspicion is that it really is as simple as: even really-well-optimized html/css/js that needs to go through a browser core will suffer performance-wise compared to something with 10-15 less layers of indirection. (Like a traditional windowing toolkit.) The Android UI toolkit isn't exactly efficent (ha!), but still seems to beat Firefox OS on super-low-end hardware judging from the reviews I have seen. The internal windowing toolkit and java-like mini language with a VM that we made for Opera Mini 5/Opera Mobile 10 with both J2ME and C VM implementations was like 3x faster than the Android UI toolkit with Dalvik for typical windowing tasks. Without any super-fancy optimizations...
- pcwalton 11y agoThe indirection is a problem with existing browser implementations (and some spec issues, such as lack of Typed CSSOM, which is the current subject of work in the WGs). There is no fundamental reason that I can see as to why there needs to be a gap between the hardware and the graphics and layout of Web apps.
- jgraham 11y agoAs a practical matter, my experience of using FirefoxOS everyday is that performance is not the main issue. Of course it could undoubtedly be improved, but it's acceptable, particularly once you put it onto reasonable hardware (i.e. not the $40 phones). Much more problematic is the lack of "premium content" i.e. services that — even if they are basically just webapps — don't work except on Android/iOS. This is a particularly vicious cycle; it's hard to convince anyone to put in the effort to support minority platforms, and it's hard to get users unless you support the same content as other platforms (see also: Windows Phone, which by all accounts is an excellent product that almost no one uses). There's also the fact that FirefoxOS is some years behind the other platforms in terms of developers and the competition has ~infinite resources, which means that some parts are lagging behind feature wise. Having said all of that, I don't think that Opera is a bad analog for the difficulties FirefoxOS faces, only it's not Opera Platform specifically but Presto in general. It had the same kind of issues with limited support from content creators and relatively available resources.