by Steven J. Owens (unless otherwise attributed)
A web application divides up into a bunch of different components. Typically people see the breakdown fairly simplistically, as follows:
This is, in fact, the way the vast majority of early web applications were organized. The application code actually existed as a bunch of individual, stateless CGI scripts (most often written in perl), that pushed incoming data into the database and pulled it back out for display (and occasionally pulled it out, munged it with incoming data, and pushed it back in).
As the rest of the world started to clue in that maybe there was something to this Internet stuff, they started wanting (not necessarily needing, but that's another story) more complex applications. This started leading to more complexity in the CGI scripts, sequences and arrangements of HTML forms that only made sense in context with each other, more scaffolding code to make the CGI scripts less individual (not as discrete from one another, less stateless).
The most commonly cited - and as far as I can tell, completely imaginary - concern in this time span (about 97-99) was performance, both of CGI script overhead (startup overhead - CGI scripts are run from scratch for each request - and general overhead, because each CGI script is run as a distinct process, with its own copy of the interpreter and environment) and of database churn (since scripts are stateless and have to pull any necessary state from the database for each request).
Lots of folks came up with tools and frameworks to address these real or imagined needs. The Java servlet specification is one of them, and it's proven to be fairly useful. It is, like many things Java, a little less than you might expect. This means a little more work, but also a little more freedom. Typically in Java, you get just enough that all the hard work has been done, but you're not locked into a specific approach for a problem. I can see the sense in this, but there are times when it bugs me.
Lots of people have come up with add-on tools and frameworks to fill in that remaining gap. There are some trends I've noticed, some lines of division that commonly occur and reoccur (or should :-). Some of these are obvious, and defined by the applications that make it up, some are less obvious but still formally defined, some are implicit in the structure, and some are just a good idea and have become common practice.
First, and this is something most people don't bother with, but I think it's important, you have to be more explicit about the protocols and framework. I'll repeat that list with these things added in, the new stuff in bold:
You should also more conscious of the natural chunking that HTML brings into the picture:
Finally, on the application side you'll find it useful to carve up the code a bit. Here's my full picture:
As usual, these aren't as neat and even as it looks at first glance. These "layers" interpenetrate and overlap each other, and some of them don't really exist without the others to define them. (I really need to find a better term than "layers", but I haven't found one yet.)
Note that I haven't said much about javascript. Javascript has become a sane option Only relatively recently. For most of my career I've considered javascript to be a trap that people get bogged down in. It's occasionally useful in very small doses, but a treacherously slippery slope. You inevitably end up with large doses, and sooner or later in there the application gets critically entangled, and your development effort bogs down.
With a lot of the recent advances in javascript, AJAX techniques, javascript tools (though still rudimentary) and javascript libraries like JQuery, this seems to have changed.