So it seems the BDFL Pronounced that Django is the Python web framework.
Obviously this makes me pretty damn happy. I’m sure this will help people trying to choose a web framework come to Django, and I think they’ll like what they find. Personally, I think Django’s the best tool to develop web sites — but of course I think that.
However, I want to make sure everyone has read Kevin Dangoor’s thoughts on the announcement. Kevin’s an awesome guy, a great programmer, and although I disagree with a few details here and there1, the general gist is spot on.
Probably the worst thing about tech communities are the holy wars. Emacs vs. vi is the Father of All Holy Wars, of course, but then there’s the operating system thing, the programming langauge thing, and now (it seems), the web framework thing.
I once asked a carpenter if he and his construction buddies sit around and argue about what brand of hammer they use. He looked at me like I was crazy — “you mean you guys do?”
As I see it, there’s two types of evangelism that happen in tech communities:
The first involves helping people who are using old or broken tools upgrade to something more productive. For example, helping someone switch from generating RSS with print statements to using a dedicated RSS/XML generator, or helping someone writing sites in plain old PHP switch to an enlightened framework like Django or RoR. This is the “good” evangelism — it’s like helping a budding carpenter switch from a hammer to nail gun.
But there’s a second, insidious form of evangelism which tries to convince people that the tools they’re using are somehow “wrong” and that they ought to switch to using the “right” tools. These arguments inevitably involve vague statements that Option A is intangibly “better” than Option B: “You’re using Ruby on Rails? Dude, you suck — Django’s totally better!”
These types of arguments are essentially moral, and that’s why they fill me with disgust. They imply that you’re somehow morally inferior for choosing some tool over another.
At lunch yesterday I talked with some coworkers about all this stuff. Jeff pointed out that open source marketing often revolves around these types of moral arguments. He specifically noted that some of RoR’s success can be attributed to its community’s willingness to make these kind of moral arguments — “Java bad, Rails good” is how RoR (successfully) sells itself to the “enterprise”. There’s plenty of other examples, of course — Firefox, Linux, and dozens of other open source projects have benefited highly from moral marketing.
But that’s just not a place I’m willing to go. Inevitably, moral marketing comes across as arrogant and self-centered; many former Rails hackers coming to Django cite the arrogance of the Rails community as the primary reason for leaving. Indeed, I came to love Python specifically because the community was usually friendly and nearly always at least civil. If there are holy wars within the Python community, they’ve been small enough that I’ve missed ‘em.
If it’s a choice between being the most popular web framework or the one known for the nicest community? I’ll take the later.
Although this Pronouncement is good for Django — and especially good for newbies confused by the rich tableau of Python web development options — I fervently hope it doesn’t kick off a holy war.
Right, if Guido gets to Pronounce, I do, too: Use the right tool for the job. TurboGears and Django (and Pylons, Quixote, web.py, etc.) fill different niches in the Python web dev landscape, and there’s no reason — or need — for there to be One True Framework.
| [1] | In particular, Kevin’s assertion that Django somehow will refuse to benefit from future developments in the larger Python community seems disingenuously naive. Kevin’s been around long enough to know that there are many ways open source cross-pollinates besides the bundles and glue code approach of a super-framework like TG. Just because Django doesn’t use SQLObject as-is does not mean we’re somehow willfully ignoring improvements. Again, there are benefits to straight-forward bundling, and there are others to letting influence be more piecemeal. It’s tradeoffs all the way down. |
Comments:
Hooray for Pronouncements!
Of course, we talked this to death over lunch yesterday, and I agree with most everything you've said. But I want to bring up that I think at least part of this has to do with that leap in quality of tools.
Imagine that you're a Java programmer. To you, "web framework" means 800 tons of XML and a stack so big you can't see one end of it from the other. Then someone comes along and shows you Rails and walks you through a quick tutorial, and it's a revelation. It's like seeing Moses part the Red Sea right in front of your eyes, and it's understandably going to completely change the way you look at things.
What I think we're going through now is a shaking-out period, where all those former 800-ton gorilla wranglers are waking up and seeing a better way to develop. The fact that, for nearly all of them, Rails is their first exposure to the new frameworks, means that they're coming in with a huge bias -- Rails brought them out of bondage, so it's naturally going to overshadow everything else at first. And it's going to take them a while to realize that most of the ideas in the new frameworks aren't really new, and that people have been doing effective development with lightweight, dynamic tools for years.
Whether we, the open-source web development community, can welcome these people, give them the right kind of encouragement and help them understand that there's a whole ecosystem of high-quality tools out there will, I think, be the deciding factor in the long-term success of _all_ of the new frameworks.
Well said, James.
Indeed, every programmer should be constantly evaluating new tools and seeking increased productivity. One of the huge benefits of Free Software is the incredibly low barrier to experimentation, and as OSS authors we should be encouraging experimentation as much as possible. I guess I'm just angry at the moral black-white overtones that pass as "encouragement" these days.
First link is wrong - forgot the :
fixed link: http://pyre.third-bit.com/b...>
Well damn. that wasn't a fixed link either. Looks like some html got stuck in it.
Fixed link:
http://pyre.third-bit.com/blog/archives/613.html
(Fixed; thanks Umbrae)
Good post, Jacob!
Actually, one of the best things about Django, imho, is the community. Allthough I am a somewhat experienced web-developer, I'm new to Python, so getting friendly answers to sometimes maybe quite dumb questions was a very big thing to me. People on Django IRC channel and user-mailinglist are great!
As a Mac user, I definitely see the holy war thing. But after using Django for about six months now, I think that Django just doesn't need any moral marketing. I mean, what's the point when it obviously does quite well withouth it :)
I just want to get people try it out and see for themselves. Using something that makes you smile when working, no matter is it RoR or TurboGears or Django, is Good Karma and _that_ is what we should be marketing!
Hi, Jacob. Nice post.
While I was at LinuxWorld, I mentioned in my class that I use Django both for fun and work. Just an aside when introducing myself, nothing more (the class was about Google web apps and code.)
Anyway, during the break, a Rails user came up to me, and very intensely wanted to know why I chose Django over Rails. 'Cause I already knew Python, I said. ;-) He persisted and I tried to tell him that I never used Rails and didn't feel I was knowledgable enough to comment on the differences (or similarities) between the two. He just kept pushing, and I got that feeling that he was looking for something to validate his own choice. I get this sense a lot with Rails devs (at least that I've met) and I wonder... if it's so great why the need for so much validation?
I was reminded of that LW moment by your post -- the need to be *right* about one's choice. If something works for you, you're more productive, and you enjoy it, then I say stick with it. That's reason enough, rather than being swayed by what everyone else thinks.
Nice piece overall, I just have one gripe with it: you state that dissing something with blanket statements like “Python sucks” is wrong, but a couple of paragraphs earlier you just did the same yourself, by declaring PHP and XML-via-print to be “morally wrong”. If I were (still) a PHP developer I’d be pissed right off by that, especially by someone who seems to get it. PHP is perfectly fine if you happen to like it, and me and you have no right to tell someone they’d better “wise up” to Ruby on Rails or Django. (Disclaimer: this comes from someone who used to write PHP code and has been working in Django almost every day since it was open sourced).
And yeah, I am well aware of the benefits of using proper XML machinery, I just think there are good enough usecases where it’s overkill/unfit.
Antonio --
Yeah, the PHP thing is unfair, but I couldn't resist at least a *little* poke at PHP. Sorry :)
I stand by my statements about XML, though -- if you're producing or consuming XML, using anything other than tools designed for that purpose is Wrong. Like you I'm a pragmatist, and so at times I use regexes to do a bit of XML munging, but I know it's Wrong.
Forgive the repeated construction analogies (I've been doing a lot of home improvements lately), but the concept of building codes seems analogous with this. As I work on my garage, I *could* cut a few corners and use larger stud spacing than the code calls for, and I'd probably be fine. Since I'm doing the work just for me, an inspector will never ding me for it, and since I'm not planning on adding on a second story the wall stability won't be an issue. Still, none of those arguments make cutting this particular corner any less wrong.
I think I don't need to beat this particular horse any more :)
There's an open link above which makes using this comment form... interesting!
I agree totally with your disgust of moral arguments - but have you noticed it's only the 'trendy' side of the web that has this problem? Those without well-frequented blogs usually steer clear of this and focus on getting things done :)
I don't have any hard evidence for this, but I reckon it's true in well over 50% of cases, and would make an interesting ethnographic study.
And yes, this is what put me off Rails totally - I see the hype and arrogance and it rubs me up the wrong way. Having said that, ajax_scaffold is really really cool and I have just used it for a disposable project!
Zope blindness - check: "Use the right tool for the job. TurboGears and Django (and Pylons, Quixote, web.py, etc.)"
Not that I disagree with much in your text, indeed, I applaud the general message, it's just that I'm fascinated by the collective Zope blindness that everybody seems to be suffering from.
Surely you don't mean to imply Zope can't the right tool for the job, ever? Surely you don't mean to imply that Zope is one of the less important Python web frameworks, compared to say, web.py? I've been using Zope for about 7 years as a Python web framework and now it doesn't even need to be *listed* anymore, and something like web.py does? I realize that I'm overreacting to this particular instance, but I've seen this happen so frequently lately I wonder what's going on, besides Zope having an obvious marketing problem. :)
"Zope having an obvious marketing problem"
The pushback I got when I last mentioned Zope in public has convinced me that if any of the Zopers who keep popping up every time anyone mentions Zope (or in this case, not mentions Zope) spent that energy on tuning the zope.org site instead, that problem would go away in an instant ;-)
Martijn is right. This is the second time [1] I see Zope is simply ignored. Sure, there are many things about Zope 2 that might be disturbing to Python developers (and you'll find I agree with most of them). But there are also many things in Zope 2 that are sadly misunderstood. And Zope 3 is completely ignored most of the time, though it uses twisted, supports WSGI, etc.
Zope has been around for the longest time. Not only that, it was *the* Python killer app for the longest time as well [2]. And by killer app I mean that it has solved problems like RESTful
web programming, standardized interfaces, pluggable components, or
practical restricted-execution environments in Python long before these have become hot topics, mostly only recently. The difference? Zope has got all that in production, in hundreds of thousands of deployments. I think that deserves *some* mentioning.
Like Martijn, I realize there's a bit of a marketing problem there. zope.org certainly sucks in various ways, but it's not *that* bad. The layout may look like the nineties, some of the words perhaps sound like the ninetees, but the news and releases are current. And the links to the docs are there and we trust our visitors to be able to find Developer Guide when they look for developer docs ;).
[1] first time: http://www.cmlenz.net/blog/... />[2] http://lwn.net/2001/feature...>
Fredrik, actually, I'm putting my actions where my mouth is, so I hope you're not including me in your comment. I've spent a lot of energy on improving zope.org, but there's a lot of inertia I needed to overcome first. Still spending energy. Progress is being made again, now.
Jacob, great article. Though your message seems a little inconsistent as at the top you make a rather general, "Django is the best for web sites", but then narrow the scope below to "using the right tool for the right job".
I have yet to see it anywhere (the comparisons generally aren't accurate as they put problem sets against frameworks that they weren't made to face), but it'd be great if the framework authors could all come up with a, "What we're tuned for" type of doc. This would help for someone who has used one of the frameworks, found out that their application doesn't mesh well with the framework design, and wants to move to one that will work with their requirements.
If a framework isn't tuned for anything at all, that's still a niche of its own of course... the "DIY builder". One of Guido's original remarks on Python web frameworks was on his desire to see such a document, and I don't think the links and examples on the Python wiki for web frameworks does a great job clearing this up.
"we trust our visitors to be able to find Developer Guide when they look for developer docs"
Uhuh. So if the Zope book isn't suitable for newcomers and developers, why does both the "New User" and "Site Development" sections point people to that document? When did you last look at your own site?
"I hope you're not including me in your comment"
Nope, but for every friendly and concerned Zope advocate, there are a dozen arrogant and condescending ones (and we've seen both kinds in this thread). Zope is pretty unique in that regard.
[Fixed bustalated non-closed links; thanks to everyone who gave me the heads-up]
Martijn -- you're completly right that I forgot Zope.
I have a few thoughts about why that is, but I think they deserve a post of their own.... stay tuned.
"it's just that I'm fascinated by the collective Zope blindness that everybody seems to be suffering from."
Martijn, as some one uses both Zope and Django heavily, I find myself conflicted. As an expert, I think it's hard for you assess the initial complexity of Zope, right now. Zope is on the seame level as J2EE in terms of surface space.
What interests me about Zope is that it's optimised for content largely due to ZODB and clever models like CMF/ATCT. For example I can see Django's field model and DBAPI as a subset of Archetypes. I have a hard time crediting that the Zope2/Zope2/Plone software layer is ideal, and neccessarily reflects the complex problems it attempts to solve. And I'm not even talking about architectural overhead of the versions, the inability to cut free of the past, and hybrid setups like Five and the permissions crosscutting. I'm talking about basics, like processing the fields of an Archetype/CMF, or filesystem based development, which are IMO non-intuitive. The essential problem is that Zope requires reversing engineering of both the source and runtime to understand what to do next. When you can do that, it's great, you're an expert. But when you can't get there you will look for a tractable alternative. Django is that alternative for many people. And assuming a port of something like CMF to Django is possible, then I think that leaves Zope being pushed further up the complexity/enterprise ladder.
"Django is that alternative for many people. "
That said, one thing I would *love* to see, and hope to get done fingers crossed, is a solid delivery system for published content out of Zope/Plone to Django backed sites. For Plone, my experience of things like ZSyncer and Entransit is "could do better". In that sense these are highly complimenatry stacks. Actually the Plone/Django combo would be hugely disruptive in the ECM space (in a good way). And like I said ATCT looks like a superset of what Django does; you'd think it's a doable thng. I work on the Atom Publishing Protocol; if we had a batched content mode there, I'd use it to schelp data back and forth.
And btw, both Zope/Django need to start using Elementtree across the board ;)
"And by killer app I mean that it has solved problems like RESTful
web programming"
In part. Zope's very much got that 90's CGI and Object Invocation magic legacy to it. It makes it way too easy to perform destructive gets, imo.
"pluggable components",
Strong agreement. There's been some discussion of this (and how far to take things) on django-dev. Zope's component model makes for good homework here (along with eclipse/osgi)
"practical restricted-execution environments in Python long before these have become hot topics,"
Not sure about that. Sure you can't just import re in a script, but Zope is basically a default-allow environment at the public resource level, right? Plus external methods and tool callouts are a lot of hassle to setup.
"I realize there's a bit of a marketing problem there."
Maybe, but this too easily dismisses any notion that Zope is overly complicated, and that Django has inherent value. Zope2 101 is *hard*. Django 101 is *shockingly* easy. You can argue some level of complexity is needed (I'd agree) for that much ootb experience from Zope/Plone, but I really do think some of it is superfluous. The Django/RoR people are doing a *great* job in flattening the learning curve without putting you in a hole when "things get rich" later on (which has always been a problem with web frameworks). I think the Zope community could learn a lot from that, in the same way the Django community could learn a lot from Zope; say around component based development, and stuff like default skinning/widgets. It's not an either/or thing.
Anyway, that's 3 in a row from me - enough already, I'm in danger of hijacking the thread. Great post Jacob!
Zope 2 has a long and interesting story, with many twists and turns. I'm a fairly experienced Plone developer, and I still find some of the Zope 2 specifics baroque. But there's a good reason for that - it's that I never had to care. :)
Honestly, I'd have a hard time recommending pure Zope 2 to someone who wanted to build a web application. I do promote Plone quite heavily, in part because for the vast majority of people (witness the traffic on the plone-user mailing list), you don't need to understand or care about the madness to build powerful applications - Plone, Archetypes and CMF saves you.
Now, we have Zope 3, and frankly it offers the most compelling development model I've ever seen (and I've seen a few). It's extremely powerful, and one of things that turns out to be much easier than it looks at first glance. The low-level documentation is also extremely good (DocTests are everywhere). The high-level "entry point" documentation is coming together, with Philipp's Web Component Development with Zope 3 book probably the best resource right now.
If someone wanted to build a *content-centric* (which is still where Zope's main emphasis lies, but a surprising number of business systems are well modeled in this way) from scratch, i'd have no problem recommending Zope 3 (and Philipp's book).
Now - if you were trying to build an application from scratch, using Zope 2 + Five would probably be mad. But then you have the luxery of being able to start with pure Zope 3, which should certainly be on your radar if you're a Python person.
If someone wanted to build an RDBMS-based system, Django and TurboGears both look like good frameworks to me, although I lack the experience to say for sure where the pitfalls are.
My philosophy has always been, use the tool that works for you. The nice thing about the Zope 3 story is that it brings component reuse much, much closer to reality than anything I've used before. The more small, simple, pythonic components (and I'd content that Zope 3 components are very pythonic, angle brackets or not) we write, the more we advance the Python cause. Beyond that, if you want a CMS, choose Plone, if you want a content-centric framework, choose Zope 3, if you want an RDBMS framework, choose Django or TurboGears, if you want pain and suffering, choose J2EE.
Martin
Hey, Jacob
Thanks much for linking to my post on the subject. I appreciate that, and it validates what my overall feel for you as a person is. I'm glad we got a chance to hang out a bit at PyCon.
I very often bring up the "vi vs. emacs" thing, There are always tradeoffs and it's a relatively rare thing that you can concretely say "doing it this way is 5x better than doing it this other way". Those things do come up from time to time, but more often it seems to be "vi vs. emacs". (Someone I work with was speaking out against exceptions the other day... it's a similar kind of holy war. For me, exceptions (as python does them) are a clear win... but I understand there are some arguments against.)
I enjoy working within the Python community quite a bit because of people like you. There's just generally less mindless shouting than you find elsewhere.
Regarding Django picking up on improvements from the rest of Pythonland... You're right that, particularly with liberally licensed open source code, you can easily pick up smaller bits of code or, at the very least, inspiration from other projects that are moving in Python. But, it's unclear to me what you'd pick up from something like SQLAlchemy (or, at least, how you'd go about it). SQLAlchemy uses a very different model which would take a lot of work to reimplement (certainly more than to just use). It's possible that the model SQLAlchemy uses doesn't appeal to you, which is fine. Everyone has their target, and the use cases that SQLAlchemy solves may not be relevant at all to the things you're trying to do with Django.
I do concede the point that there are more ways to benefit from what's going on in the broader community than just straight bundling.
As far as Zope goes: I think that the reason that Zope doesn't get mentioned as much in these types of posts is that Zope2 and Zope3 both provide a different perspective on application building than the direction that people are more generally heading in today. That doesn't mean they're "bad" or that they don't have their own places where they apply. They're just optimized for a different style of application than the kind that has people enthralled at the moment (a "web 2.0 app", for lack of a better term [don't sue me]). can you build that kind of app with Zope 3? Most certainly. But, it will probably take you more time than it would with TurboGears or Django. Will it have more reusable bits in the end? Probably... but, that's not the use case most "web 2.0" developers are optimizing for.
Comparing Zope with TG and Django seems a bit like an apples to oranges comparison.
(BTW, as a framework developer, I will say that there is certainly a lot to be learned from Zope 3 and that there is a lot of good, decoupled code that can be used. Something to consider...)
Note that I haven't been comparing Zope with Django. Both have their merits. My point is not to compare, but to include. I've been noting Zope doesn't even seem to *appear* in people's list of web frameworks in Python, and I think that's bizarre given the history of Zope, the size of the Zope community, the overlap between the Python community and the Zope community, and contributions by the Zope community to the Python community. I think that this is a blind spot that needs to be corrected, and that's why I'm making noise, and even overreacting to one such innocently written list.
Zope can be criticized. There are reasons: it's been around for a long time so there's lots of historical baggage. The community has existed somewhat separate from the Python main stream, so it's easy to do us/them. that's fine, criticism needs to happen and there are many aspects to criticize. Zope can be criticized but Zope shouldn't be completely *ignored*.
In some cases, Zope is the right tool for the job. If you want to put up a Python-based CMS, which is one form of Python web application, I would strongly suggest anyone to consider Zope 2 + Plone/Silva/CPS. You get complexity yes, but you get a truly enormous amount of functionality as well. For more general web application development needs, Zope 3 has a *lot* to offer.
Zope's initial complexity barrier is too high for a Python programmer. That's true for Zope 2 definitely (often for historical reasons), and it's unfortunately a problem with Zope 3, even though that is a lot more accessible to a Python developer already, and even though we've tried hard to make Zope 3 more Pythonic. These are valid criticisms; we've been trying to address them and hopefully we'll continue to make progress on that.
Finally I'll note that the experience we have in the Zope community with the evolution of complicated web systems over a significant amount of time is enormous. This experience is valuable. Zope 3 is the expression of some of that experience.
Amen to apples and oranges.
I think of Zope 3 as a very "serious/powerful" framework for lack of a better term. It offers some immense power, and the cost of that is (as always) a learning curve.
Zope 3 also suffers from a marketing problem (no-one really has put it out there in the same way as Rails, say, and the distinction between Zope 2 and Zope 3 is not clearly made - imho, it's so different they should never have called it Zope 3 at all). It has a documentation problem in the sense that the documentation isn't as accessible as it should be (worldcookery.com is a good place to start, btw, both for the in-print book and the Appetizers section).
But food for thought: SQLAlchemy as you say has a very particular model, and Zope 3 out of the box has very little RDBMS focus. Yet, I know of two different ways in which you can integrate SQLAlchemy with your application, and though I've yet to use either, they both seem very elegant. That doesn't surprise me, though, because that kind of a re-use and pluggability story is *precisely* what Zope 3 is designed for - from the ground up.
Martin
"Zope's initial complexity barrier is too high for a Python programmer."
The reason for that is simply that Zope 2 (at least) is, for all practical purposes, an application that happens to be extensible in Python, not a fully modular Python program. Two different things, and two different mindsets.
I'm not surprised Zope isn't being talked up here. I've wrung my hands publically before about what I believe the underlying issue to be: http://www.plope.com/Member... , http://www.plope.com/Member... and http://www.plope.com/Member... . IMO, to be considered seriously among the crowd that hangs here, the dichotomy between the "scripter" and the programmer in the Zope worldview needs to die.
"seriously"
Oh, we take Zope seriously when Zopers claim that it's an excellent web application framework. But not when they claim it's an excellent *Python* web application framework.
Revision after reading Fredrik's above comment... Zope needs two things to be considered seriously as a Python web framework by the crowd that hangs here: 1) removal of distinction between scripter and developer; 2) change the name of Zope 3 to something without any Z's in it so perhaps we can get those folks to download and review it without first choking on their own five-year-old vomit.
footnote: I'm still talking about Zope 2 -- because from what I can tell, that's what you get when you surf over to zope.org and look for tutorials and other documentation.
A name change would seem to solve that too because if Zope 3 was not named Zope, you'd likely evaluate Zope 3 on its own merits by visiting "thingthatsnotzope.org" instead, which would be a good thing. Even if *that* site was made up entirely of cat pictures, it would likely be a better resource for Zope3 than is Zope.org ;-)
But in the meantime, all I can do is reiterate what people have been repeating over and over again (apparently without effect). Zope 3 is nothing whatsoever like Zope 2. If you can manage to prevent yourself from gagging when you hear the word Zope for about six minutes, take a look at http://zeapartners.org/scl/... (screencast) to get a small idea of just how different it is (tip: the screencast is done almost entirely in emacs). You still might hate it as Python framework, but you'll almost certainly hate it for entirely different reasons than you hate Zope 2 for. ;-) Other similar introductions are listed at http://www.worldcookery.com... .
Leave a comment: