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.
Care to cite any specific examples? Are you sure that it's not just because it's easier to test on one or two standard browsers and have an official fallback of "oh, that's unsupported on $x"? A lot of time spent on quirksmode.org has taught me that things are pretty stable across the platforms, with the notable exceptions being older versions of IE and Opera.
When did the future switch from being a promise to a threat? -C. Palahniuk
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.
I can certainly cite examples of costs like $80k + $13k / yr for $2.3m potential users. I've never developed and deployed a desktop app for $.03 a user.
ignoring the parent's incoherent and completely off-topic rant, the arguments raised by the author are somewhat flawed.
take for instance:
um, all over again? when did we ever stop using the client-server model? client-server architectures are so prolific because it's simple and it works. some of the greatest technological successes in recent decades have been based on the client-server application model--for instance, database servers and network services and their derivative technologies such as the world wide web, ATMs & EFT, cellular networks, instant messaging, IRC, all types of online gaming, and the list goes on.
commodity computing moved away from dumb terminals and thin clients perhaps, but things don't have to be one extreme or the other. you can have the best of both worlds. a modern MMORPG is a client-server application, but they're certainly too graphics-intensive to run on a thin client. but if you're developing an intranet application that already uses networking and databasing, two of the most prominent classes of client-server applications, then what is wrong with using a web front-end that is cheaper and faster to deploy?
with today's high speed networking and mature browser technologies, most enterprise applications gain no benefit from being developed as a standalone desktop app. an accounting application doesn't require a complex desktop interface or lots of processing power, same with CRM and other business applications. applications like 3D gaming, multimedia production, CAD software, scientific modeling, etc. still require a standalone desktop application. but business apps that consist solely of filling out text fields & electronic forms and outputting textual data with very basic graphics are perfect for web front-ends--especially if they're network applications.
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.
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.
Will your JAR package run on my iPhone? No? Because any decently-written web app out there will. Slowly, mind you, but it runs nonetheless.
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.
Define "real" language. One that's pre-compiled? One where you have to allocate memory on your own? One where you're sending raw machine code to the processor? As far as I'm concerned, either your code causes the desired effect to happen by some means or it doesn't. The fact that I don't have to fuck around with all of the low-level stuff by writing a few lines of JS instead of a few hundred lines of $realLanguageOfChoice is a plus for me. No, I wouldn't want to try applying Photoshop filters with JS, but the 99% of things that I might want to do are often much faster to write in some sort of scripting language because I don't have to re-invent the wheel every time.
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?
And I could re-write the Gmail interface from scratch in a week too, provided I had nothing better to do with my time (maybe without an IE6 stylesheet, but even Google forces IE6 users to go into an outdated interface). It's a matter of playing to your own strengths. Google's so damn big that they overcomplicate a lot of things, Gmail included. I won't hold that against them as I live in Gmail.
A lot of the additional things you mention would work perfectly fine in the browser with not a tremendous amount of additional effort - it would mostly be a matter of updating the behind-the-scenes API to support the new functionality. Once you have a good design and a solid API to work with, hooking the two together (your AJAX calls, the dynamically-generated HTML, etc. in web apps) is pretty damn simple if you know what you're doing. The only thing you mention that wouldn't be easily solvable cross-browser is local caching and archival of messages; this is already done partially through Google Gears (just enabled in Gmail a few days ago), and client-side databases and related storage are part of the HTML5 spec (Webkit tends to be on the bleeding edge of this, and a LOT of browsers are powered by Webkit - there's a good chance that it will eventually become The rendering engine for the web, including in IE).
Don't get me wrong - there are plenty of places where web apps aren't at all the right approach. Games, as you mention, in addition to other 3d-heavy apps and very animation-heavy things in general. That constitutes a very small portion of my CPU cycles, but everyone is different of course.
How are sites slashdotted when nobody reads TFAs?