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."
No Shit. (Score:2, Insightful)
The fact that the different browsers render basic sites differently should be warning enough. Add to that different versions etc; You will never have a standardised audience to utilise these. It will always be lowest common denominator.
Re: (Score:2, Insightful)
The fact that the different browsers render basic sites differently should be warning enough.
Nonsense. Unless you're using bleeding edge UI widgets, a browser UI is quite easy to replicate accross browsers with the use of targeted CSS or simply thoughtful design. Even with a JS framework for your UI elements, browser diferences are simply not a huge consideration. Unless you want that ActiveX goodness...
Re:No Shit. (Score:5, Insightful)
Not at all. There are are all sorts of very standard issues which render differently with AJAX based apps. Why do you think even the largest web app vendors like google and yahoo support certain features on say IE and firefox and not on Safari?
Re:No Shit. (Score:5, Funny)
Because IE is a mess
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.
AJAX cross browser libs (Score:5, Informative)
Re: (Score:3)
Re:No Shit. (Score:4, Funny)
Re: (Score:3, Informative)
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.
Re:No Shit. (Score:4, Insightful)
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.
</quote>
And that's the idiot devs at Apple, for spurning the HUGE market of J2ME for platform control.
It's the number one reason I'm not buying another phone without great J2ME support. I have applications I just won't do on the web - web applications are useless, for example, when your not in a 3G area, and trust me, that's more common still in America than you probably realize.
Re: (Score:3, Insightful)
I can add a few more:
Re: (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:Why is it worth their time? (Score:4, Insightful)
Because they shouldn't have to spend much time -- design it properly, and it should just work on any browser that does a good job with standard HTML.
And because if you do test on all browsers, you'll end up with a more robust app -- not just against those versions, but against future versions. For example, if you only developed for Firefox and IE, you might easily be relying on a bug common to Firefox and IE.
Re: (Score:3, Insightful)
The thing is, most browsers display stuff differently because they're not adhering to a common standard. There is less reason for me to develop for IE if they're going to belligerently never fix a compatibility issue with their browser.
But, on the other hand, most browsers are moving to a common standard. Ultimately speaking, needing to cross-platform a webapp is going to be eliminated - or all but. Robustness is a useful quality, but spending time on something now that is going to not be an issue in the fu
Re:No Shit. (Score:5, Informative)
Nonsense. Unless you're using bleeding edge UI widgets, a browser UI is quite easy to replicate accross browsers with the use of targeted CSS or simply thoughtful design. Even with a JS framework for your UI elements, browser diferences are simply not a huge consideration. Unless you want that ActiveX goodness...
Web-apps have their place but so do stand-alone clients a good developer will know select what is right for a given project. The moment you start using that 'ActiveX goodness' you have essentially created a WebApp that only runs in IE on Windows. Which begs the question why not just write a stand alone GUI client in .NET? That would open up a whole world of UI features ad behaviour web-apps can only emulate either clumsily, with difficulty or not at all. Then there is the security issue ActiveX brings with it. The only thing an ActiveX enabled web-app has going for it is redeploy-once-update-everywhere. The whole point of a web-app is platform independence and that went out the window with the 'ActiveX goodnees'.
Re:No Shit. (Score:5, Funny)
...you should be shot.
Re: (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 a
Re:No Shit. (Score:5, Insightful)
The fact that the different browsers render basic sites differently should be warning enough.
Why would switching to a native app help you here? If the user can't be persuaded to install a compatible web browser, what makes you think that they will install a standalone application?
Re: (Score:3)
because they HAVE to install your Win95-era GUI app and it will always be an easy to support Win95-era GUI app. Somebody still on IE6 versus Firefox 3 + greasemonkey could be drastically different.. and that confuses the minimum wage help-desk drones.
Re: (Score:2)
I guess I don't see why - if your app is so complicated that it will break on IE6 - you can't just do a browser detection and warn the user that they need to install such-and-such for the site to work. Provide a way for uber geeks to bypass the check so you don't get Opera/WebKit whiners, and then make the very first step on the helpdesk script "What browser are you running?"
Re: (Score:3, Insightful)
Please read the fine article, if you don't mind.
Author is specifically referring to enterprise client/server apps. That some dweebs, a few years ago, decided that web front-ends for such apps would be a "good thing" is tragic. Stand-alone, platform-specific front-end applications are infinitely superior in such an environment.
I've been waiting for someone to write this article for years. 5 Stars.
Re:No Shit. (Score:5, Insightful)
As one of those dweebs the reasons were simple. Cost of deployment. If you have a large potential user base with few actual repeat users (which is a very large group of apps) deployment costs per user can be intense.
For example take 1m potential users and 200 daily (or weekly) users with 50 of them ever repeating within any given year. Do you deploy a million or do 150 deploys per day to essentially random desktops?
Re:No Shit. (Score:5, Insightful)
While that may sound good in theory, I have yet to see in practice where any web-fronted application had shown any lower deployment/administration/maintenance costs than a comparable desktop app. What may be saved in deployment (and many good enterprise desktop apps manage deployment nearly as transparently as a web app) seems to get eaten up by slow response and flakiness for users, network issues, web server issues, browser issues, and security issues. Admittedly, in many cases this is a matter of badly designed web apps, but in the world of commercial enterprise software, the quality of browser-based apps seems to be worse than the already pretty dismal quality of enterprise desktop apps.
Browser apps certainly have their place and can be the superior choice in the situations for which they are well-suited, but after the last decade of having way too many utterly painful browser apps forced upon me, I think the reasoning that led so many to the Kool-Aid tub needs to be reassessed.
Re:No Shit. (Score:4, Insightful)
Well you have two issues here.
1) Web apps are worse. Yes you are right they are. You take a definite hit on quality. The hope is that it doesn't matter too much.
2) Web apps are harder to deploy. That is simply false. Getting an app deployed in an enterprise can be tens to hundreds of thousands of dollars. Getting it deployed in a half dozen + home systems + laptops can be a million easy. I can easily pay for a few help desk people to work through the remaining issues with networking.
Re: (Score:3, Informative)
2) Web apps are harder to deploy. That is simply false.
Note that I never said that web apps were harder to deploy, only that in my experience the argument that web apps were significantly less costly to deploy, administer, or maintain has not been the case. Again, *in theory* they should be, but after a decade of involvement with the rollout and maintenance of dozens of enterprise apps (both desktop and browser) to thousands of users, I've never seen the payoff. YMMV, but I know I'm not alone in this assessment.
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:No Shit. (Score:4, Insightful)
seems to get eaten up by slow response and flakiness for users, network issues, web server issues, browser issues, and security issues.
All of which are every bit as problematic for standalone apps -- except browser issues, and you can always mandate that everyone install Firefox.
the quality of browser-based apps seems to be worse than the already pretty dismal quality of enterprise desktop apps.
Meh. Correlation, causation, etc...
I'll argue that it's still possible to build a good browser-based app on a similar budget as a good desktop app. On top of which, you get portability, the back button / a tabbed UI, easier maintainability (patch everyone at once), and thin-client goodness (your computer's down? Borrow a friend's), all pretty much for free.
The only technical advantages of a desktop app are performance (browser-based CAD is pretty primitive) and the ability to work offline. The former isn't usually needed -- premature optimization is the root of all evil, and unless you're really talking about CAD, the browser should be fast enough. And the latter is neatly solved with Google Gears, or possibly Adobe Air.
Re:No Shit. (Score:5, Informative)
That's why you have Java Web Start. It's as easy to deploy as a web application (it is just a couple of files on a web server), and you get the full goodness of a locally running application. And, since it's Java, it doesn't even take much effort to make sure it even runs on other clients than Windows desktops.
Re: (Score:3, Informative)
Actually, that is not quite true. Every time the user runs the JWS program locally, the JNLP client connects to the server to see if there's a upgrade available. It's even so good that it simply does the check per JAR file, so the program is upgraded very quickly, as only the files that have actually changed are re-downloaded.
Re:No Shit. (Score:5, Insightful)
I don't see why my comment doesn't apply? I know I went off on a bit of a tangent, but...
I think people are forgetting what a PITA it was with installed apps. Obscure bugs, difficulty in making sure everyone had the latest version, locked-down desktops that required IT to install the app, off-site users being SOL, platform dependency, etc. And, the BIG one, everyone in the company thought they were a VB wizard, so you had a bunch of crazy VB and VBA apps floating around without any real central control. At least with web apps you know everyone is running the same version and using the same settings, and there's some accountability for who's in charge of the thing because SOMEONE has to run the server :)
Re: (Score:3, Insightful)
Citing all those listed PITA's in the parent post, I much prefer using web applications in my line of work because they're the best tool for the specific job at hand.
Re:No Sh!t. (Score:3, Insightful)
I second this.
What about all those fine thick client apps that refuse to run unless they have elevated privileges on the workstation?
Centralized Control of Standalone Apps (Score:5, Insightful)
I think you're going to see an explosion of standalone applications tethered to a web-based datasource or back-end. iPhone and Android basically do this already - taking their cue from email programs since the dawn of the internet. Programs like Steam allow you to install local, fat clients through a thin client interface. Each of those pieces has a reason for being fat or thin, and you want to take advantage of that.
I think, in the end, the point is that you want to be confident your interface is usable where-ever, and that your backend can be swapped up without version issues, and that either way the program can do everything it needs to. The web is very good at the first two, it's just that the domain of problems it can manage has not yet expanded to the third. Is that anything but a matter of time?
Re: (Score:3, Insightful)
You've clearly never used SAP.
Re: (Score:2)
THIS is EXACTLY the problem. It is NOT always easy to install a GUI app from some other version of Windows.
I have seen so many goddamn OS specific applications in my time, that I have to restrain myself from reaching across the table and killing the guy whenever it's brought up as an idea.
Even nice Java apps can be a PITA, because you end up with apps that depend on this or than specific JRE release, and while you can bundle your release with the code, that doesn't always ensure error free delivery across m
Re:No Shit. (Score:5, Insightful)
In my experience what happens is the opposite problem:
1. Corporate IT department decrees that all machines will only run WIndows, and will only use Internet Explorer, because that way there is only one client version to target.
2. Corporate IT develops (or buys from a vendor) a web based application. It becomes widely deployed.
Needless to say, said web application only works with IE. Why should it work with anything else? See item #1.
3. A new version of IE comes out. The widely deployed app won't operate with it, because it was designed to be dependent on ActiveX, and it is incompatible with IE version what-ever-we-have +1.
4. So, corporate IT decrees that no one using this application can upgrade IE until the app has been fixed and tested.
Which is why we are still using IE 6.
Now the interesting question is, what happens when we need to use two web apps, each of which has different (and mutually exclusive) browser version requirements?
The ironic thing is that if in step #1 they had said we can use any browser, on any O/S, then we wouldn't be in this mess, because the web apps wouldn't be browser version specific.
Re: (Score:2)
I think that's true only in certain cases. If a competitor to Facebook tried to make you install an app, that would fall pretty flat. If it can be done on the web and the performance is okay, you probably shouldn't make the user install something.
Re: (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 seri
Re:No Shit. (Score:5, Insightful)
Re:No Shit. (Score:5, Funny)
Re: (Score:3, Insightful)
... and stuff like wxWidgets [wxwidgets.org], too. Multiple languages, multiple platforms, looks and acts like the running environment. No VM required. (Yes, I know, gcj exists ...)
Re: (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 t
Re: (Score:3, Informative)
Re: (Score:3, Informative)
In that case, I would recommend that you look to Java Web Start instead. It's as easy to deploy as an applet, but the user gets a real, stand-alone application instead.
Decentralization? (Score:5, Insightful)
I thought decentralization was supposed to be a good thing, the whole motivation behind having personal computers to begin with but, in the age of web apps everywhere, we seem to be returning to the days of the totalitarian, you'll-do-it-our-way-and-like-it data center (mainframe) model.
Re:Decentralization? (Score:4, Insightful)
Remember "Push" technology or whatever that damn buzzword was back in '97? This is just another iteration.
Now, not to say Web apps don't have a future. Being able to whip up a decent document, spreadsheet or presentation on the fly with nothing but an internet connection will be damn handy. But as a replacement for self-control? No frigging way.
Tossing a bone to the fanboys: This is all Microsoft's fault anyway. If they hadn't decided to use Office as a raping and pillaging tool, there wouldn't be such a goddamn stampede away from them, and towards any cheaper alternative, whether it's good for you or not.
Meanwhile, I'm happily using O.o and laughing at all of them.
Re:Decentralization? (Score:5, Insightful)
I thought decentralization was supposed to be a good thing
It has its good and bad points, like most things in life.
the whole motivation behind having personal computers to begin with
The original motivation was geeks playing around. The main reason they originally started showing up in businesses was VisiCalc, which simply wasn't available in any other form except chalk boards.
we seem to be returning to the days of the totalitarian, you'll-do-it-our-way-and-like-it data center (mainframe) model.
Except we aren't. Even a netbook is smarter than a TTY terminal. Plus, with the internet you aren't tied to a single mainframe. You can do your web email with Google, your web search with Yahoo, and your web word processing with Microsoft. The old mainframe way would be if Comcast supplied email, search, and document creation and you did not have a choice to go out and use other providers' services instead.
What you are seeing is a move towards web apps where it makes sense (email, document sharing, social networking, etc.), and people sticking with local applications where it doesn't make sense to go to the web (video or photo editing, most office documents, etc.) - anything where the bandwidth or latency requirements become too much of a bottleneck.
Re: (Score:3, Insightful)
It has the name "Photoshop" in it, but it sure ain't Photoshop... it doesn't even have layers. I think you'll see some movement of amateur photo editing move to the web, but certainly not everyone just yet.
Re: (Score:2)
How much choice do you have with Excel? Sure, you "control" the data in that you can store it locally - but there's nothing inherent about web apps that prevents you from storing data locally. For instance, Google apps let you export in a number of formats and you can even run "offline" with Gears.
So run Excel and MS is your overlord... why is that better than Google?
Re:Decentralization? (Score:5, Insightful)
I have yet to meet anybody that said their new web-based app whipped the llama's azz compared to the old thin-client or mainframe app
Unsurprising. Even with AJAX techniques to avoid refreshing the page fully, and even using JSON (maybe gzip'ed) instead of XML to reduce the traffic, and even with HTTP keep-alive to reduce the connection times, the technology used in web-apps today is still more "expensive" in terms of performance/latency than the older client/server methods. You build a 2-tier Win32 client with a direct connection to the database, and you've got a pure binary stream, composed of useful data and little else (vs. verbose XML, particularly); you don't have extra layers of webservers, you don't have a connection that starts/stops constantly, etc. You have the ability for the server to notify the client that something has changed, whereas with web-apps, you at best have something like Comet, and more likely have some sort of polling AJAX call. And the client's probably compiled, running natively, using hWnd's and whatnot; with web-apps, you may have the wonder that is javascript performing DOM updates that have to be interpreted and re-rendered by a multipurpose browser.
Of course it's less efficient. But as others have pointed out, that's not always the point. It's about control, it's about standardization, and ... oh, right, it's about control.
SQL? (Score:5, Insightful)
in this modern day-and-age, most stuff is just data anyways, and that is all database. Moving to a true client architecture, oh wait, all the data is still stored centrally, and most reports are all done via stored procedures.
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
Re:SQL? (Score:5, Insightful)
But we can use Crystal Reports or Oracle Forms!!! Then we can install 1 Gig of software to be our "server" (in addition to the DB) and another Gig of software on the client... all to look at the SQL queries sitting on the DB server!
But wait there's more!
In most companies BIG IT supports databases and data centers. little it supports servers with department apps. It's all about the responsibility. An app that hogs a desktop PC and takes 5 minutes to start is the "users" or "it" problem, not management's. The same app in a datacenter serving 50 users poorly is now an "IT" manager problem.. and they'll demand the app fixed or toss the app out. Guess which group vendors like to sell to?
Re:SQL? (Score:5, Insightful)
I'm not sure what kind of work you do, but as someone who is developing a lot of web apps right now, I'll say straight up that the data is the easy part. The internals of any system are well understood and the border cases are easy to handle.
What takes time, and what breaks, and what drives me nuts, is the UI - validation, layout, rendering quirks, etc., etc., etc.
I've recently started playing around with Adobe's Webkit-based AIR framework for this reason. It lets me interact with the local file-system, have a data store that's not reliant on a network, and above all, has a consistent UI environment.
"It's just data" is a data-centric way of looking at things, and is true in a sense. But the argument being made here is about the interface between the client and the data - not the data itself.
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: (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 som
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: (Score:3, Informative)
So unless there's an extremely good reason to install a desktop app (e.g. you really need complex local interaction, or are dealing with huge data such as video) why bother installing desktop software?
I've given one reason where installing a native app is worth it - the validation of complex user input - and that's certainly not the only positive.
I'm currently contracting as a UI developer working on an internal business application. The application isn't trivial and *could* be written as a web app but that doesn't mean it should be - and don't think they didn't consider it. The interaction that would have to be handled would be a nightmare for the user and it would probably get ignored and the milli
Win32 API - we missed you so... (Score:5, Funny)
Can we please, please go back to the Win32 API? It was such a joy to use, and I've got a Visual Studio 6 license laying around here somewhere.
5. Should every employee have a browser? (Score:2)
Well back to work.
Re: (Score:2)
Are you posting to slashdot from work (with a browser)? ... like me?
;)
Full Ack (Score:2, Redundant)
FTA:
Browser technologies are too limiting.
I couldn't agree more.
True, but people will not listen (Score:5, Insightful)
While I think the arguments against web-apps are valid, it is the newest trend and people will not listen. It will require a few very expensive catastrophies, before something happens. And then people will still not undterstand what the problem is, just that there were expensive catastrophies.
By now I believe most technological trends are not rational.
Re: (Score:3, Insightful)
Hear hear !
Technological evangelical bandwagons. All aboard.
One size fits all is another problem. Silver bullet for sale over here, will work for all applications big and small, and solve all your problems.
Honest, guv.
1997 called... (Score:3, Insightful)
It wants its irrational fear of the web back.
Web apps are not new. We have seen numerous expensive catastrophes. And the trend is not reversing.
Hell we keep pushing more and more in the direction of SOA and chubby clients (thicker than thin, but thinner than thick).
-Rick
Re:True, but people will not listen (Score:4, Insightful)
I hear what's being said but here's a scenario where anything other than a web delivered app is murder:
- We are a small company 300,000 people in some cases
- *All* of their employees use us exactly *once* a year.
Imagine trying to install a desktop client across all continents (save for Antarctica), every year, for one use. (we do have feature upgrades that would call for redeployment).
How much leverage would we have to get that done? in time? none.
Web based? no problem. We get 5-10 calls for support. No additional deployment is needed since all their computers have browsers and access is controlled centrally by them.
Like most things in life, there is good and bad with web delivered app. Is it *the* solution in some cases? Absolutely? Is the *the* solution in *all* cases? Absolutely not. Figuring out when to use what is what the gray thing between the ears is for.
Like web browsers.. (Score:2)
... 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: (Score:3, Informative)
Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term
That's not even entirely clear. There are multiple attempts [lifeclever.com] already to provide something like Photoshop in a web application, including one from Adobe [photoshop.com]. Now I don't expect most graphic pros to abandon their client version of the application, but it's also not as though there aren't web based graphic editors.
Re: (Score:3, Insightful)
Sure a lot of apps can be moved to a web interface. A lot of carpentry can also be done with a hacksaw. The question isn't "Can it be done?" but rather "Is this the best tool for the job?". For example I strongly believe a web app is an awful idea for an office suite. (Having non-sensitive documents stored and editable on the web may be a good idea depending on the application, but there's nothing wrong with using a standard format and using the appropriate document editor. Sure a web interface would give y
Re: (Score:3, Insightful)
Computers aren't like physical objects--they're vastly more configurable. Most users seem to value convenience and ease-of-use above all other attributes, and the way they've embraced webmail shows it. I'm not one of them, but that's the way users are going. Their definition of "best" is different than your definition of best.
Email is inherently suited to being a web based application. For a start retrieving and sending messages requires an Internet connection. Secondly, most email messages are just text an
Automation/Integration (Score:4, Insightful)
To my mind the biggest weakness of web apps is that you have a hard time doing any sort of schedualed reporting/exports to use in another application. It can be done, but you really have to have the stars line up just right, or use some 3rd party scripting of some sort. Doable, but painful. God forbid you want to share data between two web apps, especially when company A and company B both have it in their heads that the other should pay them for development assistance.
PHB sez: (Score:2)
But... but... we have to do it the high tech way! It has to be on the web! And use lots of XML for everything! And integrate with Microsoft Sharepoint and Project Server! And we'll have data dictionaries, and Java classes, and object-oriented OLAP cubes, and we will use some of that AJAX stuff too!
Hmph, next thing you know they will be saying we need to go back to stone-age paper and pencil!
Come on everybody: LET'S PUT IT ON THE WEB!!!! (drool, drool, drool)
Keyboard shortcuts and CLI (Score:5, Insightful)
While fat client apps can have messed up tab stops, they're generally better than their web-based counterparts. A CLI is even better allowing for things to be done in bulk/batch.
I've got over 100 buttons right at my finger tips. I shouldn't need 2 more that roll around (FPS mouselook not withstanding). Let me ALT+whatever and TAB my way around.
YMMV.
Re: (Score:3, Insightful)
Keyboard shortcuts can be done in web apps, but too many of my fellow web developers are too lazy to bother implementing them. As a keyboard fan, it drives me nuts.
However, if the truth be told, that was a problem back when I was developing client/server GUI apps as well. I always seemed to be the only guy who put the effort into ensuring the UI was keyboard navigable.
In enterprise software development, the UI always seems to be almost an after-thought. I don't think bailing on web apps will solve that prob
Re: (Score:2)
well, a lot of combinations are not available in browsers and all browsers combined doesn't leave many unused. But Mozilla has the Prism project which solves that, the webapp can detect it's in that environment and allow for many key-combo's. Also it acts much more like a normal desktop-application, you can (don't have to !) even give it access to your filesystem.
Mobility is the factor (Score:5, Insightful)
Right now web apps are king because they're always only the nearest computer away, and work on almost everything.
We're getting close to devices that provide the same functionality in a mobile form factor. Once everyone has an iphone like device that has a standard development environment we'll likely see a resurgence of local apps. But that's probably a years away at best.
Right now, you can either develop for the web, which will work everywhere, or write one app in Win32/.Net, one in Objective C for Mac, one in Java with Blackberry specific apis, one in Objective C for iPhone, one in [whatever palm is up to], one in .net for winmobile, etc, etc etc.
The only reason client side apps were ever written was because you could be fairly sure windows was your target, or it simply wasn't feasible to centralize and so you forced a standard environment.
There's no single platform anymore, and probably won't be for a while (and when it comes it'll look a lot like a web browser), so the only viable option is web based.
Does it suck? Yes and no. It's definitely better than debugging an app on 40 different platform/cpu/os version combinations.
Re: (Score:2)
Web apps don't magically work everywhere. At least some client (browser?) is needed. 40 platforms vs 40 browsers and we have moved nowhere.
Response from L4C list (Score:5, Informative)
This story was previously posted to the L4C list. Here's the response I sent there:
An interesting, albeit unoriginal, take on the problem of WebApps. Unfortunately, I do not find his arguments very compelling.
Quite a bit, actually. First and foremost is the convenience of application access. There is no software to install and you can use your applications anywhere you have access to a web browser. In addition, the rise of web applications has spurred the rise of web services. Web services share out tremendous amounts of public information allowing developers to "mashup" (I hate that term) data sources to produce superior applications. Compare that to the desktop where just getting the programs on your system to cooperate is a challenge! (To say nothing of networking.)
FWIW, the author is propagating a misconception about web applications. His belief appears to be that web apps MUST push computing power to the server. Nothing could be further from the truth. Web apps are "rich" clients rather than thin clients. Rich clients are more than capable of accepting a significant processing load. Whether that be Video Games [wiicade.com], Image Editors [pixastic.com], 3D Engines [xs4all.nl], Fractal Explorers [2tap.com], or other compute-intensive applications, the client is more than ready to pull its weight.
I personally have written an application for my current employer that requires the client to dynamically sort a 100,000 record data set in nothing but client-side Javascript. Significant computer science had to go into creating an optimized, multi-threaded algorithm that would perform well on the lowest common denominator. (IE6) The next generation of browsers that are appearing (Chrome, Firefox 3.1, Opera 10, Safari 4) will have so much compute power that a problem like my 100,000 row sorter will become easy and commonplace. Furthermore, the standards are even adding true background threads to support long-running compute operations. (The standard is based on the Google Gears implementation, which is already available.)
The communications protocol is stateless. The UI is not. AJAX UIs know their state as well as any desktop application.
Anyone who lived through the development of GUI systems know that this is not a new issue. In fact, it used to be quite common for apps to eschew Windows controls in favor of something custom. Borland, for example, LOVED their custom controls. The rise of GNOME, KDE, Java, and .NET/Avalon/WFC have created just as many problems for the desktop.
That being said, flexibility appears to occasionally improve applications. Using GMail as an example, the design would be gimped rather than helped by a "standard" Windows XP look. The clean lines of the GMail interface manage to communicate a great deal of information without creating the sort of 3D visual noise seen in applications like Outlook.
Javascript is only one component to a very lar
Re:Response from L4C list (Score:5, Insightful)
Quite a bit, actually. First and foremost is the convenience of application access. There is no software to install and you can use your applications anywhere you have access to a web browser. In addition, the rise of web applications has spurred the rise of web services. Web services share out tremendous amounts of public information allowing developers to "mashup" (I hate that term) data sources to produce superior applications. Compare that to the desktop where just getting the programs on your system to cooperate is a challenge! (To say nothing of networking.)
When software installation is so easy, and one's package manager downloads stuff using http, there is no real advantage in this case. Instead of searching on google, and going to a website, you search in pacman or yum or apt or synaptic and click on a "page" to load. As a bonus feature, it's much faster next time.
I personally have written an application for my current employer that requires the client to dynamically sort a 100,000 record data set in nothing but client-side Javascript. Significant computer science had to go into creating an optimized, multi-threaded algorithm that would perform well on the lowest common denominator. (IE6) The next generation of browsers that are appearing (Chrome, Firefox 3.1, Opera 10, Safari 4) will have so much compute power that a problem like my 100,000 row sorter will become easy and commonplace. Furthermore, the standards are even adding true background threads to support long-running compute operations. (The standard is based on the Google Gears implementation, which is already available.)
Do you not find it alarming that in this day and age, a program to sord 100,000 records is deemed impressive? On my machine (an eee 900):
time awk 'BEGIN{for(;;)print rand()}' | head -100000 | sort > /dev/null
Takes 0.7 seconds. By removing the stringification, and obvious inefficiencies,it would run much faster. In C++ is is easy to sort hundreds of millions of records in a very short amount of time using nothing more than std::sort and a suitable comparison function. The fact that in this area it is deemed impressive (and I have little doubt that it is) is a testament to a large step backwards.
Your other points stand, though.
Just come right out and say it, Neil. (Score:3, Insightful)
Enterprise applications should run on dedicated, fully optimized hardware that can be bolted to employees faces.
As far as a web browser for every employee, there are organizations that "value" productivity and organizations that actually understand how to maximize it.
Mixed response (Score:5, Insightful)
heh (Score:3, Informative)
AJAX is not the be-all of internet applications. There is also Adobe Flex and Microsoft Silverlight.
I find most sorts of apps work fine with standard AJAX controls, but Flex isn't hard to learn if you need more sophisticated UI in your internet app.
Not the most balanced article... (Score:3, Informative)
As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter.
For sure, there are some applications that make sense to run locally; or to use special local software in combination with a server, rather than a web-browser-based interface. 'World of Warcraft' won't be implemented in AJAX any time soon.
On the other hand if you want to sell 'software as a service' it's going to be easier if you're supplying ongoing services other than fixing bugs of your own creation. Furthermore, in stagnant markets (*cough*MSOffice*cough*) it could enable new features compelling enough for people to upgrade. What's more, a dependency on your data centre makes piracy practically impossible.
Not everything suits being on the web, or in the web browser. But the benefits to software companies are hard to ignore.
Painting with a broad brush (Score:2)
There is nothing like painting with a broad brush. In this case the premise of the article seems to be an ALL or NOTHING proposition. Web or Standalone application.
This is huge problem in understanding that there really is a need for BOTH. If you've ever tried to get a bunch of Term Servers running powerpoint presentations simultaneously, you'll quickly realize that some things are NOT suited for time sliced or otherwise processor sharing.
On the other hand, some things are suited for Web side (some database
not much of an argument (Score:3, Insightful)
But I thought the web was good?
WRONG! The web is bad! Well, sometimes, for some things... maybe.
There's a grab-bag of random thoughts there on some things that could be inherent problems in the web and some that are merely artifacts, and it seems neither here nor there.
The big guys always call the shots - who cares if it's browsers or operating systems, you're not going to tell MS (or Apple, just to be fair) what to do and there's no guarantee the next SP or random security patch won't bone all your effort with no notice or recourse, whether it's in-browser or on the desktop.
And the web UIs are a mess? That's nothing to do with the web - lots of people design lots of stuff, you get randomness. It's no different than on the desktop, except the long reign of some MS products and the fact that developing Windows apps you get to use some of those same form controls gets you the appearance of this magical consistency that's really just the consequence of monoculture. Open any full-screen app (read: game) and it's a brave new world, like on the web, because the pre-generated MS controls and constraints don't apply. But this is good, right, because you're not doing what the man tells you to do?
And the productivity argument... did he just need to reach 5? You can block the outside world coming in over the wire, it's not that big an effort, and then people will find other ways to screw around - hand-held devices are so powerful now the whole issue of limiting the desktop to work issues only is quickly becoming moot.
And so on and so forth... I guess it's redundant to say "you need to consider each usage case based on its specific merits," but then the decision-makers don't...
nevermind telecommuting (Score:2)
Ahhhhhhh pontificating (Score:5, Insightful)
Note that many desktop apps hit web services or communicate via HTTP now, mostly because it's 1. easy and 2. SOA became the flavor of the month about a year or so ago.
Also, many enterprise web apps, at least that I've used, have some sort of plugin/JVM requirement. Are they a desktop app? Web app? Some awesomely funky in-between?
Personally, I think these "thick vs. thin" client discussions are a nice waste of time and excuse to get page impressions.
Let's deconstruct, shall we?
Running Outlook and Office will immediately slow that poor laptop to molasses. Add a nice shiny .NET app, or worse, Java, and you've got yourself a tarpit.
You, my friend, have never used internally developed VB6 apps. I say no more.
For some applications, I completely agree. But not everybody needs to see dynamic fluid modeling or stock quotes for 3000 securities in a real-time heatmap.
Good call, time to turn to Java and .NET, which aren't controlled by big vendors.
Because deploying and maintaining desktop apps across thousands of machines is wicked easy.
Re: (Score:3, Insightful)
I've used many Java apps over many years (all "enterprise" apps) and they were all *amazingly* slow, every one. SOme are just slow enough that you notice, others take 5 seconds after clicking on each control to react. People often say this it doesn't have to be this way in Java, and maybe that's true, but nevertheless every single Java "enterprise" app I've every seen across many years and companies has been utter crap.
Also, none of them used Windows widgets on my Windows machine, so each UI was a puzzle
Advantages of web apps (Score:2)
But lets talk about some of the advantages of web apps as well.
There's another type of case against Web apps (Score:2)
That type is what I argued again here yesterday:
http://slashdot.org/comments.pl?sid=1107509&cid=26650341 [slashdot.org]
Make up your mind (Score:2)
But I thought you were just complaining about running on the server, not a browser. Yo
Point by point dissection (Score:4, Insightful)
I'm a software support rep and not even a developer and I know this is a blowhard troll.
1. It's client-server all over again.
Web applications encourage a thin-client approach: the client handles UI rendering and user input, while the real processing happens on servers. What sense does that make when any modern laptop packs enough CPU and GPU power to put yesterday's Cray supercomputer to shame?
Concentrating computing power in the datacenter is fine if you're a Google or a Microsoft, but that approach puts a lot of pressure on smaller players. Scaling small server farms to meet demand can be a real challenge -- just ask Twitter.
Furthermore, security vulnerabilities abound in networked applications, and the complexity of the browser itself seemingly makes bugs inevitable. Why saddle your apps with that much baggage?
First, it's not client server all over again, not in the way you mean it. Client/server like windows terminal server or citrix makes it easier to manage company wide systems by giving an IT guy a central point to manage, and that saves time, which translates to dollars. Web apps do the same thing, but they are benefit from even easier setup management and deployment. Terminal server is a pain in the ass when it comes to deploying an app, because it has several ways to do so, none of them web based. You could deploy it by giving everyone a desktop to the terminal server, but then the dumbass users can't figure out which is their PC desktop and which is their server desktop. You could publish the app, which requires changing settings on the server and deploying the proper shortcut to the user's desktop, which takes more knowledge, which not everyone has.
Web apps are easier to deploy in that all you have to do is provide a web address. Everyone knows how to use a web browser and click on links. Citrix even recognized this and provides software to allow you to connect to the citrix box with a web interface!
Siting a laptop is stronger than an old cray is a clever misdirection. The real question is, what's more beneficial for your business, 30 laptops that cost $1000 apiece? Or 1 very large server that costs $10,000 plus 30 laptops costing $500 apiece? I just saved you $5000 on hardware! Plus when a laptop dies, there's less downtime, because I could just hand you another machine and you just go to the web address again. No application reinstalls. Most mega servers these days cost less than a distributed environment and can handle processing quite nicely.
As far as network vulnerabilities, that's just utterly nonsensical. How does that statement say that a webapp is less vulnerable than a distributed app? Data still has to travel over a network in a distributed app! Duh! Besides, most of the vulnerabilities these days dealt with IE specifically and those dealt with how it was integrated with Windows. Pick another web browser, viola, reduced vulnerabilities. Take it a step further and deploy the web app as an intranet app so it can't be accessed outside your local subnet. Network security is for the network professionals, let them take care of it. Provide encryption as needed in the app and access levels for the data but other than that, that's not a developer's domain.
2. Web UIs are a mess.
The Web's stateless, mainly forms-based UI approach is reliable, but it's not necessarily the right model for every application. Why sacrifice the full range of real-time interactivity offered by traditional, OS-based apps? Technologies such as AJAX only simulate in the browser what systems programming could do already.
And while systems programmers are accustomed to building apps with consistent UI toolkits such as the Windows APIs, Apple's Cocoa, or Nokia's Qt, building a Web UI is too often an exercise in reinventing the wheel. Buttons, controls, and widgets vary from app to app. Sometimes the menus are along the top, other times they're off to the side. Sometimes they pop down when you roll over them, and s
Web development is fast? (Score:5, Funny)
"Sure, Web development is fast, versatile, and relatively inexpensive,"
Did Internet Explorer suddenly disappear? I must've missed that today...
False Dichotomy (Score:3, Insightful)
I believe web-versus-desktop is mostly a false dichotomy. The problem is that our standards need a rethink. Web browsers started as a kind of e-brochure viewers, and this e-brochure approach was shoehorned into C.R.U.D. uses (biz forms, data-sheets, and reports).
What is really needed is a "GUI browser" standard and/or OSS tool that has most of the desktop-like GUI functionality and behavior we've all grown to like. BUT, this "GUI browser" could ALSO be used for desktop development. Thus, one does not have to learn a different UI platform when toggling between desktop and web projects.
Most GUI kits have made this difficult by making GUI's language-specific. Fitting these to other languages is often almost as forced as HTML-browser-to-CRUD shoehorn jobs. What needs to be done is the design of a GUI protocol that is mostly declarative. Being mostly declarative makes it easier to use by different languages and paradigms. In my opinion, the "everything must be OOP" thinking is largely what has got us stuck with language-specific kits. OOP is not well-suited to declarative APIs/protocols in my opinion. Encapsulation generally leads to behavior-centric API/protocol designs. (Some disagree, it makes for an interesting and heated debate.)
The behavior-centric approaches of existing GUI kits hinders this goal. Most common GUI actions can be defined declaratively if you think about it a bit. The remaining that require Turing-Complete coding can be done by server-side and/or client-side app languages using the more lower-level features of the GUI-browser.
Think of it as kind of as a smarter and HTTP-friendly rework of X-Windows where one usually deals at the widget-level instead of at key-stroke level (but key-stroke level is still possible as an option).
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.
Sure, browsers suck, but what options do we have? (Score:3, Insightful)
I hate crappy AJAX GUIs as much as everyone else, but I also know that writing a decent "offline" application in a suitable language takes at least one order of magnitude more effort - and that is before you attempt to implement some of the features every web app has naturally (automatic updating etc.).
It's convenient to rant about the stuff we use every day, but when was the last time *you* wrote and supported a non-web based, cross-platform application with GUI and had first hand experience with all the problems involved? Nowdays we're all spoilt web developers, aren't we ...
Re:Bring back a document-only based web! (Score:5, Insightful)
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.