How Native is Native?

Posted on by

Just a fairly obvious thought that’s been kicking around in the empty space between my ears for a few weeks now. It really came to the fore when I was casting my eyes over HP’s webOS developer platform. I didn’t read so much of it but I did read (from here);

“You can think of webOS applications as native applications, but built from the same standard HTML, CSS and JavaScript that you'd use to develop web applications. Palm has extended the standard web development environment through a JavaScript framework that gives "standardized UI widgets, and access to selected device hardware and services.”

and I thought this was “interesting” in that a lot of folks have started conversations with me along the lines of;

“Is the answer native or HTML?”

and I think that the terminology is wrong.

I don’t think the choice is between “native” and “HTML”, I think the choice is between;

  • Standardised clients – I think I’d call this the “Standards API Client” or SAC.
  • Proprietary clients – I think I’d call this the “Proprietary API Client” or PAC.

and so you can write your client using HTML today, CSS, JavaScript and you have the opportunity of that client working pretty well in a browser on pretty much every platform out there although you’d perhaps end up writing different clients for different form factor devices.

If you’re feeling more progressive, you can target HTML5 and CSS3 and achieve the same effect with more functionality available to you albeit with potentially less browser support today across all devices as HTML5 hasn’t yet reached the point where it’s ubiquitous. Naturally, that’s a matter of time.

You build a standards API client. A SAC. You accept that the UI layer, API layer and language are owned by a standards body/process and that works for the application you’re building.

But, as in the webOS case, it’s pretty easy for a vendor to take that same set of implementation technologies and surface up proprietary APIs through JavaScript – anyone that’s hosted the WebBrowser control in .NET would know that you can provide an object for scripting whereby you could open up a channel to communicate from JavaScript through to the .NET framework and beyond into the native platform. It’s even more flexible if you were starting from unmanaged code and hosting the WebBrowser from that kind of environment.

So, it wouldn’t be “rocket science” to write a hosting environment that loaded up HTML and JavaScript and offered additional functionality to it either from the environment itself (like a browser does) or from the underlying OS.

Whether you’d ever do that from a web browser is a different question. The browser’s sandboxed so that’d need an awful lot of care and attention – you can’t suddenly surface underlying platform APIs to browser code but browser vendors do it in ways such as;

both of which are examples of in-browser exposure of proprietary APIs called from what would otherwise be a standards-based client.

Clearly, there are cases where you might be able to be a mixture of SAC and PAC. You might do a standards based client for 95% of your work but you might then just drop into some of that proprietary stuff on a per-browser or per-platform basis.

There’s also the question about which standards come into play – standards from whom and at what status?

Ultimately, though, I don’t think it’s about “HTML versus native” – I think it’s more a choice of whether you build a standards based client or a proprietary based client or, as is frequently the case today, both.

SACs versus PACs Winking smile