HTML5 isn't a magic bullet for cross-platform coding

HTML has undergone a step change in the last few years. Or perhaps more accurately, developers’ expectations of what HTML is capable of have undergone a step change; the improvement in the underlying technology has been more gradual. The result though has been that HTML is now seen as a serious development platform, with high profile successes ranging from’s web app to Google’s suite of web-based business tools.

Purists will insist that there’s no such thing as an ‘HTML5 app’, just an HTML one. The fifth revision of the HTML standard gave official approval to a variety of features for supporting mobile platforms better and for allowing richer graphical output. As with most of the features the standard introduced, these had mostly been introduced initially as browser-specific innovations, such as the <canvas> element first added by Apple for their Safari browser. While useful, they are less important than the previous decade’s improvements in CSS and the DOM, the innovation of AJAX, and in the emergence of Javascript libraries such as JQuery that smoothed out a lot of the cross-browser frustrations that historically bedevilled web development. But the term ‘HTML5’ has come to refer less to the actual set of revisions to the HTML specification and more to the concept that HTML and the associated web technologies are now powerful enough to implement deep, rich and slick applications that were previously only possible with plug-ins such as Flash.

It’s certainly true that HTML5 allows applications that go way beyond what webpages could traditionally manage. However, it’s easy to lose sight of how limited it still is – at least, until you actually try writing a piece of highly graphical, highly interactive code with it.

With time, effort, and highly skilled programmers, there’s not a lot that can’t be written in HTML. But often the same thing could be written in much less time in Flash or a different language, with less of a learning curve for the developers – and will look better to boot.

Let’s take a quick run-down of the disadvantages of HTML development:

  • The language isn’t set up for rich UI interaction. Sure it’s possible, but basic interactions such as drag and drop need carefully written custom code. That means more time spent prototyping and going down dead ends, where with a different language it’d be a matter of calling a standard library function.
  • Cross-browser support is uneven. This problem is less severe when targeting mobile devices than for desktop, since there’s less of a variety of browsers and the support for recent HTML features is better; but it’s still a tiresome issue that slows development and causes extra testing overhead. And when a section of UI has to be designed to gracefully degrade for IE6, say,
  • Development tools are more primitive. Javascript debuggers exist, and there are some fairly sophisticated IDEs; but because of the heterogeneity of the technologies involved and the lack of high-level standard code libraries, they support developers less effectively than tools designed for specific languages.
  • HTML was not built to achieve impressive visuals. Although it’s now capable of them, the way an HTML document is structured reflects its roots, where presentation was always a secondary concern. The layout system in particular can be maddeningly sensitive to small changes. Adjusting the position of one element can require major restructuring of the rest of the page. Yes, there are ways to minimise such issues; but again, it’s a whole extra stretch of learning curve for developers to master.
  • HTML is fragmented. Despite the attempts of the W3C to hold it to an official specification, browser support has always been rife with eccentricities, custom features and undocumented behaviour. The standard has been pushed forward by multiple competing groups, meaning there’s often several different ‘correct’ ways to implement a behaviour – and sometimes the only way to get it to work properly is with parallel browser-specific implementations.
  • And finally, the performance can run into hard limits on what’s possible, particularly with a mobile platform, where a native implementation can run that much more smoothly and crisply.

HTML5 is capable of a great deal these days. It’s a great choice for lightweight applications, particularly where a UI reminiscent of a standard web page is appropriate. There’s a vast level of investment and development going into new tools, libraries and frameworks to make it easier to use. The increasing support for vector graphics in HTML has particular promise, including the continuing improvement of PDF-to-HTML and SWF-to-HTML automated conversion software.

However, it’s not on a par with other technologies, and there’s a reason why the vast majority of phone and tablet apps are written in native languages. For simple applications, it’s an excellent way to get the software working cross-platform. For anything more graphically intensive, developers continue to need alternatives.

Categories: Experts

Tagged as: , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s