Slashdot Mirror
The Case Against Web Apps
snydeq writes "Fatal Exception's Neil McAllister offers five reasons why companies should re-consider concentrating their development efforts on browser-based apps. As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter. And while UI and tool limitations are well known, the Web as 'hostile territory' for independent developers is a possibility not yet fully understood. Sure, Web development is fast, versatile, and relatively inexpensive, but long term, the browser's weaknesses might just outweigh its strengths as an app delivery platform."
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.
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.
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
I will not give in to the terrorists. I will not become fearful.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And these issues shrink all the time. I agree with Joel regarding rich clients--I use Mail.app for e-mail, but virtually no one else I know does. Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term, but other apps will, and it's hard to see this guy's ideas mattering. Sure, they might be true, but the web is still more convenient. For me, it's become a central repository for book and other commentary in the form of The Story's Story and write about grant writing at Grant Writing Confidential. Yeah, I write my posts in Textmate, but most people don't--and most people aren't going to buy and install Textmate.
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.
My biggest complaint about browser/web apps is the inconsistent or non-existent ability to navigate the app with the keyboard.
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.
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.
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, Image Editors, 3D Engines, Fractal Explorers, 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
Javascript + Nintendo DSi = DSiCade
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.
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
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...
Even as you read this, your pants are strangling your loins! Aaa!
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.
So says the guy that just posted to a slashdot thread. If slashdot.org was just a static document with links, you wouldn't have been able to send your message back to the slashdot database for other's to read.
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
Fuck all that http shit. Bring back Gopher!
Why is it so hard to only have politicians for a few years, then have them go away?
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
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Webb apps will always have the browser in the way, with the inevitable conflicts over keystrokes. I have yet to see a web UI that even comes vaguely close to the convenience of all but the very worst standalone UI. If I'm going to willingly use a web app, there's got to be a real advantage to me as a user to using it. That's why I still use traditional word processors, not Google Docs. They're a lot easier to use, and I suspect always will be. That's not the same as net apps, though, where a dedicated standalone interface accesses data on the internet.
Quidnam Latine loqui modo coepi?
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
"All great wisdom is contained in .signature files"
"Sure, Web development is fast, versatile, and relatively inexpensive,"
Did Internet Explorer suddenly disappear? I must've missed that today...
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).
Table-ized A.I.
I second this.
What about all those fine thick client apps that refuse to run unless they have elevated privileges on the workstation?
Wearing pants should always be optional.
That's why there are numerous ajax libs that give you a standard of cross browser support without having to worry about oddities. YUI is my favorite although there are others. All of their main controls work the same across all top browsers - very nice stuff.
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.
Don't thank God, thank a doctor!
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?
[Ego]out
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 future is not a useful pursuit. In most cases, designing for these compatibility issues falls into that category.
In short; you easily could be relying on a common bug, but you just as easily might not be. There is no reason to second guess yourself for such a small return.
[Ego]out
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.
Well, that was the lamest collection of reasons I've ever seen.
It's client-server all over again? Umm. Yeah? So? Most enterprise applications are client-server. Include document and process management and your entire network is a gigantic client-server system. Come on. Is that supposed to scare anyone? Really? Wow. Should every employee have a browser? Hell yeah. If they have a computer they should have a browser. If you have a problem with your employees doing other stuff than work then you have a problem that won't go away because you take away the browser. That should be obvious to anyone who has ever been an employer.
And saying that the web is a place that is dominated by big players is just ludicrous when advocating working on the desktop instead. (I don't think I need to spell this one out for you)
No, this is all crap. There are valid reasons why certain applications shouldn't be web based. But the article lists none of these. Too much load on the datacenter. I mean seriously. Come on!
I've had a wonderful time, but this wasn't it -- Groucho Marx
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.
While browsers were readily sitting on all these computers.
Switching to server-client brought some sanity back into my life.
Certainly the network should be policed to make it secure. No helmet, no body armor, no steel door makes a security. It's just a part of it.
Server overload? 4 cores, 12 GM RAM, 2 TB hard disk are overloaded? Check your code and especially queries. Say, if in PHP you are to get an integer do only casting $a=(int)$_POST['a']; no further sanitizing is needed. Casting is non-function operation and requires little computing. Limit queries. Writing good queries and sticking to efficiency and security philosophy on a server may make an application work.
One more thing, vote for politicians who use Internet and pledge to protect it.
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.
ignoring the parent's incoherent and completely off-topic rant, the arguments raised by the author are somewhat flawed.
take for instance:
um, all over again? when did we ever stop using the client-server model? client-server architectures are so prolific because it's simple and it works. some of the greatest technological successes in recent decades have been based on the client-server application model--for instance, database servers and network services and their derivative technologies such as the world wide web, ATMs & EFT, cellular networks, instant messaging, IRC, all types of online gaming, and the list goes on.
commodity computing moved away from dumb terminals and thin clients perhaps, but things don't have to be one extreme or the other. you can have the best of both worlds. a modern MMORPG is a client-server application, but they're certainly too graphics-intensive to run on a thin client. but if you're developing an intranet application that already uses networking and databasing, two of the most prominent classes of client-server applications, then what is wrong with using a web front-end that is cheaper and faster to deploy?
with today's high speed networking and mature browser technologies, most enterprise applications gain no benefit from being developed as a standalone desktop app. an accounting application doesn't require a complex desktop interface or lots of processing power, same with CRM and other business applications. applications like 3D gaming, multimedia production, CAD software, scientific modeling, etc. still require a standalone desktop application. but business apps that consist solely of filling out text fields & electronic forms and outputting textual data with very basic graphics are perfect for web front-ends--especially if they're network applications.
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 ...
"I love my job, but I hate talking to people like you" (Freddie Mercury)