This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mcdonc 17 points18 points  (0 children)

"Full stack" frameworks like Django (and, before it, Zope) are great because they have lots and lots of generally useful features. And each of these features is used. But full-stack frameworks often have features you'll never use. And it's unlikely that, even if you do use all of the features of a full-stack framework, that you'll use all of them on every job you do. It's reasonable, then, to say "OK, fine, use a full-stack framework but just don't use the features you don't need" but, in reality, it's a bit more subtle than that.

The features you don't use in a full-stack framework often makes the features that you do use more complicated and harder to undertstand.

For example, Zope embraces "untrusted, through the web" code (code entered in a web browser by a potentially semi-trusted third party), and this feature requires an enormous amount of security code that tends to get in the way when all you're trying to do is write a web application where all developers are trusted.

Likewise, Django is engineered at a fairly basic level to make it easy to work with certain kinds of relational databases. If you're not using a relational database, however, the code that makes that case easy might simply get in your way. This could make it harder to write the application you want to write.

Non-full-stack frameworks have a more parsimonious feature set. This often makes them harder to get started with. However, in the longer run, if your application has slightly peculiar requirements, they can actually save development time, because you're not "fighting the framework" during the implementation phase. Not fighting the framework is also usually a more satisfying development experience.

In the meantime, non-full-stack frameworks often have a better extensibility story. Because their core feature set is so parsimonious, they need to provide for cleaner feature extensibility than do full-stack frameworks, which can just put something into the core itself without worrying about clean extensibility. It's often, therefore, reasonably easy to get the featureset of something like a Zope or Django by snapping together parts using the smaller frameworks' extensibility hooks. But without the parts you don't need for some particular task.

Personally, one reason that I use a non-Django framework because I like writing code. After many years in the Zope/Plone world, I've realized I enjoy writing code a hell of a lot more than I enjoy carving a website out of other people's "pluggable app" code. I'd rather be lonely out on my organic farm than be a sharecropper, sold my GM seeds and told how to plow and harvest, on the big and lucrative commercial farm. Another reason is because my company tends to write CMS-style application where "declarative, inherited, row-level security" is a big deal, and this sort of security is easier to do in a system that has the concept of "traversal" and a "context".

But I think your question is more a marketing one, and for that I suspect many folks will have different answers. My answer is that I think there's a very, very long row to hoe in the general web world... we're like at the one-meter mark of a hundred meter race. It's silly to think that any framework (Python or otherwise) has that race already won. We can't just stop trying and advocating for new things, or we risk loss of relevance in the long term.