3 ms·

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

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

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