Coming to the end of the Drupal project on which I’m currently working, I spotted someone else’s brand new site on drupal.org: TeamSugar.
The hallmark of a good frameworked site is that it’s not easy to guess which framework was used, and TeamSugar manages that admirably. While I can’t really comment on the design—I find most networking sites pretty busy, and this is no exception—it certainly feels like a lot of hard work is distancing the user experience from the limitations of the framework, and that’s admirable from a usability perspective. The fewer visitors jumping through hoops to indulge the whims of your CMS the better.
There are a couple of interesting observations in that thread, mostly because they’re guarded criticism coming from an otherwise happy user of the framework:
… We have four app servers now, I believe, and a dedicated database server. We have also extensively edited the code. The architecture of drupal, unfortunately, lends itself to doing things like issuing one query per module per node on a page. For our 8 content sites this isn’t too bad because they’re easily cached and don’t make use of many modules. For TeamSugar it’s much worse because each feature generally requires at least one module. We cache where we can and refactor code elsewhere…. [link to 1971521]
… When you’re creating web applications you’re typically going for one of three things: speed/scalability, flexibility, or maintainability. Drupal is high on flexibility, average on maintainability, and poor on speed, in my opinion. If your priority is maintainability then I’d go for one of the RAD environments like Rails or CakePHP. If speed is your priority then I’d write your own lightweight framework, or whatever, and do it yourself…. [link to 198497]
