PHP Is Legacy, in 2024(developer.vonage.com)
developer.vonage.com
PHP Is Legacy, in 2024
https://developer.vonage.com/en/blog/php-is-legacy-in-2024
25 comments
Of course it is not. I see more clients moving back to it or moving to it for the first time. People, rightfully so imho, are starting to hate nextjs (and react is getting a bit of that). It is so much easier to get something running without errors in the logs, for years at a time, and without weird frontend bugs with laravel than it is with nextjs/react. And people are starting to see that; usually after having multiple projects in nextjs over the years, teams changed and disappeared and then someone redeploys, nothing works and there we are.
> get something running without errors in the logs, for years at a time
This is something you only begin to appreciate if you've been through a couple of economic recessions. Not everybody has money and manpower to keep their website up to date every other month! A well-built app for a typical business should be able to coast along through the lifetime of, say, an Ubuntu LTS release without much effort.
This is something you only begin to appreciate if you've been through a couple of economic recessions. Not everybody has money and manpower to keep their website up to date every other month! A well-built app for a typical business should be able to coast along through the lifetime of, say, an Ubuntu LTS release without much effort.
This especially (in our experience) goes for partner-facing LoBs. Like a SaaS for your business partners, clients etc. A large companies might have 1000s of these. We get clients with 'so we have 600 applications and something is wrong with many of them after xyz'. These apps usually don't update ever but they are vital for departmental workflows and they are complex enough not to bin them and rewrite them (especially in these quantities).
The meme stacks you see every week on HN will come and go, but PHP will stay.
> the closest someone will probably give as an explanation is a massive rambling blog post written years ago
That blog post is long, but definitely not rambling, and unlike the above quote, is done in good faith. PHP night have improved, but if it has it will likely have used that blog post as a reference.
That blog post is long, but definitely not rambling, and unlike the above quote, is done in good faith. PHP night have improved, but if it has it will likely have used that blog post as a reference.
For context, this is the blog post in question:
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Ugh, that article. It took a few good points that represented real practical annoyances for working with the language, it added a monumental helping of perfectly dense refusal to consider merits that made PHP successful, and then when combined with investments programmers had made in other languages and cultural momentum took on an oversized undeserved life of its own.
Kinda ironic that because of this post I went to check out php.net for the first time in like a decade, and it turns out the site is down. Doesn't exactly instill confidence that the project is alive and well.
I cannot find a decent service to tell when the outage started. (One of those services has apparently the same exact problem - same interface and error - as php.net )
The best I found: it was up three days ago; unclear when it happened within the last ~70 hours.
The best I found: it was up three days ago; unclear when it happened within the last ~70 hours.
maybe they are updating their php to 8.4
and it's still down.
[deleted]
One thing PHP got right is its 'PHP must die' mode of operation where every request spawns a new process (ok, not a process anymore but still an isolated execution environment that lasts until the response is served.
Java, Ruby, C#, etc are application servers and this massively complicates everything.
Java, Ruby, C#, etc are application servers and this massively complicates everything.
Maybe I was holding it wrong but I found a new Laravel project out of the box takes notable time to respond to hello world HTTP requests, and to me it looks like all the time is spent loading code on each request.
I have heard a lot of praise for both laravel and php and I still reserve judgement, but since trying it out I take all the performance claims one way or another with 100% my daily recommended intake of salt.
I have heard a lot of praise for both laravel and php and I still reserve judgement, but since trying it out I take all the performance claims one way or another with 100% my daily recommended intake of salt.
Maybe I was holding it wrong but I found a new Laravel project out of the box takes notable time to respond to hello world HTTP requests, and to me it looks like all the time is spent loading code on each request
The one-process-per-request model, even with php-fpm and other optimisations, it’s incredibly expensive to scale.
Modern java on a recent jvm (>=17) is incredibly scalable in comparison.
Modern java on a recent jvm (>=17) is incredibly scalable in comparison.
I understand your technical argument.
However.
I've spent many years doing PHP and Java-based development. Often times in parallel, having PHP projects on the side and earning money in Java development.
At some point, I had a stint of several years doing exclusively PHP-based work.
Every single time, my PHP projects were serving orders of magnitude more people orders of magnitude cheaper than Java-based projects.
And when I say "orders of magnitude", it is not an exaggeration but sad truth.
I am now in the Java land again, because pay is better. My current project has already burnt several millions serving 20 secretaries that handle 1000 individual cases each year.
My mind is with the PHP project I sold several years ago when it was serving 120,000 people at the cost of a few hundred euros per year + my labor, which was essentially free, but if I could slap my usual daily rate on it, it would still be somewhere between 20,000 and 30,000€/year.
However.
I've spent many years doing PHP and Java-based development. Often times in parallel, having PHP projects on the side and earning money in Java development.
At some point, I had a stint of several years doing exclusively PHP-based work.
Every single time, my PHP projects were serving orders of magnitude more people orders of magnitude cheaper than Java-based projects.
And when I say "orders of magnitude", it is not an exaggeration but sad truth.
I am now in the Java land again, because pay is better. My current project has already burnt several millions serving 20 secretaries that handle 1000 individual cases each year.
My mind is with the PHP project I sold several years ago when it was serving 120,000 people at the cost of a few hundred euros per year + my labor, which was essentially free, but if I could slap my usual daily rate on it, it would still be somewhere between 20,000 and 30,000€/year.
The title is clickbait (no surprise there!).
PHP has its warts, but it also has uses and it is often still my go-to language when developing for web. That is, when I do not go for OpenResty (Lua) or Elixir (Phoenix). Sometimes what I really want is PHP.
PHP has its warts, but it also has uses and it is often still my go-to language when developing for web. That is, when I do not go for OpenResty (Lua) or Elixir (Phoenix). Sometimes what I really want is PHP.
I guess the people who flagged the post have read just its title.
I hate PHP as a language. However as an Infra guy, it is very performant and easy to scale. Laravel is also an incredible framework.
What is it about Laravel specifically that you like?
Also, since we're on the topic, I notice that the article also boosts it specifically as an advantage in scaling php ("Fathom's case shows that you can [scale] very effectively with an arsenal of tooling that comes from Laravel.").
This is a surprise to me. Why would the scaling capability come from a framework (generally a collection of code that's essentially executed from within the runtime)? I would expect performance scaling to come from runtime extensions or parameter tweaking or alternate runtimes.
Also, since we're on the topic, I notice that the article also boosts it specifically as an advantage in scaling php ("Fathom's case shows that you can [scale] very effectively with an arsenal of tooling that comes from Laravel.").
This is a surprise to me. Why would the scaling capability come from a framework (generally a collection of code that's essentially executed from within the runtime)? I would expect performance scaling to come from runtime extensions or parameter tweaking or alternate runtimes.
Should you re-submit it, put the original title within the quotes for "read interpreting, not literally" rhetoric,
"PHP is Legacy, in 2024"
This is an exception that calls to be editorialized. The original title is as-if a quote, which the original writers omitted to mark as such.
"PHP is Legacy, in 2024"
This is an exception that calls to be editorialized. The original title is as-if a quote, which the original writers omitted to mark as such.
Stuff becomes legacy not because of the language, but because of outdated libraries or frameworks or unavailable/uninterested developers. For me PHP is legacy, because I refused to work on PHP codebases, except I find someone who's willing to do the job for me.
Clickbait: it is not
Uh no, WordPress is here to stay.