Casey: "I think it's extremely hard to appreciate both the advantages
and disadvantages of a framework if you haven't done a bunch of stuff
both with and without one.  ...  Tim can be at least as productive
writing PHP by hand as I can using Django, but most of us can't be
Tim.  Most of us need to exploit every unfair advantage and shortcut
we can find."

I won't disagree with Casey. We see it from different angles, but
Casey has more experience at both "ends" of the problem, and an
informed, balancing approach is best anyway. Much depends on exactly
what you're doing and what resources you can call on—not to mention
what you're used to. Mutatis mutandis you're trading application speed
and for coding speed, with arguments on both sides as far as
scalability. Since application speed is just not an issue for most of
what most people do these days, gaining developer-coding speed is a
good trade.

I see errors in both directions. There are some CRUD pieces to
LibraryThing that took *way* too much time to do because we did them
all by hand. Casey's introduction of a Django framework there was very
smart. At the same time, I think Twitter got stuck in RoR. When a web
application is so extremely simple--it does basically one thing!--you
might as well write that as "close to the machine" as possible.

Tim