You all know the argument about HTML or web apps. There is a lot said about how they aren't ready yet and native apps provide a better experience. This, however, is only the tip of the iceberg. We have a lot of work to do to make web apps as good, both in their production and their use, before they equal native apps. 

Web apps have the potential to be wonderful.

After all, the web is the new desktop.

Why do we bother worrying about building apps for the Mac, Windows, Android, iOS and so on when the biggest computing machine in history is the totality of the internet and the web is its desktop. 

From this point of view it is crazy that we are creating things called "native" apps. Of course the problem is history. The web was never designed to be a place to run programs and even today it tends to resist the push towards a mature development platform.  

 More cartoon fun at xkcd a webcomic of romance,sarcasm, math, and language

HTML for example has improved a lot over the past few years but it is still a markup language rather than a UI language. Compare it to something specifically designed for the job and you soon see the lack. Even taking HTML and CSS together things aren't great. You have separation of concerns yes, but, the price is a coupling between the HTML and CSS that isn't pretty. Then you have JavaScript. A great language but it lacks so many facilities that it is difficult to know where to begin. 

This part of the equation is reasonably well known and there are lots of ways around it. You can build apps that look good on different platforms and with a little help from the platforms they can even run as equals with the native apps. Unfortunately this support isn't always forthcoming. Chrome packaged apps for example install on the desktop and avoid many of the problems of the web app - i.e. the browser. 

The problem with the browser is that for apps it just gets in the way. The back button makes perfect sense when you are navigating a document but in an app its value is dubious. Most of the conventions and controls in a browser are document and not app oriented. It is as if on the desktop the file manager was used to host everything you were running - a possible but not desirable scenario. The browser needs to act more like the operating system and simply provide Windows, UI gadgets and services to the app and otherwise it should stay out of the way.

The browser should be so unobtrusive that the user shouldn't even be aware of which browser is being used. In addition it shouldn't matter what browser is actually installed packaged apps should just run. At the moment this isn't the case and the way that browsers handle apps varies so  much that you need to know which browser is going to be the host. The act of creating a packaged app shouldn't depend on which browser the user is going to set as the default browser.

You should be able to offer and use a packaged web app that just downloads and works - on any machine with any default browser.  After all the browser is supposed to be implementing a standard - how is it that it matters what particular browser is running a particular app?

Think of the browser as the ultimate VM - one that includes not only the ability to run the code but also to host the UI. 

This is the ultimate write-once-run-everywhere situation.

We are a long way from this ideal - even though it would be trival to implement. 

Of course, we do have at least two examples of browsers acting as operating systems - Chrome OS and Firefox OS - and much as I love both, they serve to point up just how far the browser development environment is lacking. 

Consider for a moment starting to build an Android app or an iOS app or a desktop app. First you would choose your language and then your development environment. Often the development environment is provided by the platform maker - Visual Studio, Android Studio, etc.

Now think about what happens when you decide to build an app for say Firefox OS or anything that can run a web app. Is there an obvious choice of development environment? The best advice that you get is to use your "usual" HTML dev environment.

The typical HTML IDE is very lacking in the sort of features needed to create web apps rapidly. Where are the drag-and-drop UI editors? Yes you can play the hard man and say that all you need is a text editor, but this is not the way to bring down production costs and allow programmers to build apps without dedicating their lives to the details of the technologies - handcrafted CSS is nice, but expensive and unmaintainable. 

To make web apps a better proposition we need a proper tools and proper frameworks. For example, Android has standard ways of utilizing resources to take account of different sizes of screens and different orientations. It is also possible to create localized versions of Android apps with nothing extra - compare this to the need for some sort of localization library for a web app. There is just far too much in the way of bolt-on extras that are of variable quality and fail to form anything coherent. Choice is good, but it is also nice to have a secure main route to building a typical app. 

If you want to know what is missing from web application development simply look at the best in desktop app creation and notice what you don't have. Some of these features need to be re-created, but not slavishly copied. After all, the web is the new desktop and we need ways of creating web apps that are web-based.

IDEs and UI creation tools need to be web apps in their own right even if they are hosted on the desktop. Consider an IDE like Netbeans, Eclipse or Visual Studio and you will have some idea how far we are away from the desired goal. 

At the moment it is difficult to work out how best to create a web app. When you think up an idea you have to spend time working out how to support the web app on each device and perhaps even on the desktop. There are still powerful forces trying to keep the distinctions clear between these environements. For example, the Windows desktop no longer supports any sort of web app. Desktop gadgets, which were essentially web apps, were retired on Windows 7 with the usual excuse of insecurity and now the only web app host you can find is under WinRT, which is even more specific to Windows. 

What is clear is that at some point in the future you won't have a difficult choice to make when you are about to start a new project - native or web?

The web is the new native, it's just a lot newer than most of us are allowing for.