Are there any limitations of an idealistic HTML5 web application

Question

Let's assume the following two assumptions are true.

Your entire userbase has broadband access everywhere
There is an imaginary browser X that implements the entire draft specification of the HTML5 and WHATWG groups, consistently and all users use browser X.

What are the intrinsic limitations of a commercial public HTML5 web application that we need commercial public desktop applications for?

I'm interested in the limitations of plugin-less web applications that don't rely on Flash/Java/SilverLight/etc bridges for extra features nor rely on browser plugins for extra features.

Possible Limitations that don't apply:

Databases? We have WebSQL and indexedDB.
File IO? We have the HTML5 File API which does both reading and writing.
Speed? With the recent JavaScript engine race, the browser is no longer slow. Native C++ is only 3 times faster then chrome's V8 engine.
Development Tools? The web has matured and there is a whole range of tools available which are too numerous to list.
Closed Source? Yes, all the code is open source. This is a double-edged sword and there are numerous opinions on use of closed source or open source code. I personally believe the advantages of open source code outweigh the disadvantages.
JavaScript/HTML5? Arguments along the likes of "I personally think HTML5 and EcmaScript are horrible development platforms" do not count.

Known Limitations:

Real time / security (top secret) critical code does not belong on the web nor can it. It needs to be written in a low level, highly controllable language like C or C++.
Any tool that needs to interact with a foreign 3rd party piece of hardware attached to your computer will have a difficult time talking to your web application.

There is also a whole suite of programs that do not belong on the web. Operation systems, drivers, server software, low level APIs. I'm aware of that but I don't classify them as "commercial public" applications, these are the type of software that can be pre-installed on computers.

As an aside, I know the two assumptions are horribly unrealistic, but we might achieve them in 5/10/20/30 years. I'm interested in the type of applications and the features of the applications that make them completely incompatible with the web.

Motivation:

The point:

Given the set of problems where a desktop application is a valid solution.

Why is a web application not a valid solution?
How do I identify whether or not I can use a web application as a solution.

I've tried to remove the main difficulties with web applications (internet connection and browser support) by asserting they don't exist.

As a further aside, HTML5 offline applications and Modernizr are on track to solving both those issues.

What are the other difficulties with web application development?

Primary limitation: a good idea for web application enough people will want to use, connected with business model that will at least return costs. The rest is far second. — SF., Jul 12 '11 at 10:13
"What are the intrinsic limitations"? What do you mean by "intrinsic limitation"? What do these words mean? What information do you want? What problem do you have? What's the question? — S.Lott, Jul 12 '11 at 10:27
@SF remove the word "web". You need a problem and a solution. If that solution is an application then it's needs to solve the problem, have a user base and have a business model that will work. I'm just comparing the set of problems that have a desktop application as the solution and questioning why a web application will not work. — Raynos, Jul 12 '11 at 10:28
@S.Lott your correct, the question was too vague, I hope I've clarified what the actual question is. — Raynos, Jul 12 '11 at 10:31
What? "What are the intrinsic limitations of a commercial public web application that we need commercial public desktop applications for?" Does this mean "When do we need the desktop because the web won't work?" If so, all of these are duplicates: http://programmers.stackexchange.com/search?q=desktop+web — S.Lott, Jul 12 '11 at 10:32
@S.Lott I specifically searched for an answer to this question. Within the first 3 pages of that search I could not find the answer to that question. It's perfectly possible my search didn't find me a duplicate, feel free to point out a duplicate. — Raynos, Jul 12 '11 at 10:38
@Raynos: "Closed Source?" What does this have to do with anything? — S.Lott, Jul 12 '11 at 10:45
possible duplicate of Why are we still using the DOM in the browser rather than a desktop paradigm Also. http://programmers.stackexchange.com/questions/71230/why-arent-all-programs-being-turned-into-web-apps — S.Lott, Jul 12 '11 at 10:46
May I ask the context of why the question is being asked? The whole thing question seems like it was written as a college CS course assignment. — maple_shaft, Jul 12 '11 at 11:03
@MattEllen you raise a valid point. The statement was vague, I've cleaned it up. — Raynos, Jul 12 '11 at 12:59
@S.Lott It felt like it belonged in the list of "potential issues that I don't think are issues" My choice of wording seems incredibly poor here but I think you know what I mean. As for your duplicate that's merely someone stating "I prefer desktop application development and find the DOM horrible" which is a related but different question. — Raynos, Jul 12 '11 at 13:01
@Raynos: "I think you know what I mean." I do not know what you mean. Can you clarify why the legal status of the source is somehow relevant to the desktop-web distinction? — S.Lott, Jul 12 '11 at 13:05
@maple_shaft I personally feel that I can take just about any application into the web and want to be reminded of the real limitations of the web. — Raynos, Jul 12 '11 at 13:05
@S.Lott I was merely stating that with desktop applications you have a choice and with web applications your forced to make your application open source (the client). You cannot distribute a closed source binary client for your application. — Raynos, Jul 12 '11 at 13:06
@Raynos: "I was merely stating". Please update the question. A Java Applet front-end doesn't seem to be forced to be open source. I cannot figure out what this point means. Please update it to clarify. — S.Lott, Jul 12 '11 at 13:09
@S.Lott I actually completely ignored 3rd party applications like Flash, Java and SilverLight as an option. — Raynos, Jul 12 '11 at 13:11
@Raynos: "I actually completely ignored..." Where? I didn't see that in the question. Please update the question to make it clear what you're talking about. — S.Lott, Jul 12 '11 at 13:12
@S.Lott I've updated the question to clarify that. I don't personally include usage of 3rd party plugins in my definition of "web application" — Raynos, Jul 12 '11 at 13:14

