Monday, May 3, 2010

Why web2py

In a previous post I mentioned that web2py is my weapon of choice for building web applications.
Before web2py I had learnt a variety of approaches to building dynamic websites (raw PHP, Python CGI, Turbogears, Symfony, Rails, Django), but find myself most productive with web2py.


This is because web2py:
  • uses a pure Python templating system without restrictions - "we're all consenting adults here"
  • supports database migrations
  • has automatic form generation and validation with SQLFORM
  • runs on Google App Engine without modification
  • has a highly active and friendly user forum
  • rapid development - feature requests are often written and committed to trunk within the day
  • supports multiple apps for a single install
  • can develop apps through the browser admin
  • commits to backward compatibility
  • has no configuration files or dependencies - works out of the box
  • has sensible defaults for view templates, imported modules, etc

The downsides:
  • highly dependent on Massimo (the project leader)
  • the name web2py is unattractive compared to rails, pylons, web.py, etc
  • few designers, so the example applications look crude
  • inconsistent scattered documentation [online book now available here!]

2 comments:

  1. Very interesting. I've known about web2py for quite a while but never actually got 'round to using it. This might actually push me to give it a go. Lately though I've often found myself wanting something more lightweight. I've used web.py for a couple of projects, which works well, but I'm also looking at giving Flask a go - have you used this microframework at all?

    ReplyDelete
  2. I haven't used Flask but felt it didn't offer enough of the time savers that makes web2py productive: DAL, SQLFORM, auth, appadmin, etc.
    I know some of the web2py developers were impressed with its simplicity. I

    ReplyDelete