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.
I've
been given the chance to review the new Typo3 Multimedia
Cookbook
that Packt is publishing. Right now it should be in the mail on it's ...