6 ms·
What We Lost with PHP and jQuery
- mattl 1y agoThere'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.
- indigodaddy 1y agoDoesn't levelsio still build with php/jQuery for example?
- mattl 1y agoI don't know what levelsio is.
- mexicocitinluez 1y agoyes, but he famously isn't building complex web applications so there's that.
- DocTomoe 1y agoRelated: Build Boring Software @ https://www.intercom.com/blog/videos/build-boring-software/ https://www.intercom.com/blog/videos/build-boring-software/
- deleted 1y ago[deleted]
- almosthere 1y agoI 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 1y agoRunning your own infrastructure is expensive.
- dijit 1y agoyet, 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 1y agoI 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.
- dijit 1y agoYes, I get that. However there are SREs and DevOps engineers that are seemingly required for cloud solutions; and they cost more than sysadmins. So, someone is lying somewhere.
- r3trohack3r 1y agoSREs have nothing to do with cloud solutions. You may have the wrong mental model here. The profession grew out of observations made in catastrophic failures like Chernobyl. They primarily focus on organization structures, communication structures, and responding to failures. At an engineering level they focus on meta stability - decoupling local failure from overall system stability to prevent local failures from cascading to catastrophic failures - and automated tooling to loop the right engineers into ongoing incidents. The skill set is a side effect of operating at scale, where even brief catastrophic failures can result in hundreds of millions of dollars of losses; directly in revenue and indirectly to reputation.
- vanschelven 1y agoSo the trick seems to be to find, from the large set of possible technologies that are available, the subset that actually makes things simpler.
- jeremyjh 1y agoGreat lets have another thread with people who make websites arguing with people who make web apps.
- mattl 1y agoYou can absolutely make a web app with just PHP without the need to have a ton of extraneous stuff. The author isn't incorrect here. EDIT: a typical CRUD app will be fine with just PHP, HTML and CSS.
- jeremyjh 1y agoYou can call a lot of things a web app, but there are ones that you absolutely shouldn't make with PHP & jQuery, you will hit a point where that architecture becomes much harder to reason about because you've got state and behavior hooks strewn about between the DOM, database and cache like that guy with the bulletin board conspiracy map meme.
- ebiester 1y agoI'd even argue that small web apps are easier in vanilla JS. There is a definite threshold where that flips, and inside every small web app is a large one waiting for its time to shine. I've been struggling with how to write about and fix this paradox for a long time. We start with the heavy weight infrastructure because we don't know how large our application will end up. Small teams use microservices. Small teams build large continuous integration pipelines and strain under the complexity. That's partially because the large teams have built open source ecosystems that make dealing with that complexity mostly invisible. That's partially because we all neglect YAGNI. And it's partially because we need better patterns on how to in-time scale our complexity.
- draw_down 1y ago[dead]
- daxfohl 1y agoIn 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 1y agoWell… 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 1y agoMaybe, 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 1y agoThat'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".
- deleted 1y ago[deleted]
- davidkwast 1y agoThat's why HTMX is growing and Django/Rails/PHP will never die.
- deleted 1y ago[deleted]
- iambateman 1y agoI 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.
- someothherguyy 1y agodoes 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.
- ivape 1y agoIt's still a better api than the native document.query stuff that they put into the browsers. It puts so many api developers to shame. It's a masterclass. React still cannot figure out a plugin.
- someothherguyy 1y agoI developed with jQuery for nearly a decade and I would disagree. No one who argues for this seems to remember the mess of jQuery dependencies in the form plugins people would include in projects, before HTTP/2, just to have some simple functionality like a carousel, transitions, submitting forms with AJAX (XHR), and so on. Many of those things are a few lines of code now, where they were sometimes hundreds of lines of code in the past when people developed this way. The prototype pollution and general undefined behavior introduced by plugins was nearly impossible to track in projects where teams were plugin hungry. Additionally, the spaghetti that existed where people would interweave on element event attributes (onclick, etc) with scripts lead to huge headaches debugging events before devtools in browsers was mature as it is today. Honestly, I could go on forever. Walk into a large project that is 15 years old and still using jQuery UI, and you might change your mind on the merit of its elegance. jQuery was one of the nicest things around at a time when it was needed, but pining for this version of the past boggles my mind.
- ivape 1y agoJquery developers were just uneducated on structure. That's why the code was spaghetti. I would say your average Jquery developer didn't even know how to structure a well defined singleton: App = { } People are a lot more educated now. But you're right, we can't go backward, but there are many good things about Jquery that were mostly thrown out by Angular and React, and I think there's a middle-ground here somewhere. Anyways, not like it matters, AI has arrived.
- davidmurdoch 1y agoHad 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.
- indigodaddy 1y agoWhy on earth is a devops dictating this sort of thing?
- ebiester 1y agoProbably 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 1y agoYeah, 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 1y agoI 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.
- fjasdfwa 1y agoThere 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 1y agoA lot of people including myself will argue that microservices are a mistake except for a few cases.
- graypegg 1y agoI 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!
- ivape 1y agoNothing 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 1y agoThe 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_Animations_API/Using_the_Web_Animations_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
- luckylion 1y agoThe 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 1y ago
- pragmatic 1y agoWe 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!
- kyriakos 1y agoand what did we gain? A spaghetti of services with a much more complicated infrastructure.
- deleted 1y ago[deleted]
- kavaruka 1y agoI 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.
- Demiurge 1y agoHave 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.
- readthenotes1 1y agoOne 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
- mvdtnz 1y agoThere'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.
- DamnInteresting 1y agoI 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.