Skip to content

PyCon 2007: Web frameworks panel

Published on: February 23, 2007    Categories: Django, Frameworks, Python

(this was liveblogged during the panel, and the only later edits were to correct a couple of typos and add this notice — the content has not been changed)

Titus, the moderator, has welcomed everyone. No blood shed so far. Probably not taking audience questions.

Introduction of the panelists:

Titus pauses: “The most interesting thing about Django is, it’s what Guido would do.”

Titus says he’ll spark discussion by targeting Zope. First question: there’s a wide range of web frameworks, some new, some old. There are more Python frameworks than reserved Python keywords. Developers of older frameworks: would you do things differently now? New frameworks: what’s your niche?

Jim Fulton: When Zope started, the only “framework” was the cgi module. Zope didn’t start as a framework, didn’t target Python programmers or even necessarily technical people. They moved to the object-centric model and accidentally ended up with all this other stuff. Python has lots of creative people and makes it easy to produce interesting things — that’s why there’s so much stuff.

Duncan: when Nevow was first written there were other frameworks, but nothing that coupled with Twisted.

Robert: CherryPy is trying to scratch a smaller itch. It deliberately tries to be small enough to keep in your head, but also to enable people to scratch their own itches. That’s why frameworks come about — to scratch someone’s itch. CherryPy tries to do one thing — HTTP — and do it well.

Kevin: was starting a one-man company and wanted to write as little software as he could. Considered Rails, but Python already had the pieces to build great stuff, just not the glue to put them together (yes, he said “glue” — that’s not my paraphrase). Then he had to document how he’d put everything together, and decided to make that public so others could use it and see how it worked.

Ben: says it was very like TurboGears — Django and TurboGears weren’t out there yet, Ben didn’t want to write a framework. Reuse was his key factor — he also wanted to write and maintain as little code as possible. Used Zope and Plone for some stuff, but needed custom things for smaller tasks. That’s where Pylons came from.

Adrian: Django came from the kind of “I’ve got this data and this story, I need an application to go with it by tomorrow”. That led to a set of rapid development conventions, which turned into a framework.

James: ended up spending too much time working on a framework and not enough actually working on sites. Mentions he’s now using Django on the server side. Pyjamas is focused on the client side, with the same sort of ideas as Google Web Toolkit (which translates Java into client-side JavaScript). People said of GWT, “why Java?” He reverse-engineered GWT and Pyjamas does Python-to-JavaScript translation. Handles widgets, compatibility between the JS types and the Python types.

Jonathan: wanted to do Python web development, but all we had was Zope and that “made me run screaming in the other direction”. That’s one reason why we have so many frameworks. Would really like to not be in the framework business and be using somebody else’s framework, but wants something that’s first of all about pages, not objects (which Spyce handles). When you control the whole stack you can innovate faster than when you’re trying to bundle a bunch of components together.

Titus: if someone took Spyce out back and shot it, would you re-create it, or use someone else’s technology?

Jonathan: “I didn’t start a framework, I revived one”. It’d be a tough call; likes what Django does as far as controlling the whole stack, but the Django ORM is really feeble.

Duncan: there’s a perception that the multitude of frameworks is a weakness. It’s not; it should be celebrated.

Robert interjects: every time somebody pops up on comp.lang.python and suggests an experimental framework, people say “don’t do that, somebody else has done it”. Robert says do it, it’s the only way to get to what you do like.

James: re-inventing the wheel is great if your goal is to learn more about wheels.

Titus asks Kevin if he’d consider using a different framework.

Kevin: “Pylons is pretty cool”. Philosophically, Pylons and TG are fairly similar, though they’ve made a few different choices. Kevin thinks you can have more innovation with individual components with their own maintainers than with a full stack. He’s pushing to have things broken up into components for that reason.

Titus: question for Django about blog debates: “tightly integrated” versus “loosely coupled”. People get led to believe Django components can’t be pulled apart. How do you do both “tightly integrated” and “loosely coupled”. How do components differ from a full stack?

