Why PHP/Laravel?

Note: This page will be written in the first person, from the perspective of Vegan Hacktivists's former Director of Engineering, Gerard O'Neill.

TL;DR

We have been using Laravel for four years and are deeply entrenched in the ecosystem.
Introducing more technology would lead to more maintenance headaches and higher operation costs.
Projects would not be built as quickly with other technologies.
PHP and Laravel are actually really good if you give them a chance.

Our tech stack is a topic of conversation more often than I like it to be, and far more often than I ever expected it would be. I have always viewed programming languages merely as tools, especially in the context of web development, where the differences between most of the popular ones (PHP, Python, Ruby, JavaScript, etc.) are so minor. Sometimes, a volunteer will express their dissatisfaction with our tech stack and propose that we use different technologies to build our projects. Because of this, I would like to do a deep dive into why we use Laravel for our projects, and why we will not be using other frameworks.

The Origin Story

First, it's important to know the history of VH in order to understand the context surrounding our tech stack. The organization started as a very tiny group of Redditors, led by David. David is not a software engineer by trade, but had some experience building websites, mostly using PHP (WordPress, PHP Fusion, some basic custom sites, etc.). The word "deploy" was not in his vocabulary. To update a website, hosted on the shared hosting provider HostGator, he would FTP into and upload files directly onto the server.

This is how the first VH projects were built. David was somehow able to rally up a few programmers willing to work on some toy projects in this manner. Within a few months, Git was introduced, but the "deployment" process remained the same. This obviously couldn't scale for so many reasons: poor security, the need to build assets locally in production mode before uploading files via FTP, etc.

I joined VH several months after it was started. By that time, two PHP projects had already been built without a framework. I was assigned to help with the third project, which was the first one built using Laravel. This was mostly new for me, since I had experience with PHP, but I had never built a project using Laravel. At that point, I had spent the last three years working exclusively with JavaScript, and hadn't so much as looked at PHP since my previous job.

Despite HostGator not being able to support very many different technologies, the original plan was for VH to build out one new project per month, built with a different technology each time. I probably don't need to explain why this is a terrible idea, but just in case it's not obvious: This would've been a maintenance nightmare. I couldn't handle the idea of cranking out twelve hastily-coded projects per year, all needing to be maintained in their own unique ways, with an ever-changing team of volunteers.

I had a chat with David and had no trouble convincing him that this was not a good idea. Thus, we made the decision to stick with Laravel. It's the most popular PHP framework, we had already shipped with it before, and everyone on the team at the time seemed pleased with it. We also made the decision not to try to release a new project every single month.

Fast-Forwarding to Today

Long gone are the days of FTP uploads to a shared HostGator server. We have over a dozen PHP projects hosted on a Digital Ocean server managed by the Laravel Forge service. Deploying is as simple as updating the main branch. Now that we know the history of VH, as well as the current state of things, let's go over some of the reasons that we will be sticking with the current stack for all future projects.

It's Less Maintenance

We have built up years of experience managing Laravel projects, and Laravel Forge makes it virtually unnecessary to have people with DevOps experience to help with their upkeep.

If we introduce a new stack into the organization, we will not benefit at all from the experience we've gained up to this point. If we built an app with a different technology, we'd need to host it somewhere else. We'd need to make sure that we always have at least one person who knows how that project works and how to maintain it, because if all volunteers with that knowledge leave, there wouldn't be anybody who would know what to do if something breaks. This is especially important for VH, which is run almost exclusively by volunteers, none of whom we expect to be available when things go wrong.

If this isn't convincing enough, I highly recommend this talk about choosing "boring technology."

It's Faster

This will sting for some and be counterintuitive for others, but it's true. Building our projects in Laravel results in shipping faster. We do have volunteers that don't have experience with Laravel or even PHP, but this drawback is vastly outweighed by the speed gained by sticking with Laravel.

The first thing to note is that Laravel, unlike virtually all JavaScript frameworks, is opinionated with many batteries included. Listed below are a bunch of things that are already been built into the framework or offered as a first-party package, reducing the need for debate amongst teammates about which libraries to use, as well as eliminating boilerplate code and time spent setting things up.

Testing framework, from unit tests all the way up to headless browser testing
ORM
Database migration functionality
Drivers for various data stores, such as Redis, MySQL, etc.
Email functionality (both the templating and the sending of emails)
Notification functionality (both via email and stored in the database)
Localization functionality
OAuth functionality (both client and server)
Rate limiting
Code formatting
Full-text search
Job running (async/queued jobs as well as scheduled jobs)
Asset building (using Vite)

There's a lot more, but they're less relevant to the needs of VH. In addition to all of that, the Laravel ecosystem also provides us with the following, all of which are also built by the Laravel core team:

