HTML5 and JavaScript seems to be getting a lot of attention and being pushed as the next great set of technologies for write-once-deploy-many for mobile devices. If that crystallizes it would be great – wouldn’t it – like a nirvana for software developers. Imagine only have to develop once, and by sheer miracle you support n number of platforms. Brings back memories from similar pitches and discussions when Java was invented.
I’m not concerned with HTML5/JS as technologies, but more the perception that those specific technologies (could be any technology) are THE silver bullet that’ll allow you build build once-and-deploy-many without additional work. Similar pitch and hype that surrounded Java initially – and that didn’t really crystalize. Even if HTML5 becomes the predomination approach for rendering UI on a variety of devices, none of the devices will share equal characteristics, literally meaning that there’ll still be work – and sometimes significant work – to do for each specific device you want to render against, e.g. there’s a huge difference between the UX/UI on an iPad and an iPhone, that won’t be automatically resolved by using HTML5 – nor will it be automatically resolved using native tooling. A very good example of this, was that initially everybody believed that users would accept viewing web pages designed for desktop browsers on their mobile devices. It quickly turned out, that companies not offering a special tailored mobile version of their web lost viewers, and HTML got extended with features to determine whether or not you were on a mobile browser, and would then redirect you to a special mobile web page.
Take the above into consideration when vendors argues that you can support a number of different devices with same code base. It’s partly a true statement, as long as the screen doesn’t change too much. As soon as you change the screen you’re HTML based application will either sit nailed in the top-left corner or scale all elements to fit the new physical screen dimensions. Either way, there’s a huge risk that your app ends up looking skewed. To avoid that you’ll have to implement logic to accommodate that. In the event that you aren’t too concerned with the look, then this is a non-issue. But you may lose users or people will rate your app as unattractive.
There’s also the challenge of using the native capabilities of the devices. Vendors of platforms offers different levels of API that maps to the underlying OS, and recently they’re starting to push the notion of plugins – like PhoneGap. These plugins allow you to develop native code that you can call from JavaScript, which is nice, but it does raise the question why this is needed. My take is that it’s needed simply because the API offered aren’t always extensive enough to support all possible permutations of usage of the underlying OS. But seriously, if you have to do that – what’s the whole point using HTML5/JS then, as you end up having plugin code for each device that you need to maintain.
Almost every vendor of cross-platform tooling based on HTML5/JS web pages states that the key driver for using these tools are the ability to repurpose skill sets that your web developers already got – HTML and JS. Instead of having to learn new technologies. Simply because that’s cheaper than having to hire iOS developers, which are hard to get by and notoriously expensive. The funny thing is that on Android and RIM the language is Java, something that most HTML/JS developers knows as well – or C# for WP7, which all .NET developers knows (Visual Basic will be added).
On the native side, an idea could be to encapsulate anything that concerns business logic in a device agnostic language like JavaScript or Lua scripting, embed that in the native application and only focus on UI/UX when writing native code. It’ll give you total access to the underlying OS, all it’s capabilities and ability to build whatever you want without the additional abstraction of HTML5/JS and wrappers. The abstracted code can be maintained centrally and extended without impacting the native code, e.g. if there’s changes to validation rules you can update the library without having to change one single line of code in the native applications.
Long story short, my reluctance isn’t about the technologies, but about the perception that we all of a sudden can support all possible permutation of devices and OSes just by using HTML5/JS. Which won’t be the case.
Claus Jepsen 