Amazon recently moved to provide direct support for HTML5 web apps in its app store. It makes you wonder why the benefits of web standards still aren’t pushing more apps away from tedious device specific UI development. One factor is that while Amazon is giving a boost to HTML5 mobile apps, Apple’s iOS (still with the largest app catalog by far) actually penalizes them. You can choose the speed that comes with native or the standards and portability that come with hybrid apps but not both.
But there is a way to get HTML5+good mobile app performance. What if we could combine the best aspects of native and hybrid apps by compiling Javascript into fast native code while retaining all the advantages of HTML5? This could be thought of as an accelerated hybrid mobile app.
typically hybrid app architectures have fewer skillsets for developers to learn
Fixing the Right Problems
The biggest problem with native apps is the weak story around user interface development. For example, not much of the work can be cross platform. Developers have to be involved in tasks that should be able to be handed over to designers with no coding experience. Moreover, the incredible toolchain and ecosystem that exists around HTML5 and CSS3 cannot be exploited.
On the other hand, hybrid solutions like trigger.io and PhoneGap solve these user interface problems by embracing HTML5 and JavaScript, however JavaScript is not as fast as native code. Even worse, much worse in fact, is that Apple limits these solutions by removing many optimizations from UIWebView, the component that enables HTML5 rendering in iOS hybrid apps. The result is that CPU bound JavaScript in a hybrid app can be up to 300% slower compared to JavaScript in mobile Safari.
So developers are kind of damned if they do, damned if they don’t. The end result is significant but different flaws in both native and hybrid approaches.
The table below compares the strengths and weaknesses of different approaches to building mobile apps. The scoring details could be debated ad nauseam, but the point is to note the broad implications. Included for comparison is Xamarin, a native app solution that uses clever technology to allow C# and .NET to be compiled into native code.
some strengths and weaknesses of native and hybrid architectures
Accelerated Hybrid Mobile Apps
An accelerated hybrid mobile app is one that uses HTML5 for rendering and JavaScript that is statically compiled to native code. Typical hybrid apps do not compile to native code and use an interpreter to run JavaScript.
One of the columns in the chart above is Xamarin for HTML5 Mobile Apps. This is not a real product. It’s a hypothetical solution to show how existing technology could be used to create an accelerated hybrid mobile app. I might be the last person on earth Xamarin would ask to announce a real new product given that I recently critiqued their product. However, Xamarin is a good example of how a non-native programming language can be ahead of time compiled into native device code.
Compiling JavaScript
Compiling most JavaScript to native code could bypass the artificial performance limitations in UIWebView, and potentially increase performance on all mobile platforms. Once the JavaScript is compiled to native code the biggest remaining factor is rendering the HTML. This is not as fast as bare metal native UI widgets, but the interesting part is browser based rendering is continually getting faster as more and more browser display functionality becomes hardware accelerated. While the gap between HTML display rendering and native rendering may never go away, it is steadily shrinking.
Technologies like asm.js are also intended to speed up JavaScript but do so by restricting language features to make life easier for the interpreter and optimizer. However, as mentioned, many optimizations are turned off in UIWebView, making it questionable how much asm.js could actually help in a hybrid scenario.
Why hasn’t this been done already?
Certainly one reason this hasn’t already be done is the difficulty of statically compiling a dynamic language. For example, JavaScript requires no type declarations. When a compiler first sees a variable, it’s sometimes hard to tell even if a string operation or arithmetic will be needed during execution.
Another issue is JavaScript’s eval function that can run arbitrary code fragments passed to it. It can be hard to statically compile code when part of that code could come from something the user pastes into an input field at runtime.
One way to address these challenges is to constrain the problem space with respect to typing and eval functionality. Microsoft’s TypeScript shows how a superset of JavaScript can be used to provide more type information to the toolchain, while allowing annotations and compatibility with existing libraries. TypeScript is also attempting to be compatible with ECMAScript 6 which adds a non-trivial amount of sanity to JavaScript development in general. So one compromise might be to allow hybrid app code to be statically compiled for modules that use type annotations and that restrict use of eval to JSON input rather than allow arbitrary code execution.
When I mentioned this to Miguel de Icaza on Twitter he responded that he thought it would be possible but that the compiled Javascript might still not be fast enough. Not sure if he was comparing the prospect to 100% native code, but even to match the performance of mobile Safari could be a huge win (vs. UIWebView without optimizations).
To put into perspective the potential of modern Javascript, Microsoft is putting it forward as an equal alternative to .NET for building Modern UI apps on Windows 8 mobile devices. Google’s V8 engine is legendary for it’s performance. Asm.js has shown JavaScript done right can hold it’s own as a 3d gaming engine. These are all examples of Javascript only using an interpreter, albeit in concert with great run-time optimizers.
Bypassing some of the significant Javascript performance limitations on mobile devices, especially iOS, could end up vastly growing the class of apps that might be appropriate and practical for an HTML5 hybrid architecture.