The term "web app" came to mean apps that you access through a web browser. Most of them are (still) not a whole lot more then 3270 screen apps with colour. Actually 3270 devices were slightly smarter then most web apps. Even today, many web apps (and their supporting frameworks) follow this model. Since about 2000 people started using and abusing javascript to give these apps some of the responsiveness that we had back in the 70s. Yay. The term Ajax was coined when people realised they could fetch data in the background for these elements.
GMail came along and showed the first "mainstream" Real web app. It is just one "page" - which then uses the browser as the powerful GUI platform it is to render itself, in the client, and handle user gestures, in the client. What a client was meant to be, what "MVC" was meant to be. Kind of a simplified version of what people did 1000's of years ago with those xerox smalltalk and lisp machines.
This is not to say that the "ye olde" style web apps don't have a use - they certainly do. In fact the web is and should be mostly of this type of app/site (which is really a web site with dynamic content behind it). But they aren't really Applications from the user experience - at least not all they could be. Wonderful frameworks like rails seem to take things as far as they can go for content driven web sites - but most people find they want more (more importantly their users expect more) for richer apps (this is only a small subset of app out there). So you either have to find a front end Real app framework for your big complex app (like google and others do), or don't let your apps get complex, build smaller apps that can live as content driven web sites (like 37 signals do) - both are great approaches. Its just upsetting when people get confused (and you get a web site trying to be a big ugly complex app, or a hulking app for something simple that could have been done as a web site).
Some popular examples:
- GMail - an app
- Facebook - a web site with a little ajax (increasingly becoming an app - but it still relies on page refreshes)
- Twitter - a web site (and rightly so, twitter is perfect as it is).
Well, no one could say it better then the authors of the truly amazing Cappuccino framework:
Designed for Applications
Nobody will deny that there is a distinct difference between a web site and a desktop application. Similarly, we believe there is a big difference between a static web page and a full fledged web application. Cappuccino is designed for applications, not web pages.
Instead of doing all or most of the work on the server, Cappuccino applications do as much as possible in the client. A typical application would never reload, but rather send and recieve data using traditional AJAX techniques and then present that data in the client code. 280 Slides is the first Cappuccino application, and it's a showcase of what is possible with this new framework.
Instead of worrying about how to implement drag and drop, copy and paste (of text and objects), undo and redo, document saving, rich cross-browser drawing and graphics, and a slew of other features, developers are free to focus on specific problems like PowerPoint support, or Twitter integration, or whatever else makes their application unique and compelling.
How does Cappucino Compare to Other Frameworks?
Cappuccino is not designed for building web sites, or making existing sites more "dynamic". We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks, but they are forced by their nature to make compromises which render them ineffective at application development.
On the other end of the existing frameworks are technologies like SproutCore. While SproutCore set out with similar goals to Cappuccino, it takes a distincly different approach. It still relies on HTML, CSS, JavaScript, Prototype, and an entirely new and unique set of APIs. It also requires special development software and a cumbersome compilation step. We think this is the wrong approach.
