The Boy Who Could Change the World (13 page)

Bake, Don't Fry

http://www.aaronsw.com/weblog/000404

July 9, 2002

Age 15

I really got started with this whole web mess with the ArsDigita Prize where I learned how to build database-backed websites by building one myself. However, it was always assumed that these sites would be built by having a bunch of code on the server which generated pages for the user on demand by calling the database. That was simply how such sites were built, I never questioned it.

Now, a number of tools are challenging that assumption.
Movable Type
, the program that runs this weblog, has a series of Perl scripts which are used to build your webpage, but the end result is a bunch of static pages which are served to the public. All the content here is plain old web pages, served up by Apache.
Tinderbox
uses a similar system, drawing from your database of notes to produce a bunch of static pages.
My book collection pages
are done this way. Radio UserLand statically generates the pages on your local computer and then “upstreams” them to your website.

Finally, while researching
Webmake
, the Perl CMS that generates pages like
Jmason's Weblog
and
SpamAssassin
, I found a good bit of terminology for this. Some websites,
the documentation explains
, are fried up for the user every time. But others are baked once and served up again and again.

Why bake your pages instead of frying? Well, as you might guess, it's healthier, but at the expense of not tasting quite as good. Baked pages are easy to serve. You can almost always switch servers and software and they'll still work. Plus, you get to take advantage of the great features built into your web server, like content negotiation,
caching, ETags, etc. You don't get the bells and whistles like providing a personalized greeting on every page, but those are things that aren't very good for you anyway.

The one problem with the “bake” philosophy is dependencies. It's difficult to keep track of which pages depend on which others and regenerate them correctly when they change. Movable Type handles this in the obvious cases, but when you do anything other than creating or editing an entry, it makes you manually rebuild the corrector portions of the site. Tinderbox, a speedy C++ program, seems to regenerate the whole site every time. It seems that for this philosophy of database-backed static pages to take off, we'd need a really good dependency system to back it. Has anyone built such a system?

Let me know.

Update:
Some people seem to think that I want to bake because of performance. Honestly, I don't care about performance. I don't care about performance! I care about not having to maintain cranky AOLserver, Postgres, and Oracle installs. I care about being able to back things up with scp. I care about not having to do any installation or configuration to move my site to a new server. I care about being platform and server independent. I care about full-featured HTTP implementations, including ETags, content negotiation, and If-Modified-Since. (And I know that nobody else will care about it enough to actually implement it in a frying solution.) I hope that clarifies things.

If you liked this article, also check out the sequel,
Building Baked Sites
.

Building Baked Sites

http://www.aaronsw.com/weblog/000406

July 10, 2002

Age 15

Bake, Don't Fry
has been one of my more successful blog entries. I wonder if this was because of style or content (or both?). Anyway, since people seem interested in it, I thought I'd sketch out my views on how to make baked sites work.

First, let me clarify that using static web pages for your site does not preclude things that people generally associate with dynamic sites (like templates, newsboxes, stock tickers, etc.). Nor does it mean that your site can't have any interaction or collaboration (comments, boards, polls). While these things obviously won't work if you move platforms or server software, at least the content already on your site won't die. The key is to keep a strict separation between input (which needs dynamic code to be processed) and output (which can usually be baked).

So how would this work? You'd need a dependency tracking system (good old
GNU Make
might even do the job) that would allow you to add new content to the system (something tricky with Make alone—is this what Automake does?) or modify old content and would then rebuild the dependent pages or create new ones as necessary. As an example, a new blog entry should create a new page for the entry, rebuild the previous entry page, rebuild the day/week/month's pages, and rebuild the home page. It would also have to add all the dependencies for the new page (to the template, to the previous entry, to that entry, to the category name) and add a dependency to the previous entry page.

Current systems (like
OpenACS
) could even be hoodwinked into
doing this with little or no modification. The dependency information could be layered on top and then the system could simply call the dynamic scripts when that page needed to be regenerated. Of course, a purebred system would probably be better since it would give a chance for URL structure to be designed more sensibly.

Baking doesn't do everything, though. Input systems, like the code that accepts comments, would still need to be dynamic. This is a limitation of web servers which I doubt will ever be solved in a standard way. Dynamic tools (like homepage generators and search software) will either have to be fried, or use client-side technologies like SVG, Java(Script), Flash (ick!). There's no way around that.

If you're interested in helping build a system to help with baking sites, please let me know.

A Brief History of Ajax

http://www.aaronsw.com/weblog/ajaxhistory

December 22, 2005

Age 19

New technology quickly becomes so pervasive that it's sometimes hard to remember what things were like before it. The latest example of this in miniature is the technique known as Ajax, which has become so widespread that it's often thought that the technique has been around practically forever.

In some ways it has. During the first big stretch of browser innovation, Netscape added a feature known as LiveScript, which allowed people to put small scripts in web pages so that they could continue to do things after you'd downloaded them. One early example was the Netscape form system, which would tell you if you'd entered an invalid value for a field as soon as you entered it, instead of after you tried to submit the form to the server.

LiveScript became JavaScript and grew more powerful, leading to a technique known as Dynamic HTML, which was typically used to make things fly around the screen and change around in response to user input. Doing anything serious with Dynamic HTML was painful, however, because all the major browsers implemented its pieces slightly differently.

Shortly before web development died out, in early versions of Mozilla, Netscape showed a new kind of technique. I don't think it ever had a name, but we could call it Dynamic XML. The most vivid example I remember seeing was a mockup of an
Amazon.com
search result. The web page looked just like a typical
Amazon.com
search result page, but instead of being written in HTML, it was a piece of XML data which was then rendered for the user by a piece of
JavaScript. The cool part was that this meant the rendering could be changed on the fly—there were a bunch of buttons that would allow you to sort the books in different ways and have them display using different schemes.

Shortly thereafter the bubble burst and web development crashed. Not, however, before Microsoft added a little-known function call named XMLHttpRequest to IE5. Mozilla quickly followed suit and, while nobody I know used it, the function stayed there, just waiting to be taken advantage of.

XMLHttpRequest allowed the JavaScript inside web pages to do something they could never really do before: get more data.
^*
*
Before, all the data had to be sent with the web page. If you wanted more data or new data, you had to grab another web page. The JavaScript inside web pages couldn't talk to the outside world. XMLHttpRequest changed that, allowing web pages to get more data from the server whenever they pleased.

Google was apparently the first to realize what a sea change this was. With Gmail and Google Maps, they built applications that took advantage of this to provide a user interface that was much more like a web application. (The start-up Oddpost, bought by Yahoo, actually predated this, but their software was for-pay and so they didn't receive as much attention.)

With Gmail, for example, the application is continually asking the server if there's new email. If there is, then it live updates the page; it doesn't make you download a new one. And Google Maps lets you drag a map around and, as you do so, automatically downloads the parts of it you want to look at inline, without making you wait for a whole new page to download.

Jesse James Garrett of Adaptive Path described this new tactic as Ajax (Asynchronous Javascript And XML) in an essay, and the term immediately took off. Everyone began using the technique in their
own software and JavaScript tool kits sprung up to make doing so even easier.

And the rest is future history.

Both systems were relatively ill-supported by browsers in my experience. They were, after all, hacks. So while they both seemed extremely cool (KnowNow, in particular, had an awesome demo that allowed for a WYSIWYG SubEthaEdit-style live collaboration session in a browser), they never really took off.

Now apparently there is another technique, which I was unaware of, that involved changing the URL of an iframe to load new JavaScript. I'm not sure why this technique didn't quite take off. While Google Maps apparently used it (and Oddpost probably did as well), I don't know of any other major users.