So you know how the whole web 2.0 moment is about moving native desktop software to the cloud in the form of web applications, with UI being rendered through a web browser, data being pushed through the internet and everything being dependent on your ability to achieve a connection to the internet.

My question is why don't we move the other way and infuse our slick native desktop applications with offline capabilities and access to more hardware power with the "cloud". Applications could act as web pages, whenever they are launched a diff check is initiated to compare the binaries of the app with that in the cloud and download only the files necessaries, this would essentially recreate a refresh expect you only refresh once, at launch. Data could easily be pulled from the cloud and be loaded asynchronously without need to "refresh" a web page. The app would have the best offline capabilities and a butter smooth UI.

Wouldn't the move this way be easier than spending all this time developing completely new technologies to allow the bottlenecked browser to do what the OS can already do twice as fast? Am I missing something?

  • 2
    I don't really see this as a UX question; implementation questions should go on SO. Commented Apr 1, 2012 at 1:12
  • 1
    Here are three reasons: Microsoft, Apple and Linux.
    – JeffO
    Commented Apr 2, 2012 at 11:28

4 Answers 4


why don't we move the other way and infuse our slick native desktop applications with offline capabilities and access to more hardware power

Your web browser is a desktop application, so has the same access to hardware power as any other software on your computer.

this would essentially recreate a refresh expect you only refresh once, at launch

A web application doesn't have to refresh on every page. Many web apps are just one 'page' (such as Gmail).

and download only the files necessaries

Browsers do that already. HTML5 local apps take that concept even further, letting you use your web app completely offline.

and a butter smooth UI

'butter smooth' is doable in a web browser as it would be in a native app.

Wouldn't the move this way be easier than spending all this time developing completely new technologies

Web browsers, HTML, JavaScript, and CSS aren't really new technology.

Am I missing something?

I think so. Most likely, context.

The reasons to make an app a web app vs. native could include:

  • write once, deploy everywhere
  • single code base to maintain
  • upgrades are seamless and don't require end-user intervention
  • 'the cloud' or, as I like to call it, 'the internet'. So I can access my software and data from any machine anywhere on the planet.
  • no need to handle thing the browser does already (printing, file management, accessibility hooks, spell checking, etc, etc.)
  • APIs to other web apps (same benefit as local system APIs, but open to a much broader range of sources).

Granted, not all apps need to be, nor should be web apps. But unless there is a strong reason why it shouldn't be, you might as well make it web based.

  • What about the security and privacy aspect of it..? wouldn't that be a big concern for users if we move everything to the cloud..?
    – Ravi
    Commented Dec 7, 2011 at 5:30
  • Well, most everything is entering the cloud whether we want to or not. But certainly, security and privacy are always issues.
    – DA01
    Commented Dec 7, 2011 at 5:45
  • 2
    "'the cloud' or, as I like to call it, 'the internet'" Its good to hear people calling it by its proper name instead of this word that has been thought up to entice MD's sat in first class reading a magazine. Commented Dec 7, 2011 at 9:39
  • Security and privacy is a huge concern in B2B applications, because neither of the three big players give warranties for security threats. Actually you as their customer are responsible radar.oreilly.com/2011/12/cloud-service-security-attack.html
    – FrankL
    Commented Dec 7, 2011 at 13:44
  • @DA01 I disagree towards hardware and CPU power. As long as you have some small app with minor graphical or computational needs its okay, but for extensive programs you need a desktop software as 3D Shooter (like Battlefield3), complex manipulation (like Photoshop opposed to photoshop.com) and render software (like Maya 3D) show.
    – FrankL
    Commented Dec 7, 2011 at 13:48

why don't we move the other way and infuse our slick native desktop applications with offline capabilities and access to more hardware power

Some of us have.

So there are plenty of ways to accomplish what you're talking about. But there are a couple popular options in particular which were designed specifically to allow you to create applications for both the desktop and the web (and web-enable the desktop version):

1) Adobe Air

One of the more well known and successful Adobe Air applications around is Balsamiq Mockups. By using Adobe, Balsamiq was able to create a Flash application for web use and a desktop version in Adobe Air which I believe shares the same codebase (with a few extra features).

2) Microsoft Silverlight

Silverlight has an edge in this regard. I built Regex Hero in Silverlight. And where the Adobe path requires two separate components for web and desktop (Flash and Air), the 6MB Silverlight plug-in enables both web and desktop (or out-of-browser) applications by itself. Silverlight also has an easy update mechanism. You simply call CheckAndDownloadUpdateAsync() and the application update downloads silenty, and is then installed instantly when the user relaunches the application. It's your choice how you want to present that to the user, but my decision was to make it happen silently similar to the update mechanism in Google Chrome. This way you're not interrupting the user with update notifications.

