Live data from Hacker News

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

news.ycombinator.com

71–76 of 76 posts

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

#72
post #54

Earlier quoted context omitted.

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?

Zope's main problem is one of branding. Zope3 is really an entirely different beast than Zope2, but the sins of Zope2 (chiefly a monolithic and deeply intertwingled codebase that meant you mostly had to swallow the kool-aid to use any of it) have continued to plague Zope3's acceptance, even though Zope3 doesn't have the same problems. Still, Zope3 requires a bit more mental overhead due to the infrastructure it conta…

Here are two interesting related videos.

First, what Django can learn from Zope: http://www.youtube.com/watch?v=fipFKyW2FA4

Next, what Zope did wrong and how it is being fixed: http://www.youtube.com/watch?v=iAsa1P9Dvd0

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

#73
post #25
post #15

Earlier quoted context omitted.

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.

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 th…

In most cases you're well served by making sure:

a) You have a reasonably-sized developer team

b) They document and test their code

c) No single developer 'owns' any part of the code

That should ensure that your developer team's "bus number" is reasonably high.

Finally:

d) You treat them at least well enough that you're not in danger of the entire team quitting at once.

That said, it can still be useful for many reasons if they base their work on F/OSS code (languages, libraries, tools, frameworks, etc.) that has a reasonably-sized community around it. But if the developers you hire are good that is very likely to happen naturally.

There are always circumstances where writing your own may make sense in the short-term, but unless it has something to do with your business' core-competencies, or otherwise leads to a sustainable business advantage, you're usually well advised not to bother.

Post reply on HN