Poll: Pythonic startups: what web framework do you use?

https://news.ycombinator.com/item?id=523280

by wensing • 17 years ago

57 73 17 years ago

news.ycombinator.com

hendrixski• 17 years ago

Wait... there are people who wrote their own framework... in the year 2009?

randallsquared2• 17 years ago

Well, 2007, for me. But I built it over web.py, so I upped both.

(Edit: and I've since mostly switched to PHP)

Brushfire• 17 years ago

Heresy! j/k. I'm actually curious why you switched from python to php. Was it your choice or forced upon you? If your choice, can you explain? I usually meet people going the other direction.

andyn• 17 years ago

Well, Django is perhaps the most famous example of people writing their own:

http://docs.djangoproject.com/en/dev/faq/general/#why-does-t...

But I still see it a lot, there's a lot of "not invented here" or "none of the existing frameworks do exactly what we want".

sifu• 17 years ago

it's very easy to write your own framework in python, that does excactly what you need it to do and nothing more. therefore is: scaleable the way you need it for your application. not in your way of doing things. easier to debug.

it's a bit of development overhead in the beginning, but pays of in the long run.

smokinn• 17 years ago

I tend to be the same way.

If I'm just coding up a small app I don't want the overhead of a framework. I might want a bit of routing, possibly some automated mvc and that's about it. Everything else in a framework I usually care little about and just slows stuff down for no benefit to me.

Coding up a "framework" that does only the very little I actually need is fast and very little development overhead considering the number of times I've done it and the fact that I've got code I can re-use.

This isn't business advice however, it's just my own personal project preference. If you're running a business you want to be able to replace developers if they quit so it's often a better idea to go with something more mainstream like a well known framework so that ramp-up time is minimized.

axod• 17 years ago

Why is that surprising? General purpose frameworks are always suboptimal, and overly general. There's extra cruft you'd never need, parts you might need optimized aren't, etc etc.

Writing your own is often less work than trying to tailor something existing to your own needs.

zepolen3• 17 years ago

Although it's not on the list, WSGI is the framework. The most simple and flexible one (it must be, as all the other frameworks on the list are based on it).

Frameworks are great up to a point. If you burger flip web sites all the time, then they make your life easy.

If you only deal with one site, you will never get the flexibility of pure WSGI with some prefabricated framework.

Radix2• 17 years ago

I am interested what the HN group's opinion is on Grok. It sounds interesting, but I'm not advanced enough to make proper comparisons.

tdoggette• 17 years ago

Grok's main value, to me, is to interact with larger Zope applications without having to deal with all of the mental overhead that Zope entails.

You can also reap the great benefits of the ZODB very easily with Grok alone. Grok is very easy to learn, and was designed by people that really know what they are doing with regard to Python web app development.

Radix2• 17 years ago

Thanks, I've heard Zope is huge and that must be the mental overhead you were referring to. I take this to mean that it was at once a large project, but jusdging be the 124 to django and 4 for Zope + Grok I take it that it has fallen out of favor. Why? Does it make anything too difficult? Is it too closely married to ZODB, ie. are there problems with ZODB?

akehurst• 17 years ago

Add WebWare to the list.

wensing8• 17 years ago

Would someone that up'd Django please outline their plans to scale?

thingsilearned• 17 years ago

Django scales just like any other web framework. The plan to scale Django is roughly the same as the plan to scale any app.

Are there any issues in particular you're concerned about?

wensing8• 17 years ago

Have you listened to Cal Henderson's friendly rant against Django from a scalability perspective? http://www.youtube.com/watch?v=i6Fr65PFqfk

For example, did you modify the source to support multiple databases for read/write? Or is that not an issue and it's OK that it's coming later in the framework's roadmap?

philjr2• 17 years ago

  * squid reverse proxies
  * memcached
  * low memory footprint httpd serving static content (e.g. nginx / lighttpd etc.)

bobbyi2• 17 years ago

Why squid instead of varnish?

iamelgringo• 17 years ago

Ellington, which is a Django based CMS runs the Washington Post web site: http://www.ellingtoncms.com/

I don't have doubts about Django scaling.

The caching framework is really cool. I did a test a couple of weeks ago, and I got a 10x performance boost, simply by sprinkling 3-4 lines of caching code to my site. That was justing the local memory caching: http://docs.djangoproject.com/en/1.0/topics/cache/#local-mem...

I'd imagine that using a caching back end like memcache would probably give another huge performance boost. It's really pretty straight-forward and usable out of the box.

wensing8• 17 years ago

If you're using nginx, you can install the memcache module, which lets you speak directly to memcache and bypass Django's CacheMiddleware altogether.

zepolen3• 17 years ago

Caching != Scaling

adrianh• 17 years ago

Ellington does not run the entire Washington Post site. A number of specific applications on washingtonpost.com use Django (e.g., projects.washingtonpost.com/congress), but the main site (articles, columns, etc.) does not use Django.

Signed, the guy who introduced Django to washingtonpost.com

philjr2• 17 years ago

For anyone who considered Django and discarded it (especially recently since it's been 1.0), could you maybe explain the decision behind that? I'm curious as a relatively recent Django convert.

wensing8• 17 years ago

As it stands, Django doesn't support multiple databases for read/write http://code.djangoproject.com/wiki/MultipleDatabaseSupport

That makes it a non-starter for us (for now).

bobbyi2• 17 years ago

It seems that its support for SQLAlchemy isn't really first class. I'm sure its builtin ORM is workable for simple web apps, but if you are doing serious database work in python, there is no substitute for SQLAlchemy.

Of course, you can use whatever other libraries you want in your own code, but at the point where you are not using Django's ORM and you have left its lame template system for something like mako (or maybe genshi, especially if you are generating XML), then what is Django really giving you?

mdasen2• 17 years ago

I want to preface this by saying that Django isn't bad. It's really good. However, there are some maddening things.

For example:

In Rails, you can say

  Article.find(:all, :include => :comments)

and that will get you the articles with their comments. In Django, you can say

  for a in Article.objects.all():
      a.comments #hits the database again!  argh!

Before you say, "Django has select_related() which does the same thing as Rails!" select_related() doesn't work in any useful way. select_related() only works on the side that defines the foreign key - so you can get the single article that a comment belongs to, but you can't get the comments on an article without running another query. Yeah, that simple, basic, every ORM should support it case isn't handled. And it's maddening.

Forms handling and validation is another sore spot. Some validation happens in the model, some in the form, ModelForms does somethings, but not others, editing related objects is a mess. In some ways it's shocking that it's such a mess considering how awesome the admin interface is. However, I always find myself manually dealing with forms to a point that's just annoying.

The lack of a true "if" in the templates. It's just limiting in a way that I don't find useful and I find that it makes my code less clear by nesting things in weird ways to get the desired effect.

Stagnation. Django is awesome, but sometimes it takes forever for small things to go anywhere because there's a genuine hesitance in the community to "dictators". By dictators, I mean personalities like DHH who say, "well, this way works and is elegant and we're going to go with it." On the one hand, it's what makes Django really attractive as a community. Rails attracts the know-it-all personalities. Maybe DHH and Zed do know it all, but most Rails programmers definitely don't. People in the Django community are really helpful, respectful of other's knowledge, and love learning from each other. However, it also means that even tiny features must be rehashed over and over, filed in triplicate, lost, found, stamped, checked by a committee of 8, rewritten from scratch, named new-X or X-refactor, break API compatibility, and finally get into SVN. Ok, most of that was a joke, but there are lots of little areas where it just seems like Rails is willing to move on something based on the general mood where Django wants a more formal assessment and wait period before deciding whether something is ok to be in or not. And for all people complain about DHH's one-way-to-do-it mentality and Django's more open structure, Rails isn't so closed and Django not so open.

Django's big selling points (for me) are that there's a ton of python out there that's beautiful, reliable code and the admin interface that allows you to deal with content neatly and easily. Clearly there are other selling points like MVC and ORM and whatnot, but there are many frameworks that have that. Django is a lot easier to understand (at least for me) in its implementation. Django's documentation is top notch which is amazing compared to other projects, but Rails is catching up with their guides and screencasts. Django also tends to document things like their file backend hooks better which makes creating plugin-type things easier, but again Rails (with the help of the Merb team) is going to be a ton better in this area.

You won't go wrong with Django. The only fatal flaw is really the first one and it's just unacceptable at this point in time. But it's a great set of code with a wonderful community. I don't think there's another framework I'd prefer. Maybe Rails, but nothing else.

rmg2• 17 years ago

Your first issue is incorrect. You can easily accomplish the query with one sql hit. The extra() command would work if your foreignkey was defined in the comments model.

webmaven5• 17 years ago

Why the heck is Grok listed, but not Zope?

wensing8• 17 years ago

Sorry, fixed. It was early and I frankly haven't even experimented with Zope.

webmaven5• 17 years ago

Thanks! I've added my vote for Zope.

mdoar• 17 years ago

I evaluated Django, TurboGears and Pylons for a new-from-scratch application of medium complexity (10K lines Python, 4 different databases). Pylons seemed to use a number of other tools well, had an excellent book and helpful community, so I went with Pylons. Turned out fine for my app.

dualogy• 17 years ago

I swear by werkzeug.pocoo.org -- not a framework, just a neat abstraction over WSGI with lots of web-related utilities and HTTP internals support inside that keep coming in oh-so-handy.

aconbere• 17 years ago

Our stuff in python is all on top of werkzeug :)

drsnyder• 17 years ago

As odd as it may seem we often prototype something we need to test using web.py even though our primary development language is php (using Zend). I recently did this to test a REST API. This has also been part of our process of 'flirting' with using a python web framework for some of our applications (looking at pylons).

m_eiman• 17 years ago

Am I the only one who likes CherryPy?

mattdennewitz• 17 years ago

jamwt2• 17 years ago

CherryPy is a hugely underappreciated project in the Python community.

Its HTTP implementation is top notch, its tool system is a great way to write custom modules, it has excellent WSGI support, and it's just about the fastest HTTP server in Python that takes a thread-based concurrency approach.

I was the first engineer hired on a team that built an online survey-research company. We started using twisted/nevow, but eventually moved to an in-house web framework on written on CherryPy. Lots of tools have come and gone (mostly, we've rewritten components we found lacking) but CherryPy has never let us down. We even ended up hiring a large portion of the CherryPy team.

Our experiences with it were positive enough that I'm building a startup right now on a similar CherryPy-based stack (at least partially--there's also a bit of Erlang involved for the high-concurrency stuff).

If you're considering stitching together your own Python Web framework--as many shops eventually do--I highly recommend CherryPy be used as the foundation.

jamwt2• 17 years ago

Bad form replying to myself, but one more thing worth clarifying:

All the above being said, it's only fair to acknowledge that this isn't quite apples-to-apples when you look at CherryPy vs. something like Django. CherryPy isn't really a full-stack web framework, it's an HTTP server attached to a configuration and tool system that facilitates the creation of custom web frameworks.

bigsassy• 17 years ago

Certainly not.

moe• 17 years ago

Definately not.

mgj• 17 years ago

FriendFeed has an in-house framework inspired by web.py and Appengine's webapp. It was written by Bret Taylor, who was the PM of appengine when it started, but is now working for FriendFeed.

He mentioned that he might open source it, but hasn't done so yet. I encourage people to put some pressure on him to do this =)!

http://bret.appspot.com/entry/experimenting-google-app-engin...

EDIT: I'm not sure who wrote the framework, so I was wrong to say that Bret wrote it. In any case, it was written by FriendFeed developers.

ntoshev• 17 years ago

Please add GAE's webapp.

ivankirigin3• 17 years ago

Tipjoy is my first web project, actually. I started knowing python. I tried frameworks, and quit when something failed. Django was the first to go from start to live test site touch using a DB without a hiccup. I think that means something for both the quality of the documentation and the framework.

TurboGears, web.py, and Pylons failed the test.

The Python community would benefit from more people switching to Django. It does have the approval of the BDFL, after all.

endtwist• 17 years ago

Out of curiosity, what individual problems did you run into with TurboGears, web.py, and Pylons that caused them to "fail the test?"

ivankirigin3• 17 years ago

Shit didn't work. Often something in the DB layer, sometimes just getting a "hello world" in a browser.

liron00• 17 years ago

Slide: Cheetah templates. But we are moving toward making the whole apps in JS

JereCoh• 17 years ago

Pylons rocks my world!

xiber• 17 years ago

Add web2py (it's different from web.py!) to list too.

mdipierro• 17 years ago

not acknowledging actual competitors is a marketing strategy.

danbmil99• 17 years ago

what's a framework?

apoirier• 17 years ago

We use Nagare (http://www.nagare.org) for our most important customers projects, A framework with a very different approach to web development than the classic MVC / url routing / session object / template frameworks.

drewp• 17 years ago

Other = twisted/nevow

garbas• 17 years ago

zope+grok ... +100 and zodb is way ahead of time, if you didnt try it you really should.

Poll: Pythonic startups: what web framework do you use?

Related Stories