Adrian (on “full stack” versus other methodologies): you can’t do both. Documentation is a huge thing; he doesn’t want the tutorial to say “here’s how you connect to the DB, but you could also do this or this or this”. It’s cool to be able to do that, and lots of people care about it, but you’ve got to pick a focus. Django needs better docs on integrating with other stuff, because we’ve been doing documentation that assumes the Django stack. Need better advanced docs for that.

Titus: in conjunction with a full stack being good for beginners, but advanced people pulling things out, how does Zope handle it?

Jim: it’s the documentation story. You have to have stories: tell stories that address problems. Stories for people who are beginning, people with specific needs, it feels like a documentation issue. A peeve of his is “understanding the problems the solutions are appropriate for”. Zope is not the solution for creating a simple CGI application. It’s not a problem Zope tries to have a story for. You’ve got to be clear what your goals are and tell stories.

Titus: the Pylons docs say, “thank you for choosing Pylons, here are the choices you need to make”. Rebuttal in light of what Adrian and Jim just said?

Ben: we did make a conscious effort to push beginners down a single route. All our recommendations for beginners are based on “keep it as simple as possible”. Starting to change some of the recommendations. Something convenient to use, but powerful enough that you won’t run into walls. If something doesn’t give you the right feeling, they want it to be easy to swap out.

Titus pulls up a question from Eric Dobbs; the plethora of web frameworks seems Perlish and not Pythonic. Quick responses?

Robert: Python the language isn’t domain-specific. Frameworks are, and so there’s naturally a larger set of approaches and multiple ideas about how to solve the problems. Python is two decades old, how many of these frameworks are that old? There’s a push to make them mature, but at the same time we’re still experimenting to find the best way. It’s a bit much to expect maturity on par with, say, Apache.

Several other panelists murmur “that’s a perfect answer”.

Titus: final set of questions is on AJAX. In terms of your JavaScript plan and support for AJAX, do you have good support? Could it be better? Are you looking at other toolkits?

James: that’s a different kind of question for me. Am I looking for a particular sort of framework to tie myself to? Not yet. He uses Django, but TurboGears might be a better fit for how Pyjamas works. CherryPy might be perfect. The AJAX story is Pyjamas. There is a lot of overlap between what Pyjamas does and the two types of JS libraries that exist (one provides a lot of data stuff, one provides a lot of UI stuff). Pyjamas does use a lot of existing stuff; it used Mochikit’s iterator implementation, for example. Initial goal was to duplicate Google Web Toolkit.

Titus to Jonathan: you said it’s about pages. In light of AJAX, how do you deal with that?

Jonathan: there’s a difference between page-based that wants to be a little more dynamic, and then the Flex-style all-dynamic application.

Titus to Adrian: does Django have an AJAX plan?

Adrian: We don’t ship with a JS framework. Having Python produce JavaScript is like using a motorized wheelchair because you’re too lazy to walk. If you ship with a default library you couldn’t please everyone. Code generating code would be messy. Django gets a rep as “it doesn’t do AJAX”. That’s because we don’t ship a library, but it doesn’t mean you can’t use AJAX. Cites a couple examples. Though a lot of it is our fault for not documenting examples — people don’t see docs and then assume “Django can’t do AJAX”. So our plan is documentation.

Titus: that’s been your answer several times.

Adrian: that’s the most important thing we can do.

Staff member pops up: anyone using the schedule app for PyCon, you’re using Django with “AJAX” (not XML, technically).

Jim: “I’m the wrong guy to ask.” Plone is using something that’s pretty nice, at Zope Corporation they use MochiKit quite a bit. It’s not clear what the relationship between the JS library and the server technology should be. There should be some hooks, but they should be server-tech-agnostic.

Duncan: “we were there first”. They had AJAX before it was called AJAX.

Ben: originally was looking at a lot of frameworks to see how they did it. Saw Rails’ helpers and wanted that functionality, so he ported them all to Python as WebHelpers, which runs independent of framework. Generates some things, is pretty neat and easy to use. In the future, looking toward Pyjamas.

Titus thanks the panelists for coming, and we’re done.