I have the impression that more and more applications with a user interface use HTML+CSS+JavaScript client-side instead of a native GUI framework.

I wounder what are the most important driving forces for this? or in other words what are native GUI frameworks lacking to be competitive? e.g. is it easier to do some kind of things with HTML+CSS+JavaScript than with native GUI frameworks.

If we suppose the application is a client-server application where the client has a graphical user interface. What is the most important things that are easier to do in HTML+CSS+JavaScript than in the most popular native GUI frameworks?

7 Answers
7

make sure the software runs on all clients (with different hardware, OS versions, other stuff installed, etc.)

somehow transfer the software to each client

install the software on each client

troubleshoot each client individually

repeat all the above each time you want to roll out a new version

be very careful not to break compatibility with previous versions (e.g., version 4.3 better be able to load version 4.2's saved files)

Web applications also have a few advantages by nature for which desktop applications have to jump through quite some hoops:

a user's settings and documents will be available anywhere in the world, as long as there's internet access and a compatible browser (which is much less of a problem now than it used to be 5 years ago)

users can simply bookmark pages inside the application (if you do it right) and resume their work later, exactly where they left off

access to the application can be controlled centrally; users can be added and removed without modifying anything on the client; with desktop applications, the application would need a reliable (and fairly hack-proof) way of disabling or removing itself

In terms of development effort, I'd say writing web applications requires a slightly different mindset, but it isn't intrinsically easier or harder than desktop programming, given decent enough tools.

I've upvoted this but a lot of what you've said doesn't make sense for most corporates where the application is only to be used in a few locations and the SOE is locked down. We deployed new builds of the application by overwriting the one master copy on a network share & the users all ran the .exe by loading it from there. In that situation using a web app doesn't make sense but a lot of corporates are doing so at great cost & little benefit as far as I can see.
–
mcottleOct 12 '11 at 5:40

1

@mcottle: That's a fair compromise - you still use a few of the benefits, and you have to figure out solutions for a few other things such as storage and authentication, but other than that, the decision is ultimately an individual one, and the factors differ from case to case. (And if the cost for a web application is significantly higher than a desktop application would have been, including setup and maintenance, then you're being screwed.)
–
tdammersOct 12 '11 at 5:47

They were screwed. The authentication the .exe used is a weeks worth of Daily WTF posts :)
–
mcottleOct 12 '11 at 8:18

We have switched over to intranet web sites because it requires virtually nothing on the client workstation. We can maintain two servers (primary and backup) instead of dozens of workstations scattered around the country. And since the servers are on the Internet, all maintenance / repairs / upgrades can be done remotely.

It is also nice that we are platform-independent of the workstations; Windows, Linux, Mac, we don't care. Everything from Windows 2000 to Android "just works".

This makes deployment much easier. The user doesn't have to install anything, and the application silently upgrades on the next request (if a new version is available). This also makes server development easier since it's mostly not more than one client version that is used.

Built-in network client

It helps a lot that the web browsers handle all network connections for you. In example when you want to post messages to the server, you have to do almost nothing to handle the network connection. Compare this to using Apache HTTP Client, specially when you want to use a secure connection via HTTPS. The new Websockets will make this even more powerful.

Easier to make layout

This may only be an advantage against Java Swing, but maybe not compared to WPF. But doing the layout declaratively using HTML+CSS helps a lot compared to as in Java Swing where all layout is done using Java code. That would be like making layout and use of components only via JavaScript.

Easier to make asynchronous programming

Consider a sign-up form, where the user chooses a "username" and fills other fields with information. In JavaScript it's very easy to asynchronously check (using Ajax) if the username is already in use without blocking the UI, while the user can continue to fill in the other fields - and if the username is already in use, notify the user about it. In many other native GUI frameworks, you have to fire up a new thread for such asynchronous things and make the code less readable as in JavaScript+Ajax.

If it is pure UI + some data manupulation that can be done remotely, the web based application would suffice.
Native code comes into picture when you need to do some costly-operations or access some resources on the host (i.e) say you want to write an application like "wireShark" to moniter your ethernet interface on your computer.

Now comes the combinations,

Pure web-based:
it is for light weight applications, that doesnot need much of processing on the host side. Pro's: easy deployment through servers, Con's: can't do much.

The mix of Web-based + Native Code Plugin:
Pro's: This is interesting it is a mix of boath, a web-front-end & a native code backend.Yeah, a little easy to deploy & is powerful.
Cons: needs knowledge of both the sides, browser support will be a headache for the plugin development i.e, each browser(IE,FFX,Chrome) is special in a way.

I think it's easier to just get a webapp going and doing most of the right things, as opposed to native GUI applications. And here "easier" is in terms of programmer effort. Native GUI apps generally require a lot of fiddling to get buttons in the right place, text fields wide enough, etc etc etc. In the late 80s, early 90s, people built careers on doing all the fiddly GUI stuff right.

You trade off absolute control in a native GUI for rapid, easy getting it 80% correct in an HTML/JavaScript/etc GUI.