score 11 · Accepted Answer · answered Jul 12 '11 at 10:51

Off top of my head...

access proprietary hardware that exports its I/O by other means than a file. Be that scientific equipment, industrial machinery, or plain CD recorder and a digitizer tablet with tilt support.
only HTTP and a small family of other protocols. You can't create sockets as you wish, transferring whatever binary data you desire. That vastly limits connectivity with other systems and services.
No sane developer will create graphics-intensive game in Javascript. Broadband is not nearly comparable to DVD/HDD throughputs often needed. Support for 3D in Canvas is vastly inferior to what you get with game engines. No way to support joystick, multiple simultaneous keypresses, the open nature makes cheating easy. But primarily, the performance drop is not acceptable.
Heavy sandboxing. You won't get stuff that deeply integrates into the OS. Screenshots, antivirus, virtual drives, background tasks a'la system tray, administrative tasks etc.
can't be mission-critical. Depending on broadband at all times to run their basic software is not the preferred way most companies like to run.

score 3 · Answer 2 · answered Jul 12 '11 at 10:40

Essentially, anything that can be fit into the server/client model can make a good web application and ispo facto the opposite can be said to be true as well. The trend to move to the web has gone so quickly likely because seeing how most programs can be modeled into Model/Controller/View, programs can split the model and controller from its view.

Of course for efficiency reasons, some controller is placed also on the client side in order to avoid overloading the server with erroneous requests and data.

Though my point is: what programs don't fit the model/controller/view software architecture, since they are likely the same programs that were never converted into web applications. Good examples which come to mind are operating systems, task schedulers, command prompt, virus protection, spyware protection. Every one of which is likely not implemented on a web site because it doesn't fit the model. And it's no coincidence that every single one of these programs are heavily dependent upon your system. Most require direct access to hardware while others simply require a higher security to be able to be run and cannot be trusted to be done by internet web sites.

Of course, Google is completely re-adapting this concept with their new operating system. Supposedly, unlike Windows, it isn't simply a system which grew to use the internet but rather a system heavily dependent upon it. Soon you might see all these programs be made available online, allowing access to your hardware and software, given a strict certificate authentication to prevent just any site to be able to do so but rather trusted sites. I'm anxious to see what they come up with, since I'm thinking in 20 years time, computers will no longer be made with installable software. Rather all services will be available online.

score 0 · Answer 3 · answered Jul 12 '11 at 11:15

•Any tool that needs to interact with a foreign 3rd party piece of hardware attached to your computer will have a difficult time talking to your web application.

The software I am working on now has a desktop aspect as well as a web based aspect precisely because it needs to gather data from third-party peripherals. The development need for drivers, and a client desktop program to bridge the gap between Device and Web.

This doesn't exclude web applications however as these kinds of desktop applications can be thin with logic residing mostly on the server.

On the other note one can say with the aspect of cloud computing and mass virtualization that no application needs to necessarily be constrained by the limitations and security holes of web technology. Running desktop applications from a virtualized environment on a dumb terminal (Much like Citrix) has become much easier to achieve and may be the next development "fad".

The bottom line is that there are more choices now than ever before and a lot more talking heads playing up the technology of tomorrow as the "Best" way.

Interestingly, you can run desktop applications from a virtualized environment on a web browser. Ancient feature of most VNC servers is a VNC viewer Java applet, available by default on http://[remote machine]:5800/ So - desktop-app-as-web-app? — SF., Jul 12 '11 at 11:47

score 0 · Answer 4 · answered Jul 14 '11 at 02:47

Let's assume the following two assumptions are true.

Your entire userbase has broadband access everywhere

There is an imaginary browser X that implements the entire draft specification of the HTML5 and WHATWG groups, consistently and all users use browser X.

What are the intrinsic limitations of a commercial public HTML5 web application that we need commercial public desktop applications for?

I'm interested in the limitations of plugin-less web applications that don't rely on Flash/Java/SilverLight/etc bridges for extra features nor rely on browser plugins for extra features.

Ok, then here's the rub: That browser will by its very nature be insecure. So you're asking us to make a tradeoff between the two. However, getting past that, and assuming that we do have javascript (which you alluded to in your post) then the answer that there is no app that cannot be written using merely HTML5/Javascript. However, we do assume a browser that doesn't get in the way.

The thing has a local db store, can make calls to any other platform using HTTP requests (which a RESTafarian will tell you is sufficient) and can draw (via Canvas) just about anything you want. There are already 3D games written using open standards (OpenGL ish) and there are APIs to do just about whatever you want.

The only real drawback is speed. It will take time to make those HTTP API calls to other systems (databases). It will take time to process FILE(COM1:) requests (to read over a serial device on Windows for example) so those are the problem areas I would expect. Of course, I also assume that drivers are written to be accessed like files, which I'm pretty sure isn't true anymore. But they could expose such a mechanism ;)

To the user, not much will be different at all.

Are there any limitations of an idealistic HTML5 web application

4 Answers4