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 · 6h 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]
evantbyrne · 4h ago
The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being able to map/filter/reduce from a result type into another generic type would be a complete game changer. Being able specify union types would eliminate my need for the "any" type. Being able to overload would clean up a lot of code. It needs more time in the oven.
overfeed · 3h ago
> The reason Go does not have a grand framework is that the language has a severely underdeveloped type system
Counterpoint: PHP.
PHP 5.3 had an even less capable type system, but developed several usable frameworks.
evantbyrne · 3h ago
That's a complimentary point, not a counterpoint. I'm talking about Go's type system being restrictive. PHP and many other languages avoided that particular trap by allowing variables to be reassigned to any type. Java and many other languages went in a different direction and instead chose to build more complete type systems.
3eb7988a1663 · 5h ago
In the Python world, I see this as the microframework (Flask-esque) vs macroframework (Django). I will take Django every single time.
Flask prescribes so little that every project is a snow flake. Which of the N available options will you pick to handle auth/templating/cookies/email/whatever. Real decision fatigue when trying to enable core functionality. Extra special is that many of these libraries are single author creations, so maintenance and security are a mixed bag.
Django - every project roughly looks the same. You get so much out of the box that you must have special requirements if you must supplement with libraries. Since so many bits are first party, you have greater confidence that code is being maintained/checked for security problems.
fozdenn · 7h 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.
zakirullin · 6h 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.
b_e_n_t_o_n · 5h ago
I've found this for web frameworks as well. The time you spend learning the framework's abstractions could just be spent picking a queue library or whatever you need and adding it to your Go server.
N2yhWNXQN3k9 · 3h ago
In Laravel, the issue is that the framework is sold as "productive" as default. There is no real "beef" to the framework though, IMO. It is better today, but historically it is just a wrapper around symfony with some dependency injection through reflection, questionable serde, tons of magic, and with some unique takes on templates and routing, which are arguably not very good takes? Maybe components are better, but blade in general seems backwards as a template language.
Ever want to type `$model->foo instead of $model->getFoo()` but then have `$model->foo` magically call `$model->getFooAttribute()`, but fall back to `$model->getAttribute('foo')` if that method doesn't exist? Then that magically calls some casting methods, and possibly even fetches infinite records from a remote store? It is so artisan, bro. I can tell you more if you got five minutes.
some_furry · 1h ago
> 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.
Can you give any specific examples?
I'd like to see which of these are open source. And whether or not they're funded for maintenance.
hu3 · 10h 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 · 10h 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 · 7h 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 · 9h 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 · 9h 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 · 8h 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 · 7h 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 · 7h 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.
com2kid · 5h ago
JS is very much a minimal language that has a handful of choices. E.g. arrays being objects with field names that are sequentially numbered integers.
The initial equality operator was a mistake, but that was rectified over a decade ago with `===`. Not having a proper int type sucks and holds the language back in a number of ways, but otherwise the language is wonderfully regular.
And anyone who complains about the ecosystem has obviously never tried python, which after a decade of attempts, is now almost on par with JS of a decade ago!
austhrow743 · 5h ago
What if the context isn't that you're switching from PHP though? What if the choice is to stick with Javascript for the full stack, or to also learn PHP on top of Javascript?
phplovesong · 6h ago
JS is basically just a comp target as of 2025. If PHP devs used something like Haxe they would be amazed how safe their programs would be. But i usually just see slop instead.
freedomben · 9h 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 · 7h 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 · 7h 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.
reactordev · 5h ago
The issue is, if I’m using JS, why on earth would I ever use PHP? I can just await file('index.html') or return <IndexPage>
The cognitive load is null. You’re just having trouble breaking apart your learned behavior. Returning a component of jsx is just the same as writing an include for PHP.
sublinear · 6h 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 for reasons out of their control. They should be able to develop everything locally with mocks instead of your server and use whatever build tools and frameworks they want. There are also SEO and accessibility concerns with the page structure. The backend devs should not be making decisions about any of that. Sometimes the client may want quick turnaround on simple but very specific changes to the pages. None of that process should depend on backend teams who don't care and will drag ass about it because they will have to refactor their junky code that hasn't been touched in years.
Getting rid of dependencies and having good boundaries in the code that align with the way dev teams are organized is always a good thing. I'm not sure why anyone would go for SSR unless they haven't done web dev in a while or are working on a legacy project. Even if this starts out as a hobby project, you need to keep things clean for future maintainers.
reactordev · 5h ago
I agree with all of that except for SSR part. SSR is back, like it’s 1996. However this isn’t your old school monolith serving jsp pages with tag classpath hell, this is client side pages served from the server for faster rendering. We now have another layer.
Browser -> Client-Side Server Pages -> Business Logic APIs -> Backend Systems.
monooso · 9h 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.
phplovesong · 6h ago
Sadly this is true. From PHP websites 95% is wordpress/drupal/<cmstool>
k_roy · 7h 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 · 7h 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.
k_roy · 5h ago
Yep.
And meta/hack is probably the other huge mainstay of PHP outside of what the person you responded to said. And hack with HHVM was supposed to be the panacea for PHP
Just saying.
What people used to use PHP for tasks, has largely been replaced by Python.
timeon · 6h ago
> And still nobody outside of Meta cares about hack.
Because everyone is OK with PHP. I'm not even using it directly but most of the web runs on it.
phplovesong · 5h ago
Not PHP, but wordpress.
jofla_net · 8h 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!
honorary-hickup · 10h 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.
newuser94303 · 7h ago
I would never use a Microsoft language since they discontinued VB6. Open Source languages are the only sane option.
chairmansteve · 6h ago
C# is open source.
1a527dd5 · 8h 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 · 8h 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 · 8h 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 · 8h ago
PHP is growing on me. I'll have to check it out -- thanks for the idea!
klaussilveira · 10h 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
Does any of this have some kind of support of existing PHP modules?
imcritic · 2h ago
FrankenPHP sounds promising, but in reality it is a weirdo: no one uses PHP without modules. Where is the list of PHP modules supported by FrankenPHP? Is it possible to compile it with some extra PHP modules? How? I see it is tightly bound to Caddy. I am not much familiar with that webserver, I would prefer nginx, but there's not a single guide mentioning if that's possible to use nginx with FrankenPHP (as a php-fpm replacement). Also, either Caddy itself, or FrankenPHP's docker image is quite opinionated in regards to using let's encrypt certificates and it is not trivial at all how to make it work via HTTP (if something external would provide SSL) or using own certificate.
supriyo-biswas · 2h ago
> FrankenPHP sounds promising, but in reality it is a weirdo: no one uses PHP without modules.
You usually build the modules yourself in the Dockerfile, for example for the "pgsql" module:
And for http, you just put the following in the Caddyfile:
http://:80 {
# rest of the Caddyfile directives
}
conceptme · 10h ago
The complexity with debugging and maintenance seem to be overlooked, if you have the option don't do this.
RainyDayTmrw · 3h ago
One of these is not like the other. Go is also garbage collected. Embedding a garbage collected language inside another means you have two garbage collectors fighting each other.
osigurdson · 8h 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 · 7h 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.
osigurdson · 4h ago
This! Love it!
timschmidt · 4h ago
Thank you. There is still a lot of work left to get it controlling it's first machine. I am currently figuring out how best to build for all the mcu and board combinations I expect to support, and then wiring up motion control to the UI. Just got the node-graph interface for csgrs working and there's still a lot left to flesh it out fully. Advancing slowly :D
I'm the only one in there at the moment. Bring friends! lol
sneak · 4h ago
I was wondering how long it would take for the web to get to this point. It seemed inevitable once canvas became a thing. You don’t even technically need gl or wasm to rewrite an entire rendering engine in js that can just blast pixels at the full-size canvas.
Cool that you’re creating an actual desktop-style gl app with it.
timschmidt · 4h ago
I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default.
Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to fix up the native build to make use of that sort of analysis, which I'd like, because I serve the whole application from microcontroller flash where I only have 4 - 16mb to hold application and firmware, including the http server and network stack.
sneak · 4h ago
I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over.
I learned how to build for the web by looking at webpages and seeing how they worked. What you're describing is the switch from circuit boards of discrete components to everything in a single microscopic IC under a blob of epoxy.
timschmidt · 3h ago
I recognize it as a more or less universal optimization process. Everything important ends up in silicon, if it remains important long enough. And there are several stages of that.
Like you, a part of me years for SGML and The Semantic Web, and where it makes sense in Alumina I am using RESTish APIs.
But I do not pine for Javascript. Language or frameworks. 20 years has been enough. And I do not believe that some of the 4mb minified obfuscated js downloads from a CDN I've seen are in any way more accessible than a WASM binary of similar size. At least there is advanced tooling for the WASM representation. Folks who want you to read their code will still make it easy, and folks who don't won't.
To your point about learning, WASM makes some really incredible systems like https://lovr.org/ available in the browser, which I would have loved to have as a kid, but which also aren't javascript. It's related to Turing completeness somehow, once you let a little software into your structured document, it all wants in. Or maybe it's "if you give a mouse a cookie"?
I understand what you're saying about discoverability. But the developer in me really likes having a relatively simple binary interpreter to target for network-delivered cross-platform binary applications. My hope is that offering such a juicy target to the folks who want to develop applications (including myself) gets them out of all the semantic document features, allowing both sets of code to get simpler and more focused. Because I think they're two different, both entirely valid, tasks folks use the web for.
osigurdson · 3h ago
If you look at a typical next.js type app with all of the build steps, minification, post-css, tree-shaking, client side / server side, etc., it isn't exactly optimized for reverse engineering. Maybe that ship has already sailed.
singinwhale · 8h 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.
osigurdson · 4h ago
Dealing with over-fetch / under-fetch most certainly does chew up development time. Creating endless api endpoints that are only used by the web UI is also very time consuming (the industry is finally recognizing how dumb this is and moving back to older SSR approaches). How about, "the user is allowed to access this information on the server - system you figure out what / when to fetch portions of this information for viewing"?
redwall_hp · 8h ago
And I don't care about pixels; I want to see structured documents. How I choose to view those is my business.
osigurdson · 42m ago
Got it, you don't care about how the sausage is made. That's totally fine.
trog · 9h 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.
vadepaysa · 4h ago
I owe a large part of my career success to PHP when I learned it back in the day. But recently I picked it up because I had to do some maintenance work and The package management experience was really, really bad.
I really think there's a big opportunity for somebody to create the astral.sh for PHP.
With a proper package manager, PHP can do way more than what it presently can.
porker · 27m ago
What did you find bad about composer?
dakiol · 10h 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 · 10h 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.
bornfreddy · 1h ago
Yup. No shared state by default.
mhsdef · 9h ago
This is one of the things I do like about PHP.
Intrinsically minimized state (to a certain degree).
creatonez · 4h ago
You're right. It's a completely asinine approach. Especially when PHP itself is used as a templating language.
And solutions that try to fix this (custom templating engines, runtimes that run the whole thing inside a continuous PHP process) are simply putting lipstick on a pig.
The solution is to use a language that wasn't originally called "Personal HomePage"
thr0waway001 · 10h ago
Good to see PHP still trucking.
ok123456 · 10h ago
It turned out that dlopen was the "microservice" architecture we needed all along.
preinheimer · 9h 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.
forgotmypw17 · 7h 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.
phplovesong · 5h ago
How is php easy to setup?
forgotmypw17 · 1h ago
Step 1: Copy the files.
Step 2: (There is no step 2.)
porker · 10h 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 · 8h 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 · 9h ago
There's also RoadRunner, a more PHP like alternative to FrankenPHP:
When I do stuff like this, I just write the front app in the new/fast language, then reproxy the stuff not written in the fast language to the legacy app. You can even add middlewares or caching or metrics in the new app for requests going to the old one, as you can run (fast) code around both the request and the response.
It’s the best of both worlds - the new app gets to see all of the traffic, but doesn’t need to implement 100% of the routes. Any added to the new app can just take precedence over the old one, carving out the path-space that gets reverse proxied.
It seems like doing FFI for this is overly complex; I’d rather take the small perf hit of doing another request to a different process.
colesantiago · 10h ago
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 · 10h 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).
coolgoose · 9h 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
NeutralForest · 10h ago
But the question always is: was the rewrite the reason for the gained efficiency, or the new language?
colesantiago · 10h ago
Both.
Go made this worth it and it also was easy to hand over to another experienced developer.
tayo42 · 10h 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 · 8h 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". ;-)
77pt77 · 5h ago
The fact that we're still pretending PHP is a valid solution for almost anything after all these years is a joke.
Not only that, but now we have these "frankenstein" solutions with all the interop problems on top of PHP.
Just shows that as a species humans really can't learn.
phendrenad2 · 5h ago
PHP really isn't that different from Ruby or Python these days. But, I can see the perspective where none of those 3 are valid solutions given newer better options like NodeJS and Rust.
sneak · 4h ago
Yeah, I use php colab all of the time to run numpy stuff on gpus, I learned about it in my php data science class in university.
They’re basically equivalent now.
phendrenad2 · 3h ago
You're right, there is one area where Python has an advantage over PHP, but it has nothing to do with the language, really, and more to do with tools people have built to transform the language for other purposes. So it's sort of like saying Python and Ruby are completely different because Rails exists for one and not the other.
sublinear · 6h ago
This sounds absolutely disgusting to maintain. Where are you going to hire devs that want to work on crap like this?
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]
Counterpoint: PHP.
PHP 5.3 had an even less capable type system, but developed several usable frameworks.
Flask prescribes so little that every project is a snow flake. Which of the N available options will you pick to handle auth/templating/cookies/email/whatever. Real decision fatigue when trying to enable core functionality. Extra special is that many of these libraries are single author creations, so maintenance and security are a mixed bag.
Django - every project roughly looks the same. You get so much out of the box that you must have special requirements if you must supplement with libraries. Since so many bits are first party, you have greater confidence that code is being maintained/checked for security problems.
Ever want to type `$model->foo instead of $model->getFoo()` but then have `$model->foo` magically call `$model->getFooAttribute()`, but fall back to `$model->getAttribute('foo')` if that method doesn't exist? Then that magically calls some casting methods, and possibly even fetches infinite records from a remote store? It is so artisan, bro. I can tell you more if you got five minutes.
Can you give any specific examples?
I'd like to see which of these are open source. And whether or not they're funded for maintenance.
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.
The initial equality operator was a mistake, but that was rectified over a decade ago with `===`. Not having a proper int type sucks and holds the language back in a number of ways, but otherwise the language is wonderfully regular.
And anyone who complains about the ecosystem has obviously never tried python, which after a decade of attempts, is now almost on par with JS of a decade ago!
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.
The cognitive load is null. You’re just having trouble breaking apart your learned behavior. Returning a component of jsx is just the same as writing an include for PHP.
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 for reasons out of their control. They should be able to develop everything locally with mocks instead of your server and use whatever build tools and frameworks they want. There are also SEO and accessibility concerns with the page structure. The backend devs should not be making decisions about any of that. Sometimes the client may want quick turnaround on simple but very specific changes to the pages. None of that process should depend on backend teams who don't care and will drag ass about it because they will have to refactor their junky code that hasn't been touched in years.
Getting rid of dependencies and having good boundaries in the code that align with the way dev teams are organized is always a good thing. I'm not sure why anyone would go for SSR unless they haven't done web dev in a while or are working on a legacy project. Even if this starts out as a hobby project, you need to keep things clean for future maintainers.
Browser -> Client-Side Server Pages -> Business Logic APIs -> Backend Systems.
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.
And meta/hack is probably the other huge mainstay of PHP outside of what the person you responded to said. And hack with HHVM was supposed to be the panacea for PHP
Just saying.
What people used to use PHP for tasks, has largely been replaced by Python.
Because everyone is OK with PHP. I'm not even using it directly but most of the web runs on 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
You usually build the modules yourself in the Dockerfile, for example for the "pgsql" module:
And for http, you just put the following in the Caddyfile: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.
Please consider joining the Discord: https://discord.com/invite/cCHRjpkPhQ
I'm the only one in there at the moment. Bring friends! lol
Cool that you’re creating an actual desktop-style gl app with it.
Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to fix up the native build to make use of that sort of analysis, which I'd like, because I serve the whole application from microcontroller flash where I only have 4 - 16mb to hold application and firmware, including the http server and network stack.
I learned how to build for the web by looking at webpages and seeing how they worked. What you're describing is the switch from circuit boards of discrete components to everything in a single microscopic IC under a blob of epoxy.
Like you, a part of me years for SGML and The Semantic Web, and where it makes sense in Alumina I am using RESTish APIs.
But I do not pine for Javascript. Language or frameworks. 20 years has been enough. And I do not believe that some of the 4mb minified obfuscated js downloads from a CDN I've seen are in any way more accessible than a WASM binary of similar size. At least there is advanced tooling for the WASM representation. Folks who want you to read their code will still make it easy, and folks who don't won't.
To your point about learning, WASM makes some really incredible systems like https://lovr.org/ available in the browser, which I would have loved to have as a kid, but which also aren't javascript. It's related to Turing completeness somehow, once you let a little software into your structured document, it all wants in. Or maybe it's "if you give a mouse a cookie"?
I understand what you're saying about discoverability. But the developer in me really likes having a relatively simple binary interpreter to target for network-delivered cross-platform binary applications. My hope is that offering such a juicy target to the folks who want to develop applications (including myself) gets them out of all the semantic document features, allowing both sets of code to get simpler and more focused. Because I think they're two different, both entirely valid, tasks folks use the web for.
I really think there's a big opportunity for somebody to create the astral.sh for PHP.
With a proper package manager, PHP can do way more than what it presently can.
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).
And solutions that try to fix this (custom templating engines, runtimes that run the whole thing inside a continuous PHP process) are simply putting lipstick on a pig.
The solution is to use a language that wasn't originally called "Personal HomePage"
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.
Step 2: (There is no step 2.)
https://roadrunner.dev/
It’s the best of both worlds - the new app gets to see all of the traffic, but doesn’t need to implement 100% of the routes. Any added to the new app can just take precedence over the old one, carving out the path-space that gets reverse proxied.
It seems like doing FFI for this is overly complex; I’d rather take the small perf hit of doing another request to a different process.
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).
Php isn't perfect but it has a lot of shortcut syntaxes that go just doesn't have
Go made this worth it and it also was easy to hand over to another experienced developer.
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". ;-)
Not only that, but now we have these "frankenstein" solutions with all the interop problems on top of PHP.
Just shows that as a species humans really can't learn.
They’re basically equivalent now.