For years we've been told that web apps are the way of the future. But are they really? The answer is "probably not". Think about where web applications are going. You don't know where they're going? We'll let's think about where they've been.
The Stateless Abyss
For almost 20 years now, web applications have lived in the stateless depths of the World Wide Web, thanks to that wonderful little protocol, HTTP. HTTP's request/response nature allowed for simple and straight-forward communication back in the day, when all we really wanted was to ask another machine on the web for a resource.
The Dynamic Shift
As the Web grew in popularity, we started placing more and more demands on the resources for which we asked. We started making the dog do tricks. We wanted more "interactivity"; static text and images were no longer enough; we now needed the ability to customize the resource and create "dynamic content" with each request. We wanted to conduct business and stream media all over a stateless channel, where each transaction had no knowledge of previous ones.
The Stateful Revolution
Soon, having the dog roll over or shake hands was not enough as well. The time came for stateful transactions. We now want to keep track of whom is logged in, what he/she has done and where he/she has been. We want state. Only now, we're making the dog walk a tight-rope and juggle chainsaws. We've begun to do things like stuff variable values in responses and re-collect them on the next request or write database records to keep track of transaction state on the web server; all to mimic stateful transactions. Dozens of web frameworks have surfaced, many having a mechanism built-in to get around the stateless nature of HTTP. We now have technologies that effectively mix web and desktop technologies, something I like to call "webtop clients", manifest in Adobe Flash Player, Java Applets, and Microsoft Silverlight.
The Pattern
Do you see the pattern? Since the inception of the Web, web applications have evolved significantly; from static content to dynamic content, from statelessness to statefulness, from browser-only technology to browser-desktop mixture technologies. However, their evolution is not toward something new and unseen, but to something all too familiar, the thick client.
With today's frameworks for desktop application development and deployment, the justification for many of today's web applications, especially web apps internal to a company, are no longer legit. Take a look at Apple's iTunes; everything Apple flows through that application. As for deployment, Microsoft's ClickOnce for .NET Windows applications and Sparkle for Cocoa applications make deployment and updates so easy, it's ridiculous. Don't get me wrong, web applications do have their place, but the number of scenarios for which they are the optimal choice is dwindling; sure they can be used for nearly everything, but what's the point? It all comes down to the following question: in a particular situation, what problem does a web application solve that a desktop application does not? When you realize how many times you can't find any, you'll realize that web applications are overrated.
9 comments:
Some good points, although I dare say the lynch mob is a-comin'
; )
What is the point? I don't know about you, but the point is making it easy for people to enter their information and buying your product. That's it.
if there was a universal desktop app that people could use to pay for the oriental rug under the newly purchased poker table, then we wouldn't need http apps would we? But hey, what do I know, I am only a math teacher. :)
I agree with "the point is making it easy for people to enter their information and buying your product", but only when the purpose of the app is outwardly focused toward use by the masses (although the Apple iTunes desktop app even has all that wrapped up).
However, I think you're narrowing the idea of an application down to specific type. In reality, what percentage of applications are that type? How many need to "reach the masses" with an easy barrier to use and entry? It's gotta be small compared to the number of utility and point of business apps that each company's internal information systems group builds or buys.
But I do agree, that type of application is optimally implemented with a publicly accessible web application.
I think you completely miss the "multiple computers" scenario. The reason I use Gmail is not because I don't wanna install an email client on the computer I use. It's because I don't wanna install an email client on the five computers I use. Especially when one of those computers doesn't allow any installs without IT's permission..
You miss a few of the advantages of deployment through a browser.
1.Convenience: I dont need to install your application. to start using an application, it can be a matter of clicking a link
2.Cross Platform: a murky area, since cross browser support isnt the best, however "every" computer has a browser. not every computer has the ,net / jre / whatever.
3.Security: The browser is still somewhat of a sandbox, I cant do much harm from the browser, I can do a lot (pretty much anything) with an executable.
4.Ease of development: this maybe more of a personal preference, since I have had a few people disagree. but I much prefer fighting with js + css than working with gtk/windows forms/swing, the latter may be more powerful, but there isnt much that cant be done with the former, and it takes a hell of a lot less time
i think what most people like about web apps is that they do not have to install anything. they just pop-open their browser then view reports, approve stuff, etc. and it could be accessed anywhere.
you have to admit, installing applications are a pain in the ass. you have to consider what OS, system configs, etc. the user is using where in web applications, all you need to worry about browser compatibility...
Php 0.02 ^_^
I write an offline app, intentionally. I'll likely extend to the web but for now it's great offline. So I agree with the spirit of your general message.
But here's a time when web is preferred: when the pipe between the UI and the DB has to be broader than the link between the UI and the user. So lots of data with many joins and re-queries - rather have that zipping around a local network than over the cloud. Produce a small graph/whatever, then send it to the user.
E.g. Gmail. I can pull my data into Outlook, but I don't. Don't want to. Let them search the multi-GB data and send me a summary.
but, my friend, by far the biggest point you missed was that web apps work. Yes its very simple.
Anything beyond that doesn't remove that previous possibility of writing great apps (gmail included but don't forget facebook), it just expands the power of the app developer through choice.
oops i explained that badly. hopefully you can work it out yourself.
The fall-off rate of getting users to install a client-based piece of software versus clicking a link - even having to wait for it to load - is immense.
If you need to have tons of logic like iTunes - which is an immennnnse file size which can likely be optimised some, but that's beside the point - then clearly a client is the only game in town.
But we can get more and more basic stuff into those fat clients which are user-friendly.
Like most tech issues - depends on what your goal is...
alex@hoye.org
Post a Comment