Wednesday, September 06, 2006

The Evolution of Web Applications

Fred Gallagher's rant today on megatokyo (strip 902) made me feel a little old. On the topic of "the ebb and flow of obsolescence," he mentioned some bits of the moldy old days of PCs, before hard drives and directly-connected modems. Wow, talk about pre-historic. Anyway, if you'll allow me to ramble on a bit...

The year was 1997, and I was a freshman at RPI. The campus ACM club was giving a lecture on a relatively new feature of the web called CGI. It was horribly boring to hear about the importance of echoing a Content-Type header, newlines, and whatnot, (so boring that I won't bother linking to the specifications here), but I came out of it hungry to see what this stuff could do. I got back to my dorm room, fired up a telnet connection to the campus Unix network (we actually had Ethernet back in those days, but no DHCP, and it took a month for the help desk to assign you a static IP address), wrote my first CGI script using plain old shell echo commands, and then... nothing. It turned out that the network admins had disabled CGI on the main network, due to the potential insecurity. It would be another year or two until I had access to the Computer Science department's web server with its CGI capabilities.

We learned all about how Environmental Variables held the URL query string, and how POST data was sent through standard input. I don't remember if the CGI.pm module was available at that point. That module was a major help, since you could access individual variables through the param() method, and not have to parse them out of the input yourself.

With more modern, web-specific languages like ASP, PHP, and ColdFusion, we don't even need to include a library to do those things. They've become implicit to the whole web application concept, no longer just a convenience.

We also saw how, back in those old dark days, we could use output functions to send strings of HTML back to the client. And they were ugly HTML strings, to be sure. Since so much of the markup includes quotes, and quotes usually need to be escaped with backslashes, your CGI code tended to look a bit like this: print "<td colspan=\"2\">$stuff</td>"

So there was quite a disconnect between the code generating the HTML and the final output, which would then be rendered in the browser. As you can imagine, it was (and sometimes can still be) a major headache, especially for high-quality applications with layouts designed by professionals. I still deal with issues of code-generated HTML, and the fact that designers have a hard time making changes to it, particularly if they're used to working in a visual editor. Now that we have embedded processing directives in the aforementioned modern languages, we're much better off, and more able to divide-and-conquer the workload.

0 Comments:

Post a Comment

<< Home