Symfony 1.1: Should I be worried?

I read Francois’ most recent view on Symfony’s verbosity and was surprised at his dissent given his core involvement with the project. I can definitely see where he is coming from, as it can’t be easy to write easy-to-digest documentation for such a complex beast. I’m wondering if it is worthwhile upgrading as I’m quite happy with the framework as it stands - don’t get me wrong, the new form subframework is definitely a step in the right direction, but I don’t really like straying far from my metaphorical “comfort zone”.

Decent documentation would go a long way to convince me that a version switch is a good idea, but I don’t think I will find much reassurance if the next version of the book looks like a glorified API manual. I do hope that appropriate features and improvements from the 1.1 branch are merged across to 1.0, not just important security patches. I also hope we won’t end up with a split in the community as a result of the aforementioned blog post..

This entry was posted on Thursday, May 8th, 2008 at 8:20 pm and is filed under 1.0, 1.1, Editorial. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

4 Responses to “Symfony 1.1: Should I be worried?”

  1. jwage Says:

    I really don’t think so. In my opinion the verbosity, flexibility and configuration are good things which allow large applications to be built in an extendable and easy to maintain way. The catch some would say is the learning curve has the potential to be greater for less experienced developers to dive right in. It requires good documentation and a little more api studying and understanding by the developer before being able completely begin to develop rapidly. But this learning curve is small and significant and well worth it in the big picture. I would say that frameworks that are built in a way that is the easiest to understand quickly and has less magic and tools at your fingertips can be less ideal once you begin to deal with larger applications. This is because you are doing a lot of work manually, which could be automated or extended from some base functionality. i.e. forms, lists, models, database abstraction, etc. On the flip side this means that symfony might not make sense for smaller one-off projects due to the higher overhead.

    Just my two cents.

  2. superhaggis Says:

    Thanks for taking time out to comment. :-)

    I’m guess I’m just concerned about how these significant changes to the framework will affect it’s marketability. “Enterprise-ready” is currently one of the hooks used, and I wouldn’t want to see that change to “enterprise-focused” or “enterprise-only”. There are a lot of enthusiast PHP developers out there who get a kick out of Symfony development, and I wouldn’t want them to feel alienated by future design decisions (the removal of RoR-a-like helpers, for example).

  3. halfer Says:

    My first thought, superhaggis, was I think the same as yours: uh-oh, a split in the community. But I don’t think Francois’ post is indicative of that, and I know Fabien and colleagues will take the criticism with good grace. After all, they’ve been fairly bulletproof in the past, given the number of negative comments thrown at the framework/docs/whatever by struggling users, in the fora and from elsewhere!

    It will of course be interesting to see where Fabien and co take the framework, but if Francois’ core point is that “a few proxy methods to help non-expert programmers won’t hurt the codebase”, then I’m inclined to agree with him. I can’t see how adding a bit of “polish” is going to hurt extensibility at all.

    Off topic: if you want to encourage commenters here, then I’d suggest turning off the registration feature, and have a captcha instead. People generally won’t bother with the hassle otherwise, imo :o)

  4. superhaggis Says:

    The “proxy method” suggestion is a great one - you can never have too many wrappers! :-)

    Point taken regarding blog registration! Cheers!

Leave a Reply