The venerable Uncle Bob wrote some thoughts on picking a framework:
Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?
I’ve quoted the end of the post, but you should read it in full, it’s worth it. I agree with most things in the article. You should constantly learn stuff and try making the basic functionality yourself to get a better understanding of how things work.
Though there is certainly truth to it I don’t fully agree with: “Before you commit to a framework, make sure you could write it.” It’s good advice when you’re very experienced or if you have time enough to investigate lots of stuff. For most people this isn’t that case.
When starting out writing PHP almost 10 years ago I made my own little framework because I didn’t know any better. I thought I was doing fine. Looking back at the projects I made with it, I’d say they’re all horrible.
Zend Framework 1 came out. It sped up my development because I didn’t have to do every little thing myself. Did I understand everything ZF was doing behind the screens? Certainly not. Did ZF create value for me right from the start? Hell yes. While using the framework on various projects I read about how it worked and learned a lot about PHP. I thought I was doing fine. Looking back at the projects I made with it, I’d say they’re all horrible.
A few years ago I read some positive articles about Laravel. I really liked the syntax and the feel of things. Sure, it was a gamble to choose a framework I didn’t know but it worked out really well. While using Laravel I learned, thanks to some excellent learning resources, lots of things on design patterns and best practices.
It’s certainly possible that, in the coming years, Laravel will be replaced by a new shiny framework. Maybe I’ll then write a post on Laravel saying “I thought I was doing fine. Looking back at the projects I made with it, I’d say they’re all horrible.” .
Generally speaking I think the following applies to most frameworks and most programming languages:
- When you see a framework / language that feels good to you, read a bit a about it.
- If you still feel good about it, use it on a small project
- If after that project you still feel good about it, use it again, maybe on a bigger project. Learn a bit more how framework and language works.
- Repeat steps 2 and 3 until you find yourself at step 1 again.
The most important part is the learning in step 3. If you don’t do this you’ll be a programming cowboy forever.
Of course all of this depends on context. I would never pick a technology unknown to me when starting to work on a large and expensive task. Learn and experiment when working on small projects. Use what you have learned on the big ones.