Still, there's a time to consider one of the above solutions, and a time to build an app with HTML/Javascript. Here are a couple issues to take into account...


The speed of HTML rendering and Javascript runtime performance has improved substantially over the past few years. Then IE9 utilizes the GPU for rendering. So there's been some big performance wins lately and there's a stronger reason to build a rich web-based application on these technologies than ever.

However, the implementation details across browsers is still embarrassingly varied. It's still difficult to create a processor-intensive application that runs well on all popular browsers. In addition to that, there's one thing that has plagued both JavaScript and Actionscript (in Flash) for years. They can't do multi-threading. Now, multi-threading isn't always necessary to build a rich & responsive application. It's possible to pull off asynchronous operations without multi-threading. But at times multi-threading is exactly what you need to achieve the speed you're looking for, leverage multi-core CPU's, etc, etc. Silverlight has multi-threading, and it's another big win for Silverlight.

Compatibility and Adoption Rates

So this is where the decision becomes complicated. Silverlight only runs on Windows and Mac. Adobe Flash/Air will run on Windows, Mac, and Linux. And then Flash is more widely adopted than Silverlight, but Silverlight is more widely adopted than Adobe Air.

And in a sense, the latest HTML5 technologies are still behind Adobe and Microsoft in terms of adoption rates. But surely that will eventually change. The browsers are still implementing features in the HTML5/CSS3 spec. But perhaps the biggest advantage with HTML5 is future compatibility. In addition to PC, Mac, and Linux, modern tablets and even phones are being sold with modern browsers which support HTML5 in some capacity.

You can follow adoption rates at http://riastats.com/ but note that the HTML5 chart only takes into account Video and Canvas support.


Microsoft has recently come up with a new consept in MVC 4 beta preview for a Single Page Application. This looks like just what you're asking for.

See this presentation (1h15min):
Building rich Single Page Applications (SPAs) for desktop, mobile, and tablet with ASP.NET MVC 4

It is basically building a HTML5 application where the all the functionality is loaded down to the client, and executed there. Additional data that is needed from the server is retreived using JSON or XML data services. It is even possible to download everything needed including all the data, so it is possible to run the application offline. When going online, the application is automatically syncronizing to download (and upload if editing is part of it) changes since last time you ran it online.

It is also possibilities to build this as a mobile app.

Wouldn't the move this way be easier than spending all this time developing completely new technologies

Although this seems like "new technnology" it's really "a move this way" from Microsoft to package existing technology (HTML5, Javascript, JSON etc.) using MS Visual Studio to create such applications in an easy way. They are even depending heavily on some 3rd party javascript libraries (jQuery/knockout/upshot) that you can chose to replace with others of your taste if you want to.


I disagree with DAO1 that 'butter smooth' is doable in a web browser as it would be in a native app.

This is a topic of much discussion at our 50-person software company. IMHO, any application that represents a substantial portion of a user's time at the computer is much more effective as a native app (in our case WinApp) than a webapp. For example, I use Microsoft Outlook on a daily basis. It comes in a WinApp and also a very sophisticated webapp, appropriately named Outlook Web Access. The the two apps have all the same basic capabilities and a similar UI, but the WinApp is better in almost every conceivable way, mostly because of the myriad subtle, hard to describe benefits of the WinApp. I've queried dozens of users familiar with both versions and not a single one ever uses the webapp when they have access to the WinApp.

Another example is Google Docs or Microsoft Live Documents. Each of these give a reasonable facsimile of the experience of using Word or Excel, but neither is nearly as rich a user experience as the native app. If your main goal is to share the document real time, then the web versions may be worth the sacrifice, but if you're an accountant who spends all day working with spreadsheets, I can't imagine you would choose the webapp given the native app option.

I would be interested to hear if anyone has a personal experience where there is a WinApp and a webapp version of the same product where you would choose the webapp to do large amounts of work. I think webapps are appropriate for occasional use like buying a plane ticket or ordering a tshirt, but for applications that users work on for hours each day, a native app has countless advantages. Stated differently, the benefits of a WinApp are more than worth the installation for high-usage applications.

  • 2
    This is a very subjective answer. You state "...the [outlook] WinApp is better in almost every conceivable way" but don't actually state any of these reasons. The same with your statement "but neither [google docs or microsoft live documents] is nearly as rich a user experience as the native app", but how are the win apps a 'richer' experience?
    – JonW
    Commented Mar 30, 2012 at 19:33
  • And yet, Microsoft is moving all their office software to the cloud as web apps. ;)
    – DA01
    Commented Apr 1, 2012 at 0:41
  • Office 15 will remain a desktop application, and always will, until our browsers can execute javascript "Faster" then C++, when that happens then we can talk about Full Office in the cloud Commented Apr 1, 2012 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.