DEV Community

Cover image for bake don't fry

bake don't fry

ajcwebdev profile image anthonyCampolo ・3 min read

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.

In the 2002 blog post Bake, Don’t Fry, Aaron Swartz talks about the benefits he sees in using static sites (baking) instead of server generated pages built on demand (frying).

Some websites are fried up for the user every time. But others are baked once and served up again and again.

He mentions three tools in particular:

  • Movable Type: Uses Perl scripts to build the webpage and ends with static pages served to the public
  • Tinderbox: Draws from database of notes to produce a bunch of static pages
  • Webmake: Perl CMS that generates pages

Baked pages are easy to serve because you can switch servers and software, but the 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.

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.

I hope that clarifies things.

The next day he published Building Baked Sites as a follow up to explain his approach to these types of sites.

He first clarifies that using static web pages does not preclude things generally associated with dynamic sites (templates, newsboxes, stock tickers). It also doesn't mean that your site can’t have any interaction or collaboration (comments, boards, polls).

The key is to keep a strict separation between input (which needs dynamic code to be processed) and output (which can usually be baked).

If you want to separate your input and output you need a dependency tracking system that allows you to add new content to the system or modify old content. It 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.

He then describes how systems in 2002 like OpenACS could be configured to do this without much modification. The dependency information could be layered on top and the system could call the dynamic scripts when that page needed to be regenerated.

He also mentions input systems as an example of something ill suited for baking. 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.


Editor guide