8 ms·

HTML5 is not ready

76 points by cientifico 14y ago

paupino_masano 14y ago
To be quite honest I find the biggest drawback for HTML5 on mobile devices is speed. Even simple applications have a noticeable lag that isn't present (or can be hidden) on Native applications. As an example (as used in the article), Facebook is one of the worst performing apps on my phone, often taking me to places I never touched and crashing occasionally. Therefore I would suggest that the hardware/implementation still needs to catch up first before choosing a blanket HTML5 architecture (which mind you the hardware is doing gradually). Now, perhaps it because I am testing on older hardware; however this is for good reason. I test based on hardware that my clients/target audience use - if they upgrade and they get a speed increase then that's a bonus - but until then they need to get the best possible experience given the hardware they have. I will use HTML5 for applications if I can get a reasonable return on investment by doing so, but usability is always number one - if it doesn't perform well then it may as well be thrown out.
- hdragomir 14y ago
  This is also a big problem we have encountered, and I've even summed up most of the workarounds and hacks you have to employ to gain speed. https://speakerdeck.com/u/hdragomir/p/fast-mobile-uis https://speakerdeck.com/u/hdragomir/p/fast-mobile-uis It's still a long way to go from there, though. I work on Pocket Island, at wooga.
  - novalis 14y ago
    Thank you for the link. I just don't know how RemoteInspector negates the existance of a FlashPlayerDebugger, so the "thank you" part of the slides is exagerated in my modest view. I use Haxe and compile mostly to the c++, Android and HTML5 targets (and soon to Haxe/Flambe through Wafl, I hope) but the .swf target is and has been serviced by a localhost debugger for a long time. The debugger is available for Active X, NSPAPI for the other browsers and through a standalone version. Also, your caching experiences will vary from other people using other caching solutions, add to that non blocking node.js backend or a neko vm threaded server and the "loading js will freeze the UI" slide turns to something diminute. But I believe that can only be achieved by not depending only on pure javascript solutions for all parts of the mobile app. Contrary to your inference in the slides. I think your advice is perfect for offline webview implementations but that is only part of the problem when online service connections come into the picture, don't you think ?
    - hdragomir 14y ago
      You are right. The slides are very vague, I know -- and I'm working on that. I do talk a lot about loading assets and logic and how hard it is to actually get stuff across in a nice way. I never say go pure javascript. What I say is that you don't need mammoth frameworks on top of javascript. We ended up depending on PhoneGap quite a bit in the end. Thank you for the great comment
