why we should avoid tipfy – a gae framework

as we recently found out, choosing a framework for GAE can be a costly and frustrating affair. for various reasons we decided to go with tipfy (http://www.tipfy.org) for one of our projects. at that time the tipfy framework version was 0.5.9.

GAE has evolved and i guess tipfy had to catch up with the new additions.

the current version of tipfy is 1.0b1 … the source layout has completely changed which means we have to spend effort to make it work with the latest form it has taken.

the maintainers of tipfy clearly don’t think backward compatibility or easy porting an issue worth consideration. we have since decided to do away with tipfy and port it back to vanilla GAE. from experience the only thing we will miss is the jinja templating which was superior to the django template engine a year or so ago. in fact more important (from our requirements point of view) things like the google map reduce functionality should work out of the box – it was a royal pain to get it to work on tipfy. the tipfy implementation appears quite weak.

our recommendation for anyone out there trying to choose a framework to start on GAE is to stick to the core GAE itself and at the most venture into django.

of course, we welcome tipfy experts to educate us on what we are missing. but for now, tipfy is not yet mature for serious development.


4 Comments to “why we should avoid tipfy – a gae framework”

  1. looking back at this post after a week, i must say it looks a wee bit of a “personal attack on tipfy”.

    but I hold on to that opinion that tipfy is not there yet.


  2. We liked jinja2 so much that we decided to get it to work with the webapp framework. Which was hardly any effort at all. copy the jinja2 folder to an appropriate location within your GAE project (the code below assumes that it is available in the same directory as the webapp handler)

    from jinja2 import Template, Environment, FileSystemLoader

    # you can skip the loader part, we needed to do some funky path translations which required # us to override the default loader.

    env = Environment(loader=MyLoader(''))

    class GenericPage(webapp.RequestHandler):
    def get(self):
    template_values = {

    file = 'index.html'

    template = env.get_template(file)

    that’s it. the call signature is remarkably similar to the django templating engine which makes the switch very easy.

  3. (cross-posted from StackOverflow)

    Any framework that intends to provide native support for SDK handlers will need to wrap them (adding “no value” as you say). This is a duplicated effort that causes maintenance problems. The solution, imo, is to stick to webapp or use a framework that stays close to webapp. And for this I suggest webapp2:


    I described this dilemma here:


    • it is sad to see tipfy go this way –

      As of July 18, 2011, tipfy is looking for a new maintainer. Contact us through our mailing list.
      In the meantime, we highly recommend webapp2.

      in a way, I feel vindicated with my original stance that tipfy is not up there. as a contributor instead of developing a “framework” which tends to be too grand (simply because the creators want to address a large audience and make it generic) develop individual components (libraries) like jinja2 which address gaps or add significant value. tipfy did neither.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: