4 ms·

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 b

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

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