I'm using web.py. I really didn't want something like Django or even Pylons where it feels like you're programming to the framework and not to the language. In my experience (with other frameworks), this leads to a really quick 80%, and then you get really screwed over as you try to complete the remaining 20% and have to fight the framework all the way.
I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.
That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can see your startup running and adjust from there. It's basically a prototyping tool.
IMHO, startups should not be using any framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something new that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.
you lost me with that last paragraph, to put it nicely.
your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.
while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.
Thing is - I don't see frameworks solving these problems. I see frameworks doing things like automating directory layouts, adding some magic to reduce typing, handling request dispatching, etc.
I see libraries solving these problems. I use Cheetah too, and am grateful for its #filter Websafe. I use Markdown - it has the same javascript: bug as Reddit, but at least I or someone else can submit a patch to Markdown and have it fix every site using Markdown and not just my own. I use the parameter replacement available within DBAPI to avoid SQL injection attacks.
I don't like software that tries to solve all my problems, because it inevitably mis-guesses and solves about 80% of them, making the remaining 20% pretty hard in the process. I like software that tries to solve one of my problems and solve it well, because then I can swap in the best solution for the job. Fortunately, the newer Python frameworks (Pylons?) are going down that road, but I didn't see much advantage in using Pylons over using DBAPI + Cheetah + Prototype + Web.py dispatching.
Can you explain to me how unsexy problems like browser incompatibilities (yes a major pain) lie anywhere within the scope of webpy? Those seem to lie within the scope of the templating system and js library that you choose.
A larger, more complex framework does present serious problems when you have to architecture everything in strange ways to meet scaling needs or otherwise.
Note how much the twitter guys were so scared by ROR's complexity that they resisted doing the most trivial modifications? I want to understand my framework "all the way down." This is much the same reason I use linux.
Exactly. Webpy is for programmers, django for people who want to feel like programmers, but are really just walling themselves into pre-defined ultra-boring patterns.
And real computer scientists only program in machine code because everything else is a shortcut, right?
So you're saying that since web.py fails to provide a solution to common problems, it gives "real developers" the freedom to implement it themselves? Pesky frameworks like django only allow the same developers to jump straight to doing new things. Uh, that must be the pre-defined ultra-boring pattern.
I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.
That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can see your startup running and adjust from there. It's basically a prototyping tool.
IMHO, startups should not be using any framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something new that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.