tomjen3 14y ago
I beg to differ. The company I work for (cego.dk) has released an HTML5 game (you can play it here http://chrome.voodoofriends.com/ http://chrome.voodoofriends.com/) and yeah there is a ton of small things you have to take care of, and yes IE9 is a pain in the ass but you can mostly bundle the source code and just ship it on the appstore (http://itunes.apple.com/us/app/voodoo-friends/id514562699?mt=8 http://itunes.apple.com/us/app/voodoo-friends/id514562699?mt...) and what you can't just bundle are things like in-app pucharces which will never be crossplatfom and a few issues with sound. Is it worth it? Well that depends on what your goals are and what your belief in the future is. If you think IOS is enough, then go for it (and use the better performance to make a more beautiful game) but if you don't like to build on somebody else land, HTML5 is the best news in a very long time. BTW the app is currently free on the app store but I doubt it will be for long.
- batista 14y ago
  While you "begged to differ", your answer is full of caveats and little assurances...
laserDinosaur 14y ago
"The promise of HTML5 is still an exciting one and while the time for mass market implementation may not be in 2012, we’re confident its time will come." Considering the specs are not even projected to be completed until around 2015, I think they might be stating the obvious here. Of course HTML5 is not ready yet, it's not ready yet.
- daleharvey 14y ago
  You arent stating the obvious, just a misunderstanding of the standardisation process "HTML5" is not a single thing, and it wont suddenly be released in 2015, there is a lot to it and a lot of people are using various parts now and have been for a long time.
- tudorizer 14y ago
  I wonder how the browsers will be in 2015...
  - robmcm 14y ago
    I wonder how the hardware will be in 2015...
marknutter 14y ago
It's ready when people start using it, and people have started using it.
daleharvey 14y ago
really confused by the description of their issues, yes you need to be online to access and download the game the first time, no you shouldnt need to be online to play it, yes an app packaged for offline still has access to a server. Congrats to them to opening up the source and publishing this, html5 gaming is still a pretty new field and everything like this helps.
- hdragomir 14y ago
  The problem was getting fresh content (missions, better assets, what have you) to the user. If you go with long autonomy, you get a fairly static game which you can update in big jumps. If you go with fast updates, you sometimes delay the startup of the app. Either way, getting your application across initially can take some time. Originally, the game was meant to run within the Facebook app -- for which you would always need internet so we had to optimize for fast delivery. I work on Pocket Island, at wooga.
  - daleharvey 14y ago
    I dont see where there is any conflict between how it works natively and how it can/should work with an offline web app though. The assets shouldnt take any significantly different time to transfer between native / html, and you have the same choices of when you want to transfer them
  - zanny 14y ago
    Web workers!
kripken 14y ago
> As any HTML5 developer will tell you, coding HTML5 is hard work. I develop using HTML5 or whatever we want to call it, and I most definitely do NOT say that.
- lukifer 14y ago
  Agreed. I also found this amusing: "What is a simple task on native apps can be a decidedly more complex and time consuming task with HTML5." While this is true for some tasks (web audio still sucks), it's the other way around for other tasks (last time I tried to dynamically re-flow text in iOS was a nightmare). They also assume a gaming context, which is just one of many things that can be done with HTML5. The way I see it, HTML5 is absolute ready for use, but not fully matured, similar to web applications in the days of Netscape. Understand the tradeoffs of the various ecosystems, and pick the best tool for the job.
  - jcromartie 14y ago
    When I want to dynamically re-flow text on iOS, I use HTML in a UIWebView. Otherwise, native is easier for presenting a navigable and interactive UI. Using the right tool for the job is always the way to go.
  - hdragomir 14y ago
    Then, in the spirit of your last comment, for making pretty games on mobile devices, stick to native for now. I work on Pocket Island, at wooga.
kunle 14y ago
One tough thing for HTML5 is that the platforms that the community want to write for (iOS & Android) have no intrinsic incentive to actually support it (other than lip service). A world where HTML5 is dominant for the most profitable tier of games or apps is a world where the best developers dont have to write in iOS & Android (where Apple and Google respectively make their money), so given that, what's their incentive to make sure HTML5 reaches feature/performance parity with their native platforms?
- Peaker 14y ago
  Apple is claiming that the app store is break-even. That it benefits them only indirectly by making iOS a more attractive choice. If that is true, and HTML5 worked better with iOS than with Android, that would work well within that strategy. I think perhaps there are other reasons for poor HTML5 support on the mobile platforms.
  - zmmmmm 14y ago
    > it benefits them only indirectly by making iOS a more attractive choice Since you agree it benefits them - and your use of the word "only" is deceptive here; having the best app catalog is no marginal thing, it is an enormous benefit, often cited as the primary reason Android tablets have struggled and why WP7 failed - why don't you think that benefit - which exists primarily because HTML5 still sucks for mobile apps - incentivises them not to improve browsers? It would be trivial for both Google and Apple to remove a large number of the barriers to HTML5 apps replacing native apps. But they don't, and it's been long enough that time is not an excuse.
  - ThomPete 14y ago
    Apple don't want the app store to be anything but break even. They have it because it's a way to make money where it really matters which is the hardware.
  - hdragomir 14y ago
    wooga chose to focus on iOS because of the less fragmentation. I work on Pocket Island, at wooga.
Craiggybear 14y ago
HTML5 may not be finished but it is ready.
drivebyacct2 14y ago
Sounds like they were not using offline caching (correctly?) at all and had very obvious side effects as a result.
- jcromartie 14y ago
  Last time I experimented with this, it was not a viable option for my use case for several reasons.
- hdragomir 14y ago
  We did use offline caching aggressively when we launched with Facebook. Most of that logic has been removed, though, when we went the PhoneGap route. Also, https://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag https://speakerdeck.com/u/jaffathecake/p/application-cache-d... I work on Pocket Island, at wooga.
posabsolute 14y ago
What a bad choice of title (on HN). It's totally not what the article is saying, it only focus on gaming, and specially on mobile. That being said an interesting article on a interesting html5 game.
azakai 14y ago
> HTML5 is not ready. I am guessing there was serious effort behind this game, but... it doesn't even run on Firefox. One of the basic things in writing HTML5 apps is testing on multiple browsers, so I guess this was not tested much?. So I am not sure what to make of the seriousness of this project and how valid its conclusions ("HTML5 is not ready") are.
- georgemcbay 14y ago
  The fact that any project that stresses HTML5 at all often behaves very differently in different browsers to the point where most HTML5 demos list a "works on this browser" message is a pretty good argument that HTML5 is not ready, IMO.
  - azakai 14y ago
    I see that point, often there are minor differences between browsers and it's hard to fix them all, but it isn't that hard to at least get your app to load in the main ones. This failed at that.
bhalden89 14y ago
HTML5 is not ready? HTML5 games may not be ready for mobile browsers, but check out what CocoonJS can do: http://blog.ludei.com/html5-fails-to-deliver-for-mobile-games-cocoonjs-begs-to-differ/ http://blog.ludei.com/html5-fails-to-deliver-for-mobile-game...
pjmlp 14y ago
Native apps are the way to go to fully take advantage of the target platform, specially when doing games. HTML/JS/CSS is a lousy way to code applications. I feel the pain everyday.
- david927 14y ago
  I feel your pain, but HTML5 can get rid of that stack, especially when doing games. It goes from HTML/CSS/JS to just JS.
huskyr 14y ago
“Sound on HTML5 has some peculiar limitations. It can only be activated via user action and there’s a delay of about half a second that can make for a strange in-game atmosphere.” Sound on HTML5 audio on iOS has this limitation. It's not at all specific to HTML5. iOS 6 will get the web audio api which hopefully will solve some of these problems.
- hdragomir 14y ago
  Please don't get me started on Android. :-) And as mentioned in a previous comment, this is mostly about Mobile HTML5. I am also keeping my fingers crossed for iOS6! I work on Pocket Island, at wooga.
  - huskyr 14y ago
    The only way i could get 'HTML5 audio' to work on Android 3.0 was by using Flash. Which is...pretty ironic.
cromwellian 14y ago
Angry Birds for the Web was developed for HTML5 and it works reasonably well on desktops and cross-browser (runs on Chrome, Firefox, and IE9+) It runs offline via HTML5 AppCache, via Chrome app, or online. Maybe your article should be titled "Writing games in HTML5 for Mobile Devices is not ready". because I don't think the same reasoning applies to the desktop. You won't achieve 100% reach, as you will fail on some combination of hardware, but perfect is the enemy of the good here. Also, I think there is a little bit of arrogance in the two articles Wooga posted. They claim they are one of the most technologically sophisticated HTML5 games, but that seems dubious. Angry Birds, Field Runners, Bejeweled, Sonar, and Cut The Rope, are just a few of many of the games out there are push the limits of HTML5 performance, and are much smoother than Wooga's offering and do more onscreen. I don't want to bash them, I just want to make the point that if they are having performance issues, it's not because they are pushing the limits of what the browser is capable of. The real lesson is that mobile browser performance sucks, especially Canvas operations. If and when Mobile Safari and Chrome for Android get WebGL, mobile HTML5 games might be more plausible. Javascript performance on mobile has been doubling roughly every generation. The newest WebKit implementations like iOS6 support the Web Audio spec which addresses low latency sound, and File System APIs for local storage. In another generation, it may be more viable. Have a look at Quake ported to HTML5 done in 2010 by me and a few others: http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=player_embedded http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=playe... Back then, it ran at 45-60fps. Today, it runs at 200+fps on Chrome on the same machine. There are options for multiplatform development. Angry Birds was done with PlayN, in which you write you game in Java, and we compile it to JS (with GWT targeting CSS3+DOM, Canvas, or WebGL), Android (run direct on dalvik with OpenGLES), Flash (via GWT->ActionScript compiler), and IOS (via translation to CLR + Monotouch ahead of time compiler) hAXe is another similar platform. Write code in ActionScript3-like typed-Javascript, compile to JS/SWF/C++/Objective-C/etc.
- kombine 14y ago
  > Javascript performance on mobile has been doubling roughly every generation This is a very strong statement. And even if it was true, there still are fundamental limitations to Javascript performance, i.e. you wouldn't expect it to reach the native performance.

76 points by cientifico 14y ago

To be quite honest I find the biggest drawback for HTML5 on mobile devices is speed. Even simple applications have a noticeable lag that isn't present (or can be hidden) on Native applications. As an example (as used in the article), Facebook is one of the worst performing apps on my phone, often taking me to places I never touched and crashing occasionally. Therefore I would suggest that the hardware/implementation still needs to catch up first before choosing a blanket HTML5 architecture (which mind you the hardware is doing gradually). Now, perhaps it because I am testing on older hardware; however this is for good reason. I test based on hardware that my clients/target audience use - if they upgrade and they get a speed increase then that's a bonus - but until then they need to get the best possible experience given the hardware they have. I will use HTML5 for applications if I can get a reasonable return on investment by doing so, but usability is always number one - if it doesn't perform well then it may as well be thrown out.

hdragomir 14y ago
This is also a big problem we have encountered, and I've even summed up most of the workarounds and hacks you have to employ to gain speed. https://speakerdeck.com/u/hdragomir/p/fast-mobile-uis https://speakerdeck.com/u/hdragomir/p/fast-mobile-uis It's still a long way to go from there, though. I work on Pocket Island, at wooga.
- novalis 14y ago
  Thank you for the link. I just don't know how RemoteInspector negates the existance of a FlashPlayerDebugger, so the "thank you" part of the slides is exagerated in my modest view. I use Haxe and compile mostly to the c++, Android and HTML5 targets (and soon to Haxe/Flambe through Wafl, I hope) but the .swf target is and has been serviced by a localhost debugger for a long time. The debugger is available for Active X, NSPAPI for the other browsers and through a standalone version. Also, your caching experiences will vary from other people using other caching solutions, add to that non blocking node.js backend or a neko vm threaded server and the "loading js will freeze the UI" slide turns to something diminute. But I believe that can only be achieved by not depending only on pure javascript solutions for all parts of the mobile app. Contrary to your inference in the slides. I think your advice is perfect for offline webview implementations but that is only part of the problem when online service connections come into the picture, don't you think ?
  - hdragomir 14y ago
    You are right. The slides are very vague, I know -- and I'm working on that. I do talk a lot about loading assets and logic and how hard it is to actually get stuff across in a nice way. I never say go pure javascript. What I say is that you don't need mammoth frameworks on top of javascript. We ended up depending on PhoneGap quite a bit in the end. Thank you for the great comment

tomjen3 14y ago

I beg to differ. The company I work for (cego.dk) has released an HTML5 game (you can play it here http://chrome.voodoofriends.com/ http://chrome.voodoofriends.com/) and yeah there is a ton of small things you have to take care of, and yes IE9 is a pain in the ass but you can mostly bundle the source code and just ship it on the appstore (http://itunes.apple.com/us/app/voodoo-friends/id514562699?mt=8 http://itunes.apple.com/us/app/voodoo-friends/id514562699?mt...) and what you can't just bundle are things like in-app pucharces which will never be crossplatfom and a few issues with sound. Is it worth it? Well that depends on what your goals are and what your belief in the future is. If you think IOS is enough, then go for it (and use the better performance to make a more beautiful game) but if you don't like to build on somebody else land, HTML5 is the best news in a very long time. BTW the app is currently free on the app store but I doubt it will be for long.

batista 14y ago
While you "begged to differ", your answer is full of caveats and little assurances...

laserDinosaur 14y ago

"The promise of HTML5 is still an exciting one and while the time for mass market implementation may not be in 2012, we’re confident its time will come." Considering the specs are not even projected to be completed until around 2015, I think they might be stating the obvious here. Of course HTML5 is not ready yet, it's not ready yet.

daleharvey 14y ago
You arent stating the obvious, just a misunderstanding of the standardisation process "HTML5" is not a single thing, and it wont suddenly be released in 2015, there is a lot to it and a lot of people are using various parts now and have been for a long time.
tudorizer 14y ago
I wonder how the browsers will be in 2015...
- robmcm 14y ago
  I wonder how the hardware will be in 2015...

marknutter 14y ago

It's ready when people start using it, and people have started using it.

daleharvey 14y ago

really confused by the description of their issues, yes you need to be online to access and download the game the first time, no you shouldnt need to be online to play it, yes an app packaged for offline still has access to a server. Congrats to them to opening up the source and publishing this, html5 gaming is still a pretty new field and everything like this helps.

hdragomir 14y ago
The problem was getting fresh content (missions, better assets, what have you) to the user. If you go with long autonomy, you get a fairly static game which you can update in big jumps. If you go with fast updates, you sometimes delay the startup of the app. Either way, getting your application across initially can take some time. Originally, the game was meant to run within the Facebook app -- for which you would always need internet so we had to optimize for fast delivery. I work on Pocket Island, at wooga.
- daleharvey 14y ago
  I dont see where there is any conflict between how it works natively and how it can/should work with an offline web app though. The assets shouldnt take any significantly different time to transfer between native / html, and you have the same choices of when you want to transfer them
- zanny 14y ago
  Web workers!

kripken 14y ago

> As any HTML5 developer will tell you, coding HTML5 is hard work. I develop using HTML5 or whatever we want to call it, and I most definitely do NOT say that.

lukifer 14y ago
Agreed. I also found this amusing: "What is a simple task on native apps can be a decidedly more complex and time consuming task with HTML5." While this is true for some tasks (web audio still sucks), it's the other way around for other tasks (last time I tried to dynamically re-flow text in iOS was a nightmare). They also assume a gaming context, which is just one of many things that can be done with HTML5. The way I see it, HTML5 is absolute ready for use, but not fully matured, similar to web applications in the days of Netscape. Understand the tradeoffs of the various ecosystems, and pick the best tool for the job.
- jcromartie 14y ago
  When I want to dynamically re-flow text on iOS, I use HTML in a UIWebView. Otherwise, native is easier for presenting a navigable and interactive UI. Using the right tool for the job is always the way to go.
- hdragomir 14y ago
  Then, in the spirit of your last comment, for making pretty games on mobile devices, stick to native for now. I work on Pocket Island, at wooga.

kunle 14y ago

One tough thing for HTML5 is that the platforms that the community want to write for (iOS & Android) have no intrinsic incentive to actually support it (other than lip service). A world where HTML5 is dominant for the most profitable tier of games or apps is a world where the best developers dont have to write in iOS & Android (where Apple and Google respectively make their money), so given that, what's their incentive to make sure HTML5 reaches feature/performance parity with their native platforms?

Peaker 14y ago
Apple is claiming that the app store is break-even. That it benefits them only indirectly by making iOS a more attractive choice. If that is true, and HTML5 worked better with iOS than with Android, that would work well within that strategy. I think perhaps there are other reasons for poor HTML5 support on the mobile platforms.
- zmmmmm 14y ago
  > it benefits them only indirectly by making iOS a more attractive choice Since you agree it benefits them - and your use of the word "only" is deceptive here; having the best app catalog is no marginal thing, it is an enormous benefit, often cited as the primary reason Android tablets have struggled and why WP7 failed - why don't you think that benefit - which exists primarily because HTML5 still sucks for mobile apps - incentivises them not to improve browsers? It would be trivial for both Google and Apple to remove a large number of the barriers to HTML5 apps replacing native apps. But they don't, and it's been long enough that time is not an excuse.
- ThomPete 14y ago
  Apple don't want the app store to be anything but break even. They have it because it's a way to make money where it really matters which is the hardware.
- hdragomir 14y ago
  wooga chose to focus on iOS because of the less fragmentation. I work on Pocket Island, at wooga.

Craiggybear 14y ago

HTML5 may not be finished but it is ready.

drivebyacct2 14y ago

Sounds like they were not using offline caching (correctly?) at all and had very obvious side effects as a result.

jcromartie 14y ago
Last time I experimented with this, it was not a viable option for my use case for several reasons.
hdragomir 14y ago
We did use offline caching aggressively when we launched with Facebook. Most of that logic has been removed, though, when we went the PhoneGap route. Also, https://speakerdeck.com/u/jaffathecake/p/application-cache-douchebag https://speakerdeck.com/u/jaffathecake/p/application-cache-d... I work on Pocket Island, at wooga.

posabsolute 14y ago

What a bad choice of title (on HN). It's totally not what the article is saying, it only focus on gaming, and specially on mobile. That being said an interesting article on a interesting html5 game.

azakai 14y ago

> HTML5 is not ready. I am guessing there was serious effort behind this game, but... it doesn't even run on Firefox. One of the basic things in writing HTML5 apps is testing on multiple browsers, so I guess this was not tested much?. So I am not sure what to make of the seriousness of this project and how valid its conclusions ("HTML5 is not ready") are.

georgemcbay 14y ago
The fact that any project that stresses HTML5 at all often behaves very differently in different browsers to the point where most HTML5 demos list a "works on this browser" message is a pretty good argument that HTML5 is not ready, IMO.
- azakai 14y ago
  I see that point, often there are minor differences between browsers and it's hard to fix them all, but it isn't that hard to at least get your app to load in the main ones. This failed at that.

bhalden89 14y ago

HTML5 is not ready? HTML5 games may not be ready for mobile browsers, but check out what CocoonJS can do: http://blog.ludei.com/html5-fails-to-deliver-for-mobile-games-cocoonjs-begs-to-differ/ http://blog.ludei.com/html5-fails-to-deliver-for-mobile-game...

pjmlp 14y ago

Native apps are the way to go to fully take advantage of the target platform, specially when doing games. HTML/JS/CSS is a lousy way to code applications. I feel the pain everyday.

david927 14y ago
I feel your pain, but HTML5 can get rid of that stack, especially when doing games. It goes from HTML/CSS/JS to just JS.

huskyr 14y ago

“Sound on HTML5 has some peculiar limitations. It can only be activated via user action and there’s a delay of about half a second that can make for a strange in-game atmosphere.” Sound on HTML5 audio on iOS has this limitation. It's not at all specific to HTML5. iOS 6 will get the web audio api which hopefully will solve some of these problems.

hdragomir 14y ago
Please don't get me started on Android. :-) And as mentioned in a previous comment, this is mostly about Mobile HTML5. I am also keeping my fingers crossed for iOS6! I work on Pocket Island, at wooga.
- huskyr 14y ago
  The only way i could get 'HTML5 audio' to work on Android 3.0 was by using Flash. Which is...pretty ironic.

cromwellian 14y ago

Angry Birds for the Web was developed for HTML5 and it works reasonably well on desktops and cross-browser (runs on Chrome, Firefox, and IE9+) It runs offline via HTML5 AppCache, via Chrome app, or online. Maybe your article should be titled "Writing games in HTML5 for Mobile Devices is not ready". because I don't think the same reasoning applies to the desktop. You won't achieve 100% reach, as you will fail on some combination of hardware, but perfect is the enemy of the good here. Also, I think there is a little bit of arrogance in the two articles Wooga posted. They claim they are one of the most technologically sophisticated HTML5 games, but that seems dubious. Angry Birds, Field Runners, Bejeweled, Sonar, and Cut The Rope, are just a few of many of the games out there are push the limits of HTML5 performance, and are much smoother than Wooga's offering and do more onscreen. I don't want to bash them, I just want to make the point that if they are having performance issues, it's not because they are pushing the limits of what the browser is capable of. The real lesson is that mobile browser performance sucks, especially Canvas operations. If and when Mobile Safari and Chrome for Android get WebGL, mobile HTML5 games might be more plausible. Javascript performance on mobile has been doubling roughly every generation. The newest WebKit implementations like iOS6 support the Web Audio spec which addresses low latency sound, and File System APIs for local storage. In another generation, it may be more viable. Have a look at Quake ported to HTML5 done in 2010 by me and a few others: http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=player_embedded http://www.youtube.com/watch?v=fyfu4OwjUEI&feature=playe... Back then, it ran at 45-60fps. Today, it runs at 200+fps on Chrome on the same machine. There are options for multiplatform development. Angry Birds was done with PlayN, in which you write you game in Java, and we compile it to JS (with GWT targeting CSS3+DOM, Canvas, or WebGL), Android (run direct on dalvik with OpenGLES), Flash (via GWT->ActionScript compiler), and IOS (via translation to CLR + Monotouch ahead of time compiler) hAXe is another similar platform. Write code in ActionScript3-like typed-Javascript, compile to JS/SWF/C++/Objective-C/etc.

kombine 14y ago
> Javascript performance on mobile has been doubling roughly every generation This is a very strong statement. And even if it was true, there still are fundamental limitations to Javascript performance, i.e. you wouldn't expect it to reach the native performance.