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."
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 large system. Quite a few languages are available to make data and services available to the Javascript client. But once you get to the client, Javascript is the only language that has been well designed for document delivery. Its dynamic nature means that modules can be loaded and executed faster, and dynamically plugged and unplugged without the difficulty of writing special code like other languages. This sits well with the dynamic web services of the World Wide Web and helps explain why alternatives like VBScript and Java Applets never caught on.
Right tool for the right job. Someday someone will come up with a better tool for the web and browsers will begin supporting it.
Witness HTML5, which explicitly addresses these issues. If you have one of the betas of upcoming browsers (FireFox 3.1 or an Opera dev build are two I'm aware of), you can visit http://tinyvid.tv/ [tinyvid.tv] and see the future of multimedia without plugins. Granted, these are not here yet. Flash is holding down the fort for now, but it won't be long until solid alternatives are widely deployed.
Silverlight is merely more of Microsoft's anti-competitive practices and has no significant marketshare. Quicktime is not a web technology, but merely made use of by many web technologies. Safari will continue to use it as the underlying player for its implementation of HTML5 video.
It's true that Microsoft has planted itself firmly in the way of progress. Even their implementations of the standards are one of their more extreme examples of "Embrace, Extend, and Extinguish". This being L4C, I shouldn't have to tell everyone that we should not reward such business practices. I've begun firing IE users on my hobby sites and am pushing for cross-browser standards compliance at my employer. Surprisingly, there is very little resistance to these choices. Many IE users appear more bemused than upset at being "fired" and happily launch Firefox to view the content. Why they still bother with IE at all probably has more to do with convenience and employer mandates than an actual desire to use the product.
This statement is a bit self-serving. When spun like this, it makes browser vendors sound almost malicious and does not separate out Microsoft's efforts from the rest of the industry. The truth is that the browser makers are working together on HTML5. Features are implemented in an experimental capacity as a real-world test before they are finalized. (One of the mistakes made during the W3C days was that no implementations of the specs were done. This made the real-world implementations difficult to support and fragile to use.)
The same could easily be said of Windows, Linux, and even Mac OS X. These systems hardly hold still. Windows in particular has a new technology every week. Was that Winforms I was supposed to use or was it Avalon, Silverlight, or WPF? ADO, DAO, JET, ODBC, weeee! ASP.NET 1.x, 2.0, or 3.5, can't decide. 4,5,6 pick up sticks.
I won't go into the ABI changes or variety of API choices for Linux. Suffice it to say that choice is a core part of the technology market. The real question has always been whether or not the old stuff will work on the new platforms or not. When it comes to web technology, the answer lies in whether you tied yourself to a vendor (e.g. Microsoft, Netscape) or if you used cross-vendor standards as your foundation.
White-listing is not a difficult problem with today's networking technology. Ignoring the Internet does not make the issue of employee access to unfettered applications go away. The problem exists with any new communications technology. Should we stop using technology? (And with Cell phones now having sophisticated web browsers CAN an employer stop the technology?)
When the telegraph was invented, many employees used the system for personal communications among operators. A BBS-like culture developed among these operators. When the telephone was invented, employees began using the device to communicate with family and friends or conduct personal business on company time. Mail and office supplies are another place where employees can and do abuse their privileges.
The issue at hand has more to do with the responsibility of the employee than the advent of the web browser. Just as employers have had to strike a balance with employee use of their other facilities, so will they need to strike a balance with employee Internet usage. The only difference is that electronic safeguards can be implemented for low-responsibility positions (much in the way the supplies cabinet can be locked) while employers must evaluate their high-responsibility employees based on output and productivity rather than anything as minuscule as internet usage.
(As a developer, I can tell you that cutting off Internet usage would leave me incapable of doing my job.)
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.
Browser... OS... What's the Difference? (Score:2, Informative)
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.
By the same logic, one shouldn't program at all. After all, different operating systems handle the same source code differently. Add into that different versions, etc; you'll never have a standard audience and therefore all programs everywhere will always be the lowest common denominator.
Srsly, browser rendering is a well specified standard. To claim it's a barrier to good software is silly.
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:Java applets for serious web apps (Score:3, Informative)
Re:No Shit. (Score:1, Informative)
IE, as of 7 still had problems with translucent div's overlaying select boxes with the select boxes bleeding through.
This is marked in their database as "by design" or what-not and their recommendation is to iframe it or make it non-translucent.
Joy. Things should work and not have unintended side-effects.
AJAX cross browser libs (Score:5, Informative)
Re:... and so what? (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: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:Java applets for serious web apps (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.
Re:No Shit. (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:3, Informative)
exe vs. php (Score:2, Informative)
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.
Re:SQL? (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 million or so spent developing it would be wasted.
So I guess the moral of the story is that it's a case by case basis on whether to go to a traditional app or not. I think Flash/Flex and Silverlight are good middle ground since you can still run it in a browser but have rich client capabilities. The installation for those is very easy and some pretty impressive things can be done with them. Java certainly dropped the ball on this with regards to applets and webstart. Once you are past the more complex (compared with flash/silverlight) JRE installer, applets work and perform fine, but webstart isn't transparent enough, there are too many dialogs and download windows that pop up when starting up the app. That confuses a user and as a developer I find it ugly and annoying.
Installing and managing desktop applications is extremely expensive compared to browser-based app's.
I wouldn't say installing any traditional app is extremely expensive. It's no more cost prohibitive then making sure everyone has the same browser version. A little extra time installing could save a lot of productivity that a properly written native application can give you.
The rule everyone should follow is that, in the end, it's all about the user. If they are better served with a web app then that's what they should get, and the same goes for a traditional app. The author seemed to be saying that with the current buzz around web apps, like Twitter, Facebook, the ton of Google offerings, etc., some things are being developed there that really have no place on a web page.
Re:No Shit. (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.