I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them.
It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing things with the god framework, because each project has to deal with a niche infrastructure environment and/or business context that requires some hack or additional dependency. Then when you need to, say, upgrade a language version, you can't follow the god framework's guide for doing this (if there even is a decent one) because it will break your workaround. So you end up with this hodgepodge which never gets updated until it reaches a critical point where it cannot continue to run on your infrastructure, and it forces a big migration project.
Using a selection of libraries to build up the elements of a web service, and creating your own high-level abstractions for utilizing them, does require an additional time investment, but it leaves you in more control to do upgrades piece by piece, and to pivot the way things work when it is needed.
I feel like the Go ecosystem follows the latter approach more than most, and it was bit of a mindset shift for me at first, but I've grown to appreciate it.
tombert · 3m ago
Web frameworks for me are one of those things that's "great until it isn't".
If you're making a simple app then web frameworks can feel downright magical (like the original "Build a blog in 15 minutes with Rails" demo [1]), but for anything that gets even remotely complicated, I find that they generally just get in the way.
I personally have grown to prefer the "mid-level" HTTP setups, like Express with Node.js or Vert.x with Java.
[1]
zakirullin · 3m ago
PSR to the rescue! For the past ~5 years I've been only using PSR-compatible components, with no framework whatsoever. For both enterprise-grade projects and small services. The reason was the same - those all-encompassing frameworks in long run just don't work. Too many constraints, too much hustle maintaining/updating.
fozdenn · 48m ago
Yep, In my domain only Go/Rust are useful. The opinionated framework culture never fits the bill. I think Rails/Laravel/Django are great when you have a beaten path for relational DB crud.
hu3 · 4h ago
> In short, the modern PHP ecosystem gives us the best of both worlds: the ability to build quickly and confidently in PHP, while still having powerful options (C, Rust, Go) for performance-critical parts. This hybrid approach lets us stay productive without sacrificing speed where it matters most.
I understand this for a large codebase where rewriting is not feasible.
But if that wasn't the case, a C# APIs achieves both speed of development and execution in my experience. You'll rarely need to reach for C++ or Rust.
PHP is great but the language still doesn't allow things like typed arrays. It will happily accept string in a array of dates, for example.
ThinkBeat · 3h ago
Having been in the C# world for a long time, and the various web/api frameworks.
PHP is really nice if you dig into it, it includes so many great
functions and functionality built in for creating web stuff.
It also has a number of issues,. but to quikly put something together
PHP take the win in my limited opnion.
mircerlancerous · 44m ago
Completely agree. I don't work much in PHP anymore, but there's still nothing that's faster or easier to get something up and running. I use it for web services, and command line scripts when I just need something fast.
reactordev · 2h ago
The only reason PHP still exists is because of shared hosting companies and Wordpress.
PHP’s initial appeal was you could do scripting on the server side, “turn off PHP with a ?>” spit out normal html, and “turn back on PHP with a <?php”.
For a beginner programmer, it was simple, easy to understand, and had an include so your designs were’t nested table hairball messes of garbage. (but your CSS was definitely garbage).
Today, it’s so easy to run JavaScript, I can build a basic jsx site in under an hour, just like I can with PHP and includes. With Bun, I can quickly write a data access layer as well and wire up crud APIs w/ JWT auth. A weekend project in both.
hnlmorg · 2h ago
PHP might have a bad reputation but I honestly don’t think JavaScript is a better language in real world terms.
I do get why JS appeals to people, but switching from PHP to JS feels a little winning an internet argument — you might feel smarter for doing so but in reality all you’ve done is sunk time into something that doesn’t make you any better off.
tialaramex · 1h ago
There's a firm foundation in Javascript. The choices aren't choices I'd make but they're choices I understand. Brendan Eich knew what he was doing and it shows, indeed if it was made simply of bailing wire and string it'd have been replaced.
For PHP on the other hand - even when I started writing PHP3 - so certainly not the very beginnings, it's clearly just cobbling together whatever works from unrelated half-understood parts and so there's no coherent centre to it, when I last worked on some PHP earlier this year it still felt like bailing wire and string.
hnlmorg · 1h ago
The JavaScript invented by Eich is nothing like the clusterfuck that is the modern JavaScript ecosystem. And modern node.js code will look nothing like the JavaScript Eich developed for Mozilla.
Equally, PHP3 is worlds apart from modern PHP.
Your point is a little like saying “motorbikes are easy to maintain because they’re based on the penny-farthing”. Times have changed and your references are literally decades out-of-date.
zelphirkalt · 30m ago
Do we need to post that JS' weird things link here? Of the basics of JS, few things are sound. The "firm foundation" idea doesn't really work for JS. It might even work better for PHP, and I am saying that as someone, who doesn't want to do PHP ever again.
freedomben · 2h ago
I'm not a huge fan of PHP, but for simple sites I think you way underestimate the power and simplicity. It feels old compared to jsx approach, but old doesn't always mean bad. I've increasingly returned to the template rendering model pioneered by PHP and for sites that aren't full blown apps, it is a lot simpler which means faster iteration and reduced cognitive load. I think you really have to decide based on the complexity you need
sublinear · 41m ago
> I think you really have to decide based on the complexity you need
I don't really agree. I think the goal should be to reduce complexity where possible, but not if you're inevitably painting yourself into a corner.
If you want the simplest and most scalable way forward, write static pages and avoid server-side rendering.
zelphirkalt · 26m ago
How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.
sublinear · 1m ago
I'm coming from the perspective of real world business concerns, not hobby projects.
It's inevitable that you will need to host the pages somewhere else like a CDN to lower latency, integrate with other backends, and the biggest one is allowing the frontend devs to have complete control of the HTML so that stylesheets and javascript don't randomly break and they can develop everything locally with mocks instead of your server.
monooso · 2h ago
> The only reason PHP still exists is because of shared hosting companies and Wordpress.
Unfortunately I can't think of anything constructive to say about this nonsense.
> Today, it’s so easy to run JavaScript, I can build a basic jsx site in under an hour, just like I can with PHP and includes.
You assume people agree that it's preferable to work in JavaScript.
k_roy · 1h ago
And still nobody outside of Meta cares about hack.
The niche I think PHP had back in the day has largely been supplanted by Python.
Maybe it’s better now, but after moving on from it to basically anything else after a 25 year career, I don’t miss it.
monooso · 30m ago
I'm not sure what point you're trying to make by mentioning Hack.
At this point it's diverged from PHP to the point that it's basically a different language, is (IIRC) actually slower than PHP 8, and the HHVM doesn't even support PHP any more.
As such, it's not a huge surprise that relatively few people outside of Meta give it much attention.
I also moved on from PHP several years ago, and don't miss it. That doesn't mean I don't recognise that there are still perfectly legitimate reasons to choose it.
jofla_net · 1h ago
>It will happily accept string in a array of dates, for example.
Yeah theres a bunch of oddities that rear their head from time to time.
I've had one peculiar JSON de-serialize bug lately that really threw me for a while. I normally do the json_decode() with the second arg set true, which yields an assoc arr. This doesn't tell the whole story though.
IF the key is numeric when decoding, PHP will make its key an int! and not a string like the rest. I'm guessing it does the equivalent of an is_numeric() check or something.
This yields an array with keys which could be ints and strings :/
Still for all its warts though it is a fantastically Frankenstein of a language!
newuser94303 · 24m ago
I would never use a Microsoft language since they discontinued VB6. Open Source languages are the only sane option.
honorary-hickup · 4h ago
> It will happily accept string in a array of dates, for example
While completely true, you are using static analyzer anyway which won’t let you do this.
I'm working in PHP for about 15 years by now, and for about 10 of them I was promised generics. In favor of your health, don't hold your breath.
1a527dd5 · 2h ago
Joined {{company}} when everything was using 5.4, there was a big distaste of PHP back then.
But as PHP have released newer versions I'm convinced our migration away from PHP (which is just finishing) is probably a step backwards _now_ that PHP is awesome.
Everyone still thinks it is like 5.x days, it really isn't.
criemen · 2h ago
I'm not so sure: If you think about hiring talent, there's a perception in the wider industry about PHP (rightly or wrongly, let's not debate that here) that'll prevent access to a lot of great developers. So even if not warranted anymore on technical merits anymore, in terms of employer branding, I'd say migrating away from PHP is helping.
adamors · 1h ago
Right on, I wrote a lot of PHP 15 years ago and I swore I’ll never get back to it. I’m a much better developer now and I’ll actively avoid any company doing PHP in 2025.
tomrod · 1h ago
PHP is growing on me. I'll have to check it out -- thanks for the idea!
klaussilveira · 3h ago
Pasir is like frankenphp, but in Rust. Very promising, but still early in development:
There's also all sorts of interesting experiments, like ngx-php, which basically embeds PHP via Zend API inside an nginx binary: https://github.com/rryqszq4/ngx-php
The complexity with debugging and maintenance seem to be overlooked, if you have the option don't do this.
osigurdson · 2h ago
Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints.
It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.
timschmidt · 51m ago
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it.
I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users.
I am really happy with WASM / WebGL for being abstractions which allows for this.
singinwhale · 1h ago
Thinking about user seeing pixels is seeing just a part of the picture. As all software projects you don't optimize just for immediate user experience but also development time.
Time to first draw rarely coincides with development time.
redwall_hp · 1h ago
And I don't care about pixels; I want to see structured documents. How I choose to view those is my business.
forgotmypw17 · 53m ago
I do this with Perl.
One of the reasons I like Perl is because of its high committment to backwards compatibility.
I like PHP because it's so easy to set up an installation of my app, but the breaking changes have bit me hard in the past, so I try to minimize its use.
Together, it's a great combo.
trog · 2h ago
Very curious what sort of workloads are being talked about here that have the intensity that have C or Rust or Go extensions are necessary? I can certainly believe they exist but I'd be really interested to find out more and why it makes sense to add this complexity into the stack and not solve in other ways.
dakiol · 3h ago
The one thing I don't like about PHP is that the whole application is bootstraped (and autoloading and the configuration is re-evaluated) in every single http request. Sure thing there's cache and all, but it just doesn't feel right (compared, to, for instance, an http server written in golang)
klaussilveira · 3h ago
There are well documented and production-ready libraries that you can use to run your own servers with PHP alone, no need for fpm or mod_php. PHP's JIT is pretty impressive and you would be blown away by the results.
This is one of the best things about PHP IMO. It makes it very easy to scale out.
mhsdef · 2h ago
This is one of the things I do like about PHP.
Intrinsically minimized state (to a certain degree).
thr0waway001 · 4h ago
Good to see PHP still trucking.
preinheimer · 2h ago
Reminds me of how Yahoo! worked back in the day. All their display logic in PHP, with the hard business logic in c extensions.
ok123456 · 4h ago
It turned out that dlopen was the "microservice" architecture we needed all along.
porker · 3h ago
PHP's FFI support is a feature that's 2/3 there and isn't seeing improvements. It makes me miss Python's cffi.
dingdingdang · 2h ago
Bet you don't miss Python's massively lackluster performance when compared to PHP though! Nb. I use both for diff things (good luck instrumenting ai stuff with PHP!) but the fact that I have to reach for C extensions for python to even get a basic loop to run at reasonable speed remains peculiar/scary for me.
maurice2k · 2h ago
There's also RoadRunner, a more PHP like alternative to FrankenPHP:
I bit the bullet rewriting my app from PHP to Go and it paid off for my company, we're talking 20K lines of PHP code, reduced to 4K lines of Go and with the added efficiency gains with it.
I think some orgs just need to take the jump and plan a rewrite, add tests (easier with Go) and just do this if they are a PHP shop, I would say it's worth it.
Instead of blending Rust/PHP or Go together and having an unmaintainable mess of a codebase.
criemen · 3h ago
How did you reduce LoC with a move from PHP to go?
Go is a pretty verbose language, whereas for me PHP is somewhere in the middle of the pack in terms of verbosity (Haskell would be on the terse side, enterprise Java and Go on the verbose end, particularly due to the constant error-checking after every function call).
NeutralForest · 4h ago
But the question always is: was the rewrite the reason for the gained efficiency, or the new language?
colesantiago · 3h ago
Both.
Go made this worth it and it also was easy to hand over to another experienced developer.
coolgoose · 2h ago
I fail to see how you got 5x lower loc from php to go.
Php isn't perfect but it has a lot of shortcut syntaxes that go just doesn't have
tayo42 · 3h ago
Surprised you made it more compact and not have it turn into 40k lines of if err! = nil
Ive done do rewrites of stuff in python and it gets really verbose, plus dependency injection patterns for testing.
benjiro · 2h ago
A ton of stuff in PHP is mostly templating + DB calls for a lot of websites.
If you combine Go + Templ for instance, your "if err" are mostly on the DB calls. What you needed to check in PHP anyway.
Yes, the if err != nil is extreme frustration when your doing for instance, type conversion. But if your already doing this with reflection in your DB calls (by casting to the correct types in your struct), that saves a ton.
Same with getting external data, casting it directly to structs and if something is wrong, its a single "if err".
And if your just doing PHP style programming in Go, well, _, ignoring errors like PHP does and you can panic/recover to make Go act as badly as PHP, to save on the "if err". ;-)
It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing things with the god framework, because each project has to deal with a niche infrastructure environment and/or business context that requires some hack or additional dependency. Then when you need to, say, upgrade a language version, you can't follow the god framework's guide for doing this (if there even is a decent one) because it will break your workaround. So you end up with this hodgepodge which never gets updated until it reaches a critical point where it cannot continue to run on your infrastructure, and it forces a big migration project.
Using a selection of libraries to build up the elements of a web service, and creating your own high-level abstractions for utilizing them, does require an additional time investment, but it leaves you in more control to do upgrades piece by piece, and to pivot the way things work when it is needed.
I feel like the Go ecosystem follows the latter approach more than most, and it was bit of a mindset shift for me at first, but I've grown to appreciate it.
If you're making a simple app then web frameworks can feel downright magical (like the original "Build a blog in 15 minutes with Rails" demo [1]), but for anything that gets even remotely complicated, I find that they generally just get in the way.
I personally have grown to prefer the "mid-level" HTTP setups, like Express with Node.js or Vert.x with Java.
[1]
I understand this for a large codebase where rewriting is not feasible.
But if that wasn't the case, a C# APIs achieves both speed of development and execution in my experience. You'll rarely need to reach for C++ or Rust.
PHP is great but the language still doesn't allow things like typed arrays. It will happily accept string in a array of dates, for example.
PHP is really nice if you dig into it, it includes so many great functions and functionality built in for creating web stuff.
It also has a number of issues,. but to quikly put something together PHP take the win in my limited opnion.
PHP’s initial appeal was you could do scripting on the server side, “turn off PHP with a ?>” spit out normal html, and “turn back on PHP with a <?php”.
For a beginner programmer, it was simple, easy to understand, and had an include so your designs were’t nested table hairball messes of garbage. (but your CSS was definitely garbage).
Today, it’s so easy to run JavaScript, I can build a basic jsx site in under an hour, just like I can with PHP and includes. With Bun, I can quickly write a data access layer as well and wire up crud APIs w/ JWT auth. A weekend project in both.
I do get why JS appeals to people, but switching from PHP to JS feels a little winning an internet argument — you might feel smarter for doing so but in reality all you’ve done is sunk time into something that doesn’t make you any better off.
For PHP on the other hand - even when I started writing PHP3 - so certainly not the very beginnings, it's clearly just cobbling together whatever works from unrelated half-understood parts and so there's no coherent centre to it, when I last worked on some PHP earlier this year it still felt like bailing wire and string.
Equally, PHP3 is worlds apart from modern PHP.
Your point is a little like saying “motorbikes are easy to maintain because they’re based on the penny-farthing”. Times have changed and your references are literally decades out-of-date.
I don't really agree. I think the goal should be to reduce complexity where possible, but not if you're inevitably painting yourself into a corner.
If you want the simplest and most scalable way forward, write static pages and avoid server-side rendering.
It's inevitable that you will need to host the pages somewhere else like a CDN to lower latency, integrate with other backends, and the biggest one is allowing the frontend devs to have complete control of the HTML so that stylesheets and javascript don't randomly break and they can develop everything locally with mocks instead of your server.
Unfortunately I can't think of anything constructive to say about this nonsense.
> Today, it’s so easy to run JavaScript, I can build a basic jsx site in under an hour, just like I can with PHP and includes.
You assume people agree that it's preferable to work in JavaScript.
The niche I think PHP had back in the day has largely been supplanted by Python.
Maybe it’s better now, but after moving on from it to basically anything else after a 25 year career, I don’t miss it.
At this point it's diverged from PHP to the point that it's basically a different language, is (IIRC) actually slower than PHP 8, and the HHVM doesn't even support PHP any more.
As such, it's not a huge surprise that relatively few people outside of Meta give it much attention.
I also moved on from PHP several years ago, and don't miss it. That doesn't mean I don't recognise that there are still perfectly legitimate reasons to choose it.
Yeah theres a bunch of oddities that rear their head from time to time.
I've had one peculiar JSON de-serialize bug lately that really threw me for a while. I normally do the json_decode() with the second arg set true, which yields an assoc arr. This doesn't tell the whole story though. IF the key is numeric when decoding, PHP will make its key an int! and not a string like the rest. I'm guessing it does the equivalent of an is_numeric() check or something.
This yields an array with keys which could be ints and strings :/
Still for all its warts though it is a fantastically Frankenstein of a language!
While completely true, you are using static analyzer anyway which won’t let you do this.
The generics support will likely come in the near future, there has been momentum in it again: https://thephp.foundation/blog/2025/08/05/compile-generics/
But as PHP have released newer versions I'm convinced our migration away from PHP (which is just finishing) is probably a step backwards _now_ that PHP is awesome.
Everyone still thinks it is like 5.x days, it really isn't.
https://github.com/el7cosmos/pasir
Which uses the following Zend API bindings for Rust:
https://github.com/davidcole1340/ext-php-rs
There's also all sorts of interesting experiments, like ngx-php, which basically embeds PHP via Zend API inside an nginx binary: https://github.com/rryqszq4/ngx-php
And workerman, which has a hybrid backend of asio libraries, so you can get pretty fast runtimes: https://github.com/walkor/workerman
It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.
I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users.
I am really happy with WASM / WebGL for being abstractions which allows for this.
One of the reasons I like Perl is because of its high committment to backwards compatibility.
I like PHP because it's so easy to set up an installation of my app, but the breaking changes have bit me hard in the past, so I try to minimize its use.
Together, it's a great combo.
https://reactphp.org/
https://www.php.net/manual/en/book.ev.php
https://bitbucket.org/osmanov/pecl-event
https://www.workerman.net/
https://frankenphp.dev/docs/worker/
Intrinsically minimized state (to a certain degree).
https://roadrunner.dev/
I think some orgs just need to take the jump and plan a rewrite, add tests (easier with Go) and just do this if they are a PHP shop, I would say it's worth it.
Instead of blending Rust/PHP or Go together and having an unmaintainable mess of a codebase.
Go is a pretty verbose language, whereas for me PHP is somewhere in the middle of the pack in terms of verbosity (Haskell would be on the terse side, enterprise Java and Go on the verbose end, particularly due to the constant error-checking after every function call).
Go made this worth it and it also was easy to hand over to another experienced developer.
Php isn't perfect but it has a lot of shortcut syntaxes that go just doesn't have
Ive done do rewrites of stuff in python and it gets really verbose, plus dependency injection patterns for testing.
If you combine Go + Templ for instance, your "if err" are mostly on the DB calls. What you needed to check in PHP anyway.
Yes, the if err != nil is extreme frustration when your doing for instance, type conversion. But if your already doing this with reflection in your DB calls (by casting to the correct types in your struct), that saves a ton.
Same with getting external data, casting it directly to structs and if something is wrong, its a single "if err".
And if your just doing PHP style programming in Go, well, _, ignoring errors like PHP does and you can panic/recover to make Go act as badly as PHP, to save on the "if err". ;-)