![[No PHPun Intended] A Brief History of Web Development](https://nophpunintended.com/comics/a-brief-history-of-web-development.png){kind=link}
Yep, PHP is turning 30 this year! Wondering if “PHP is still relevant?” Ever since we have been hearing that PHP is dead. It was “dead” 10 years ago, 5 years ago, and “is dead” today. But somehow - it isn’t. Anyway… happy birthday!
Yep, PHP is turning 30 this year! Wondering if “PHP is still relevant?” Ever since we have been hearing that PHP is dead. It was “dead” 10 years ago, 5 years ago, and “is dead” today. But somehow - it isn’t. Anyway… happy birthday!
The main issue with PHP is that it’s designed for a pre AJAX web. Before when there was a real distinction between backend and frontend. The idea with PHP is that the server code is responsible of generating HTML on the fly.
Server code generating HTML is icky in modern web development.
it’s what html was designed for. there’s nothing icky about it. with htmx et al the serverside web is coming back in a big way so we can finally drop this react stuff.
Now it was a great while ago I wrote anything in PHP. What icks me is the separation of concern. It has a tendency to cause code that’s concerned with logic and rendering at the same time. The act of moving a button can interfere with the logic, and it obfuscates how the entire website looks like.
Maybe there’s better coding practices to ensure better separation of concern in PHP.
that just sounds like what i hear from react devs.
There’s been a big uptick in interest around SSR lately, so maybe not.
What’s actually icky is making a website an SPA, duplicating business logic in the back and front, when it could perfectly be served as a server side rendered HTML.
What absolutely no. Server side generated code is still king in the right hands. Why have client lift all of thay when server side html rendering basically costs nothing. Even strong js driven front end you can still add much through server side by providing proper hydration paths. Good devs take advantage of both worlds but server side is incredibly powerful today.
AJAX everything is icky. It’s part of what’s made browser tabs take more RAM than a typical desktop had in 1998.
I exercised all client side JavaScript from an app I maintain. It’s fast, clean, and the back button always works. I just checked on one of the more complicated pages, and according to Firefox’s memory profile, it takes about 2.6MB of RAM.
Where PHP really goes wrong is mixing HTML and code by default.
Wow, that really is a light weight! What exercise do you have your code perform to get such impressive results?
No JavaScript, just HTML and CSS. Basically no images. The heaviest page dumps 50 rows of logs in a table.
It’s admittedly a fundamentally simple frontend, but we all know of frontends with a simple job and a not so simple frontend.
Ah, so it sounds like it was more about dieting than exercising.
I was thinking more in the sense of an exercisism.
The belief that exercising one’s code is good? I am certainly all in favor of testing, to be sure!
(Sorry, I have been having some playful fun at your expense: the actual word you have been reaching for is excise, e.g., “If only I had exercised more, then I would not have developed a tumor requiring excision!”)
I believe the huge mistake in HTML wasn’t having some sort of element-level addressability.
People went insane over “the page flashes for 15ms because we have to reload the header and footer and it doesn’t look NAAATIVE!” and the response was to SPA/AJAX everything, inviting a huge Turing-complete nightmare of possibilities when 95% of what peopleneed would be delivered with < form action=“blah” replace_with_response=“#foo” >
That and a dearth of native widgets-- a < combobox > and a < menu > that worked like the system menus might have kept JavaScript as the sick oddity it should be.
I like prerendering :(