HTML is Still the Great Equalizer

If you had to sit down and write some software for end-users, which platform and language would you write it in now? How about five, ten years ago, or three years in the future? I believe the answer ought to be “HTML” for all of them1.

Of course, in the interim there have been platforms that have waxed and waned in popularity. Off the top of my head,

• Microsoft’s MFC/.NET platform.
• Apple’s Cocoa, iOS frameworks.
• Google’s Android SDK.

These are some platforms available now that make sense to develop on, whether for performance, discoverability, stability, or industry convention. That said, web apps have shown their resilience, and that they’re going to stick around. When I saw Microsoft announce Windows 8 today with native HTML5 app support, I figured that sticking with HTML is a great strategy on both sides of the platform.

Of course, Microsoft is hardly the first company trying to leverage web architecture for an operating system; Google’s Chrome OS is about to be released and HP’s WebOS is already in phones. Native support for the most popular customer OS in the world, though, is a pretty big deal: it puts web apps on the same standing as Microsoft’s own .NET, and acknowledges that web development can create a good user experience.

It’s actually pretty scary how fast HTML5 has come along. Chrome Experiments and Mozilla Labs have shown that today’s browsers – equipped with modern CPU’s, having direct access to GPU’s, and running optimized Javascript engines – are getting to be as capable as native applications. The driving force here is a combination of excitement for possibilities within the browser, and competition from browser vendors themselves to grab/keep a piece of the lucrative online search market.

For application developers2, the web stack now fulfills the “write once run anywhere” premise that Java made all those years ago. Browsers have reached a somewhat of a parity across computing platforms (desktop, mobile, and tablet), and development time is no longer doubled from having to support uncooperative clients3. Web frameworks and libraries are abundant and provide a wide field of choice, from easy-to-use scripting languages with built-in MVC architecture, to fast-running minimalist templating systems holding up thousands of clients per server deployed. And since code is pushed from servers to the browser client, pushing out patches, bug fixes and new features is just a new user session away.

For systems vendors and OS makers, supporting web technologies means attracting all the developers who have converted to the web stack, without having to spend nearly as much effort evangelizing a new platform (Apple’s WWDC, Microsoft’s PDC, and Google’s I/O are such events, although obviously they do a lot more). Getting easy ports of web applications is also a big plus, as evident by how often Angry Birds is cited as the app to legitimize a new platform. Supporting HTML gives a platform an instant developer base.

So the problem with web-based applications has always been its inability to provide as good of an user experience as native apps. With the amount of functionality and hardware access that browsers now provide with the HTML5 spec, though, the problem as more about the lack of a great UI library for a lot of these diverse web frameworks. iOS and OSX apps owe their good looks to Cocoa’s Core Animation library, and .NET updates their widget library with every iteration, but web developers are often forced to develop their UI and look-and-feel from scratch.

App frameworks like Sproutcore alleviate this issue to an extent, but OS vendors will want applications to retain their OS’s look-and-feel, and it’ll be up to the developer to provide a UI that’s better than the OS default and convince users to switch to using it. We already see this in some ways – Skype clients embed a good amount of HTML, and Adobe Air apps feel independent from the OS – so it’s more in changing the way users think about their apps, on both desktop and mobile.