Laravel Sail - A standardized Docker environment which sets up everything you could ever need to develop a Laravel project.
Laravel Jetstream - A starter project that gives you a fully-built authentication system (including things like password reset emails and 2FA), profile editing, session management, teams functionality (optional), and an API for all of the above. It also has things like Tailwind CSS set up already.
Laravel Breeze - A more lightweight version of Jetstream with fewer features out of the box.
Laravel Forge - Mentioned above, the service that manages our Digital Ocean server and provides us with the ability to manage tons of stuff: scheduled jobs, daemons, PHP versions, configuration files, SSH keys, environment variables, Redis queues, SSL certificates, automatic deployments, failed deployment notifications, and more.
Laravel Envoyer - A service for handling zero-downtime deployments, as well as many other things (heartbeat checks, deployment hooks, even more notification possibilities, etc.)

Last, but not least, we were also given a free lifetime license to use Backpack, an extremely powerful third-party admin panel for Laravel.

All of the things listed above are technologies we actively use. If we were to build a project using a JavaScript framework, we would not be able to use any of it. In order to get the same functionality, a non-trivial amount of time would need to be spent building it from scratch, or at best, writing boilerplate code in order to connect many third-party tools together. This doesn't even take into account the time spent figuring out which technologies to use in the first place, nor does it take into account the added DevOps requirements we'd likely have with other technologies.

Something also worth noting is that using the same technology for each of our projects allows for much more code reuse. If a similar feature has already been built in a previous project, it is typically very easy to replicate that functionality in a newer project, either with a simple copy/paste or by taking inspiration from the existing code.

In short, Laravel helps us ship faster.

For the sake of completeness, I should note that certain frameworks such as Ruby on Rails, Django, Phoenix, etc. are also opinionated, but for some reason, virtually all complaints about PHP and Laravel come from those wanting to use a JavaScript framework, hence the focus I place on JavaScript in this section.

Addressing Common Concerns

In case everything up to this point hasn't been convincing enough, let's go over some issues that have been raised over the course of VH history.

"I Don't Have PHP Experience"

This is probably the most valid objection to using PHP. As much as I believe that web programming languages are very similar, and that a good developer should be able to get up to speed in a new technology quickly, it still does take some time and effort. This is obviously a bigger ask for a volunteer than for a full-time employee.

However, as stated above, Laravel makes us faster. If we were to use another technology, we would simply be trading time spent learning for time spent debating/making decisions, writing boilerplate code, and maintaining a bigger, more complex set of technologies. It's simply not a good trade.

"I Don't Like PHP"

This is probably the most common objection that we've gotten, though in my personal experience, this statement is actually an alias for the above one. To put it more bluntly, the vast majority of people who claim to dislike PHP are those who have never (or almost never) used it, thus don't have enough experience with it to have an informed opinion. Even if that isn't true for someone, it's not enough of a reason for us to fragment and complicate our stack.

"PHP Can't Do X Well"

There are certainly projects where PHP would make less sense to use. If we were building a project with lots of real-time functionality that made heavy use of WebSockets, then it might make sense to build it using a different technology. With that being said, we would still need to explore using PHP as an option before making that decision. In order for us to use a different technology, the benefits would need to significantly outweigh the drawbacks. Again, I highly recommend reading Choose Boring Technology for more perspective.

In any case, none of our projects have ever had requirements that were even remotely difficult to satisfy with Laravel, so this is a non-issue.

"PHP is Dead" / "Nobody Uses PHP"

This is something I've been hearing for at least the last ten years, and it's about as true today as it was back then. Not only is Laravel an extremely popular framework, but technologies like WordPress, Drupal, etc. are used for so many websites that PHP powers almost 80% of the web. The language itself is constantly improving over time, not only by adding more modern functionality, but also introducing significant performance improvements.

Here's a quick list of companies/websites you've probably heard of which use PHP:

Facebook
Wikimedia
Mailchimp
Etsy
Slack
HelloFresh
Tumblr
9GAG
Upwork
Skillshare
DeviantArt
Tailwind UI

PHP is not dead, and it isn't going anywhere anytime soon.

Moving Forward

I hope this article explains why we use the technologies we use. I know that regardless of how much it makes sense for us to keep using Laravel, it will cause unhappiness for some people. However, it's important to realize that this is true of any tech stack.

After all of this, you may be of the opinion that I'm simply a Laravel fanboy or a PHP apologist. While those things may well be true, it's worth noting that I am a pragmatist above all. If the first several VH projects were built in Ruby on Rails, Django, or Express, I would've advocated for us to continue building apps with that technology, and we'd probably be using one of those instead of Laravel today.

Thanks for taking the time to read this post. Let's keep coding for the animals!