Lately I’ve found myself being baited into the same old debate over and over and over again, and I’m getting tired of making the same arguments each time. Usually it begins with someone lamenting how Django is anti-community or too inflexible or generally suffering from a raging case of NIH. From there it progresses into people proclaiming how TurboGears or (more often) Pylons is objectively “better” because of how they’re designed, and how it would be nice for Django to follow their lead.
Before I go any further, I’d like you to go watch Malcolm Gladwell’s 2004 TED talk. He’s going to talk about Pepsi and pickles and spaghetti sauce and mustard, but you should watch the whole thing because it has a relevant lesson for the Python web framework world:
There is no perfect Python web framework. There are only different Python web frameworks that suit different kinds of people.
Fundamentally, there are two ways you can go about building a Python web framework; I’m going to refer to them as “full-stack” and “glue”. In a nutshell:
The choice of methodology here will affect every aspect of the eventual framework, and no matter how hard the developers try, they will never be able to mask that from end users of the frameworks.
Django is a full-stack framework. Pylons and TurboGears are glue frameworks. These are fundamentally different approaches to building a framework, and they are both perfectly valid; the developers behind them have made a conscious choice about which approach they prefer, and put all their time and energy into fulfilling the goals of that approach. Web developers — the end users of web frameworks — also tend to have a preferred approach, and will naturally congregate around a framework which suits their preference.
There will always be framework developers who prefer the full-stack and there will always be framework developers who prefer glue. There will also always be web developers in each camp. Thus there will always be a market for both kinds of frameworks.
There is no perfect framework. There are only different frameworks that suit different kinds of people.
Also, there will always be people in both camps who are utterly, steadfastly convinced that they are objectively right and the other group is objectively wrong. I expect that with time, full-stack versus glue will become one of the great holy wars of the Python web-development community (and it probably already has).
People in the full-stack camp will go on and on about how glue frameworks don’t really give you a clear roadmap; sure, they may have a default configuration which pre-selects a particular set of components, but that doesn’t really mean much and the tutorials and documentation will have to be fragmented according to which template engine or which ORM you use, and you’ll have to go hunt up all these other projects and read their manuals, and it’s just icky.
Those people will be wrong. A glue framework isn’t terribly hard to learn, and if you don’t want to research all the different options you can just go with the defaults, but the primary goal isn’t to give you just one set of components and say “here it is”. And the ability to cherry-pick exactly the right set of components for a particular project is incredibly powerful. It’s like the world’s most powerful Lego set; you’ve got blocks in all shapes and sizes, and you can build pretty much anything by combining them in just the right way.
People in the glue camp will go on and on about how full-stack frameworks are too inflexible; sure, you can drop in another ORM or another template engine, but then you’ll lose all the handy shortcuts and have to write more code. And because they tend to develop their own components, they’re not good community players — it’d be so much better if they’d just pull stuff off the shelf and contribute improvements back to other projects!
Those people will also be wrong. A full-stack framework isn’t inflexible, it’s just highly optimized for one set of components. It’s still easy to use others with it if you want to, but the primary goal isn’t to support every conceivable combination of components and say “go pick what you want”. And having a full set of tested components that Just Work out of the box is incredibly powerful. It’s like having the greatest toolbox ever; you’ve got hammers and wrenches and screwdrivers and drills right there, and you can build pretty much anything by using them in just the right way.
The fact that all of these people are wrong will not stop any of them from continuing to maul each other in public over whose philosophy is better.
Unfortunately, I don’t think so. Taking one approach seems — though I could be proven wrong in time — to mean that so much of your time and effort will be spent on fulfilling the goals of that approach that you won’t be able to focus enough time and effort on the goals of the other, and if you try you’ll end up looking like you did a half-assed job of it; Jack of all trades will be master of none. A full-stack framework has to ensure that its components are of high quality and all work together; that’s a big enough job in itself without trying to make them work with any random thing somebody pulls off the shelf. And a glue framework has to ensure that its adapters and interfaces scrupulously follow various standards and specifications (like WSGI, which is not trivial to get right) and work with as many components as possible; that’s a big enough job in itself without spending development time on maintaining a particular arbitrarily-chosen set of components.
And again, no matter how hard developers try, a full-stack framework is always going to obviously be a full-stack framework, and a glue framework is always going to obviously be a glue framework. That fundamental choice of development methodology is going to affect every bit of code in the framework, and the particular strengths and weaknesses of each approach are always going to show through. So this division will probably exist for as long as there are Python web frameworks.
I’d like to think so, but it’s doubtful that it’ll happen. In an ideal world we’d all realize that the choice of methodology comes down to subjective preference, and that it’s a great thing to have the choice; Python web development wouldn’t be nearly as much fun if everyone were shackled into a single vision of the One True Framework (even if Guido were to Pronounce on this, which he really hasn’t — “as standard as PIL” isn’t much of a Pronouncement). And in that ideal world the folks who like full-stack frameworks would hack on them and use them, and the people who like glue frameworks would hack on them and use them, and we’d all come together and sing songs round the campfire about how much better off we are than those poor guys who are stuck with PHP.
But it’s not an ideal world, and so we’ll have the holy war and name-calling and FUD from both sides (I’ve certainly been guilty of it, and I’m only hesitantly trying to reform), and in the end that only thing we’ll agree on is the bit about PHP.
I’d love to be proved wrong, though. Anybody want to sing around the campfire and toast marshmallows with me after the web frameworks panel at PyCon?
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
Great piece, James. As much as I love to hate you, you’re pretty damn good at this blogging thing, my friend. :)
I couldn’t help but see a bit of an analogy with the age-old Mac vs. PC argument here, whereby the Mac is the full stack and the PC is the glue. Apple works with a limited set of hardware components (and often builds their own), and uses software to make them work really, really well together. It’s never going to be quite as flexible as a PC, which can work with thousands of different hardware components. But, the downside of the PC is that each of the components may not play quite as nicely together, because it’s simply impossible for software (like an operating system) to account for every possible combination, new releases, etc, etc.
And that Gladwell TED talk is one of my favorite ever. Fits perfectly here. Nicely done.
I like django more than pylons/turbogears. Why ? Because it’s faster to make apps with it and imho you can understand your code better.
You hit that nail right on the noggin.
I’ll offer the campfire. Chad Whitacre (of Aspen fame) and I (of CherryPy infamy) are getting a nice suite at the Residence Inn next door…all web dudes welcome anytime. But I’ll probably be offering mudslides and margaritas instead of marshmallows. ;) Wanna put something official together, say Friday night?
I’ll just leave a link to my thoughts on the matter.
http://programming.reddit.com/info/15ds9/comments/c15evd
Any person that claims the other camp should not exist because of their approach, attitude, or whatever, is certainly doing more harm than good.
Excellent write-up.
Robert: I’ll be at the Courtyard across the street, but I may drop by. I can bring rum. I like rum :)
i like chunky spaghetti sauce. it must have lots of visible solids!
for the 2/3 of you who like some other kind of sauce, well, poo on you…because you’re WRONG.
i like toasted marshmallows, too =)
James, I think you’re peddling a false dichotomy. The relevant distinction is really between monolithic and modular framework architectures.
Personally, I’m attracted to the modular approaches and the vibrant resulting “middleware” ecosystem that WSGI has fostered. Pylons is only a early example.
But please feel free to tell us what exactly is missing from the Pylons stack which prevents it from being a “full-stack” framework.
I’ve replied to this here: http://blog.ianbicking.org/full-stack-vs-glue.html
I think you just set off a flamewar about flamewars :-)
For me it doesn’t matter much what I choose, as long as I’m not forced to use PHP. (I’d prefer Django any day, though.)
I’m somewhat agreeing with Patrick above, though I never tried Pylons (which - by the way - makes me think of StarCraft) so I can’t really make anything close to an objective comparison.
N.B.: You need to post more often in the Django category on your blog!
I would have to agree with Ian Bicking. The full-stack vs. glue approaches are not a good way to describe the differences between Pylons/Django/TurboGears. I would agree that there are full-stack vs. glue approaches to development, but I would consider Django as a glue environment. I would put Plone on the full-stack side. If you are making assumptions about base models, security, workflow, eventing, indexing, versioning, user management and HTML/CSS/JS conventions - this is what I would consider full-stack. If you’re building an application using Django/TurboGears/Pylons you are likely to have a lot of custom requirements, and will be designing a lot of your own assumptions in your application, and so will be spending much of your time glueing together your own custom components. Finally, I am not sure how Zope 3 would fit into the glue framework vs full-stack framework split - it began life as a replacement for a full-stack/pluggable application (Zope 2) but changed course along the way to become a glue framework - perhaps now it could be described as a glue framework designed for building full-stack frameworks?
Hey, I found this because I’m doing some evaluation of languages and web frameworks and am seriously interested in Python. Anyway, I posted about my search for a new language and web framework and am looking for people who can make suggestions. Thanks in advance: http://www.mikeschinkel.com/blog/onthehuntforanewprogramminglanguage/
Ian, for me a practical way to reveal the existence of the distinction is a simple question: if I report a bug in a major component used by the framework (say, the ORM or the default template system), should the bug be directed to the framework developers or to a third-party project? If it goes to the framework developers then they’re full-stack and they’re supporting all their components. If it goes to a third-party project then they’re glue.
If I’m using Pylons and find a bug in SQLObject, I imagine I’m going to be expected to report that bug to SQLObject and not to Pylons — Pylons’ job is not to ensure SQLObject’s code works, Pylons’ job is to ensure that the Pylons code which hooks SQLObject to other things works. If I do report the bug to Pylons by mistake, I’d expect it’ll get forwarded upstream. Hence, Pylons is a glue framework.
If I’m using Django and find a bug in the ORM, however, I report it to Django; Django’s job is to ensure that the Django ORM’s code works. Hence, Django is a full-stack framework.
Maybe that’s a better practical distinction and I probably could have done a better job of articulating it.
Also, Django doesn’t claim to have a decoupled framework; we claim to have a framework made of loosely coupled components. There is a key difference here, and again it reveals a distinction: our primary architectural goal is not to have easily swappable components (though we try not to get in the way of that too much), our primary goal is to have a full set of well-architected components which work well with each other. So again, the full-stack/glue distinction shows up in actual practice.
This distinction is not illusory and was not made up on the spot to cover for architectural defects — it is a real difference in architectural style between Django and frameworks like Pylons.
Kevin, I’d say even by your definition Django is full-stack; all of the contrib stuff — the admin, auth system, comments system, etc — make very definite assumptions about other things you’ll be doing, as do many of the built-in shortcuts and all of the generic views. For example, you can use the Django admin app on top of other ORMs or even applications written in other languages, but you’ll need to generate a Django models file and settings file for it to use (Django can help with generating the models file, but you still need it); I think that sort of thing pretty firmly pushes us over into the full-stack category.
I don’t like flexibility. The cost in development time is too high.
I always went for the flexible solution, because it makes so much sense. But I have burnt my fingers badly enough times to know that flexibility doesn’t simplify a project, it adds complexity. And complexity means long development time.
I don’t like finely granular object design either. The possible ways to combine them explode and you end up with a never ending project.
All I wan’t is just enough flexibility and just enough granularity to implement the requirements. For me Django has given me that on my current project, so I don’t really give a toss about the alternatives.
Which is Rails?
phil, Rails is full stack, I believe. But, it is also not a Python framework. ;)
Nice words, James.
Someone said it was a false dichotomy (‘use my dichotomy instead’ ), but nuances aside, this is a useful way to think of it. That there are more than two web frameworks under the dichotomy leads me to think we are either wasting brain power collectively, or need to ferret out the nuances that would make it a trichotomy or quadotomy.
Plain, Chunky, and Tangy versions may all make sense, we just oughtn to make two versions of “Chunky Tangy” - lets do each approach in its own flavor with excellence, and with distinction from the other(s).
What web framework I’ll be happiest using in the long run is not any clearer to me, but I sure am getting hungry.
EP
I like python because it fits into my brain. Almost every time, I tried using something from stdlib, I had this eureka moment. Stuff work just the way I would expect them to. I love python.
Of all the frameworks I have tried, DJANGO adheres with this principle very neatly. I have had my share of troubles, but number of eureka moments have been largely dominating.
I couldn’t care less about glue or full stack. I understand the clean codebase so well, I can twist and bend it when extreme cases demand it. Till then, I am happy.