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.

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.LottJul 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.
–
RaynosJul 12 '11 at 10:28

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: programmers.stackexchange.com/search?q=desktop+web
–
S.LottJul 12 '11 at 10:32

4 Answers
4

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.

2. WebSockets expose a TCP socket. You do not have access to UDP in a browser but TCP gives you a lot more options.
–
RaynosJul 12 '11 at 13:07

1

3. WebGL is making some interesting progress. OpenCL support has recently started. Sure it's still 5 years behind desktop game development but it's starting to become possible.
–
RaynosJul 12 '11 at 13:08

1

@Raynos: WebSockets would provide sockets-like functionality but requires specific handshake, you can't easily adapt it to existing systems, you need server-side modifications. Meaning no generic ssh client web app. WebGL might solve some of the gfx problems, still no solution to bulk data requirements (gigabytes of textures and meshes), controller I/O, also audio support is currently pathetically poor.
–
SF.Jul 12 '11 at 13:18

it's not ready yet. Far from ready, I was questioning the limitations of the W3 specification not the implementations. I recognise your lack of backwards TCP server support though\
–
RaynosJul 12 '11 at 13:21

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.

•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

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 ;)