The Case Against Web Apps 431
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 so what? (Score:5, Interesting)
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 [wordpress.com] and write about grant writing at Grant Writing Confidential [seliger.com]. Yeah, I write my posts in Textmate, but most people don't--and most people aren't going to buy and install Textmate.
Re:No Shit. (Score:3, Interesting)
The last time I logged into a "real user" Windows desktop, all the apps I saw looked different. Even applications from the *same* Microsoft Office suite use different widgets, and behave in wildly differing ways---and let us simply not go into the details of the horridness of all instant messaging apps, all manufacturer-provided apps that deal with hardware, anti-virus, media players, and what not. "Completely different" is the new "good", judging from the evidence.
I would be very surprised if, under a serious evaluation, the way applications "render" on the Windows platform, with applications installed to match, say, a default ubuntu install in functionality, even came close the the more or less uniform way an ubuntu desktop "renders".
Re:No Shit. (Score:4, Interesting)
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.
Re:SQL? (Score:5, Interesting)
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?
Re:No Shit. (Score:3, Interesting)
To get to 99% you are supporting something like 5 engines.
General population: .5 .1 .7 .9
Internet Explorer 69.8
Netscape
Mozilla
Firefox 20.7
Opera
Safari 7.2
Chrome
For example on technical sites usage can look like:
IE7 26.1%
IE6 19.6%
Firefox 44.4%
Chrome 3.6%
Safari 2.7%
Opera 2.4%
Re:SQL? (Score:3, Interesting)
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.
Never underestimate the lack of attention that the users will pay to those messages when you do punt them back to the same form and let them know what the problem is. I have a shopping cart that checks to see if the credit card number entered is a valid card number. If the card does not pass it's check digit, the user is returned to the payment form to fill that in again, with a message that the card number was invalid.
While this does prevent running up lots of transaction charges for trying to charge something on a non-existent card due to a typo, many people wouldn't notice the message and would just go off to whatever else they wanted to do without completing the order. We were getting several incomplete orders in the shopping cart each week due to this. After I implemented a little bit of javascript to run the check digit in the browser and throw up an alert for an invalid card number, the problem with incomplete orders in the system vanished. We do still have the number checked on the server as well, just in case someone has javascript disabled.
Re:Decentralization? (Score:1, Interesting)
In most cases the data is still being processed remotely. In cases where it isn't, being dependent on an ever-growing stack of software and connectivity 'providers' would turn computing into the current hell of the cell phone experience: every click costs me more money than it did yesterday. What was 'free' today is not tomorrow. Juggling 'minutes per dollar' and/or paying ridiculous fees is one of the reasons I avoid using my cellphone's network services whenever possible. Having to do it whenever I use a computer is enough to turn me off the whole concept. It's far too easy to bolt troll-guards on to base-service access, network access, cpu time, memory usage, secondary storage, and maybe even the equivalent of 'roaming' fees in the form of 'idle time' charges for simply leaving the computer connected running IM software. Yuck. They can have it.
If I ran excel, ms does not have 'control' over anything. They can go out of business and I'll still have access to my data because it is stored locally along with the application to manipulate it. Same with openoffice or any client-only software. Then there are the privacy/big-brother concerns. You can bet that governments will want access to the storage sites..you know.. 'for the children.'
Another example is this site. I'm trying to submit this message and it refuses to accept because it thinks I'm a script for some unknown reason. Imagine if this was mission critical work :P. The probability of my network connection dying or problems at the provider's backend is a lot higher than a local hardware failure.
Performance. There is no way that a network even 30 years from now will be able to provide the latency and bw of a local piece of hardware. Physics won't allow it.
Re:SQL? (Score:5, Interesting)
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.
Re:No Shit. (Score:3, Interesting)
There is also Qt, totally easy to use (macro-based C++ code style). On Windows and Mac, it actually calls to load the native widgets instead of making its own, unlike so many other APIs for Windows.
UI inconsistency has been a problem forever and it seems to never end. Microsoft fails to keep the UI consistent, Apple at least tries, and Linux has UIs in whatever way the developers want them. Open up XChat, there's no File Edit View menus, there's XChat View Server menus. It may make sense once you get used to it but it is still inconsistent. There are no 'files' to deal with in XChat but the menu names are inconsistent. Then there's Pidgin with different menu names as well.
KDE and GNOME both try to fix this problem by having interface guidelines, just as Microsoft and Apple do. The problem is when someone (even someone like me) wants a quick and dirty solution that needs a GUI, they could care less about GUI guidelines and they want something that will work for THEM.
On the web, we cannot standardise UIs that are programmed with JS or whatever you wish to use because every site has their style sheet to keep their site unique. All we really need is completely standardised JS and web layout across the board for browsers.
If it weren't for web-enabled apps... (Score:5, Interesting)
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.
Re:No Shit. (Score:2, Interesting)
True, but IE7 less so than IE6 and IE8 less so than IE7. As time goes on the more rigorously you adhere to standards the more likely your pages will render identically on different browsers.
I just wish people would ditch IE6. It still has about a 10% hit rate on our corporate site getting ~3k visits a month.
Web Apps: SImple to rollout. No client sizing (Score:2, Interesting)
A very large percentage of enterprise applications are multi-page forms based. The works reasonably well for that with a relatively low training issue. Every new hire knows how to use a web browser. Older very shortcut, abbreviation driven systems let experienced users fly through the system but many jobs have either high turnover or high numbers of irregular users. Web apps are great for that.
Web applications are easy to roll out to the enterprise without any client reboots remote install scripts or any of the other nastiness. All of the client machines in the enterprise are supported. Remote deployment doesn't require remote desktop or other higher complexity solutions. Most enterprises only support one browser internally so there isn't any cross browser issue.
Fat apps have their own issues. Applications that are large enough to be very hard on the web are often complicated and hard to build as a fat application. Data integrity issues across views and panels can be a pain. Two tier client server applications often still need two levels of validation, both on the server and client.
Mail and calendaring are two good examples of applications that work well enough on the web for some very (very) high percentage of users.
Re:No Shit. (Score:3, Interesting)
there are good web apps and bad web apps, just like there are good/bad desktop apps.
using frameworks like jQuery, YUI, Prototype, etc. you can easily develop complex web apps with advanced interfaces that is cross-browser compatible. if the web apps at your workplace all require IE, then you need to talk to the person making the purchases. not only do they need to realize that there are better browsers (and the need to support open web standards), but also that any web developer oblivious to web standards and cross-browser compatibility is by definition incompetent, if not dangerously inept in other areas as well.
Re:No Shit. (Score:4, Interesting)
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.
Re:Really. (Score:4, Interesting)
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 [wikipedia.org], 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.
Re:No Shit. (Score:5, Interesting)
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.
Re:No Shit. (Score:4, Interesting)
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.