Ask HN: Why do you use framework X?
17 comments
I'm not a fan of frameworks, if their particular philosophy fits with the way you think, they're probably great. For me, they just don't seem to fit and provide a lot of bloat.
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.
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.
Likewise, I code in Python with mod_wsgi, web.py, SQLAlchemy and a library I've built up of common classes and functions:
* 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.
* 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.
I was very much of that opinion before as well. But I've since come to change my mind. I'd like to concentrate on those parts that are unique about the application that I write, not the stuff that every application has to do anyway. This takes a lot of time and effort to maintain, especially if you want to stay 'current' and want to compete with the rest of the market.
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.
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.
I sympathize, but there seems to be so much stuff that goes into a web framework. One of these days I want to make a list, to help deciding on "create my own" vs "external".
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).
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).
I agree with your points, although i ended rolling with pylons as the foundation. It allows me to add extras such as gzip wsgi layer, secondary dbs (tokyo and mongo), and roll my own custom routes with little effort.
Completely agree. The best framework is one you've built yourself IMHO.
The best framework is the one you would have built yourself, but which is improved and promptly bugfixed by someone else. :)
I still disagree. Frameworks are usually multipurpose general 'jack of all trades master on none' type things. Unless you've built your own based on some specific use case(s).
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.
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.
... except where you have new employees who need to use it, and you don't have any documentation. This is, to me, the one of the best parts about using Django or Rails--the ramp up time for new hires is lessened by being able to hire experienced developers in "framework X" from the get go, or when hiring juniors one can simply point them at a tutorial.
I forgot to ask. I haven't had experience with repoze. Do you like it? Do you prefer it instead of rolling your own?
Well, I've only used repoze.who and repoze.what.
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 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 generally decide on a framework project-by-project. I started off with Django because I was experienced with Python. The project went ok but I found, as most people seem to, that when the code started growing more organically (often called 'maintenance mode' :)) it got real ugly real fast. I went looking for an even more dynamic language than Python, stayed with Perl for a while (Catalyst) and eventually went with Ruby (Rails, specifically).
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 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/
What was your decision-making process when evaluating frameworks?
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'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.
Have you ever used a different framework?
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.
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.
I did ASP prior to ASP.NET but nothing but javascript and HTML prior to that so, no. I do use jQuery outside of ASP.NET/.NET if that matters. I've debugged code in other languages but no dev.
I've heard this comment from others before - but alas, I cannot echo it as I haven't had experience with anything ASP or .NET related.
Not an uncommon sentiment though.
Not an uncommon sentiment though.
http://www.djangobook.com/en/2.0/
Was sold in less than an hour of reading.
Was sold in less than an hour of reading.
What was your decision-making process when evaluating frameworks?
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.
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.
I use CodeIgniter extensively and have also tried Kohana. How did I get there in the first place? I believe that the best code you can find is the one you can write, however, I only have one life and not enough time to rediscover the wheel, so I went for the second best and decided to use CodeIgniter as was closer to what I wanted in that being a smaller framework I could mould it around to what I wanted to develop. Before selecting it, I downloaded CakePHP and gave it a try, it was just too big a framework for me. Have I got any regrets not really, would I use it again, yes but at least this time it comes with all the additional bells and whistles that I have attached to it. In reality the more you use a framework the more you .. forking it out towards your own needs and style.
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.
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'd be interested in hearing how well-suited CodeIgniter is for a web-application that will be brought FAR beyond just presenting blog-like content. What I intend to build will be a full-blown web-based app.
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.
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.
I'd heavily advise ditching CI and hacking around with Kohana Version 3. Despite my misgivings it is super fast, super extensible and extremely powerful.
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.
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.
Cool. I'll give it a look. Thanks so much for the reply.
Documentation plain and simple. If someone can't be bothered to document it, then I can't be bothered to use it. If two libraries have good documentation then you read up on both and decide which fits your mental model better.
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.
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.
My company's big project right now is built in CodeIgniter. We picked a framework for a number of reasons, but mostly as a way of standardizing the code. Rather than everyone having some arbitrary way of doing something, we found it easier to use a set framework with its own conventions, at least in terms of naming schemes and file structure and whatnot.
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.
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.
One of my biggest criteria when I was looking at frameworks was how much each one wanted you to "drink the kool-aid." I'm not saying it's a bad thing to have conventions built into the framework to make developers' lives easier, but some frameworks really demand total commitment to their system. Since I was looking to slot the framework into a very large existing PHP codebase, I knew we couldn't immediately start doing everything "The _____ Way (tm)."
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.
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.
* What was your decision-making process when evaluating frameworks?
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 ;).
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 ;).
For me I based my choice on modularity, available components and available documentation.
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 :)
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 :)
There are quite a number of people who don't like activerecord. They usually swap it with datamapper. Search on github for "rails-template", its recipe for settinf custom rails.
I have been using Symfony for about 3-4 years now. I knew I wanted to use a PHP framework when I first started looking into frameworks because it was the language I was already very familiar with.
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.
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.
My top reason for using a framework for a new project is typically that I want to learn it. Since I worked for myself for most of my developer career so far (but don't any more, to be clear), that wasn't a problem.
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.
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.
Bought in to work on an in house framework that was to be fair quite outdated, needed to find something that would fit the same space as the technology it was replacing (Basically Java + J2EE) but at the same time wanted something that was friendly to rapid app dev + agile, had used Django extensively before but obviously not a possibility here.
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.
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.
I started using django a few years ago. Previously I'd been using php and had built up my own 'framework' of tools. I'd learnt python though, and loved it (perhaps the finest language in the world) - I'd heard some talk about django and thought I'd give it a go.
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.
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.
Oh, and I forgot to mention the community (which is amazing - very friendly), the job opportunities, and the brilliant documentation.
My own, java + apache velocity. In the process of switching to compojure.
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
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
I look for a framework which satisfies 80% of my criteria. This saves me about 20% of the work.
clickable links:
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.
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.
Because I wrote it.
* What was your decision-making process when evaluating frameworks?
* 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?
* Assuming you're sufficiently experienced in framework X now, what are your regrets? What makes the other frameworks look like greener grass?
* If you could start your project over again, would you chose the framework again?
* 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.
Thanks!