Slashdot Mirror
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."
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.
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.
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.
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
Need a Catering Connection
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.
Time for some tasty Shiner Bock!
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.
Money I owe, money-iy-ay
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.
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.
-- [ta]
If you're going to go the Java route Java Web Start, 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...
---
where there's fish, there's cats
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
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.
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.
Time for some tasty Shiner Bock!
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..
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.
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.
www.HearMySoulSpeak.com
Pros of web-based client:
Advantages of a roll-your-own client:
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS