For a new project I am using Doctrine2, Twitter Bootstrap, Jquery & JqueryUI, and Backbone.js & Underscore. At first I figured I'd try out Symfony2 and Yii, to see if maybe they could kickstart the project and get me most of the crud functionality - but while both of them probably could provide quite a bit, they also both provide way more than I need. And worse still, both of them force me in a given direction.

Maybe it's a question of already having a set of bad habits that I really should do away with, but it very often feels like I spend way too much time working against a framework. Yes, it does indeed enable doing some things faster, and typically the way of thinking is not too far from what I do anyway (Symfony2 is MVC oriented, as is CakePHP and CodeIgniter, which I'd also consider using) - however for the project I'm doing now I really just want to throw some minimal code together and get some functionality going, and both Symfony and Yii got in the way of that by insisting on too much configuration or giving me things I don't need (Yii presented me with a boiled down phpmyadmin interface - what the hell do I need that for??).

So instead I'm opting for including libraries in my project and just using them as I see fit. Instead of dictating my code they become building blocks, and then suddenly they do enable faster work. Of all the libraries included here, I think jQuery and Twitter bootstrap do the best jobs - the documentation is solid and they really get out of the way. Doctrine2 is doing pretty good too, but it's harder getting it to work properly for you. Also, it has more hidden snags than the others, but seeing as it's also a more complex entity that's par for the course.

Backbone.js in particular could use some work, though.. The documentation is rather poor, to be honest - it details the functionality of the library but doesn't actually show you how you're supposed to build with it. Instead, the creators just link to various projects built with it. This has the sad consequence of you finding better documentation about the library in a three-part blog post than on the page of the library itself. Specifically, I've based my new project off of the blogging by Christophe Coenraets about a wine celler project.

One can of course argue that learning by example is the best way to learn but that is, quite frankly, rubbish. Actual apprenticeship means learning from a master (i.e. someone that knows the right way to do things), it doesn't mean gleaning information from a blog and then putting pieces together. An example of the problem: I have once before tried to create a project with backbone.js, thinking that it would be a good tool for my specific problem (managing a good number of model-entities in javascript). However, the project ended up slow as hell, soon as you had more than just a few models working. Why? I have no idea. And that's the real problem: I don't know what I did wrong in my use of backbone.js. I don't even know how to check if I made typical errors or if I did in fact use best practices for backbone.js. Because the documentation for the project is sparse, at best.

This could be a good reason to get involved in the documentation of backbone.js, but for me this project was really supposed to be about getting my idea done - not about spending a good amount of time getting to know how libraries work. Not that I mind spending some time getting to know a tool, mind you, but that's just not what I wanted to do this time round - I can spend plenty of time on that as soon as I have a prototype up and running, but before that it just drags out the project and takes away energy.

Moral of the story

There are two kinds of projects (and then all things in between, but anyway - two extremes). There is the "I'm building something cool and learning a lot while I'm doing it - I want everything to be done right". And then there is "I'm building something cool and really want to get it finished so I can use it - I want everything to work right". When you're doing the second thing, having to learn a new tool extensively is just a pain - that's the main reason taking up a new framework for a project you just want to finish quickly is a bad idea.

To get the best of both worlds you need to think about which type of project you're actually working on: do you mainly want to learn new tools or do you want to get that idea done? If you don't give it some thought before starting out, you'll end up with halfbaked projects - and that's just no fun at all.