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.
davidmurdoch · 17h ago
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.
indigodaddy · 17h ago
Why on earth is a devops dictating this sort of thing?
ebiester · 16h ago
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 · 15h ago
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 · 16h ago
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.
iambateman · 17h ago
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.
fjasdfwa · 17h ago
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 · 15h ago
A lot of people including myself will argue that microservices are a mistake except for a few cases.
graypegg · 16h ago
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 · 16h ago
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 · 16h ago
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 · 16h ago
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 · 15h ago
The native animation API isn't that bad, and it is somewhat informed by the jQuery API.
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.
No comments yet
DamnInteresting · 8h ago
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.
davidkwast · 17h ago
That's why HTMX is growing and Django/Rails/PHP will never die.
almosthere · 17h ago
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 · 17h ago
Running your own infrastructure is expensive.
Hobadee · 17h ago
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 · 17h ago
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.
dijit · 16h ago
You don’t get away from any of those by hosting in a cloud.
Your colo provider should be doing their part for physical access for ISO27001/SOC2 and PCI-DSS.
I quite literally know all about this because I was running payment card infrastructure in a colo, as part of one of the largest e-commerce software suites in the UK at the time.
paulryanrogers · 14h ago
Indeed. But cloud can provide a faster and easier path to getting there, at least IME.
dijit · 14h ago
No?
Cloud gives you direct access to compute at the click of a button (provided you have quota).
The ISO/PCI cert requirements are not accelerated by their use, only the initial deployment speed of your solution. If at all anything the latest I've seen is that there are more checks in cloud for various areas where you can accidentally leak data through poor permissions or because someone could enable those permissions.
For example in Google Cloud there was an additional requisite that I monitor any admin users oauth2 application accesses for their google accounts; this was not a requirement for on-prem.
paulryanrogers · 11h ago
Yes?
At least in my experience as a service provider.
With cloud I can easily plug in a compliance vendor like Drata, add connectors to my other vendors, and get a significant amount of evidence quickly.
Bespoke on-prem solutions bring plenty of their own challenges that are just N/A or handled by cloud vendors, like physical security.
Maybe as a payment processor things shake out differently. Though having read far more of PCI v4 than I'd like, I doubt it.
jauntywundrkind · 16h ago
And any one of those could become an existential risk, could take down your entire company.
Do you trust your people to never slip up? To make sure there's really the reliability & security guarantees that your company depend on? Are there competent technical hands available at all times to handle issues as they come up? This adds significantly to the org chart, requires constant caring to be added, to keep it steered and staffed.
I'm a huge fan of self hosting, of buying your own hardware. Especially for very technical entities, that have lots of overlap & intimacy with computers. But your company needs to have reason to believe it can do the job not just well, but to a degree where you're sure you won't lose the entire business. Needs to believe they really are on top of this huge domain! I see very clearly why folks go cloud, and I wish the world was in a better position, had more to say, to show why buying pizza boxes is gonna not just save you money buy be an enduring acceptable safe choice.
Much safer to not wade in here, shutting the hell up is free, and there's plenty that can go wrong, but I do think Kubernetes presents the first maybe acceptable opportunity for broadly acceptable DIY computing, delivering key three things: an essential integrativeness of concerns allowing it to be a comprehensive cross-cutting platform for your business's compute, delivers strongly on the security and dependability you absolutely must have in a well known way, and avoids the historical trap of each company ending up married to their own specific boondoggle infrastructure that's been hand cobbled together by whomever had such and such task at the time. There's a stable practice here, one that many companies and practitioners are honing; there's much difference between Kube clusters sure, but these intracacies and elaborations support the creation of something that is mostly alike, if you look from one company's clusters to the next.
luckylion · 14h ago
Would you trust cloud providers to never slip up though? I don't think the split is "perfect but pricey" vs "less expensive but shaky". It feels similar to the autonomous driving question, where safety of autonomous driving is often compared to perfection instead of human drivers.
Would UniSuper engineers have trashed their entire infrastructure the way Google Cloud did? Granted, that's not a common thing to happen, but they got _very_ lucky that day that they had a backup elsewhere and didn't fully commit to trusting Google.
jauntywundrkind · 7h ago
Nothing's perfect? But theres a lot of orders of magnitude difference in investment in what most companies can and will do versus what a hyperscaler will!
And while your company is a single petri dish with your own specific problems, these folks have to see a lot of shit. Sometimes yes it all goes bad even there anyways! The resiliency fails! But given how much they've thought about it & how much they've hedged against 1 in a million 1 in a billion cases that they see semi regularly that your company might never notice until it's too late, I think there's a ton of reasons to trust these generally very well exercises systems with pretty sizable engineering teams & deployments behind them. More so than what most folks can bring to bear.
These matters are existential threats for your business. And they are existential threats for big providers, for HyperScalers, even more so. Google very publicly owned up to UniSuper, found out why it happened (a blank form on an internal tool lead to the account having a 1 year time limit with auto-deletion), and publicly announced their three fold plan to make sure at least this specific horribly threat would never happen again:
> We deprecated the internal tool that triggered this sequence of events… We scrubbed the system database and manually reviewed all GCVE Private Clouds… We corrected the system behavior that sets GCVE Private Clouds for deletion for such deployment workflows.
The mere fact that this was such a notable event should be itself notable. In general, the hyperscalers have been stupendously reliable. And absurdly secure. They have small armies dedicated insuring both.
I look forward to this new era where finally we might have computing of our own good enough & broadly known & trusted enough to make doing our own - even with small teams - viable!! But heavens yes, keep off-site backups!!!
paulryanrogers · 14h ago
There is an element of "never fired for buying IBM" involved. If AWS screws up then theoretically they've a bigger bank roll for any settlement or judgement.
sixtyj · 14h ago
You can read DHH tweets how move from cloud to own infra was -90% of monthly money.
Mikhail_Edoshin · 3h ago
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.
const_cast · 13h ago
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 · 17h ago
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 · 17h ago
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 · 16h ago
> they factor in the cost of the engineering talent necessary
You need to do that for cloud as well. The assumption that you can just get the developers to spin up what they need doesn't work. You need a team of "cloud engineers" if you don't want your cloud bill to go crazy. I know a few people that does AWS for clients, they basically spend all their time maintaining, upgrading and reworking things to reduce the cost.
In one example, when AWS changed their IPv4 pricing, one of the went in an managed to remove 90% of their public IPv4 usage. You need to say on top of the cloud platforms, ensuring that costs stay low is a full time job.
No comments yet
dijit · 17h ago
Yes, 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 · 16h ago
SREs 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.
jeremyjh · 16h ago
That's what it meant 8 years ago. Now SRE is just a synonym for "devops" which now is a synonym for "sysadmin" in most companies. You won't have both devops and SREs in most orgs, and you won't have any devops doing dev work.
r3trohack3r · 16h ago
If you’re fighting snake oil and buzzwords, you gripe isn’t with the cloud.
You can “buzzword” yourself into job security just as easily on a VM.
mrweasel · 17h ago
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.
ahofmann · 15h ago
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.
pragmatic · 16h ago
No you just shift bounded capex to unbounded opex.
mattl · 17h ago
Is it? $40 a month gets you a pretty beefy dedicated server.
EDIT: (I can't reply for a bit) Quick glance at https://www.hetzner.com/sb/ seems to suggest 64GB RAM and a full Intel i7.
Hobadee · 16h ago
Define "pretty beefy", because in my research $40 will only get you something like 8 vCPU and 16GB RAM.
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 · 17h ago
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 · 16h ago
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 · 15h ago
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 · 17h ago
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.
indigodaddy · 17h ago
Doesn't levelsio still build with php/jQuery for example?
mattl · 17h ago
I don't know what levelsio is.
msephton · 17h ago
He's a successful entrepreneur, and yes he still builds with php.
mattl · 17h ago
Almost as if the two are unrelated.
mexicocitinluez · 17h ago
yes, but he famously isn't building complex web applications so there's that.
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.
ivape · 17h ago
It'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 · 16h ago
I 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 · 13h ago
Jquery 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.
const_cast · 12h ago
Right, it's unfathomable that we ended up with the ridiculously verbose query API. When jquery is right there. Just steal that API. That's what C++ has been doing with boost for, like, 20 years.
pragmatic · 16h ago
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!
kyriakos · 15h ago
and what did we gain? A spaghetti of services with a much more complicated infrastructure.
kavaruka · 16h ago
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.
mvdtnz · 10h ago
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.
readthenotes1 · 15h ago
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
jeremyjh · 17h ago
Great lets have another thread with people who make websites arguing with people who make web apps.
ebiester · 16h ago
I'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.
mattl · 17h ago
You 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 · 16h ago
You 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.
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.
And the ops team has preconfigured systems for single page applications but not MPAs.
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.
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.
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!
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!
https://developer.mozilla.org/en-US/docs/Web/API/Web_Animati...
No comments yet
Your colo provider should be doing their part for physical access for ISO27001/SOC2 and PCI-DSS.
I quite literally know all about this because I was running payment card infrastructure in a colo, as part of one of the largest e-commerce software suites in the UK at the time.
Cloud gives you direct access to compute at the click of a button (provided you have quota).
The ISO/PCI cert requirements are not accelerated by their use, only the initial deployment speed of your solution. If at all anything the latest I've seen is that there are more checks in cloud for various areas where you can accidentally leak data through poor permissions or because someone could enable those permissions.
For example in Google Cloud there was an additional requisite that I monitor any admin users oauth2 application accesses for their google accounts; this was not a requirement for on-prem.
At least in my experience as a service provider.
With cloud I can easily plug in a compliance vendor like Drata, add connectors to my other vendors, and get a significant amount of evidence quickly.
Bespoke on-prem solutions bring plenty of their own challenges that are just N/A or handled by cloud vendors, like physical security.
Maybe as a payment processor things shake out differently. Though having read far more of PCI v4 than I'd like, I doubt it.
Do you trust your people to never slip up? To make sure there's really the reliability & security guarantees that your company depend on? Are there competent technical hands available at all times to handle issues as they come up? This adds significantly to the org chart, requires constant caring to be added, to keep it steered and staffed.
I'm a huge fan of self hosting, of buying your own hardware. Especially for very technical entities, that have lots of overlap & intimacy with computers. But your company needs to have reason to believe it can do the job not just well, but to a degree where you're sure you won't lose the entire business. Needs to believe they really are on top of this huge domain! I see very clearly why folks go cloud, and I wish the world was in a better position, had more to say, to show why buying pizza boxes is gonna not just save you money buy be an enduring acceptable safe choice.
Much safer to not wade in here, shutting the hell up is free, and there's plenty that can go wrong, but I do think Kubernetes presents the first maybe acceptable opportunity for broadly acceptable DIY computing, delivering key three things: an essential integrativeness of concerns allowing it to be a comprehensive cross-cutting platform for your business's compute, delivers strongly on the security and dependability you absolutely must have in a well known way, and avoids the historical trap of each company ending up married to their own specific boondoggle infrastructure that's been hand cobbled together by whomever had such and such task at the time. There's a stable practice here, one that many companies and practitioners are honing; there's much difference between Kube clusters sure, but these intracacies and elaborations support the creation of something that is mostly alike, if you look from one company's clusters to the next.
Would UniSuper engineers have trashed their entire infrastructure the way Google Cloud did? Granted, that's not a common thing to happen, but they got _very_ lucky that day that they had a backup elsewhere and didn't fully commit to trusting Google.
And while your company is a single petri dish with your own specific problems, these folks have to see a lot of shit. Sometimes yes it all goes bad even there anyways! The resiliency fails! But given how much they've thought about it & how much they've hedged against 1 in a million 1 in a billion cases that they see semi regularly that your company might never notice until it's too late, I think there's a ton of reasons to trust these generally very well exercises systems with pretty sizable engineering teams & deployments behind them. More so than what most folks can bring to bear.
These matters are existential threats for your business. And they are existential threats for big providers, for HyperScalers, even more so. Google very publicly owned up to UniSuper, found out why it happened (a blank form on an internal tool lead to the account having a 1 year time limit with auto-deletion), and publicly announced their three fold plan to make sure at least this specific horribly threat would never happen again:
> We deprecated the internal tool that triggered this sequence of events… We scrubbed the system database and manually reviewed all GCVE Private Clouds… We corrected the system behavior that sets GCVE Private Clouds for deletion for such deployment workflows.
https://cloud.google.com/blog/products/infrastructure/detail...
The mere fact that this was such a notable event should be itself notable. In general, the hyperscalers have been stupendously reliable. And absurdly secure. They have small armies dedicated insuring both.
I look forward to this new era where finally we might have computing of our own good enough & broadly known & trusted enough to make doing our own - even with small teams - viable!! But heavens yes, keep off-site backups!!!
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.
Someone needs to study these claims tbh; your point is contrary to my experience.
You can subsidize the cost of self hosting by discounting your time/skill in DIY - and you don’t have to interview yourself.
You need to do that for cloud as well. The assumption that you can just get the developers to spin up what they need doesn't work. You need a team of "cloud engineers" if you don't want your cloud bill to go crazy. I know a few people that does AWS for clients, they basically spend all their time maintaining, upgrading and reworking things to reduce the cost.
In one example, when AWS changed their IPv4 pricing, one of the went in an managed to remove 90% of their public IPv4 usage. You need to say on top of the cloud platforms, ensuring that costs stay low is a full time job.
No comments yet
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.
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.
You can “buzzword” yourself into job security just as easily on a VM.
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.
EDIT: (I can't reply for a bit) Quick glance at https://www.hetzner.com/sb/ seems to suggest 64GB RAM and a full Intel i7.
https://www.hetzner.com/dedicated-rootserver/ax42/
But 8/16 is $95+ on AWS.
That's where they get you.
In fact, I would be surprised if AI were to generate code as rube-goldbergery as React would have you write. Shrug.
Gemini might default to a framework and Tailwind CSS, but I can tell it to use vanilla Javascript.
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.
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.
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.
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.
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!
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.
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.
EDIT: a typical CRUD app will be fine with just PHP, HTML and CSS.