I prefer to start small, and add libraries as I need them.

For example, for my current project I was at the point where I needed to add authentication/authorization, preferably with openid support and fallback to a simpler system for development/test installs. I've been able to implement most of this with very little effort by using repoze.who and repoze.what (python). They're flexible enough to do a few things which would be harder to do in a framework where components are written to interface with other parts of the framework, instead of being really generic.

Apart from those two libraries I use beaker for sessions, werkzeug for dispatch, couchdb as a database, mako for templating, my own forms library, etc..

Basically I put together my own framework from already existing components, with a few components of my own for those tasks where I feel the existing solutions aren't good enough or don't solve my problem.

With this approach it does take longer to get up to speed, but you're not tied to any particular way of doing things and can replace any part as needed.

* Mod_wsgi - standard (and imho best) way to connect code to a web application.

* web.py - a framework for people who don't like frameworks. It does exactly what you want it to do and then gets out of the way.

* SQLAlchemy - the benefits of a smart ORM, from being able to define a Model in native Python to the baked-in protection against SQL injection attacks, more than justify the cognitive overhead involved in learning it.

If what you make is limited in scope and you can easily handle the worlkload then more power to you. But I find that for me it is more efficient to reuse well written code, even if that means I can't claim I wrote 100% of the project.

If a framework limits you, then that is a good reason to roll your own. But that comes at a price, maintaining a codebase is not without cost.

Maybe if there are libraries for all the needs in your language, it is doable. But it seems a bit of a headache. I am not sure I even want to waste time on thinking about my own framework. It is not the most interesting problem (how to write a web framework).

It's extremely unlikely that it'll be improved by someone else in exactly the direction you need it to be improved based on your particular use case.

Depends how important it is to your success though.

I started implementing my own .auth library before I found those two. repoze.who is exactly what I had in mind for an authentication library, and much better architected than my own solution. I don't use any of the existing plugins (apart from openid), so the real win for me is the improved design compared to whatever I could come up with.

I'm sufficiently experienced in Rails now and don't regret it at all. It is quite heavy for your average website, though... For this reason I tend to use Sinatra for lighter stuff (my personal website, etc) since it doesn't give you anything except it's base DSL for handling requests. I end up re-implementing tiny parts of Rails, but which part depends on the project and I tend to re-use those parts I've re-written often.

If I could start my big, main project again, I would still use Rails -- no question. Tool support is a huge part of a big project, and Rails is ready.

I have been missing Perl a little, though, and Mojo feels really awesome (and quite Sinatra-like, a good thing :)), so I might convince myself to go that direction sometime as an experiment.

Links:

- Sinatra - http://www.sinatrarb.com/

- Rails - http://rubyonrails.org/

- Django - http://www.djangoproject.com/

- Catalyst - http://www.catalystframework.org/

- Mojo - http://mojolicious.org/

I'm a Microsoft guy and have been for 12+ years. When .NET Framework came out, that's just what I went with.

Was your ultimate choice made simply because the framework was the defacto in your language of choice?

No, I chose it because it was going to be popular in the MSFT community and, as a consultant/trainer for MSFT technologies, it's my job to know those things.

Assuming you're sufficiently experienced in framework X now, what are your regrets? What makes the other frameworks look like greener grass?

No regrets - it's "good enough". And nothing makes other frameworks look better to me. I can see how they look better/interesting to others but, for me, I'm happy with the .NET suite of tools/languages.

If you could start your project over again, would you chose the framework again?

Yes.

Did you choose framework X secretly because you just wanted to learn it?

I sort of answered this already - chosen because it was destined to be popular with my clients. At the time (2000), MS was putting tons of weight behind the marketing campaigns for .NET Framework and C# so you knew it was going to be supported. And, after coming from Visual Basic 6.0 and ASP, looking at the .NET Framework and ASP.NET - it was easily miles ahead of what we were currently able to do without .NET.

I started my web development career on asp.net but now that I have experience with django I wish to never see another line of asp.net code again.

Not an uncommon sentiment though.

Was sold in less than an hour of reading.

Accessibility, features, technology (i.e. is it up to date with the latest language features), development (looking for highly active development)

Was your ultimate choice made simply because the framework was the defacto in your language of choice?

No. However I did reject some other language frameworks because of having ot learn the specifics as well (RoR for example).

Assuming you're sufficiently experienced in framework X now, what are your regrets? What makes the other frameworks look like greener grass?

Most of the regrets are about the development. I chose KohanaPHP which is a solid framework - and but of a power user one (lowish documentation but very powerful once you get to grips). The problem is that they scrap revisions so easily - version 2 is ending it's lif cycle after a very short time frame and V3 is a complete rewrite using HMVC ideals (as opposed to MVC). Porting to V3 is something of a pain (mostly Im not going to bother while V2 still suits my needs). There are also outstanding bugs in the v2 framework that need ironing out and it's looking like they might not all be done.

