from Hacker News

What We Lost with PHP and jQuery

by amaccuish on 6/1/25, 3:39 PM with 75 comments

  • by davidmurdoch on 6/1/25, 4:22 PM

    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.
  • by Demiurge on 6/1/25, 5:14 PM

    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.

  • by iambateman on 6/1/25, 4:20 PM

    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.

  • by graypegg on 6/1/25, 4:32 PM

    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!

  • by mattl on 6/1/25, 3:56 PM

    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.

  • by fjasdfwa on 6/1/25, 4:25 PM

    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!

  • by vanschelven on 6/1/25, 4:10 PM

    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.
  • by almosthere on 6/1/25, 4:01 PM

    I don't know why everyone is moving to "cloud native" where the databases and queues are not even software you can run locally.
  • by davidkwast on 6/1/25, 4:19 PM

    That's why HTMX is growing and Django/Rails/PHP will never die.
  • by daxfohl on 6/1/25, 4:18 PM

    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.
  • by DamnInteresting on 6/2/25, 12:31 AM

    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.
  • by someothherguyy on 6/1/25, 4:20 PM

    does using jQuery today make things easier to maintain? i am not so sure. you don't even need jQuery for many things today that you would have used it for thanks to improvements in the Web API, CSS, and JS.

    also, maintainability of dependencies in web projects that do use build chains seems much better today than even 8 years ago, and it seems to be improving. esbuild, vite, and other projects have simplified the tool chain. improvements in CSS have reduced the need for pre-processors, etc.

  • by mvdtnz on 6/1/25, 10:43 PM

    There's middle ground. Something like ASP.NET MVC or Spring Boot with Alpine.js is only slightly more complex than PHP/jquery but far more modern and powerful.
  • by readthenotes1 on 6/1/25, 6:18 PM

    One large website I know about had five+ different versions of jQuery running simultaneously. It was too difficult to try to keep all the pages on the same version
  • by kavaruka on 6/1/25, 4:49 PM

    I think this is just nostalgia, in the past decade I worked on several web apps, with lot of interactions and real time data (online auctions, live sport scores, customer support) and using jQuery (or even Angular.js) for this purpose was awful, because you had to reinvent state management and think about rendering performance.

    You don’t understand the tools we have now, probably you are not the target and you can still use PHP + jQuery.

    And is false that they weren’t package managers: the de-facto standard was Bower, used in combo with Grunt as task manager, with a Ruby toolchain that included LESS most of the type to preprocess styles.

  • by pragmatic on 6/1/25, 4:43 PM

    We lost an unmaintainable spaghetti code mess.

    Not crying any tears.

    Vanilla javascript now is way better than the mystery methods in jQuery. Does this call return zero, one or many things? Also what does it return? Who knows! We'll find out at run time!

  • by jeremyjh on 6/1/25, 4:15 PM

    Great lets have another thread with people who make websites arguing with people who make web apps.