It’s not legacy code — it’s PHP

In the last year, Vimeo developers have written backend code in lots of languages — PHP, Go, Ruby, Python, NodeJS, Java, C, C++, and a bit of Rust.

In 2004, we started with just one: PHP. It was an ideal language for brand-new startups like Vimeo. PHP’s interpreter enabled entrepreneurs to develop prototypes rapidly, and it came with a large standard library that took the hassle out of common tasks like sending emails and accessing databases.

Most startups fail, but some PHP-based startups were still around ten years later. A few had achieved meteoric growth, and some of those (most notably Facebook) decided PHP was a bottleneck, and had started migrating away from it. There were two big reasons for that mini-exodus: PHP’s performance, and the challenge of maintaining large PHP codebases.

Performance-wise PHP in 2014 was slower than it needed to be, and arrays consumed much more memory than necessary. Maintaining large PHP codebases was also made harder by the lack of good static analysis tools that could detect bugs at scale.

Vimeo had grown many times over in the ten years since 2004, and our PHP codebase along with it, but we hadn’t grown enough for those issues to really get in our way. When Facebook publicly gave up on PHP, though, some developers here thought PHP was on its way to becoming the FORTRAN of the Internet age. A new wave of backend engineers planned how we might carve up 500,000 lines of PHP into a bunch of better-engineered, faster, and more testable Go services.

For a while it felt imminent, but we never got around to abandoning PHP. There were some obvious reasons — rewriting an entire codebase is resource-intensive and error-prone — but also a slightly less obvious one: PHP got better.

Saying “PHP got better” doesn’t really do justice to its transformation. In the last six years, PHP’s execution time has more than halved, the community has grown immensely, and there’s now a popular drive to improve PHP codebases (old and new) with insights gleaned from static analysis.

It took a while for PHP’s improvements to arrive at Vimeo. First we had to get off an old version of PHP — 5.4 — that we’d been running in production many years past its expiration date. Migrating to PHP 7 made our backend responses much faster and, as a bonus, PHP 7’s improved syntax enabled our developers to write slightly cleaner code, with full language-level support for return and param types.

PHP hasn’t stopped innovating — version 8, released two weeks ago, brings many language-level improvements that will allow our developers to express business logic more succinctly. We’re looking forward to upgrading early next year.

Static analysis is awesome

PHP makes it very easy to get started, but out of the box it doesn’t provide much protection against shooting yourself in the foot. Countless developers over the years have tried PHP for a brief period, shot themselves in the foot by accident, then given up on the language.

I occasionally shot myself in the foot with PHP, too, but, instead of giving up, I decided to build a tool that improved my aim. Thus Psalm — a static analysis type checker for PHP — was born.

Psalm’s core functionality is broadly similar to TypeScript’s checker, borrowing some ideas from Facebook’s (PHP-derived) language called Hack. Psalm tells you when PHP code may cause a type error in production, and also when your logic doesn’t make sense. It adds some extra functionality like unused class and method detection, and Psalm can fix many issues it finds automatically.

Using Psalm as part of our CI pipeline in the last few years has had a transformational effect on how we write PHP at Vimeo: Psalm has given us the confidence to make large-scale changes without worrying about breaking absolutely everything.

Those changes, some of which introduced modern PHP coding standards to our codebase, have helped eliminate the legacy smell — when it feels safe to make changes to code, it’s not really legacy code any longer.

I built Psalm to solve my problems but, now we have open-sourced it, it has helped solve many other people’s problems, too. Psalm has also recently helped us identify a ton of security vulnerabilities in our codebase before they could be exploited by bad people.

As a quick aside, if anyone reading this works with a large legacy PHP project that they’re afraid to make big changes in, I’d strongly recommend they start using a static analysis type-checking tool. Psalm (and similar tools) can grandfather in existing issues within your codebase, letting you slowly improve code quality.

Old code ain’t necessarily legacy code

In the mid-2000s, there weren’t any well-established PHP ORMs, so we built our own. Luckily PHP provides loads of building blocks for making a simple ActiveRecord-style ORM, including MySQL support, query parameter binding, and magic getters and setters. It also helped that we had some really smart engineers who were up to the task.

Our ORM’s last major upgrade was ten years ago. It has had some minor improvements — bug fixes, better types, and a few new features — but the basic structure is unchanged.

Over the years there have been a few attempts to use a different ORM, but none of the proposals were made in response to new business needs, instead motivated by dissatisfaction with the ActiveRecord pattern.

Ultimately none of the proposals took hold. It turns out that old code can be preferable to new if the old code:

• Does its job effectively
• Is simple to analyse statically
• Is well tested
• Is idiomatic

Thankfully our existing ORM meets all four requirements.

Keeping reliable old code around also gives us the opportunity to focus our engineering effort on things that bring material benefit to the business, and I’m contractually obligated (but also delighted) to say that Vimeo has been on a roll recently, with a ton of great new products like Vimeo Record.

“PHP doesn’t have to be terrible”

Many developers wrote a bit of PHP a decade ago and have since moved on to better-respected languages. They’re often eager to tell others how relieved they are to not be writing PHP anymore, and how it can’t be redeemed.

I’m here to tell you that it can, and Vimeo’s continued success with PHP is proof that it’s a great tool for fast-moving companies in 2020.

PHP’s renaissance has converted at least one former naysayer. A colleague and longtime critic of the language took me aside one day and thanked me, very earnestly, for showing him that “working with PHP doesn’t have to be terrible.”

Interested in flexing your engineering chops at Vimeo? Join our team!