Also there is sometimes a tendancy for it to bottle neck on some PHP versions / installations - I have not yet tracked down why but it is concerning me more and more.

If you could start your project over again, would you chose the framework again?

Yes I think so. I started on Code Igniter and Kohana was a more actively developed fork of that (later fully rewritten) so I was versed in the syntax and so forth.

It is a powerful framework.

Did you choose framework X secretly because you just wanted to learn it? In other words, was it attractive to you just because all the cool kids were doing it and you wanted to add it to your toolbox? Be honest.

Honestly - no. I used Code Igniter after a recommendation from someone. After finding it frustrated I heard from a forum post about Kohana and how it got rid of those bugs - and it did. At the time the cool kids were going with RoR - their website instantly turned me off at the time so I never bothered.

For blog variants I have mostly used Drupal and I have a couple of blogs using Wordpress. Don't underestimate the power of both of them and that is one reason why I am still sticking with PHP for the forseeable future. I can attach a Wordpress installation to a CodeIgniter framework and with very little additional work, I can have a blog working - albeit with ugly code! After all wordpress is only 10 tables, Drupal is about 50.

I'm about to start a new project, and thought I'd settled on CI as my framework of choice (never coded w/ a framework, so trying to get it 'right' on my first try), but some of the comments I've read here and elsewhere have me second-guessing my choice.

CI is just not updated enough IMO to form the stable base for an app.

As for taking it beyond blog content - I've created all sorts of complex sites; for example featured realtor website (property search, user management etc.) a wiki/"stackoverflow similar" site and am also working on a twitter "ticket" and marketing site (which is pretty complex). So it is suited to stuff like that.

I tried RoR before it had hit version 1 and the only documentation was the prag Prog book. Looked through the Zope and Django documentation and found the documentation to be better quality. Django just fit my mental model better so that is what I went with. I don't regret the choice, sure I have found some corner cases where I and it haven't agreed but that happens any code that you don't write from top to bottom.

We went with CodeIgniter on an outsider's suggestion, and in retrospect, it was probably not a great choice. We've found a few weird things in their core classes that we've had to modify, which should never happen. I've used Zend since that project and I greatly prefer it over CI. The documentation can be a little funny (explanations of functions are in places where you wouldn't expect it) but overall I've just found it to be much more robust.

I've heard good things about Kohana, so I think if I were to start a new project, I'd look into it. I think my biggest concern would be being able to update the core classes without having to rewrite all the code, so what ErrantX said here about Kohana going from MVC to HMVC is sort of worrisome.

Another criteria I used was to just browse through the quickstart and reference documentation and look at code examples. How complete were they? Did the accompanying description make clear what all options were available? Could I imagine adapting this code to work with our system? If the documentation was crappy, I was likely to give it a quick pass. Maybe a bit unfair, but a project that hasn't put in the time to make the docs shine has probably left some rough edges in other, less-obvious places (plus if we adopt it, I have to read that crappy documentation every week of my life).

I ended up going with Zend, and haven't regretted that for a second. It's been quite easy to take the pieces of ZF that are useful to us and use them together or in isolation. The libraries are great, the documentation is (usually) wonderful and complete, and it all just works.

very clean internally framework code. not necessarily large user base. something where the original devs may likely still be using their creation within the next two years. lightweight. no magic!!!

* Was your ultimate choice made simply because the framework was the defacto in your language of choice? In other words, did you choose Rails for Ruby, Django for Python, Cake for PHP, just because the language itself was what you knew?

Two years ago, I wanted ruby, but not rails. I settled with rails and moved on to merb once that was available.

* Assuming you're sufficiently experienced in framework X now, what are your regrets? What makes the other frameworks look like greener grass?

I have a background in writing and choosing frameworks. So I knew rails was not a fit before I used it but it was all there was if I wanted to go with ruby. Merb still is a fit despite its relative neglect this year. I have few regrets continuing its use.

* If you could start your project over again, would you chose the framework again?

I am doing a new project now, I'm using merb again because I have invested in it and it works well. If I were to move on, it would be for a javascript framework as I should benefit from javascript client and server. Such js frameworks are not mature enough for my needs.

* Did you choose framework X secretly because you just wanted to learn it? In other words, was it attractive to you just because all the cool kids were doing it and you wanted to add it to your toolbox? Be honest.

no. I'm cool enough as it is ;).

I got tired of working on dozens of authentication/registration systems, or admin interfaces with sortable tables ... that's boilerplate that distracts you from the purpose of your project.

I'm currently using Catalyst (Perl) for heavy-weight projects. I like that I have CPAN modules at my disposal.

I'm also playing with Django (python) ... I like that it has already built independent modules (see Pinax / django-cms) and a customizable admin interface. It also has very good (free) documentation. I always wanted to get familiar with a CMS platform like Drupal, but I haven't found any that I liked, and Django seems like a good alternative.

I don't like Rails because currently it is too monolithic. There's no way you can replace ActiveRecord with little effort without losing functionality. It is also too heavy for my taste and makes too many assumptions about my application. Of the projects I worked on this year, none of them fits the Rails model.

I took a look at Merb (Ruby) and it looks good. But it doesn't have a large following. Version 2.0 will be merged with Rails, so Rails 3.0 looks promising.

I don't care about language choice as long as I like the language :)

In decision making there were a number of different aspects I considered first. The two largest were the community and documentation for the framework. Many of the other frameworks lacked documentation or a large supportive, and knowledgeable, community. Symfony is known to have quite a large learning curve, but it offers multiple 24 hour tutorials to get you acquainted with it(Jobeet and Askeet). The IRC and Forums community are very active and more than welcoming to help anyone with questions.

Every framework has a few special features that others do not, however Symfony's plugin base is very large and often helps make the other framework's grass not as green.

If I could start my projects over I would still choose Symfony, however on a couple I might choose to implement them in a different language which is more suited for the project.

However, to continue using a framework, my top criteria are low (or no!) boilerplate and whether it keeps its hands off my SQL and templating.

Looked around in the J2EE space and found grails which was;

A) Modelled after ruby on rails conceptually B) Constructed from a large amount of best of breed components in the respective sphere which addresses that piece of the framework, like Spring and Hibernate. C) Had a language which didn't make me want to tear my hair out.

