On one of our NetBeans mailing lists, a new programmer asked a question, how should they build their application that needs to run on ten client machines talking to a MySQL database.
The quick answer was "build a web app."
I just don't understand this. The web app architecture is - c'mon, admit it - ugly for applications that need to have dynamic behavior (e.g. almost every app out there). It was never built for that. HTTP/HTML is a static, document-oriented protocol and markup. HTML came from SGML, which is all about documents and publishing, not dynamic database-driven OLTP applications.
But it wasn't always that way. When I was fresh out of school, the browser didn't exist, and we built simple client/server applications. The client talked directly to the database using a database-oriented protocol.
There were issues, of course, the primary one being how to manage versioning and upgrades across thousands of machines, each with their own operating system and versions, some of them sporadically connected (e.g. on laptops). One of the key advantages of the web is that you install it in one place, and everybody automatically gets the upgrade. And it runs on everybody's machine. It's so cool.
Having a middle tier also allows you to disintermediate between the clients and the database, which can give you a chance to improve performance and scale through things like caching, pooling, clustering, replication and so on. But none of that is needed when you have a small number of users, so why create complexity when it's not required?
Now, if you're building an application to be accessible over the Internet, or if you need to scale, it's a different story. You need a middle tier, and one that speaks HTTP if you're going over the Internet.
But even then you can use Java and Java Web Start, and your client application can talk to the middle/web tier using a service API. There is no reason why the server should be responsible for composing the UI for your application. It can be a server, not a UIer.
If you have Java antibodies, you can use Flex or Silverlight. Or take a look at Cappucino.
There are reasons why these RIA architectures are popular - they are meant for dynamic applications and dynamic behavior, unlike HTML, which really was never intended to be anything more than a way to display static documents. With these RIA environments, finally we're getting back to building apps with tools and an underlying architecture that match the dynamic application paradigm.
But just because it works for Google doesn't mean it works for you or your users, or that it's the best architecture. It's just the architecture we've had to work with for the past fifteen years.
Now, there are times when a web app makes sense, absolutely. The answer, as always, is "it depends." But when someone asks you how to build a database-oriented app please don't just default to "web app". There are other, potentially superior, options out there...