Yes, Firefox is even slower. From the Android based Nexus 7 (2013) on the Ember benchmark:
Chrome Beta: 1589ms
Chrome: 1750ms
Firefox for Android: 2446ms
That’s the same benchmark that the Nexus 9 scores 750ms, and the iPhone 6 scores 250ms.
1 Like
Bah, it’s sad to see this happen. The hardware on some of the newer / flagship devices kicks serious ass and it could probably overtake the latest iPad, but without proper code it’s useless.
Without impressive battery upgrades I don’t think we will see mobile devices catching PCs this year:
Javascript will never be as fast as native code (interpreted, hyper-flexible…), and mobile CPU’s won’t be as fast as desktop ones (unless batteries improve a lot), so web apps are not going to be as smooth as native apps in my opinion.
Also, native apps have more tools and integrate better with the system.
I think it is not the time yet.
Which carrier are you with? I frequently get 4G in the city and rarely less than 3G.
That said, I agree with your general point. It’s one of the Google Maps app’ biggest limitations, as far as I’m concerned, that it can’t display map data offline but relies on an always on connection.
Back with O2 now, who are slightly better (importantly I am usually reachable in the office now). For the last two years I’ve been with EE. No signal most of the time in the office - often nothing within half a mile of the office!
That’s why they invented asm.js, a statically-typed subset of JavaScript that’s intended to be written by compilers. While only Mozilla officially supports it, asm.js code (from C source) is part of the standard benchmarks all the JavaScript interpreters use.
Garbage collection does slow things down, which is why Apple ultimately got rid of it in Objective-C, but not for the reasons you might imagine. (Android still garbage collects.) On average, well-written garbage collection is faster in most cases than non-GC (in part because you don’t need to release if you only created temporary objects.) The cost is in predictable latency. A smooth mobile app is 60 frames per second, meaning the main thread needs to finish every 16ms. That’s not enough time for garbage collection. (Smooth non-touch apps can feel smooth with more latency.)
I don’t think you have to be at Google to fix bugs. It’s open source. Just send your patch, no?
Yeah, but this kind of hardcore JS language / compiler design stuff is way beyond my skill level.
1 Like
I can’t disagree with your information about performance of tablets versus some other form factor. However, you haven’t addressed something I find more compelling as I get older and my eyesite isn’t what it one was - display size.
As an example, I recently decided to replace my failing Nook HD+ 10" tablet with something else. I wasn’t interested in going smaller after enjoying the 10" display size and resolution of the Nook. I was looking for a tablet I could use as a reader (in portrait mode). What I discovered is that most tablets use screens with the aspect ratio of 16:9 or 16:10 meaning that when you use them in portrait mode, the screens are long and narrow. If you’re viewing a magazine on a 10" screen with a 16:9 aspect ration, the page is scaled to the display width reducing the page size to about what it would be on a 7 or 8" tablet. My Nook didn’t have this issue because the ratio was 3:2 which is a nice comfortable page size for reading which approximates that of a physical book. Here’s a comparison of different aspect ratios. My options came down to a small number of tablets where there wasn’t some trade-off I was forced into.
My point here is that since that majority of tablets and mobile devices are in the 8" range, they’re limited in use due to the size of the display. While we could run pretty much any app in a web browser on such a device, I don’t see that one could effectively use Photoshop on devices of this size. I see tablets as interim devices. Good enough for when using a full size device isn’t a practical option. As such, I don’t really see them entirely replacing full size devices.