On Tue, Jan 29, 2013 at 9:00 PM, Lee Burrows <subscripti...@leeburrows.com>wrote:
> 2) JS performance varies widely across browsers and even for best > performers, its not that snappy. > > Well, compiling AS3 to JS solves #1 but what about #2? > I'd expect that at least it doesn't make #2 any worse. The minimum overhead introduced to simulate some AS3 language features is usually negligible or even overruled by the cleaner application design. Building snappy HTML5 applications is still a challenge, but this is true for any application. The story of Sencha re-building Facebook's mobile client in HTML5 http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ shows that a) performance can vary across platforms, even or especially when implementing native (Facebook's original Android client was less snappy than Sencha's HTML5 counterpart) and that b) it was rather a question of software engineering to end up with a snappy client, not a question of technology. Another aspect is that I expect Flex to be used rather for business applications than for, e.g., games. In contrast to 3D or particle simulations, the things that have to feel snappy in business applications are well supported in the browser, e.g. smooth scrolling (e.g. through CSS3 transforms). When doing graphically rich stuff, it is also rather the browser's canvas or SVG implementation that is the limiting factor, not the JavaScript engine. My experience from converting some 2D Flash retro games to HTML5 is that on a desktop browser, they are probably factor 3 more CPU-intensive, but still fast enough. WebGL might even totally change this. So it is really hard to say right now, but I'm sure that if we always take performance into account and in an opt-in fashion use the latest browser technologies, it is possible to build Flex so that it allows you to produce JS applications that are sufficiently snappy on every reasonably new device. Greetings -Frank-
