A few weeks ago I had the great pleasure of speaking at WDC 2011. WDC is a great little conference in Bristol, and I have had the pleasure of speaking a few times now. One of the things I advised in my eclectic, meandering talk was to ask people what frameworks they used, and find out why they chose them. A few people have since asked me to elaborate on how I ended up using Rails, so I thought I’d write up a few thoughts on the frameworks I’ve used in the past, and what I’ve learned.
Way back in the day I was an HTML/CSS developer – cutting and slicing PSDs into workable HTML. I started playing around with PHP when a couple of my friends introduced me to it. include() was the weapon of choice – imagine how much time I could save by including the same tiny templates everywhere! This was a revelation, and like most of the decisions I’ve made, closely linked to being lazy.
I think being lazy is a positive attribute for a developer. The lazier you are, the more likely you are to do work to avoid later work. If you find you have to do the same tasks every time you start a new project, for example, you might automate those tasks into a script, saving you loads of time in the long run.
That was why I moved to CodeIgniter when I discovered it. Here was a small framework, without many dependencies, that was easy to get into and fairly straightforward. And it was great. For simple apps, I knew everything that was going on. CodeIgniter saved me loads of time and frustration doing the boring bits.
One day soon after, I saw a friend using Symfony properly, and the sheer power available blew my mind. When I started working with James Mcglinn at Eventfinder, I discovered that learning Symfony was nothing like learning CodeIgniter. It was hard.
Wherever there’s magic, there’s a lot of work involved in learning the rules. A lot of people have told me that they don’t like the amount of magic that goes on with Rails – and that’s fine. But I think it’s a bit of a silly argument. It’s like saying there’s too much magic involved in using cars, and that’s why you ride a horse. It’s called magic because it’s like a magic trick – it makes something complicated and difficult seem effortless. But a lot of work goes into every magic trick – and you’re bound to get it wrong a few times.
When I moved to the UK, I worked for a company with a Rails application. I’d heard how good Rails was, and how it was swiftly becoming the next big thing, so I wanted to learn it – and here was a great opportunity. For future reference, never try and learn a language and framework when building on a brand-new application that supports an entire company. That was a bit hair-raising.
Learning Rails was a bit like learning Symfony. All the concepts were still valid, but the implementation was different. Everything that should’ve been in a certain place was somewhere else. Ruby is a much nicer language than PHP, though, and that makes quite a difference. PHP is a bit slap-dash and inconsistent, and it continues to soldier on in a haphazard fashion. Ruby and Rails, though, are both built with a final product in mind. This was the key difference for me – Rails seemed to be striving towards a really nice way of doing things, and Ruby provided a really nice language for it. In contrast, Symfony seemed to wrap a framework around the most available language. Both are great, don’t get me wrong – but that’s one thing I prefer about Rails.
The important thing to remember along the way is that you can do it. Other people have learned to do these things, and while they be very smart people they’re certainly not orders-of-magnitude smarter than you. You’re perfectly capable of doing it, but you’re afraid of the unknown. A new language, a new syntax, funny brackets where they shouldn’t be… it’s frightening. You just have to remember that good things take time. You’re not going to be great overnight, but if you work at it for long enough, it’s worth the slog in the end.
Log in with Twitter to comment!