Serious Semicolons

Tag: php

  • PHP is Alive, Well, and Worth Learning

    According to a new survey whose results were summarized in a recent Gizmodo article, CEOs are planning on slashing junior roles in the near future to focus on mid-level roles as work on low-level, simple tasks shifts to AI. Juniors are being told to study Javascript, Typescript, and even Java and Kotlin, emerging from their flowy robes and fancy cap clutching a C.S. degree in these topics, and then being told they don’t have a job because AI can do it. To these juniors, I have a rallying cry that is equal parts fervent and encouraging: learn PHP!

    My friend Mike Page gave a great UnCon talk recently at PHPTek 2026 about how pervasive and trope-y the idea of PHP being a dead language has become. There are countless memes about it, from two-headed hammers to chronologies of “it’s <year>, PHP is out, learn <lang>”. I am here to state, unequivocally, and I especially hope you hear me if you are a junior engineer worrying about your burgeoning career:

    The rumors of PHP’s death have been greatly exaggerated.

    me and a metric crapload of other paid professional PHP developers

    At the same conference I mentioned above, I stepped into an impromptu job fair to support a friend. In that job fair, I heard no fewer than three companies mention that they were looking to hire for a role supporting a “port old PHP to new PHP” role. The “from” codebases ranged from CodeIgniter 3 to older versions of Laravel. The “new” codebases included Symfony, Laravel, CakePHP, and possibly more. Not a single “we’re escaping PHP for Node” or “We’re rebuilding our legacy backoffice in React from PHP5”. No, from PHP to PHP. And, despite the name, this was a Javascript con, too! Indeed at the end of 30 minutes I realized that there were quite a few React- and Vue-first developers in the room with us. In speaking to some of them afterwards, I found out that it’s not just PHP developers that are seeking to learn PHP. The language has an immense amount of pull and gravitas, once you look past the memes.

    The famous ‘PHP is a hammer with two heads’ meme. The joke landed in 2012.

    An additional reason I hear cited all-too-often for avoiding PHP is that it’s old. If your argument is “this language is garbage because it was created in the early 90s” then, first, I shall challenge you to a duel as that is when yours truly was born–and indeed I have aged like a Lagavulin–and second, I would ask if you had you seen the most recent PHP release? It was November 2025. PHP is a language that is still going strong after 32 years. Somebody even got PHP version 1 from 1995 working and responding to HTTP requests. In addition to the PHP language itself, most of the popular PHP frameworks place an extremely high value on backwards-compatibility (see Symfony framework’s Backwards Compatibility Promise).

    Something important to keep in mind: “it works” is not the same thing as “good code”. There are dozens of features that are present in more modern versions of the PHP language that older versions can only dream of. But if you need to write something once and have it work forever, PHP is a safe bet.

    Shift your attention now to framework-of-the-week land. In my career I’ve had the dubious privilege of maintaining a 5+ year old React application. Opening the Dev Console in my browser was complete carnage: deprecations, warnings, errors…ketchup and mustard everywhere making it impossible to locate and fix the actual issues my users were reporting, like componentWillMount has been renamed, and is not recommended for use, or the same for componentWillReceiveProps, or even this fun block of deprecated dependencies that would require weeks to fully refactor:

    That codebase became “don’t touch it unless you HAVE to” very quickly. AngularJS was gaining some steam as one of the first SPA frameworks when Google rewrote it from scratch and shipped it as a different framework that just happened to share the name. But, if you built on AngularJS 1, you didn’t get an upgrade path, you got an EOL notice. What if, in that time, you built a projection-ready app that needed to run for 20 years? This is not uncommon in the government and educational space. I have never heard of this happening with the PHP language itself. Frameworks? Sure, but not the core.

    Why does one class of languages rot and the other doesn’t? For PHP, backwards compatibility is a language mandate. Don’t believe me? Check the RFCs, see how many are rejected for not considering X or Y edge case that would adversely impact users of older versions of the language. The syntax for attributes (#[MyAttrib]) was in no small part decided because the ‘#’ symbol is a line-comment in older versions of PHP, meaning that versions of the language that weren’t compatible with that syntax would simply ignore it. I greatly admire the folks that are submitting RFCs to the mailing list, because so much thought goes into every little detail. That community will not let a backwards-incompatible comma get through. Meanwhile, it seems all-too-common that Javascript frameworks need transpilers and reinvent themselves biannually, leaving the carcasses of their code on your hard drive to clog up your technical debt queue.

    I greatly admire the folks that are submitting [PHP] RFCs…that community will not let a backwards-incompatible comma get through.

    Aside from stability, what is so great about PHP that everyone is missing out on? SO, so much, and this is the part of this blog that I was the most excited about writing. At my current job, I have the great opportunity to work on a bleeding-edge API: latest PHP version, latest features, latest dependencies. If it’s stable, actively maintained, and fits one of our use cases, then it’s a candidate for use. Here are some of my favorite PHP features that you may not be aware of:

    • Attributes – attach metadata to your classes and methods to add yet another solution for sharing code between unrelated parts of the codebase. I used this to build attribute-based routing which helped me clean up a 200+ line config file that was a manual update chore.
    • Reflection – scan your PHP files to get information about the AST without building a tree parser. I did that once, in Roslyn for C#, it was…ok, it was actually kinda fun…but not something I would want to do again. Reflection and attributes go together hand-in-hand.
    • Enums – represent magic strings and other primitives in your app as an actual typed object. Loosen the coupling between the values in your database and what is read in your code. I’ve used enums to sidestep complex issues in apps with big databases that would have required a risky query otherwise.
    • Tooling like PHPStan and Rector. The former is what I call a “bug preventor”…it prevents bugs before they happen. The latter is an engine for rapidly applying boring refactorings in a methodical way, saving you literally dozens of hours of manual edits and embarrassing reverts caused by AI mishaps.
    • Mutation testing with Pest. You’ve got tests, bravo, but how good are they? Pest will modify small bits of your SUT to see if your tests catch them. If testing is more than a casual nice-to-have in your project (and it should be), you should absolutely try mutation testing with Pest.

    These are just a handful of basic features, there are even more advanced ones that even I haven’t played with yet, like fibers (pause/resume live code) and async (coroutines).

    That’s nice, but, I’m a junior dev that just graduated and I don’t even know what half of these things are, except maybe async. We didn’t cover this stuff in my CS labs! Why should I care?

    You should care because features like these are what turn a regular-old-boring PHP app into an enterprise-grade powerhouse, and that’s where the money is. Ever wondered how to write scalable code? This is how. Ex-FAANG folks I’ve talked to tell me these are exactly the patterns they expected new hires to bring on day one.

    Here’s the PHP advantage: these are language-level features, documented in one place, and guaranteed to be backwards compatible across major versions. In JS land, the same patterns live in framework documentation, and they’ll be subtly different from React, to Vue, to Redux, to Angular 5/6/7/8/9/…/21, or whichever new framework is the flavor of the week.

    And, *grabs soapbox and stands upon it*, here’s my issue with FAANG, by the way. They are the ones who have caused this mess of creating and proliferating so many JS frameworks that it’s impossible to know which one is right to learn, then abandoning them in service of their latest business venture. (Seriously, go to killedbygoogle.com and search for ‘javascript’.) FAANG churn is a huge part of why JS is the way it is.

    Conversely, PHP is stewarded by The PHP Foundation and is not owned by anyone. So it can’t be killed by anyone. Now, as fun as it is to dunk on Big Tech, I will say that their commitment to advancing computer science is admirable. But how they’ve done it, I vehemently disagree with, and I’m not the only one. FYI, I’m not an embittered, rejected job applicant: I’ve never applied to work for them, and I never would. If I were to exit the PHP ecosystem, I would go for a C++ or Python-focused team. Why? Because those are two other languages that aren’t owned by a corporation and therefore can’t be killed off.

    So, juniors, I sincerely hope that your transition from higher education to the corporate world is smooth and easy, but if it isn’t, here is my advice:

    1. Learn concepts first, and languages second. Once you’ve learned the concepts you can learn any language. And, don’t worry about picking a framework at first, either. Frameworks come and go, languages last for as long as they are maintained, but concepts live forever.
    2. That said, if you have to pick a language to learn, pick PHP. IMO it is extremely easy to learn and understand because it makes so many powerful features easily accessible natively, and even more functionality (Redis, MySQL, advanced debugging) is one extension-install away.
    3. Here’s the most important bit: if you already have Javascript experience, your time was not wasted. I have yet to work in a PHP position that didn’t require some Javascript knowledge. Your experience is additive, not detrimental. On your resume, I would put “Javascript”, though, rather than <FrameworkOfTheWeek>

    Myself and millions of other PHP developers know what the rest of the tech world seems to not know: PHP is alive and well, and there is a bevy of work to go around. Maybe not at huge multinational companies, but at your local mom-and-pop shop or small business. Happiness with your work and a stable paycheck matter more than the names on your resume, I have lived it both ways. In a few years, or maybe less, when the AI bubble “pops” and there are massive volumes of crap slop code to clean up, remember your old friend PHP, and the companies I mentioned earlier looking to port old code TO PHP, not FROM PHP. Help mop up the AI slop and replace it with nice, clean PHP.

  • PHP Doesn’t Have a Marketing Problem (A Response to Brent Roose)

    PHP Doesn’t Have a Marketing Problem (A Response to Brent Roose)

    I was reading the latest newsletter by Brent Roose, Developer Advocate for PHP at JetBrains, and I found myself disagreeing — out loud, apparently, because my 6-year-old looked over from her morning routine, unmoved, most likely because she is not a PHP developer. The premise is that PHP’s biggest problem is marketing, and that the PHP Foundation should be paying for a website redesign, a full-time docs hire, conference speakers, an omnichannel social media presence, internals blogging/vlogging, and “high-impact features” that can be marketed.

    I have a ton of respect for Brent, have interacted with him on his streams, and he has done a ton for developers in the PHP world, so I want to be clear up front: I am not interested in dunking on him. I read most everything he writes and emphatically issue “+1″s in my head. I was (and am) genuinely interested in his projects such as Tempest, and I think his framing of the problem is at least worth taking seriously — even if I think he’s wrong about the answer.

    But, I DO think he’s wrong, and pretty fundamentally so. Let’s take it point by point.

    Re: paying a design agency to redesign php.net

    Brent’s first suggestion is that php.net needs a proper design-agency-led redesign. I would push back on the premise harder than the suggestion, per se: I don’t actually think php.net looks dated, I think it looks timeless. I don’t think too many people coming to PHP from Node, Go, or Rust are bouncing because the homepage is too gray…er, purple. The Foundation just ran a paid design contest for the 8.5 release page in November, with $1,500+ in prizes. This shows the community is already interested in iterating on design, just incrementally and on volunteer-friendly terms instead of via an agency engagement.

    The site is plain, yes. It’s fast. There’s no cookie banner, no AI-generated hero illustration, no parallax scroll, no autoplaying videos or GIFs, no sticky CTAs getting in the way. You land on it, find what you came for, and leave. It’s the opposite of sticky, like a quick-reference card instead of an audio-visual experience. In 2026, when seemingly EVERY. OTHER. SITE. has been redesigned by someone who clearly briefed an LLM to “make this look snazzy” resulting in it looking nearly identical to every other AI-built site (eugh)…I think php.net’s restraint is a feature, not a liability. Readability beats flashiness, especially for developer-facing resources.

    Here’s a more direct counter-example, too: Some CakePHP Core folks (shout out to Kevin and Jos) just spent a few weeks migrating our entire docs ecosystem from RST to VitePress. The new sites look great, didn’t change navigation patterns (so we didn’t confuse our existing users), and we did the whole thing on volunteer time. No design agency required. If a small framework’s core team can pull off a tasteful refresh on weekends, the language itself doesn’t need to outsource its identity to a branding consultancy.

    I’m not opposed to php.net evolving. I just don’t think hiring an agency is the move.

    Re: paying someone full-time to work on the docs

    This one is among the few of Brent’s points that confused me, because as far as I can tell, this is something the PHP Foundation already owns. Their team’s listed contributions explicitly include “writing documentation,” and as of their 2026 hiring round they fund eleven developers across the language.

    If the argument is “the Foundation should hire more docs-writers”, then that’s totally reasonable to advocate for! But that’s a different argument than “pay someone to do this” because someone is ostensibly already being paid to do this. I have at least one friend in my circle who is a PHP docs contributor. Are they being paid? If not, why not? There should be ample funds available, because the Foundation has a transparent funding pipeline: sponsors include JetBrains, Automattic, Sovereign Tech Agency, Laravel, GoDaddy, Sentry, Symfony, Passbolt, and many others.

    Sidebar: Brent works at JetBrains, which has been one of the Foundation’s largest sponsors since day one. I think there’s an interesting opportunity there for him to push from the inside.

    The other thing that nagged at me reading this section was the underlying claim that people can’t actually learn PHP effectively from the current docs. I just don’t think that’s true. The PHP docs are great. They’re not a hand-holdy tutorial site, and they shouldn’t be, because excellent supplemental tutorial sites like Refactoring.Guru already exist for that purpose (I link this site to my team ALL the time). If anything, the docs could use a little more crosslinking to those resources. That’s a much smaller intervention than “hire a full-time writer.”

    I also want to plug Tylae, an actual real-life PHP docs contributor I had the pleasure of meeting (virtually) recently. There are people doing this work now, on volunteer time, and I’d rather see Foundation resources go to people like them than to a brand-new contractor with no community context.

    Re: paying conference speakers to speak outside the PHP bubble

    This one I agree with, so I won’t dwell on it too much other than to say: I volunteer as tribute!! 😆

    Cross-pollination between communities is one of the most underrated drivers of language adoption. I speak from personal experience. One of the best, most entertaining, most useful talks I ever sat through at a PHP conference was a Lemon Lemon talk about Progressive Web Apps – highly orthogonal to PHP, delivered to a room full of PHP devs. Nobody in the room cared the slides weren’t about PHP. The ideas were good, and the delivery was sharp. I went home and built and deployed a PWA, just for the fun of it! Imagine if the roles were reversed, and a JS or Rust dev went home and developed a quick CakePHP plugin or PHP Agent Skill. Amazing.

    In an era where agents and MCP/A2A are taking the world by storm and everybody’s trying to figure out whether Node.js or Python is the best for LLM-enhancing scripts. Why not PHP, I ask you? Why not PHP?

    So sure, fund some PHP folks to go talk at JSConf, GopherCon, RustConf, whatever. I’d genuinely watch a “PHP for Skeptics” talk show up in front of a Node audience.

    Re: investing in social media everywhere

    This one I have some thoughts on. Brent’s list of platforms PHP “should be everywhere” on includes X, Reddit, newsletters, blogs, Instagram, TikTok, Facebook, and LinkedIn.

    Notably absent…Mastodon. As in, phpc.social, the most popular PHP-flavored federated server that I know of, where a huge chunk of the post-Twitter-eXodus PHP community currently hangs out. I’m not sure if Brent is on Mastodon, I couldn’t find them with a quick search, but if you’re reading this Brent and no one has yet done so, please allow me to warmly extend the invite! We’d love to have you!! The more the merrier. The point is: the Fediverse is where a lot of the actual human-oriented conversation is happening right now, especially the conversation that developer advocates want to be a part of.

    A few of the other platforms on the list just give me pause, and it could be because I’m an old-Internet denizen. X and Reddit are increasingly bot-saturated (“@grok is this true?” “@grok make a meme of this” smh.) and algorithmically hostile to non-engagement-bait content: PHP showing up there isn’t going to convert anyone, because (at least on my feed) it would appear between the “Anthropic just released the cheat code to using Claude to make ZILLIONS!” post and the flood of AI-generated fake imagery that makes me feel gross just scrolling past it. And what, exactly, would the PHP Foundation post on TikTok and Instagram? There are only so many cute pics of elePHPhants one can take. How about a short-form video of someone talking about their day as a core PHP developer? I just don’t think that one lands on anyone’s feed.

    Obligatory elePHPhant pic. Gifted to me by my friend John Congdon, of SDPHP

    I’m not saying it can’t be done on these social media platforms, and again I’m quite skeptical and cynical towards most social media for technological news, but the lift seems too high to make it worth it. Newsletters and blogs are kind of the same thing, structurally, and I actually think Brent is doing a great job with these already.

    What I’d actually advocate for…and this might just be a thinly-veiled “more of what already works” pitch…is leaning into the federated, blog-and-RSS, conference-and-podcast ecosystem that already exists. Because it does exist, and it’s good, and it doesn’t require anyone to make TikToks, and doesn’t require me to “like, comment, and subscribe” to anything.

    Re: killing the mailing list and replacing it with vlogs

    I was having this exact discussion with a coworker the other day, so my face went :O when I saw this show up in Brent’s newsletter. Internals being “inaccessible” because it’s on a mailing list is not really the problem, because most users don’t want to read the actual internals discussions. PHP is, deep down, very gnarly C code. Brain hurty, unless you live and breathe it. Most working PHP developers do not need or want to follow the day-to-day of zend_execute_data getting refactored.

    What people do want is something like Anthropic’s Claude Code changelog: a curated, regular, technical-but-readable summary of what’s shipping, what’s in progress, and what’s coming. Bullet points, hints, with links to the deeper RFC discussions for people who want to go further. I would subscribe to that in a heartbeat. That’s the artifact I think is missing — not a vlog series, and specifically because…

    Brent, you are doing this already, and doing it well. So is PHPUgly and PHP Architect. My friend John Congdon and his pals have been putting out quality, entertaining, perfect-vent-needed-for-a-weekday-afternoon podcast content for ages. Also, Roman Pronskiy is doing it on the Foundation side. Suggesting “someone should blog/vlog about PHP” without acknowledging the people currently doing this work read to me as inadvertently dismissive. But I’m hoping I misread it. There’s a thriving content layer around this language already. Maybe what’s missing isn’t more content, it’s better aggregation and discovery of the content that exists.

    What a logo. I mean REALLY! Somebody get these folks a Design Award!!!!

    Re: investing in high-impact features and marketing them

    My response to this is the same as to the docs point above, which is isn’t this what the Foundation is supposed to already be doing? Their funded developers ship features, fix bugs, and the Foundation publishes transparency reports periodically detailing all of it. If specific sponsors, and there are a lot of them, want particular high-impact features prioritized, then the channel for that conversation already exists. But if it’s not happening, then something is broken internally with the Foundation. If those conversations ARE happening and the rest of us aren’t hearing about them, that’s an information-flow problem, and it loops back into the “PHP Foundation Changelog” idea I floated above. That’s an intervention I’d actually advocate for.

    From the outside looking in it seems like all the tools are in-place. Granted, the Foundation is less than 5 years old at this point, so you could attribute this breakdown to their relative infancy. But, I fervently hope this gets figured out soon, else it could cause some of those sponsors to pull their funds. The shininess of philanthropy does wear off eventually (see the “past sponsors” list on the PHP Foundation’s website).

    OK, rant over. What am I actually arguing for?

    When I lay these rebuttals out next to each other (and, thank you for sticking with me while I pontificate my thoughts point-by-point) I notice they all share a shape: most of Brent’s suggestions are framed as “PHP needs to buy these things,” and most of my responses are some flavor of “this is already happening, but you may not be looking in the right place.” That’s a big distinction. It’s the difference between:

    1. this language has a marketing problem and
    2. this language has a visibility into its own community problem.

    If I had to name PHP’s biggest problem in one phrase, it wouldn’t be marketing. It would be fragmentation. Do the CakePHP developers know what the Laravel developers are doing? Do the xdebug developers know what the dd-trace-php developers are doing? And most importantly: do the people doing the work and the people consuming the language know about each other? The answer to that isn’t a JetBrains-scale marketing budget. It’s better aggregation, better cross-pollination, and more broadcasting of the volunteer and Foundation-level work that is already happening.

    Brent is uniquely positioned to help with this, by the way. He works at one of the Foundation’s top sponsors. He has a massive audience, and he’s already running a top-tier blog that I am delighted to see show up in my inbox, and a YouTube channel about PHP that is quite successful. If he wants more of what he described, he is maybe one of ten people in the world that can make it happen: so make it happen. This is the principal reason I wanted to write an almost 2,000 word response to it (and, as you can probably tell by my grammar, I do not use AI to write my blog posts).

    So, with respect and admiration, I disagree, Brent. PHP doesn’t have a marketing problem. It has a we should talk to each other more problem. And we’re already doing that, just not in the channels you may think.

    Further Reading