The Disastrous Fragmentation Of Web Apps
Written by Mike James   
Friday, 26 October 2012

Web apps are a great idea. You write an app once and it works on everything - where have we heard that idea before? However things aren't quite working out as expected. There are huge splits appearing in the fabric of HTML5 and the web app.

For a web app you work using nothing but standards-based technologies - HTML5, CSS and JavaScript  - and your app will run on anything that can browse the web.

Sounds good, but it's going disastrously wrong and in the main the people responsible for the mess seem to be working from the best intentions.

Web apps are easy, until you actually try to create one. In principle. all you have to do is learn HTML5, CSS and JavaScript and start working on your creation. However, this misses a few important points.

The first is that the standards aren't enough to get you access to the platforms' hardware. W3C has made lots of attempts to create standards that allow you to access the hardware, but most of them are first drafts and, even if they aren't, the degree to which each browser implements these non-core HTML5 standards varies so much that they might as well not be standards.

This is the reason that frameworks like PhoneGap, or its open source version Cordova, exist. They have custom JavaScript libraries that provide access to a range of supported mobile devices - iOS, Android, Window Phone (WP7), etc.

This framework-based approach is a good one, but it isn't standards-based unless you pick a single framework to be your standard. A more serious problem is that this creates an artificial split between mobile devices - phones and some tablets - and the bigger computing platforms like laptops and desktops. There is also the problem of where the new browser-based OS machines - Firefox OS and Chrome OS - fit in These are not supported by the commonly encountered frameworks.

The problem is really caused by the frameworks moving the web app from the browser into a custom built container which mimics a native app. Essentially what is happening is that, instead of running the web app in a browser, it runs in a special native app container and, while browser versions exist for the desktop, portable, tablet and phone platforms, the containers are generally available only on phone/tablet systems.  In particular, it makes no sense at all to add such a custom container to a browser-based OS.

In short frameworks simply create fragmentation.

To avoid such fragmentation we need to not only stay with web standards, we also need to use the browser as the host for the app.

The problem is which browser?

In theory, all browsers are created equal - because they implement the standards. Until quite recently we were passing through an amazing period where browsers were seeming to converge.

Now, however, both Firefox and Chrome are innovating new ways of accessing the hardware as part of their efforts to become complete operating systems. Usually when you look at the documentation there is a comment to the effect that "this API isn't standard but we are making efforts to make it a standard". This is good but doesn't really help.

IE is different from the other two main browsers because it isn't being driven by a need to become an operating system. IE has an operating system - i.e. Windows or Windows RT. It is evolving, but not in the same way that Firefox and Chrome are.

If you work really hard you can create an app that runs on both Firefox and Chrome. Usually you can't also accommodate IE unless the app has a very limited range of functions.

So to create a universal web app we have to stick to the browser - but who wants their app to look as if it is running inside a browser?

This brings us to our second big split - packaging.

Chrome has an application specification, a packaged app, which allows you to write a web app and have it treated as a standalone app. If you follow the instructions you can even have your app installed into the Chrome store and displayed on the Chrome app page. It will even run as an app under the Chrome OS. This is all good, but don't expect your Chrome app to work under Firefox .And we can forget IE as a candidate for packaged apps; Microsoft has a very different approach.

Firefox was very late to the idea that the browser could be an operating system. but it is catching up. What was called "boot to Gecko" is essentially Firefox as OS, and Firefox Web Apps is a specification for running your app under both Firefox and Firefox as an OS. The big problem is that this specification, which Mozilla is tying to convince everyone is some sort of standard by calling it "open web apps", is different from Chrome's.

This difference goes deeper than just the manifest and packing used to deliver and maintain the apps. Both browsers have quite deep APIs enabling their apps to get at facilities normally denied to web apps. 

In other words, Firefox and Chrome have become two different platforms for web apps.

This is not how it should be. Where has the write once run anywhere idea gone?

It is now write once and run on anything that Chrome runs on and write it again to run on anything the Firefox runs on.

This isn't' too bad because both are free and can be installed together on any supported device. But from the user's point of view it's not ideal. If you have an Android device do you really want to be forced to install Firefox when you prefer Chrome?

What about Microsoft?

As already mentioned, IE is a very different setup. Microsoft used to have a way of building web apps into the desktop - Windows Gadgets. However, these have been dumped in Windows 8 and you can't even use them any more under Windows 7. Even the Gadget store has been closed.

Why?

The answer is that Microsoft no longer wants you to use web apps on the desktop, but WinRT apps under WinRT - i.e. what used to be called Metro Apps. These don't run under IE at all,and so there really isn't any incentive to make IE into a browser operating system to compete with Windows and WinRT.

Finally, what about Apple and iOS?

Safari supports web apps, but again in its own particular way. It also doesn't offer any deep APIs to allow you to get at the system - just the standard HTML5 ways of doing things. This is the reason why recently there have been some comments about HTML5 apps not really being a good choice on iOS and how much better native apps are.

The reason is that while Chrome and Firefox are being developed to allow web apps to be as good as native apps, or as good as they can be, Apple really doesn't want web apps to equal native apps. The reason is that it has control over native apps but not so much over web apps. Again, this is a marketing/business decision - nothing to do with technology.

So there you have it.

If you want to write a universal web app then you need to target the browser.

Only the browser has any hope of supporting the same app across desktop, tablet and phone applications because the browser is the only entity which runs HTML5, CSS and JavaScript across all of these platforms.

However, if you target the browser with a packaged, standalone, web app you immediately discover that Firefox and Chrome are doing things their own way, IE isn't doing anything much at all and Safari is hobbled to keep iOS native apps on top.

It isn't the best of all possible worlds but if you want to create web apps that work well you have to either target Chrome or Firefox. As both run on Android and Windows the only platform that you miss out on is iOS.

 

Related Articles

Microsoft goes native - HTML5 that is

Why Do We Tolerate IE? Just Say No

Semantic HTML5?

Creating Web Apps - The Camera API

The One Addition That Would Make HTML5 Great

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin,  or sign up for our weekly newsletter.

Banner

Last Updated ( Friday, 26 October 2012 )