A new “bleeding edge” version of TextMate appeared this evening, featuring extensive improvements to the bundle infrastructure. (If you’re not sure what this means, read my earlier post on how bundles are the heart of TextMate’s stupendousness.) Allan Oddgaard has put a lot of thought into the balance between distributed bundles and user customizations, and has developed some really elegant solutions that allow you to benefit from improvements in the bundles (some of which move at a rapid clip thanks to motivated community developers) while retaining your specific customizations.

After the frameworks post I kept thinking about this. Of course any generalizations I make are heavily colored by my own direct experience, but the progression seems to go along these lines:

1. Make static web pages.

2. Make modular pages using simple includes (in SSI, PHP, ASP, or what have you).

3. Make pages with more involved functionality (form submissions to database, basic CRUD).

4. Get sick of re-building dynamic stuff for every project; write your own kinda portable library or framework.

‘Twas google/ig, and the odeos
Did skype and quimble in engrade:
All simpy were the buzzingos,
And the feedpaths carbonmade.

“Beware the Frapprflock, my son!
The jaws that bite, the claws that catch!
Beware the Yubnub bird, and shun
The del.icio.us Offertrax!”

He took his orkut sword in hand:
Long time the slawesome foe he sought –
So rested he by the Numsum tree,
And stood awhile in thought.

Eric Meyer recently wrote a post titled “Flummoxed by Frameworks” that received a lot of commentary. I belatedly added my own two cents. I have a feeling that this isn’t the last time the subject will come up; I’m copying my own response here (along with the link to Eric’s post) mostly so that I can find it later when I want to explain this to somebody else!

Eric, you mention that you wrote all of An Event Apart’s registration stuff using PHP and MySQL. I take this to mean that you did it once. Imagine if you did it three times, or five times, or fifty times for different clients, with minor variations. Imagine how sick you’d be of re-implementing the same core features over and over. Your approach would change a little bit with each job, as you discovered better ways to implement certain features. Imagine the nightmare of trying to support all those clients each one using a slightly different snapshot of your learning process.

I built a toy site using Django’s “generic views” last night. Basically this means that for the first time I created an app without writing any real code – I defined a model, wrote some rules mapping URLs to Django’s generic view functions, and made some templates that get called by that view code (I spent most of my time fussing with the templates!).

This would have been pretty easy to hack up in PHP, too, but there are lots of things that would have been just as easy to not do the “right” way – things like clean URLs everywhere, redirect-after-POST (to avoid multiple submissions), custom error pages, a polished admin for inspecting and editing the data, nicely modular templates. Django made it easier to do it right than to do it wrong.