I'd actually never used groovy, which is the language that the grails framework uses internally, before, but found it to be easy to adjust to having a fairly good grip on the general digital polyglot, and having the ability to mix and match with java code has been very eye opening just because of the sheer volume of ready made solutions to the vast majority of problems out there.

To be honest the thing I hate the most about grails is stack traces, they're ridiculously verbose, huge, multipage sprawling monsters, and there's really not much to complain about aside from that.

If I could start my project over again and the need to have it work in the J2EE space was not there, I'd be very hard pressed to say if I'd choose grails or django, both are spectacular at what they do, with their own unique advantages and disadvantages.

I didn't choose it because I wanted to learn it, I was already very familiar with the paradigm and it was obviously the right path forward in terms of getting some rapid app dev processes in place for this organisation, mostly I just wanted to show people what was possible, rather than building apps with string concatenation and manual sql with selects by row and index ( I shit you not ) while staring at AJAX and the general web app environment with increasing confusion.

And it blew my mind how easy it was. And how well architected. And how it took me a tenth of the time to make a website/app

I've chosen it for every project I've had a say in since - absolutely no regrets.

In terms of framework envy, I've tried out a few others. Rails seems nice, pretty equivalent to django, but I haven't really any desire to learn ruby - it seems too similar to python.

I've also played with stuff like web.py etc.

One of the advantage with django's full stack is that it 'just works'. While it is undoubtably a big framework, if you get in the right mindset you can develop ridiculously rapidly.

Why my own? It's simple, does what I want and does it well, and when it brakes it's my fault. No learning curve :p

http://news.ycombinator.com/item?id=712975

http://news.ycombinator.com/item?id=750142

I found myself in much the same position, so I read all those same links asked a bunch of questions and settled on Django (for now, we'll see how I feel in a couple of weeks).

The decision making process consisted of listing all the contenders, reading as much as I could about them then asking a few HN'ers in private what they would pick if the choice were up to them.

I got some pretty interesting replies, but the most interesting fact was the common 'thread', Django and ruby/rails were mentioned by just about everybody that bothered to answer, Cake by quite a few.

Other technologies were mentioned too (lift on scala for instance), but were either still very immature or had big strikes against them right from the get go (personal ones, technical ones).

So that settled the basic question for me, now the hard part was to choose.

The key decision factors for me were:

- the possibility to migrate to the jvm at some point, which means I could use some of our investment in the large number of tomcat servers we've got deployed (don't ask).

- the python language, which seems to be a more universal and widely supported language than Ruby, I do a lot of other progamming besides web stuff and the availability of all kinds of third party modules and code really helped here.

- GAE support

- the fact that I had already done a little bit of python programming definitely helped but I would have been more than willing to learn any language.

Cake looked very tempting, I have about a decade invested in PHP, and if the language were the only factor then I would have probably gone with Cake.

I'm not 'sufficiently experienced in framework x' (this has been going for about 5 days now). I chalk up most of my frustration so far to being unfamiliar with the tech, in half a year or so I'll be able to make a more reasoned statement on that.

If I could start again, I'd probably reach the same conclusion because I'd apply the same method, sure there is some frustration but there always is when you're learning something new.

Your last 'be honest' question, no, rather the opposite, I have some pretty major issues with Python (that bloody whitespace thing, it's just too much of a hassle, significant whitespace was a bad idea in makefiles, it is not much better in a programming language). But I feel that the platform has enough momentum to justify my investment in time and other resources.

During the installation procedure (django/wsgi/apache on Etch) I ran into a bunch of snags, if you decide to go this route and you are using the same or a similar platform then let me know.