As I’ve been building a new PHP application, recently, using the Slim framework, I’ve come to find myself at a bit of a crossroads in my outlook on building them.
In short, you could sum it up like this:
Is it better to use an opinionated framework, one with everything included such as Laravel? Or, is it better to use one that starts off with as little as possible, such as Slim, later adding what you need?
Let’s briefly consider both approaches.
This approach is reflected in frameworks such as Mezzio and the aforementioned Slim Framework. Frameworks such as these, give you only the absolute essentials required to build an API or web app, those being: configuration, routing, a DI container, error handling, and middleware.
Yet, they’re built in a very flexible way, allowing you to rapidly integrate the tooling and packages that you need and are most comfortable with. For example, you could add PHPUnit for testing, Doctrine for data source interaction, laminas-inputfilter for input filtering and validation, and Redis for content caching.
Thanks to Composer and Docker Compose, it’s pretty trivial to find what you need, and get going quickly.
This approach has a number of benefits, with the primary three being not locking you in to:
One way of building an application;
One specific set of tools;
One set of conventions
You get to pick the tools that you and your team are most familiar with and feel are right for your project, as and when you need them.
However, this minimalistic approach comes at a cost.
It means that you need to spend time integrating and configuring tools and libraries for each project, instead of having a pre-defined set ready to go. To be fair, I’m thinking that, after a short while, you’d start creating packages or scripts to automate this, so that the process progressively becomes more efficient and less tiresome over time.
And, it may be harder and slower for developers to move between projects, because developers have to learn how the next project is constructed, which tools it uses, and how it is configured.
While the consistency of the all-in-one framework, to some, may seem quite repetitive and rigid (insert other adjectives as you wish), developers know what to expect and where to look. Given that, yours and your organisation’s investment learning that framework can be much more valuable.
This approach is reflected in a framework such as Laravel (currently the king of PHP frameworks) or Symfony. These frameworks are very opinionated as to what you’ll need and how you’ll build an application.
This might seem off-putting at first, but this approach has a host of advantages as well! For example, you don’t have to think as much about the tooling that you’re going to use. It’s either provided by default or it’s available in the larger ecosystem.
Hat tip to the Laravel community. They’ve done an astounding job of creating a wealth of tools and services that integrate beautifully together and cover a significant number of use cases; these include Forge, Vapor, Breeze, Envoyer, and Cashier.
In addition, they provide a host of defaults that work across a range of use cases which suit a broad number of the ones that you’re likely to encounter.
By bringing so many tools under one, proverbial, roof, it helps the documentation to be less disparate. As a result you can often find the information you need quicker, and in a more cohesive fashion.
By contrast, if you’re working with a host of different packages and tools, you have to move between different documentation silos to find the relevant information. Yes, after a while you’ll get used to the right places to look, but you’ll likely still be slower at first.
One, potential, downside I see to this approach, however, is that they may limit your exposure to a broad range of tools and approaches. Out of a combination of necessity, practicality, and pragmatism, these framework espouse a specific way of working and a specific set of tools. There’s nothing necessarily wrong with that, and it may work perfectly well for you.
However, depending on your career path, you may find yourself at a disadvantage eventually, as you’ve not had exposure to enough tools and ways of working, such that you become somewhat pigeon-holed. In a way, you end up becoming limited to a certain style of application development.
If, at some point in the future, you want to try something new, it may require a significant investment of time and effort before you can start being effective in that new field.
I’d argue that "better" is quite a loaded or subjective term – perhaps even pejorative in this day and age. I’d also argue, even more strongly, that it doesn’t always matter which approach or framework you use. You have the potential to build good and bad applications with both. As the old saying goes:
You can build good software with bad tools, and bad software with good tools.
That said, I want to give a special mention to Laravel in the early stages of developing an application. Even if you’re a sufficiently knowledgeable and experienced PHP developer, I think Laravel has a decided advantage. From what I’ve seen, it lets you build a prototype or initial version so incredibly quickly.
Where things go from there, though, I don’t think anyone can really say with certainty, nor confidence.
In essence, there are advantages to both approaches. Experiment with a number of frameworks. Learn their approaches, and their shortcomings. Observe and interact with their communities. Get a feel for what they’re like to build with.
Then, use the one that makes most sense in your situation, whatever that may be. Don’t feel the need to change for anyone, if there is no need to do so. Use the tools and tooling that works for you, and be proud of that.
I’ll leave you with one last paraphrased quote, from Larry Wall, creator of Perl:
Software frameworks differ not so much in what they make possible, but in what they make easy.
For the longest time, Zend Framework hasn’t had the strongest support for command-line tooling and scaffolding. However, in recent times, that’s all changed. Come find out how to use Expressive’s new tooling support to create modules and middleware rapidly.
Laravel’s Eloquent ORM isn’t likely the first one you think of when using Zend Expressive. You likely think of Zend\Db or Doctrine. But, with a little bit of work, it’s possible to use Eloquent with Expressive. Today’s tutorial shows you how - step-by-step.
Homebrew makes installing PHP and so many other great tools on macOS a breeze; almost as easily as a Linux package manager. But how do you install the Imagick extension? In this short post, I’ll show you the shortest way to do so.
There are a number of ways to set environment variables in PHP. But the approach I use most often in development is a wonderful package called PHP dotenv. In this tutorial, I’m going to step you through how to install and use it.
Please consider buying me a coffee. It really helps me to keep producing new tutorials.
Join the discussion
comments powered by Disqus