Note: This is part 1 in a series on Laravel Application Development at ArcStone
My favorite part about being a web developer is the fact that this industry never stands still - you have to constantly keep up with the times.
Almost a year ago, I wrote a blog post about the backend frameworks / CMSs we to use here at ArcStone. Well, one of our core values is "Evolution," and so perhaps it should come as no surprise that that post now needs a little updating.
We still recommend WordPress for a lot of our clients who need content-driven marketing sites for the same reasons as before. It offers too much out of the box to ignore, including an intuitive admin dashboard and instant access to thousands of free (or inexpensive) plugins for pre-built features. When a plugin isn't available, we've been able to build surprisingly robust functionality right alongside custom themes.
But for more complex, data-driven applications, we have shifted from using Symfony1 to Laravel 4. We've also got a special internal project in the works that's built on Node.js, but that's a topic for another day. Today I want to talk about Laravel 4 and why we chose it for application development at ArcStone.
Some Backstory: The Symfony Project
ArcStone used the original Symfony1 framework for many years until it was finally eclipsed by Symfony2. In the PHP community, Symfony2 was more or less revolutionary. Unlike PHP frameworks that came before it, Symfony2 focused on "decoupling" - using code that you can easily swap out for other code: code that doesn't know anything about the other code it's working with. Decoupled code is more flexible, easier to maintain, and easier for other developers to re-use in different projects.
Symfony2 is so decoupled, in fact, that it's partly advertised as a set of standalone components. (A "component" is just a bunch of code intended to perform a specific task.) One component handles security, one handles email, one handles visual presentation - and on and on and on. The security component doesn't care what the email component is doing - each component is only concerned with handling its one specific domain. This principle is called the "separation of concerns", and it's all Symfony's founder cared about:
You can use any Symfony2 component in any other project without the rest of the framework (more or less). And if you're building a Symfony2 project, you can swap out any Symfony2 component with whatever else you want (more or less). You can even create your own framework on top of Symfony2 components. In fact, that's partly what's going on in the design of Laravel 4.
A Challenger Appears: Laravel 4
Laravel had already seen a lot of early adopters in versions 1, 2 and 3, in large part because it's inspired by the philosophy that "happy developers make the best code". Laravel's creator Taylor Otwell succeeded at putting that philosophy into practice, in a few key ways:
"Elegant, expressive syntax" - i.e., code that reads almost like English
Actively seeking out and addressing common developer "pain points"
Thorough, clear documentation
Best practices from other frameworks (Rails, Django, ASP.NET...)
Laravel had already grown into a vibrant community by the time Laravel 4 was released. That community includes a number of prolificwriters and screencasters, and so there is never a shortage of educational material. What I've found especially impressive is the community's passion for teaching not just the Laravel framework, but good coding practices and concepts generally.
Like Symfony2, Laravel 4 is highly decoupled and made mostly of separate components that can be easily swapped out if something else is required. In fact, many Laravel 4 components come from Symfony2. In terms of selecting components to package with the framework "out of the box", Laravel prides itself on using "the best of the best" of what the broader PHP community has to offer.
Why ArcStone Chose Laravel 4 Over Symfony2
As you may have inferred earlier, Symfony2 represented a pretty fundamental change - for the entire PHP community, including developers familiar with Symfony1. When ArcStone decided to stop using Symfony1 for new projects, that prior experience wasn't going to make it any easier to pick up Symfony2. Both Symfony and Laravel have similar capabilities, both bundle together numerous excellent PHP packages into one cohesive whole, and both have a thriving community of developers ready to answer questions.
In the end, ArcStone chose Laravel 4 because the syntax was more pleasant to use (the Eloquent ORM was particularly impressive, as was the ease of Authentication), because of the abundance of well-written books and documentation, and because the learning curve wasn't quite so steep. Those may seem like superficial considerations at first, but they can make a huge difference if, say, a new developer joins a project and you need to bring them up to speed quickly. This is not to say either framework is better than the other. Symfony2 is a fantastic framework - Laravel and the PHP community in general owes it an enormous debt (HttpFoundation, anyone?). But for ArcStone, Laravel just seemed like the right fit.
In Part 2, I will talk about some of the development techniques we've found useful with the Laravel framework. Stay tuned!