Web apps: the future of the internet, or an impossible dream?

Web apps: the future of the internet, or an impossible dream?

Summary: Web apps are being touted as the future of both desktop and smartphone applications, but with so many hurdles to overcome, can they really succeed?


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."

An example of how a gov.uk site adapts its design to fit different screens and devices. Image: Government Digital Service


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."

Related stories about web development

Topics: Mobility, Smartphones, Software, Web development


Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • hmm not there yet

    Google and Microsoft just tried and ultimately failed to build a completely html5 YouTube app. That says to me that you average corporate web programmer would also fail in 2013. Maybe someday will be here but the promise is just that for the near term, perhaps in 2016-2018 but don't hold your breath.
    • Actually it means nothing.

      Far too likely MS/Google is doing nothing but sabotage of each other.
      • Wrong! Microsoft is 100% motivated to deliver a great YouTube app for WP

        The sabotage was 100% googles bs. They're completely full of crap. They wont provide MS the apis they need to build it. They are 100% trying to cripple it so it's not as good as the native apps on ios and android.
        Johnny Vegas
        • No it isn't.

          They are making lots PR noise over the inability.
        • No they're not

          They're 100% committed to doing things that they'll be able to twist into negative press for Google. Otherwise, they wouldn't have done deliberately provocative things that you and I would never do, like republish an app that is known to be non-compliant with explicit terms of service.

          "Instead of pulling the application like Google requested, Microsoft pushed out an update on the very day Google demanded it be removed, nixing the download option but not addressing the lack of ads. Microsoft was poking the bear, and it knew it." http://www.theverge.com/2013/8/16/4627342/microsoft-google-battle-over-youtube-windows-phone

          Not saying Google is without blame in this, but MS ain't the white knight in this little jousting match. Google, for its part, is I believe poking at the fact that MS limits WP so much in so many area - they insist on HTML5 both to drag MS toward reasonable HTML5 support in WP, and at the same time I'm sure they don't mind that it highlights the negative effects of MS's closed-system control over WP (e.g., HTML5 video in WP won't play in the browser, it shells out to the MS media player, where MS has complete control of the experience).
  • Well, I hope web apps die.

    I really do, because I hear that Borg implants itch terribly.
  • I've yet to see an online email client as fully featured as Pegasus Mail.

    I've yet to see an online email client as fully featured as Pegasus Mail. Nothing really matches its filter system, even today.

    Don't get me wrong - I still use online mail because of its convenience.

    But I'm sorely disappointed by its lack of features.

    . . . and the same story goes for pretty much every offline app vs its desktop counterpart. Evernote? Desktop version is best. Dropbox? It's just a poor reflection of your file system. Google Docs vs Microsoft Office? Office has more features.

    Inevitably, and almost without fail - the desktop version of any web app is more fully featured.

    Except for one thing: "Social" features. Everybody web developer seems to think that Every App on Earth Must Be Social. Never mind if the application is really awkward to use socially. It Must Be Social, even if being social doesn't make sense.

    Now, thoughts on your observations:

    "1. Offline capabilities"

    Absolutely. The offline experience is horrendous, even if the app is theoretically designed for offline use (I'm looking at you, Gmail!).

    They're always a miserable experience offline. Half the time they don't have your data - the other half, the browser lost your app. I don't remember the last time an HTML5 app actually *worked* offline.

    "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."

    Screw megabytes. I want gigabytes. I want to be able to watch video and play top-tier games offline.

    If it's gonna be mere "megabytes," then I'm still gonna be looking for regular apps, not web apps.

    "2. Performance"

    Frankly, it's time to be able to use other languages in browsers. Languages similar to C#.

    JavaScript is as quirky a he**, and isn't a good language for large scale apps.

    And to be honest: I'm not convinced by the idea of having to use three or more different languages to learn just to code an app. Sure, large organizations like Microsoft may not mind because they hire separate people for HTML, JavaScript, and CSS, but for small businesses it means being fluent in several languages, which is a greater cognitive load on developers.

    "3. Limited access to platform features"

    This is largely due to the fact that the W3C is slower than a glacier on a cold day. It takes ages to get everybody to agree to a new standard. Native implementations of hardware features will always be first, because there's no need to pass through a standards committee.

    "What's the real outlook for web apps?"

    I'd like to see something different than HTML, JavaScipt, and CSS for the primary languages someday. They're nice languages, but they're 20+ years old and really not designed for today's apps.

    HTML was designed for hypertext, an old and outdated concept. It was never intended to be used for full applications.

    JavaScript is designed to make web pages less static - but again, it was never designed to be used for full applications.

    We need new languages for the web. And I think long-term, that's what it'll take to make application development a reality for the web-based world.

    And oh, yeah, one more thing - I'd like to see web "apps" that really act like real apps - without the browser chrome, and with integration with OS features that regular apps have.
    • have you met real people

      who make their living using html and not knowing css?
      no to mention that css is not a language.
      • The point is . . .

        The point is - I want things to be easier and less complicated for devs. Especially new devs that might be learning web development for the first time.
  • adjunct to, not replacement

    Native code on a LAN attached workstation has too many advantages to think in terms of "replace"; but the web apps can provide a lot of mobile and platform agnostic usage cases. Keep the web apps focused on providing the functionality needed by phone, wandering-tablet, and remote users; keep it clean and quick.

    In a world full of 3Ghz processors, "interpreted" or "unoptimized" are not the limiters; inappropriate design is the much more likely culprit. You could write snappy native applications on a 25mhz 386, but you had to make accommodations for the limits of the systems... just because you knew how to make a cute animation was not sufficient justification to burn cpu cycles displaying it.

    Today, web apps generally are still infested with too much "cute" and not enough "get r done". As HTML5 gets traction in the coming years, I expect this to change.
  • Looking at it from the wrong angle

    Every time this discussion comes up and the virtues of web apps are touted, it's always by people whose daily life is about developing for the web (naturally). The problem is, they're looking at it from the wrong angle.

    They say that mobile web apps will be the future. If Firefox OS becomes dominant, then yes, that's true. Until then there are Google, Apple, Microsoft & Blackberry. And while they support web apps, they all save the good stuff for native apps. Not to mention, there's no benefit for mobile OS developers to embrace the "write once, run anywhere" ideology. Then there'd be no reason to buy iPhone over Android over Windows Phone, etc.

    Speaking as a mobile developer, I experimented with mobile apps. And let me tell you, it's a pain in the left eyeball. Just creating a very simple user interface with HTML5 and CSS a) takes waaaay longer than native apps and b) takes far more work to implement. Plus you then need middleware such as PhoneGap to bring the whole thing to life.

    Finally, watch this video at the end in the Q&A (https://developers.google.com/events/io/2012/sessions/gooio2012/112/). A mobile web developer asks if Google will make an easier way for web devs to comply with Android design principles. The answer was "No" and the best part? "We'd rather have you develop natively".

    There you have it folks. As long as there are competing mobile OSs, native apps will always win. Even Ubuntu - who claims web apps will not be second class citizens - still defaults to native apps. Web apps are a pipe dream.
    • I agree

      PhoneGap and jQuery mobile promised to make it easier to make an iPhone app and a Windows Phone app. Not my experience - after all the convoluted display logic I found I had to do and trying to wire it all up to Javascript event listeners that often wouldn't cooperate, personally I think it is easier just to build something in XAML and xcode's Interface Builder, and then write the separate C# and Objective C code.

      I guess that makes the HTML5 app approach twice as hard?
  • Online is really important to marketing, your choice be damed

    It's more important to gather recon on you and click points ala slideshow vs list article so what you want is really irrelevant, just so you know. Many sites user experience has greatly deteriorated and the trend continues which gets to the issue that they don't really care about users experience though they do care about users personal data and gathering intel on users. That's why online is so important, if your not online they can't harvest and redirect/misdirect, force reload pages, racking up page/ad view numbers.
  • With Android on the vast percentage of mobile devices, it's the standard

    While I agree with the goal of the W3C, there are still only two platforms on the vast majority of devices... Windows and Android. And both Windows and Mac OS can run Android apps with BlueStacks.
    This will affect the need for standards based alternatives. Over and over, de facto standards win out.
  • False dichotomy

    You argue that there are two choices: "standards based" solutions like HTML5 which run on everything with a bit of tweaking for each browser and platform and "native" which has to be rewritten for each platform.

    First off - the amount of tweaking for each browser on each platform isn't trivia... but we get there by basically tossing away any feature we can't make work or guarantee exists on all platforms. So that's a bit of a lose right up front.

    There are ways to write apps so that the bulk of the app is portable. That doesn't happen often currently because there's a tendency to start off in Objective C on iOS, which isn't a portable language - no one else uses it other than Apple. But if you start your app development with the goal of maximum crossplatform compatibility, options like Xamarin's Mono mean that not only can the majority of your app be cross platform, but you can also tailor each version to use the features of that particular platform and tune it to look the best on each one.
  • But great for the government...

    Interesting that the article points to the government (in this case, the UK) as the one place where web apps have gotten a real foothold...

    The one place where there's no need to worry about responsiveness to input, user experience, or client-side performance. Where cost of implementing bare-minimum functionality is the only factor. Where there's no worry about competitive systems, because there is no way for users to go elsewhere (unless they leave the country.) Ultimate user lock-in, and the bare-bottom basement of expectations: web apps shine.

    Way to go, web apps!
  • I just don't see it.

    Sorry but differentiation is what sets companies and products apart. Everyone doing exactly the same thing in exactly the same way is going to impress, no one.

    I've been at this long enough to remember "main frame" days and terminals. PC's came on the scene and people couldn't get rid of their terminals fast enough. Not because the main frame could do something but because it allowed the end user to do more and do it in a way that worked for them.

    One small example, we ran "Oaks word processing" on IBM big iron. When others in the company seen what I could do with MS Word they demanded the same flexibility. When they seen how I could customize it to my specific needs with a bit of coding for an add-in it was over.
  • Many issues will affect future web app usage

    Good article. I'm glad to see somebody admitting that web apps aren't entirely satisfactory. There are some other aspects of web apps that keep me from using them more widely: 1) security, both for the app itself and of the online environment; 2) reliability and speed of access; and 3) loss of version and update control. A development issue is that there is a more complex universe of equipment and software to be harnessed to achieve the desired results. Sometimes these might not be significant disadvantages, but they often are for me.

    I don't see web apps as the rulers of the (serious) computing universe as a matter of manifest destiny at all. For tablets and casual applications, web apps benefit from user-operation simplicity. Some tasks are well suited to web apps, namely those that are simple, infrequently used, and do not require archival access.
  • Web App Kool-Aid

    I'm retired, so I'm not trying to create any buzz here. For the last eight years (at least), I've been preaching to professional colleagues and students alike a simple three-word message: "Connectivity, latency, and performance" (OK, four if you count "and"). For reasons of personal financial interest, CIOs, lazy sysadmins, and web developers have been slurping the Kool-Aid and forcing slow, underperforming apps on the people who actually do the work. There was a widely accepted study done decades ago that showed any application response time over two seconds affected productivity - users got distracted, lost their trains of thought, and got frustrated just waiting. Workers who want to plunge in and get the job done with the minimum unnecessary fuss are being punished for their initiative. I'm just an IT/academic geek who fled management after one year, but this seems to be a stupid way to run a business.
    • 7 seconds now... :-)

      That study was updated er changed for convenience to 7 seconds and whenever it suits them even higher. So if your app response time is 12 seconds don't worry someone will think that's good enough. They'd be totally wrong but frankly they don't care about user experience any more than they care about providing a decent paying job.