 |
 |
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