 |
 |
In addition to initial productivity, maintainability and enhanceability, including by future people who won't be you, is a huge consideration. A framework can probably either help or hurt that too, depending on how good it is. Jonathan Tim Spalding wrote: > 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 > > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu