What We Lost with PHP and jQuery
84 comments
·June 1, 2025davidmurdoch
timw4mail
There's a generation of developers who have never used bare-metal hardware, and have never built a simple server-generated website.
indigodaddy
Why on earth is a devops dictating this sort of thing?
ebiester
Probably because it's an "Ops" team that controls the keys and uses infrastructure as code rather than devevloper and operations combined as a mentality.
And the ops team has preconfigured systems for single page applications but not MPAs.
davidmurdoch
Yeah, basically this. Not really preconfigured though, from what I can tell (and how long it's taking) but more like they have precedent for an implementation that has passed security audits.
davidmurdoch
I was surprised myself. I think it is because my org doesn't typically need to provision servers with oauth authenticated endpoints. I think they've done it only once before and for some reason standardized the first way as the way.
I just need to ship this tiny tool very quickly (initial server request to delivery is about 5 weeks, but I didn't know they were complicating things this much until about 3 weeks after the initial request), otherwise I wouldn't just give in here.
sam_lowry_
OAuth 2.0 is tricky with static frontends, I concur )
Demiurge
Have we actually lost PHP and jQuery? I don't think so. I mantain some of those website, I don't I'm losing much. If I have a single dynamic page, I might actually use PHP, but if I have a complicated app, I use a framework.
If the "industry" default has new JS/Node powered ecosystem, perhaps some people, including myself, would agree that PHP frameworks are still ahead of the overly modular JS frameworks, there isn't anything like Laravel or Django for the JS world.
But, for simple cases, templates are still very common, including static site generators, but even PHP.
iambateman
I use a modernized version of the PHP+jQuery stack.
It’s Laravel with Alpine (or Vue in some cases).
It retains all the simplicity of classic web development with a lot more sensible tooling and significantly improved language — PHP of today is worlds better than the old days.
There is a lot of gold in the vein of simple web technologies, even if they’re not being propped up by the PR department at billion dollar companies.
graypegg
I do think other tech gets unfairly bound up with jquery in these sorts of posts. It makes it feel more like nostalgia than a real recommendation.
Jquery isn’t going to make anything easier today. It’s definitely contemporary with this age of web development, but the expected standard library in a browser implementation of JavaScript (+css animations triggered by JavaScript) includes all of jquery’s features automatically. What you will get is more complex stack traces and a rather large dependency (large in comparison to no-dependency) that just unlocks a bespoke syntax for other JavaScript features.
Places where you used jquery, can now be just JavaScript. It’s lovely to use like that actually!
Everything else, totally agree with though!
luckylion
The one thing I really miss from jQuery is the fluent interface. $(".someclass").hide() and all of them are hidden. document.querySelectorAll(".someclass").forEach(e => e.style.display = "none") is a lot more verbose. $(".someclass").addClass("something else") translates to document.querySelectorAll(".someclass").forEach(e => {e.classList.add("something");e.classList.add("else");}) so now you either write your own mini-abstraction over DOM methods or use some framework, even if the things you want to do absolutely do not need it.
someothherguyy
classList.add is variadic, so a more honest implementation might be
var _ = s => document.querySelectorAll(s)
_('.someclass').forEach(e => {e.classList.add('something', 'else')})ivape
Nothing touches jQuery's intuitive $.animate. Just about everything has looked absurd since then. It's not really anyone's fault, these frameworks are not as flexible as they were made out to be. Small post-mortem.
someothherguyy
The native animation API isn't that bad, and it is somewhat informed by the jQuery API.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
fjasdfwa
There was an industry shift from stateful monolithic services to slim event-driven microservices in ephemeral environments.
We didn't lose PHP, it's just no longer in the spotlight.
In fact I applied to a Laravel role very recently but they didn't like that most of my recent experience were with Go and Rust and not PHP.
If you want a PHP comeback, hire that Rust engineer that wants to use Laravel!
kyriakos
A lot of people including myself will argue that microservices are a mistake except for a few cases.
vanschelven
So the trick seems to be to find, from the large set of possible technologies that are available, the subset that actually makes things simpler.
null
almosthere
I don't know why everyone is moving to "cloud native" where the databases and queues are not even software you can run locally.
p_ing
Running your own infrastructure is expensive.
Hobadee
Have you seen a cloud bill recently!? My buddy worked for a company that was spending a million on their monthly AWS bill. You can easily buy all your own infra, plus hire an engineer or two for the price that some of these companies are dropping on "inexpensive" cloud services.
paulryanrogers
Now add SOC and PCI compliance, DR with RTO, HA, etc. No doubt it could still be cheaper. But self managed infra does add up quickly.
sixtyj
You can read DHH tweets how move from cloud to own infra was -90% of monthly money.
const_cast
It's pretty much always cheaper than going to cloud services.
The biggest thing I hear otherwise is "but salaries!". Okay, but you're just replacing your sysadmins with AWS devops people, who I can't imagine are cheaper.
Cloud isn't simple, it's very complex. You need just as many people and just as much knowledge to make it work.
dijit
yet, it costs 1/5th of what cloud does with any kind of minor load.
Someone needs to study these claims tbh; your point is contrary to my experience.
r3trohack3r
I think when some people say “self hosting is expensive” they factor in the cost of the engineering talent necessary to successfully sysadmin the setup and ongoing maintenance - and the cost/risk of shopping for and evaluating that skillset to find and retain an engineer that isn’t going to muck the whole thing up.
You can subsidize the cost of self hosting by discounting your time/skill in DIY - and you don’t have to interview yourself.
mrweasel
Sure, but so is running on AWS, Azure or GCP. Your on-prem bill tends to not run amok though. You don't wake up one day and get a bill for $100.000 for something that was accidentally deploy Friday afternoon.
People are starting to learn that cloud hosting isn't exactly cheap. It's great for quickly scaling, there's way better automation tools, e.g. Terraform, a lot of the complicated stuff is done for you, but it's not cheap.
37signals is running their own infrastructure, and it's cheaper than cloud.
Mikhail_Edoshin
Cooking your own food is technically less efficient; the per-meal costs are definitely higher than in a restaurant. But somehow eating in restaurants is more expensive.
ahofmann
It just isn't. We are talking websites here. You can serve billions of requests from dirt cheap vps. Heck, I just saw a hetzner website, on a hosting plan for 20 € pumping out almost a terabyte of traffic per month. The database is included in the hosting plan.
null
pragmatic
No you just shift bounded capex to unbounded opex.
davidkwast
That's why HTMX is growing and Django/Rails/PHP will never die.
DamnInteresting
I unapologetically love PHP + jQuery, even for new projects in 2025. The technologies are solid, and they didn't stop working just because they are no longer trendy. Is vanilla Javascript "better" than jQuery? Sure, in some ways. But for those of us steeped in jQuery, it's so much quicker to whip up an MVP. If the ~90k of bandwidth becomes an issue, I can always retroactively swap jQuery for vanilla.
daxfohl
In a couple years when everyone is just manipulating AIs to make huge blobs of who-knows-what-but-it-works code, we'll hark back to how simple hand-coded React was.
owlstuffing
Well… React apps are a category of huge blobs of who-knows-what-but-it-works code.
In fact, I would be surprised if AI were to generate code as rube-goldbergery as React would have you write. Shrug.
xnx
Maybe, but you can also dictate what technologies the AI uses.
Gemini might default to a framework and Tailwind CSS, but I can tell it to use vanilla Javascript.
daxfohl
That's true for now, and of course will be possible in the future too, but I think there's a potential future where AIs just own the whole stack: client, server, some inscrutable protocol between them, some ML model on both ends that interpret requests and responses, etc. All updated in real time, no manual version bumping or dependency pinning, etc. Will all that make things better? IDK, but it fits into a long line of "what hardware giveth, software taketh away".
mattl
There's no reason we can't still build things like this if we want to.
I'm looking at my next project now and I think I'm going to build it like this again because if it has any hope of lasting a decade or more, it needs to be relatively easy to maintain.
null
indigodaddy
Doesn't levelsio still build with php/jQuery for example?
mattl
I don't know what levelsio is.
msephton
He's a successful entrepreneur, and yes he still builds with php.
mexicocitinluez
yes, but he famously isn't building complex web applications so there's that.
DocTomoe
Related: Build Boring Software @ https://www.intercom.com/blog/videos/build-boring-software/
Had a 45 minute conversation with someone from devops this week trying to convince them that I don't need an API server and Front end server since my application is just an app that outputs HTML and uses HTML forms with a maximum of about 2 simultaneous users ever. He couldn't fathom this "architecture" and I ultimately lost the battle ... I must have a front end server for static content, as they don't know how to set up just a backend. He even argued that I must ship JavaScript because oauth won't work without it. I got tired and gave in... I'll just ship a "front end" with a static redirect to the "backend" domain.