grok vs. django comparison

Question

What are the smashing (pun intended) features of grok that makes it better than django? how do I know when my project needs grok+zope, or it can just be developed with django ?

Answer 1

I don't think any of the frameworks are intended to have any 'features' that make one 'better' than the other, or 'needed' in certain circumstances. Rather, the difference between Django and Grok - or Pylons, or Turbogears - is really one of approach. You may find the approach of Grok to your liking, or you may prefer one of the others. I doubt there is much you can achieve in one of them that you can't in any of the others.

Answer 2

Grok is basically all the power of zope in a way easier to use package. So you do get all the luxury of a real python object database (though you can use an sql backend). And I assume you know about the adapters/utilities/views of the so-called "zope component architecture". Those allow you to make a robust application. Especially handy if you later need to selectively customize it. And security is traditionally a zope (and thus grok) strong point. Development and deployment are handled fully with eggs (and buildout): in my experience this is a robust and reliable and repeatable and comfortable way.

If you have an application that can work with straight sql tables without needing much selective customizing afterwards: nothing wrong with django. You'll have to do much security yourself, so that needs a keen eye. There's much less of a framework behind it (an ORM and a url mapper), so your python will feel more "pure and simple". This also means you need to do more yourself.

There's nothing from stopping you from selectively using parts of grok: http://pypi.python.org/pypi/grokcore.component for instance is very much the core. Pretty well isolated, so you can use it without buying into the whole zope stack. I'm pretty sure you can use that in django. grokcore/zope component is just python code. This gets you the adapters/interfaces/utilities. I don't know what you're building, so you'll have to experiment.

One thing hugely in favour of grok that I'd suggest trying out: zope's ZODB object database. A good ORM (and django's is pretty ok) helps a lot taking the pain out of SQL databases, but a real object database is just plain luxury :-)

Answer 3

Zope was the first object publishing framework evah, and the Zope community has a long experience with Doing Things The Right Way. Zope 2 was the first attempt, Zope 3 was the next attempt, and we are now into the third generation of web frameworks, which includes Grok, BFG and Bobo.

Grok is massive, and has even more modules available that doesn't come when you install the base (and it's in the process of reducing the number of required modules as well, so the footprint gets smaller). BFG and Bobo go the other way around, and are minimalistic frameworks but with easy access to the Zope Toolkit and all the functionalities of Zope.

And although Django is making many of the same mistakes Zope2 did, they are also fixing them much faster, so I completely expect much of this discussion to be moot in five years, because I expect every single Python web framework to use WSGI+WebOb+Repoze+Deliverance+Buildout as a base by then. But even then I'd go for frameworks where I can use the Zope Component Architecture and ZODB, but that includes not only the ones made by the Zope community, but also for example Turbogears. And maybe it will include Django too by then, who knows... :-)

Depending on what the project requirements are I would today go with either Plone (if they need CMS), Grok or BFG (depending on the involved developers, and the complexity of the task and the budget). This is of course partly depending on my large experience with the Zope technologies and my small experience with Django, but mostly because I can use ZTK and ZODB in Grok and BFG.

YMMV, etc, blahblah.

• Zope Toolkit
• Brandons talk on the Zope Component Architecture (Video from PyCOn, Slides from PloneConf)
• BFG
• Bobo