Web-Clients vs. Desktop Clients?

lundmatt asks: "My company is a software development institution that has been around for awhile. We are in the process of designing a large in-house tool to merge our current bug tracking, version control, design and implementation processes, and a few other stand-alone systems. A large debate we're having is whether to implement a Web-based client or a desktop application client. Most people fit neatly in a pro-Web camp and others in a pro-desktop application camp, unfortunately we are in a position where we can't develop both." There really is no right answer to this question, as many applications can adopt themselves into either environment. Sure, there are several applications that can benefit from one or the other, but the concepts of Web and desktop are dovetailing, and have been for years.

"The argument of the desktop proponents is that Web interfaces are not productive for a tool which would benefit from a lot of rich GUI controls such as trees, etc. The Web-proponents argue that Web clients are no less productive. The Web-proponents argue that deployment effort is zero though the desktop proponents feel this is a negligible issue for us. Surely we are not the first company to debate this though I've had a difficult time finding 'unbiased' studies that compare and contrast the two options. I hoped that some of your readers would have some opinions about this and since we're all SlashDot fans, we thought we'd drop you a line."

Java, XUL

[free779]

One option is to deploy a 'fat client' approach, but not by using traditional executables. Create a Java application instead. This will run on any machine with a VM, and give you all of the advantages of a native client (rich GUI).

Another possible option is XUL, Mozilla's user interface language. While it is an XML dialect and fairly simple to use, I wouldn't call completely stable yet, and it forces you to deploy Mozilla/Netscape to all desktops.

I personally prefer web interfaces (especially from an administration/support view) since you no longer have to deploy client applications - a real bitch! Any changes to the application are right there for all users. Unfortunately, HTML doesn't allow for particularly rich user interfaces.

If it is absolutely imperative that there are certain UI aspects be implemented that cannot be done with HTML, you may be forced to write a client application. However, if you can convince everyone involved to keep their expectations within bounds, I would suggest a web interface.

Future proof

[jbert]

It might not work for your app, but I would recommend considering defining the operations you need to perform as a 'protocol'.

This protocol could be as simple as some XML/HTTP or whatever you like. You can then implement one server and whichever clients you like.

Once you have done this, you can develop a web client (which just translates web forms to and from your protocol) or a native UI.

If you DON'T do this and you go the web route, your web app will be a combination of the server+client components and it will be difficult to seperate them in the future.

Speaking from experience here...web interface not bad, but the fact it is co-located with the server encourages short-cuts best not taken.

desktop.com

[bobm]

There once was a site called desktop.com that had (IMHO) a really app server. You wrote your app in perl and it seemed to work well.

Right now we are attempting to keep from having to write yet another VB app and migrate to the web based apps.

Does anyone know what happened to the desktop.com stuff and if there is anything like it (in the way of dev tools). Note: the desktop.com stuff was totally DHTML and scripting, no java on the client.

Re:One thing to consider

[toast0]

so basically what you're saying is that using a web server would be less secure than using a file server?

i think that a web server could be more secure, since the amount of damage you could do with a users account would probably be less, if it was run off a fileserver, everybody would need direct access to the files, but a web interface could limit the things you could do.

in either case, if the server with all the data is compromised, you're screwed

Re:One thing to consider

[TotallyUseless]

yes, I mainly mean the possibility of someone accessing the data on the web server. Or possibly even snooping in on the data being sent back to the server.
Im assuming this solution will be used from a centralized location or office, rather than from locations distributed in different areas/cities/etc. It more than likely would not be more difficult to develop a dekstop version (if they have good engineers) than the web version, so I'm not sure I can see a real advantage to a web interface, other than possibly write once, run anywhere ability. That could be good or bad tho, depending on their needs and paranoia.
I say write a desktop version and run it from a file server, or install it where it is needed.

Keep it open

[SlightlyMadman]

Where I work, we have a big, crazy web application very similar to the one you're describing. It was originally created (before I got here) as a web app. This, of course, brought with it a whole mess of problems (mostly, people kept asking for crazy stuff, and we had to use lots of javascript, DHTML, etc. to support it, which brought browser compatability issues, so we tried to scale it down, and support everything, while still keeping the functionality, and the whole thing got all screwy). So, what we ended up doing, was to seperate the client interface.

We have all of the business logic in scripts on the server. These scripts take http requests and respond to them with XML. We then made a bunch of client pages (web), which completely duplicated the current functionality, but containing only presentation logic. Now, the system is open enough that we can support multiple clients. Our customers can even write their own. They can be web, desktop app, palmos, java, anything that can open an http connection, and we can concurrently support any number of different versions.

So, my suggestion, would be to pick whichever one is easiest for you, but keep the interface seperate, so you can create another client later, and not have to touch the business logic. We haven't rolled out the new version of it (so this isn't tested advice), but we have very high hopes for the maintainability and flexibility of this structure.

cross platform libraries

[Dukhat]

Check out www.wxwindows.org. WxWindows is a crossplatform windowing library, which is supposed to be really cool unlike Java's AWT. It has bindings for C, Perl, Python, and probably other languages. If you use Perl or Python with WxWindows, you should have a fairly universal development platform.
I doubt that you need to access the graphics framebuffer or the audio device directly since you are actually considering using a web interface, but if you do need to create your own graphics, you can take a look at www.libsdl.org. A good example of a program using libsdl is at www.winbolo.org.

Re:Java?

[dSV3Hl]

Well, thats not quite what they are looking for, I think. A web app should be more like slashdot than like a real application. (Not saying /. is not a real application :)

Anyways, Java is a good option for both. You could write the middle and back end to be nutreal, and a servelet to dish out the webapp, and an applet to dish out the application. Works great for me anyways.

Re:Java?

[Evil Grinn]

It seems to me that this would appease both parties in this case as well as eliminate a lot of porting efforts if you ever decide to roll out your application to other platforms.

If you're going to go the Java route Java Web Start [sun.com], would probably be better than an applet.

