Is the approach of one PHP Framework better than any other?

:idseparator: - :idprefix: :experimental: :imagesdir: /images

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.

== The “Just What You Need” approach

This approach is reflected in frameworks such as https://docs.mezzio.dev/[Mezzio] and the aforementioned https://www.slimframework.com/[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, https://docs.laminas.dev/laminas-inputfilter/[laminas-inputfilter] for input filtering and validation, and Redis for content caching.

Thanks to https://getcomposer.org[Composer] and https://deploywithdockercompose.com/[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.

== The “Batteries Included” approach

This approach is reflected in a framework such as https://laravel.com/[Laravel] (currently https://www.jetbrains.com/lp/devecosystem-2022/php/#which-php-frameworks-and-platforms-do-you-regularly-use-if-any-[the king of PHP frameworks]) or https://symfony.com/[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.

image::quotes/taylor-otwell-on-laravel.png[]

In addition, they provide https://laravel.com/docs/9.x/configuration[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.

== Is one better approach than the other?

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.

== A framework won’t make or break you

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.