Slashdot Mirror
The Case Against Web Apps
snydeq writes "Fatal Exception's Neil McAllister offers five reasons why companies should re-consider concentrating their development efforts on browser-based apps. As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter. And while UI and tool limitations are well known, the Web as 'hostile territory' for independent developers is a possibility not yet fully understood. Sure, Web development is fast, versatile, and relatively inexpensive, but long term, the browser's weaknesses might just outweigh its strengths as an app delivery platform."
And these issues shrink all the time. I agree with Joel regarding rich clients--I use Mail.app for e-mail, but virtually no one else I know does. Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term, but other apps will, and it's hard to see this guy's ideas mattering. Sure, they might be true, but the web is still more convenient. For me, it's become a central repository for book and other commentary in the form of The Story's Story and write about grant writing at Grant Writing Confidential. Yeah, I write my posts in Textmate, but most people don't--and most people aren't going to buy and install Textmate.
Even with true clients, much data processing is still done in the datacenter. maybe some advanced analysis is done on other machines with a data dump, but still... it's all data
True, and real client developers - those who have built many clients - will continually push processing to the server, keeping the client as thin as possible. A server can be upgraded or replaced, you don't necessarily know what a client is going to be running. My only complaint with TFA is that his first argument overestimates the power on a desktop.
What I think he is really saying is that data validation is better handled by traditional desktop apps a lot better than web apps. Of course traditional apps include browser plugins like Flash and Silverlight, along with C, C++, C# and Java applications. In most web apps a user puts in info, presses next and then when something isn't right they be punted back to the same form with maybe a message explaining why. This validation can be handled instantly in traditional apps, giving the user more feedback and better interaction. Also, since most are just glorified wizards, web apps quickly become a productivity bottleneck for advanced users.
Other than a simple form-type interaction, why bother with it in enterprise applications? A company can require the install of anything they want in their required configuration, so why not a rich client that follows UI standards?
"Is life so dear, or peace so sweet, as to be purchased at the price of chains and slavery?" - Patrick Henry
What I think he is really saying is that data validation is better handled by traditional desktop apps a lot better than web apps.
Javascript was created specifically for the purpose of validating forms. I think it still does fine at that.
In most web apps a user puts in info, presses next and then when something isn't right they be punted back to the same form with maybe a message explaining why.
Bad app, not bad platform. In my web apps, you will often be punted back (because I'm lazy and haven't finished it), but there will always be a message explaining why. And in the fields which you might have to try frequently, like username, it will do that validation in realtime.
But there's no reason you can't validate everything immediately. The main reason you see it done that way is it's more important to validate it on the server, so that's what gets done first. In far too many apps, desktop and web alike, it's done in the other order, so if you sniff the network traffic, you can do anything you want.
since most are just glorified wizards, web apps quickly become a productivity bottleneck for advanced users.
Again, that's a symptom of "most" web apps, not a warning away from the platform as a whole.
For that matter, what kind of "advanced users" are we talking about here? A well designed web app will be RESTful, meaning it's trivial to develop a script that talks to it, or any kind of frontend you want. The savvier users might start developing and sharking Greasemonkey scripts. How, exactly, were you proposing to add scriptability to a desktop app?
why bother with it in enterprise applications? A company can require the install of anything they want in their required configuration, so why not a rich client that follows UI standards?
First, the browser is going to give you a lot of UI standards, nearly for free. Users used to web apps will start wanting things like a tabbed interface, a back button, bookmarks...
Second, because you get some of the more important advantages of a thin client. If everything your users need to do is in a web app, this has several important effects: You're free of Microsoft (you can just give them a bare-bones Linux box that boots to Firefox), the machine is interchangeable (if it fails, just replace it with a fresh one and the user can simply login again), telecommuting is easier (just grab whatever you trust and open the app via SSL), and maintenance is much easier, just upgrade the app in one place and everyone gets the upgrade. As for upgrading the clients, much easier to push out a browser update and a few OS updates than all that plus a half-dozen custom application updates.
Sure, it's easier in an enterprise environment, because you can mandate a browser. If your developers like Firebug, your users will use Firefox, end of story. But your comment assumes that there are advantages to a rich client...
Speaking of which, the browser is much smarter than a VT or an X server. Just about anything you'd need to do in a business app -- especially a simple form-type interaction -- you can do client-side.
Basically, you get all the advantages of a thin client, and all the advantages of a rich client, except for a few areas (extremely high-performance, 3d, or needing a lot of local disk storage) -- and those are being worked on (JS keeps getting faster, Flash supposedly has 3D now, and things like Google Gears and Adobe AIR are providing ways to access the local disk.
For the vast majority of enterprise apps -- the kind that would work just fine as thick clients on 10-year-old computers, or even as DOS apps when that was the new thing -- the Web is pretty much all upside, if done right.
Don't thank God, thank a doctor!
I am the sole IT person for a nonprofit, volunteer animal rescue. They don't have any money to pay for professional staff (preferring to spend it on the animals instead).
All of our IT tools (a wiki, a bird tracking database, OTRS, our website, a chat server, etc) are webapps.
The type of people, for the most part, who are willing to volunteer to do animal rescue are not geeks, techies or even "power users". For a long time our animal tracking database was a client application. 75% of the volunteers had so much trouble figuring out how to INSTALL IT and connect it to our database (even with written instructions) that they didn't even use it, and had to ask others to do all their data entry for them.
It got to the point that each adoption coordinator had to be set up with a technically astute "data entry buddy".
Now that our bird database is a webapp, all the coordinators can use it, because they CAN navigate to a website and use the tool.
So, yeah, there's a place for thick client apps too, but without webapps we'd be screwed.
By that logic - why not just go full win32 client-server and cater to a single OS and drop the browser entirely?
And that's a very good question indeed. You do not even have to constrain yourself to Win32 - use Java, for example, delivered either over the Web through a browser or just downloaded and executed in whatever way the client wants. Then you lose nothing and gain a lot.
Basically the question is: what value does a browser add to your application? I can see two: it is already present (and so requires no download) and it contains a set of UI controls that you don't have to write. Both advantages are minimal.
Minimal advantage 1: If your app is net-based it can be safely presumed that downloading of a JAR (for example - it could be a Qt executable just as well) is not a problem. If the bandwidth is limited then you are actually far better off with a custom app because it can talk to the user on its own, and can buffer net packets. Then cost of one-time download of the app itself is dwarfed by savings on traffic and latency.
Minimal advantage 2: prepackaged UI controls. That is really laughable. There are tens of UI libraries out there, and each of them is better than those pathetic forms that HTML offers. You also will be using a real language, not JS. Your application can be highly interactive, use widgets that browsers don't have, can do tons of local processing... in other words, it would be better, and it would be the same on every computer, since the browser is out of the picture.
So why people still try to cram the application into a browser? I'd say conservatism plays a major role. Online games, for example, are not ran in the browser, though they are heavily net-based. In other cases the super-thin client makes sense; for example, maps - the client just does not have the data to display, so it has to download it from the server, so it makes programmer's job easier to just ask the server to prepare the whole image, and then the client only shows it. But Google Earth also exists, and that is a far more advanced application - and if it can be easily loaded and started just by following a Web link then there is no reason to run anything in the browser. In fact I use Google Earth more often than maps.google.com, though as I said both are good.
The best scenario I can think of when use of a browser makes sense is when your app is so simple, and your needs are so basic, that you benefit from the infrastructure that is already present in the browser. Google Mail, though, is outgrowing the browser very quickly; I could implement the whole UI in Qt within a week, easily - and how many people worked, and still work, and *will* work on hacking AJAX to make GMail work on 33 browsers? This is a good example of conservative / legacy situation, when every Web mail was a web mail, and Google had to compete in that area. But today if Google offers an equivalent of Google Earth for mail - with additional features that are available only there, like built-in PGP/GnuPG/SMIME support, or caching of messages, or automatic archival of all your mail as it comes, or HTML mail, or many more - then I'm sure there will be tons of people interested, just like tons of people use Google Earth or Picasa. Google servers will benefit too, since they don't have to cater to every user's action - they only need to serve pure data, and only that data that the client hasn't already cached. Basically, a better IMAP client, only with Google's "conversations" and UI.