It's amazing to me the effort put forward to develop web sites. Incredible ammounts of coding time have gone towards creating web sites that can do everything from keeping a list of favorite books to turning on the microwave. But sometimes I wonder if the actual coding effort is a large struggle to overcome a simple problem: HTML.
On one hand... I adore HTML. It's simple, it's an amazing concept, and it's very accessable to pretty much anyone with a little patience and some time. It's an excellent tool for what it is, a tool for delineating text.
But that's exactly what no one uses it for.
I've been looking at blogging software lately (as if that one wasn't obvious), and came across Movable Type, a really nicely built program based on Perl and HTML::Template. Which brings back a session I attended at the O'Reilly Open Source Convention on HTML markup modules for Perl. There were several, HTML::Template being one of them. It's one of those things, it seemed, that all serious web programmers do at some point: build a templating system for their web site.
I'm looking over tomorrow's schedule of Things To Do. One of them is to update some information using a Wiki. Wikis are fascinating tools, in that they have been made to quickly format pages so that anyone can update information on them. They even have their own markup language, using "---++++" for marking up headers and placing underscores around items which the author wants italicized.
Another is to start working on a new web site using Struts -- a framework developed by the Jakarta project for allowing someone to use JSP Tags, servlets and forms to develop a "Model-View-Controller" web site. Handy, if you know JSP, servlets, and what the heck a Model-engine-helper-whatever is about. Simply put, JSP tags are like the "---++++" on the Wiki - a way to mark things up and/or place information at a particular spot. Servlets are just programs that you can access from a web browser (with differences, but pass those over for a moment). And the MVC is a architecture, which basically says it's best to put the presentation ("View") in one place, put the code ("Model") in another, and have some single piece of code go in between ("Controller").
All three of these are ways to overcome a few basic problems with HTML. Basic, in that HTML, when invented, wasn't intended to do these sorts of things.
And we keep solving that problem over and over again.
Mind you, I'm naming 3 I've come across this week. And I'm not looking hard, I'm just going about my daily business. We're trying to do things with HTML that this was never intended to do, and instead of fixing HTML, we're doing everything but that.
There's a good reason for it: HTML is pretty standard, it's used and easily accessable on pretty much every computer around there. But even the people who work on it daily can tell you there's been a lot of weird hacks and downright strange ideas thrown into the mix.
Even HTML has been added to, what with CSS, XHTML and a ton of other "great ideas". But the problems remain, and will remain, until people get a decent handle on the problems. Here's my list of what the problems are, and a solution or two to generate a simple, elegant solution to the problem:
1) HTML is static
I can tell you every one of these solutions is trying to overcome the simple fact that an HTML file is just a markup language, *meant* to be static. HTML is about as static as you can get. Even with CSS, it's still pretty static.
Solution: make it not static. Boys & girls, we're not going to fix the fact that these things are flat files and can't do stuff based on interpretation without some sort of computing engine. So... don't! A couple of possibilities are:
-- Make a set of markup tags that include computing possibilites (not javascript. For pete's sake, that doesn't even run the same most of the time on