2008-09-24

CherryPy doesn't get enough love.

I tell you, it's true. CherryPy doesn't get nearly enough love on the web. Everyone hypes up django and RoR, but barely any mention of cherrypy.

Now, I'm not trying to rag on django, or RoR - they're both wonderful tools - however, I've found my match (so far) with cherrypy.

CherryPy really isn't a web framework - it's more of an HTTP framework. If you're writing a web-application, or website that calls for a framework, then it's fairly easy to pick and choose each part of what makes up a framework, and set it up how you like. Granted, it's normally possible to customize all (or a large portion of) the individual tools that a framework like django uses, but it seems to me that when a lot of people use a framework, they end up never exploring other options for doing what they need to do. Really though, the point about having to pick-and-choose what tools you use for templating, interacting with the database, etc is a minor one.

The real benefit that I get, as a developer, from using cherrypy is the ease with which I can perform iterative development with a minimum amount of learning a bunch of new stuff. Ruby on Rails can make iterative development pretty easy, but I have to learn:

  • The RoR directory structure.
  • How to use RoRs default templating system.
  • ActiveRecord
  • RoRs quirks.

That doesn't seem like much, but really it's quite a bit of stuff. If you've got what your building entirely planned out, already have the design done, and it's fairly large, it can be really nice to just have a place to drop all that stuff into.

That's rarely the case for me. Many times when I want to make a web-application, it's pretty small. Using RoR feels like overkill, there's so much stuff generated that I won't ever use. There's different configuration options for tons of different stuff, and so on.

As an example, I recently implemented a tool for downloading Ubuntu packages and their dependencies as a tarfile. It's about 150 lines of HTML, 80 lines of CSS, and 150 lines of python, plus a smattering of javascript making use of jquery. It doesn't touch a database at all, it's a simple app. It's simple enough that I didn't feel the need to use a templating system - the few methods that generate dynamic content do it through yield statements. Sure, having markup in method code is generally a bad thing, but it is a very small amount of markup and it makes it very easy to know exactly what's going on without having to look at a whole lot of files. This is only a good strategy for simple cases - if the method logic needs to get more complicated, or the markup needs to get more complicated, than the yield statements can (and should) be refactored out into templates.

CherryPy lets me do this. It doesn't care, and it makes it abundantly clear that it doesn't care how the "exposed" method creates what it will be sending back to the user. Need a templating system? Find one, learn how to use it, integrate it into your app.

My tool for downloading Ubuntu packages and their dependencies is one python file, plus the directory structure for html files, stylesheets, and javascript files. CherryPy has a server built into it, that has more than met my needs so far, and it's configuration is right there at the bottom of the file after "if __name__ == '__main__':".

When I first started fooling around with CherryPy, I was a bit confused. The online docs weren't that great, and finding info about configuring the server was difficult.

Then I opened up the code for CherryPy itself. It's well written. It's well documented. It's pythonic as all fuck. I don't need documentation, I can actually read and comprehend the code for CherryPy without much of a strain, without being familiar with the codebase. Oh my.

So in short, cherrypy allows me to:
  • Only do "web frameworky" stuff when I need or want to.
  • Not have to be familiar with how to turn the "web frameworky" stuff off in order to do the above
  • Iteratively develop my web-apps at a sane pace, building them as they proceed.
  • Always write a web-app that I know intimately.
  • Understand what's going on under the hood due to the quality of their source

And those are a few of the reasons that I have fallen in love with cherrypy.

13 comments:

  1. Completely agree with you here. I use CherryPy often and find it meets my needs very well.

    ReplyDelete
  2. I agree also. I've been using it for a while, while teaching myself Python at the same time. Learning curve was tiny, and CherryPy stays out of your way. It *is* interesting that it gets almost no press, especially considering it's at the core of TurboGears, as I understand it, which gets much more attention. I don't suppose you'd be willing to share the source of your little app, so I could take a look at someone else's usage?

    ReplyDelete
  3. You are right! I know there are other frameworks out there, but CherryPy is written in harmony with my way of building websites.

    ReplyDelete
  4. @Ty - The source of the app can be found at launchpad.

    ReplyDelete
  5. Thanks! I'll take a look.

    ReplyDelete
  6. I must beg to differ about equating Django "hype" with RoR hype. In my experience, the entire Ruby world is *glistening* with ideology along the lines of "why Ruby is so cool" and "why you're an idiot not to use Ruby and RoR." I personally find it extremely distasteful; it sounds just like ads. If you go to djangoproject.com in contrast, you see a well-designed site with a list of features up front. You don't have to drink the cool-aid :) On top of that, the writing style of the docs is pretty good if you stay away from the Django book, which I've found to be a waste of time.

    I still think you're right about CherryPy though - for lightweight web apps, Django would be burdensome.

    ReplyDelete
  7. @d - I just meant that I see a lot of hype about django, and that using django carries a lot of the burdens of using other frameworks, like RoR.

    The community around django is much more friendly (and practical, from what I've seen), and I agree about the perceived "elitism" of the RoR community - I think that a lot of that comes from RoR being the first "OMG I can make a website" thing people are exposed to these days, other than php.

    The type of hype I see about django is markedly different than the type of hype I see about RoR. Perhaps hype is the wrong word - "buzz" may be more appropriate.

    In short, I wasn't trying to equate django and RoR, in anything other than the sense that there's a decent amount of "learning-how-this-system-does-this-and-that" involved with using either of them. Their communities are wildly different, from what I've seen.

    ReplyDelete
  8. THat is because it plainly doesn't work.

    ReplyDelete
  9. I actually ditched CherryPy for Werkzeug and am liking it much, much more.

    ReplyDelete
  10. Interesting stuff. I've been trying to find out why someone would use CherryPy over Django, Pylons, TurboGears, etc.. and your post helped me understand. I'm going to spend time learning more about CherryPy in general.

    ReplyDelete
  11. What I really like to see is a CherryRuby framework, ie, the simple intuitive cherrypy framework with the simple intuitive ruby code.

    Just cause I really find it much faster to learn Ruby then to learn Python. Why!? The IRB and its code completion ofc.

    ReplyDelete
  12. nvm my last comment i just found ramaze :)

    ReplyDelete
  13. I love cherrypy and I love his http server, for most of my needs I don't need another server.

    Ruby: I hate the syntax... so I haven't go to much deeper into the language.

    Django: It's fine, but it needs an http server like cherrypy one.

    ReplyDelete