Web apps: the future of the internet, or an impossible dream?
The web may have been created to share static documents, but today web browsers are capable of supporting sites that are getting close to the look and feel of apps we run directly on our phones and computers.
Fast forward several years and the web could be the platform of choice for building an app, rather than iOS and Android. That's a goal of the web standards body W3C, as part of its mission to refine the technologies the web is built upon.
Apps built around standard technologies created to build websites — primarily HTML, CSS and JavaScript — offer the promise of being able to build one app that, with some tweaking for different browsers and hardware, can reach nearly every device in the world that runs a browser.
In contrast, the native apps we're used to on smartphones or tablets are tied to a specific operating system. Under normal circumstances, an Android app can only run on a smartphone running the Android OS or an iOS app can only run on an iPhone or iPad.
The web's ability to serve a potentially enormous user base — without the cost of building the same app several times over for different operating systems — is what the W3C believes will make web apps dominate in future.
"Creating products and services that are accessible across devices is obviously extremely important from the point of view of developed markets where people will regularly use more than one device," said Jo Rabin, head of the Core Mobile Web Platform Community Group at W3C.
"The web quite clearly has the very significant advantage in that it has a totally cross-platform reach. The web is really the only viable platform on which you can say 'I will write this thing responsively and it will work, broadly speaking, on any device'.
"That can't be said of native and that seems to me a clear advantage of the web platform, and one that will be emphasised over and over again."
Web applications — the road ahead
The web might have a massive user base on its side, but there are plenty of hurdles between web apps and mainstream acceptance as a computing platform. Web apps today are not a match for native apps in many areas; running web apps offline is a sub-par experience, limited access to smartphone hardware makes simple tasks like saving photos more difficult than it should be and web app general performance lags that of native apps.
The W3C is under no illusions about how much work it needs to do to get browser technologies born to serve static web pages to a point where they can efficiently build web apps that people want to use.
"There are relatively simple use cases that you ought to be able to carry out using web technology but at the moment you can't because the standards are not ready or haven't been written or because of interoperability difficulties," Rabin said.
Common tasks that people might want to carry out on a phone or tablet — storing photos and voice recordings locally, making calendar entries or navigating using a phone are all still too difficult to implement well in a mobile web app, the mobile web group found.
There is also the problem of the web platform itself not being consistent, in that the same app may look or behave differently across different browsers. There are differences in what mix of web technologies — primarily HTML, CSS and JavaScript — and features each of the major browsers support, leaving developers to have to implement workarounds for missing features in different browsers. Even where the same technologies are implemented across browsers there are cases of these technologies being implemented differently.
The W3C CG identified the need for better software for browser makers to check they have implemented web technologies in the same way so that web pages and apps look the same in every major browser without developers having to dance around quirks.
To address these shortcomings the W3C is lending staff support and resources to the Core Mobile Web Platform Community Group and reinventing it as the Web and Mobile Group Interest Group. The group's remit is to marshall the various W3C groups that draw up the specifications for web technologies so they can come up with the baseline set of web technologies that can be used to build mobile apps.
There are a number of areas where mobile web apps currently fall short, but there is also a lot of work currently taking place to bring web technologies up to speed.
1. Offline capabilities
The first attempt at getting offline to work for web apps, HTML5's application cache (appcache) feature, has been widely pilloried for its shortcomings, and inspired such colourful screeds as "Application Cache is a Douchebag".
The spec has several seemingly counter-intuitive features, such as not automatically loading fresh content once data had been cached, even if the user is online. Jake Archibald, Google Chrome developer advocate and author of the aforementioned article, said that appcache is based upon a number of high-level and faulty assumptions about how applications will want to cache data.
"People found it difficult to deploy in the manner in which it was intended to be deployed," said the W3C's Rabin, who is also CTO at mobile marketing agency Sponge.
"In the light of experience we discovered you couldn't do some things that people wanted to do."
The W3C Web Applications Working Group is now looking at the use cases that need to met by the next generation of appcache.
Any improvements to offline capabilities will complement work already taking place to run web apps outside the browser. The web platform is being used as the basis for a growing number of operating systems, first through Chrome OS and now with Mozilla's smartphone-targeted Firefox OS. Google recently made 'packaged apps' — Chrome web apps that behave more like native apps and can be run offline and outside the browser — the centrepiece of its Chrome Web Store.
Local storage is another area being lined up for an overhaul, with the recent publication of a definition for a new web storage API, which would allow megabytes of data to be stored by apps and sites running on the browser.
2. Performance
The slower performance of web technologies relative to native software is another stick that is used to beat the web apps.
As the defacto scripting language of apps in the browser, JavaScript is somewhat of a millstone when it comes to performance. On the one hand it is an interpreted language, which until recently meant that JavaScript source code acted as instructions for a piece of software called an interpreter, rather than being compiled into machine code. This is the feature that gives JavaScript its portability between platforms, allowing it to run on a browser regardless of whether that browser is running on a Mac, Windows or Linux PC, or an Android or iOS smartphone.
However, JavaScript's additional level of abstraction from the underlying hardware, compared to software languages that compile to machine code, comes at a cost to performance. Recently, browsers have implemented JavaScript engines that slightly lessen this performance gap by using just-in-time compilers, which typically compile certain stretches of Javascript into machine code just ahead of being run.
JavaScript is also hobbled by its dynamic nature — for example, not requiring data types to be defined by the developer. This dynamic nature forces JavaScript interpreters to have to handle a wide range of possibilities when interpreting code and limits opportunities for performance optimisation. Ways are being found around these limitations, such as Mozilla's introduction of support for asm.js in Firefox 22.
Asm.js is a subset of JavaScript that eschews several dynamic features of the language and in doing so allows JavaScript engines in the browser to make performance optimisations that JavaScript's dynamic nature would render impossible. However, support is limited to Firefox for the time being and there are other limitations on performance asm.js can't address such as JavaScript engines not really being able to handle multi-threaded code.
While ways are slowly being found to bypass JavaScript's design limitations, improvements to other web technologies are providing alternate routes to better performance, such as support for rich animation effects through CSS Transitions. And there are other stumbling blocks to mobile app performance in the browser that are more noticeable to users and should be simpler to fix than redesigning JavaScript.
Google Chrome's Archibald recently said that one of the features of mobile web apps that sticks out most to users as a performance shortcoming was the 300ms delay before mobile browsers react to a user touching a screen, implemented to detect whether the action be repeated and should be interpreted as a double tap.
Through these incremental improvements in web technologies' performance and the introduction of newer and faster hardware Rabin believes web app performance will get to the point where it's good enough for the majority of applications that user's want, outside of more specialist apps that require high-end performance such as first-person shooter games.
"The web platform has the advantage in the sense it is increasingly good enough and better than good enough for lots and lots of use cases," he said.
"The question is not, I don't think, is native going to be faster than using JavaScript or the web platform generally? But 'Is the web platform going to be fast enough to carry out a reasonable range of applications on a reasonable range of devices?'."
3. Limited access to platform features
Native apps are generally first to gain access to new platform-specific hardware features — be it navigating using a phone's GPS and accelerometer or taking pictures with a phone's camera. But if a particular hardware feature becomes popular, standards to implement that feature in the browser will always follow, Rabin said.
Work is taking place within W3C to standardise APIs for web technologies to access many of the features found on modern smartphones. Ongoing work this year includes setting out a system-level API to allow a web app to manage a device's contacts book, a messaging API for sending and receiving SMS and MMS, new mechanisms for capturing photos and recordings, new event triggers that could handle mouse, pen and touch inputs, a new push API to allow web apps to receive messages in the background, new media queries for responsive web design, an API for exchanging information using NFC and precise control over resource loading times in a web document.
In October last year the W3C also launched the Systems Applications Working Group, whose goal is to provide a runtime environment, security model, and associated APIs for building web applications with comparable capabilities to native applications. Since its launch, the group has published seven specifications, touching on topics such as the security model outside the browser and raw sockets.
What's the real outlook for web apps?
The W3C's Rabin may be confident that browser technologies will become "good enough" for the bulk of mobile and desktop users to accept web apps as an alternative to native, but does the rest of the world agree? It depends who you ask.
One area where Rabin's philosophy that the web will be good enough to become the de facto platform for apps is already taking hold is in government. The UK's Government Digital Service has decided that in the majority of cases the government will build responsive web sites and apps that work on PCs, tablets and mobiles rather than invest several times over in creating separate apps for iOS, Android and other mobile platforms.
"We believe the benefits of developing and maintaining apps will very rarely justify their costs," the deputy director of the service, Tom Loosemore, wrote earlier this year.
"Apps may be transforming gaming and social media, but for utility public services, the 'making your website adapt really effectively to a range of devices' approach is currently the better strategy. It allows you to iterate your services much more quickly, minimises any market impact and is far cheaper to support."
But there are plenty of companies still to be convinced that web apps are ready for mainstream adoption. Earlier this year, LinkedIn's senior director for mobile engineering Kiran Prasad explained why the social network for professionals had decided to switch its focus from the mobile web to native app development.
For LinkedIn the primary failing of its mobile web app stemmed from it running out of memory and UI shortcomings due to animations being insufficiently smooth. Development of mobile web apps also proved to be more difficult than programming for other major platforms, Prasad said, citing the lack of a debugger and diagnostic tools that could give the firm the information it needed about bugs and performance issues.
The breadth of the shortcomings that LinkedIn identified when developing a mobile web app, both for the user and the developer, indicates just how much work has to be done before mobile web apps can reach a "good enough" standard in the eyes of users and developers.
There's also Facebook, whose founder Mark Zuckerberg last year described the company's decision to rely too much on HTML5 to build its apps as its biggest mistake. However, both companies are still developing for HTML5 and other web technologies and both seem committed to mobile web in the long haul.
Rabin remains optimistic that web apps will get there: "More and more, as web capabilities and the coherence of web standards improve, there will be no reason to write the vast majority of business and commercial applications using anything other than web technologies.
"To my mind it's a question of manifest destiny."