Well, I know someone was waiting for this post, so after my usual Wednesday RPG night, here I am trying to sum up some months of squealing brain gears and subsequent mumbling.
Let’s do away with it from the start: Symfony2 lost. I’t not something I like to state, but in the end, what turned up is that (at least for us) this version of the framework doesn’t help us raising our productivity.
Why? Easy-peasy, compared to other solutions Symfony2 suffers following flaws:
- High cost of project setup.
- Even if framework components are loosely coupled, still they are coupled; trying to decouple them results in a shitload of work (doing it right) or a shitload of hassles (doing it wrong).
- Documentation is still far from perfect and given they sticked to The Book & The Cookbook model, it will probably never be.
- Steep learning curve; this could not be an issue until you’ll have to face with recruitment or (even worse) relying on external professionals.
- Above points sum up into the possibility to reach dead-ends.
In the end, Symfony2 is a very expensive framework. It’s not bad per-se, quite the opposite! It’s steady, complete and well engineered. But…
"Beam me up, Scotty."
"Sure, Captain! It will suffice to send a signal to plasma injector, so that power units could be heated enough to activate ray caster. The ray will analyze your body, reading you molecular structure and instructing the computer to encapsulate it into a tachion-field which will then be destroyed while your atoms will…"
"Oh my… Scotty, just press that fucking button!"
Web is a moving target. A fast moving one, actually. That’s why we as web-designer have to react quickly. What’s the point in using a tool which completeness is mostly a burden?
Read carefully, I’m not whining about having complexity to deal with. I’m talking about having complications. Put it this way: I don’t fear complexity in problems. I fear complexity in solutions.
Web framework panorama is full of steady and simple solutions that enhances productivity. I’m currently drooling for RoR but I know it won’t last forever. Yet from what I scratched from its surface, it’s a good example of a tool which completeness doesn’t get in the way.
Web framework panorama is also full of steadier thus complex solutions that enhances other aspects of perceived product quality: code durability for example. Spring and Hybernate are examples of this. Symfony2 is another.
Aside every personal consideration, what a startup as Agavee needs is not to build leviathans of documented majesty.
He makes the depths churn like a boiling cauldron and stirs up the sea like a pot of ointment. Behind him he leaves a glistening wake; one would think the deep had white hair. Nothing on earth is his equal— a creature without fear. He looks down on all that are haughty; he is king over all that are proud.
The goal is to deliver high quality web-applications to happy customers, on time. Yesterday @cirpo pointed me to Getting Real, a book that we could resume as “Do less (code), provide more (value)”. To make this more digestible to average coder: giving a fixed amount of value, the less lines of code, the more value you get per line.
Say captain, say wot!
S0 w0t? So, what we ended up with is CodeIgniter 2. This is not a perfect solution and I state this clearly. CI2 is a flexible, fast, pretty complete and stable framework. Since version 2 it’s community driven, and it is growing well, thanks to Sparks also.
So why do I say it’s not a perfect solution? Well, despite I’m pretty fond of it, what I feel is that, for our needs, it won’t stand the test of time. Actually if we were all experienced rubyists or shrewd pythonistas maybe we’d go for well known big names in that ecosystem. But that’s not a step we’re ready to do.
So my forecasts is that soon or later we’ll need to get some more from a framework than basic code organisation, a set of classes and some conventions. Maybe CI will grow faster than we’ll do. Maybe not. The important thing is that it provides a way to be productive now, an affordable learning curve, solid structure and high performances at the cost of some more coding (but what the heck, we are coders!). We’ll then collect experiences and wait for our customers and our own ideas to teach us what our tools will have to be tomorrow. In the meantime this will hopefully leave us a lot more time to spend learning something more advanced. Who knows? ;)