(not that I've actually used it, mind you, but I do like the fact that it appears to be free of the browser-related issues that can occur with applets)

Of course, then you'll need to roll out JWS itself to all your computers...
---

Re:One thing to consider

[Aunt Mable]

What? How might a script kiddie get access to something when you're only sending interface and you keep the state on the server? Do you just mean having a server online - or wot, eh?

-- Eat your greens or I'll hit you!

Java?

[_w00d_]

Being brand new to Java programming and not knowing the specifics of your project, I definitely wouldn't be the best authority on this. But the question I have is this: couldn't you write the application in Java and use it both as an applet and a standalone application? It seems to me that this would appease both parties in this case as well as eliminate a lot of porting efforts if you ever decide to roll out your application to other platforms.

One thing to consider

[TotallyUseless]

If you go with a web based interface, you might have to worry about what could happen if a script kiddie gets access to the programs/data/etc. If you used a desktop based approach, it would prolly be easier to keep secure. I have been dealing with a similar problem where I work (although on a smaller scale) and I spent many nights debating which way I should do it. I ended up using a mixture of both, but that appears not to be an option for you.

My experience

[Stormie]

The last place I worked, we were pondering the same question. In our case, we were starting a project to rewrite some old systems (which ran under VMS, with a character mode interface via telnet), with something more modern, namely VB + MS SQL (hey, the company was in bed with Microsoft, there was no way management was going to pick anything else).

Now, I can't tell you which is better because I left the company and the country before a decision was made. :-) But I can tell you what we were thinking. Note that this was from the perspective of a totally Microsoft shop. Depending on your situation, certain factors (like: a web front-end should be inherently cross-platform) which meant nothing to us, might mean something to you.

Distribution: This was a big one for us. We had a strong culture of fixing bugs and adding features by quickly editing and recompiling some code.. on the live system.. (yeah, we had a dev system as well, but for quick changes, we took the "cowboy" attitude and just did it in live). So, it was important for us not to lose the ability to do an instant fix. This pointed us in a web direction.

Ease of Development: I guess from your description of having two "camps" that you have people on hand with the necessary skills to go either way. We didn't - we knew VB, but we were learning as we went when it came to web work. Remember that "what you can do" is often a far more important issue than "what you should do" when it comes to corporate IT.

Quality: As your desktop advocates suggest, you can just plain do a better interface with a local exe than with a web frontend. If you go the web way, you just know that some manager will want some feature which is really, really hard to do nicely on a web page - but you can always do there things in code.

Other things: Using a web server is one extra point of failure. But its also one extra layer of scalability (if it turns out your "business logic" is a bottleneck). But of course you could do a three-tier design without the middle tier being a webserver. If your in-house tool ever needs to be accessed from "out of the house", it's surely easier if all someone needs is a web browser. A client-server application should require less network bandwith than web traffic. Also don't forget that you could do a web page which was basically just a "carrier" for a bunch of Java applets or ActiveX controls, to get the distribution advantage of the web interface with most of the other advantages of the desktop app.

Oh well, just a few ideas for you to throw into the pot..

Is web portable?

[bluGill]

Web based clients are not nessicarly easier to devolp, nor are they nessicarly portable. Here at work I'm forced to use a web based system that only works with IE on windows. IE on solaris or netscape on anything doesn't work right. (Ironicly most of the devolpers use solaris on their workstation) Because of java (bad use of java) we have a slow, bloated, non-portable interface that is hard to use. We could have made a windows verison that was better in all aspects, but the idea of cross platform was too important when we started, Java (not yet at 1.0) was the best thing. We took it, ran too soon, and nobody is willing to admit we need to start over from scratch despite the complaints.

Web based clients are good for somethings, and poor for others. Java is cross platform in theory, but combins netscape's bad implimentation with Microsoft subversion and it is useless. Straight executables are good for speed, but remember that your algorythms and data structures still determin speed. Executables are great if everyone uses windows (or unix/mac, but that is rare) every day, but annoying to those who don't normally use windows, but have to just for the one application.

So really the question is: Do you have users who do not normally use windows who would have to now. If so is there a problem giving them a windows machine? If everyone uses windows, the advantages of an application outweigh everything else. If you have to support a number of different operating systems, then web based wins, make sure they stay cross-platform and nothing is done to compromise speed.

PLEASE have only one and stick with it

[dmorin]

We just went through this with a large content repository software vendor. We'd been using the desktop client on their recommendation because their web client always sucked. Well, with the new version of the software, they fundamentally revamped both -- but internally,they kept a desktop development team and a web development team. So now depending on who you talk to they recommend one or the other solution, and neither is 100% -- they have some major overlap, but they come off looking like a Venn diagram where each tool can do certain things the other can't.

We wanted a web client. We have dozens of users spread across Boston and Chicago, both on the company net and wanting access from home. It's difficult to administer that sort of installation (especially once the software patches start coming out). The vendor wants us to use the web client, because most of the new features of the new version are in that client. Our existing customer wants us to keep using the desktop client because they already know that one and don't want to rock the boat.

The problem is that the web client stinks. LOTS of things wrong with it, not bug wise, but just bad-interface wise. So several times I day I utter the following sentence: "Wow, the web client is lousy at X. Does that mean we have to use the desktop client? But shoot, we can't, because the desktop client is lousy at Y." We're hoping to force the vendor to accept our list of changes and modify the web client, it's our only hope.

Did that answer your question? A web client, please. And DONT make it IE/5.5 only, we hate that. And please make sure that it's full featured, don't rush it out the door just because you want a web interface and then realize that there are fundamental features you forgot to support.

Depends, but web probably works out better

[raju1kabir]

Pros of web-based client:

• More secure. Communications travel through well-understood mechanisms (HTTP GET/POST) for which there are oodles of data-sanitizing code samples available. Protocol handlers themselves (browser and HTTP server) are under intense scrutiny, and chances are someone else will find a problem, leading to a public update, before someone on your site does.
• Faster to develop. The main advantage of using a web browser as a client is that someone else has already written all the GUI and event-handling code, and abstracted it to a high level (HTML). This is typically the most annoying and painstaking part of software development, so consider yourself lucky.
• Cross-platform. If you use a web interface, you are not shoving your choice of platform down anyone's throat. Your staff can use what they're comfortable with.
• No need to play OS upgrade catch-up. When your users start using a new version of their favorite OS, you don't have to worry that it will break your client software.
• Easier to find developers/maintainers. Competent web programmers are easier to find than competent application developers.
• Familiar interface. Users already know how to interact with web-based applications.

Advantages of a roll-your-own client:

• More flexible, powerful GUI. Because HTML forms are so generalized, there are some things they don't do well - oddball user interface elements, highly interactive elements, etc.
• Speed. If you optimize your client for the specific purpose, you don't have the overhead created by all the unused functionality in a general-purpose browser, protocol, and server.