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 the browser is ubiquitous. It's the absolute best way to distribute a service out to millions of people. Its the visual channel into the Internet. So we've worked with it. Thousands of developers have grown up building apps using HTML/CSS/JavaScript, session state, multiple tiers and so on.
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.
But today there is Java (write once, run anywhere) and Java Web Start (auto-upgrade to all your client machines). They are mature and battle tested. If your application is only going to run on the local network, there is
absolutely no need to create a multi-tiered HTML/CSS/JavaScript monster. You can use traditional client/server, with rich clients written in Java and deployed by Java Web Start talking directly to your database using JPA/Hibernate/JDBC. You can use the visual design tools in NetBeans or Eclipse to visually build your application. No hacking <table><tr><td> garbage.
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.
Now, folks like Google want you to keep building browser-based HTML applications, using JavaScript for dynamic behavior to muck with the DOM (note their
new browser with superior JavaScript performance). Why? So they can scan your text-oriented application and inject targeted ads. Not possible with RIAs where the application is compiled into byte codes.
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...