I Found a Beautiful Text Editor and PHP Tooling Destroyed It in Sixty Seconds

I installed Zed last week. For those who don't know, Zed is the new editor from the people who built Atom. Same vision - a beautiful, thoughtful coding environment - but this time built in Rust, so it actually runs fast. Atom was always gorgeous but sluggish. Zed fixed that.

But that's not what got me.

What got me was the monotone syntax theme. First time I opened a file, I thought something was broken. No colours. Grey text on a dark background, or dark text on light. Just... code. Like Notepad, if Notepad had been designed by a genius developer.

I was about to change it when I stopped myself. Why would the Zed team - people who spent years thinking about how developers read code - ship this as a deliberate option? So I looked it up.

Turns out there's a body of research on syntax highlighting and cognition, and the findings are more interesting than you'd expect. A 2015 eye-tracking study found that highlighting helped beginners but the effect diminished with experience. Another study found no significant difference in fixation duration or cognitive load between coloured and monochrome code. The supposed benefits of syntax colouring are largely assumed, not proven.

The Zed team's thesis is that colour creates visual noise. Your brain processes every highlighted keyword, every green string, every purple function name - even when you don't need to. Monotone lets you read code instead of scanning it. The structure comes from indentation and whitespace, not from a rainbow palette fighting for your attention.

The makers of Zed should be applauded for thinking outside the box. While every other editor competes on who can offer the most syntax highlighting themes, Zed asked a more fundamental question: what if the colours are the problem?

I decided to try it. Leave the colours off. See what happens.

Everything was going well. I was excited. I felt as though I was exploring a whole new world. That is, until...

The PHP Extension

I installed the PHP extension.

Instantly, the monotone was gone. A cavalcade of ghastly "SoyDev" text hijacked my screen. Garish shades of shocking pink and sea-sick lime coloured syntax highlighting flooded back - not as an option I could configure, but as the default, overriding both the theme I'd chosen and all of the hard work that had been carried out by the Zed team. Fine. I can fix that.

Then I noticed the squiggly underlines.

My function names were flagged. Not because they had bugs. Not because they referenced undefined symbols. Because I'd written them in snake_case.

The PHP extension was scolding me for writing PHP in the style of PHP.

And then - while I was still processing this - I suddenly noticed that my brace style had changed. Opening braces that had been on the same line as their function declarations were quietly moved to new lines. The extension had reformatted my code without asking. No dialogue, no confirmation, no "would you like to apply PSR-12 formatting?" Just... done.

How PHP Tooling Works Now

Let's talk about what happened here.

Zed's team spent years thinking about code readability. They built a considered, minimal, opinionated environment that boldly but thoughtfully challenges assumptions most editors take for granted. A PHP extension undoes all of it - without asking any questions and without giving any notifications.

That happens, not because the extension author has a different philosophy. It's because this is how PHP tooling works now. They enforce the following set of assumptions:

1. PSR-12 is correct.
2. If your code doesn't match PSR-12, you're wrong.
3. The tool knows better than you.

These aren't presented as preferences. They're presented as facts. The squiggly underline isn't saying "this doesn't match your configured style"-it's saying "this is wrong." There's no neutral option. No "I see you're using snake_case, would you like me to adapt?" Just immediate, silent correction.

And look-if you want PSR-12, if you want your braces moved, if camelCase is your preference, that's fine. Use the tools as intended. But the tooling doesn't ask what you want. It assumes. And the assumption is always the same: rules decreed by a self-appointed committee - formed in 2010 - define and dictate the only valid way to write PHP.

The Native Style of PHP

Here's what bothers me.

PHP is written in C. The PHP standard library uses snake_case. The language's own conventions-array_map, str_replace, file_get_contents - are snake_case. When you write PHP in snake_case, you're writing PHP in the style of PHP.

PSR-12 is out of alignment with the coding style of the PHP language. It's a style imposed on PHP developers, borrowed from Java conventions, and adopted because some influential framework developers preferred it. That's fine as a choice. But it's not the language's native idiom.

Consider: how do you write "get element by ID" as a function name?

In snake_case: get_element_by_id()

Unambiguous. No confusion. The underscores are explicit word boundaries.

In camelCase: getElementById() or getElementByID()?

Is "ID" one word or two? Is the D capitalised or not? JavaScript's DOM uses getElementById. But another library might use getElementByID. Or getElementById. The conventions aren't even internally consistent!

This isn't a theoretical problem. It's a practical source of bugs and confusion. Snake_case solves it by being explicit. CamelCase perpetuates it by being ambiguous.

The tooling should let you choose. Instead, it chooses for you.

The Solution

So I uninstalled the PHP extension.

I'm back to monotone. Back to my brace style. Back to snake_case without squiggly lines telling me I'm doing it wrong. And I couldn't be happier.

Zed is beautiful again. It works the way its creators intended-minimal, fast, considered. The PHP Establishment's opinions are no longer overriding mine every time I open a file.

Native PHP

Here's the thing the PHP Establishment needs to understand: there is now an alternative.

It's called Native PHP. It means writing PHP in the style of PHP - snake_case, same-line braces, no framework dependencies, no committee-approved conventions imported from Java. It's not a rebellion. It's not ignorance. It's a deliberate choice to work with the language as it was designed, not as a working group decided it should be retrofitted.

Native PHP isn't "wrong." It's an entirely different but perfectly legitimate way of working with the language. We're here. We're building things. And from where we're standing, we're the ones using PHP properly.

The PHP Establishment can keep their squiggly lines. We'll keep our sanity.

DC