6/10/2026 at 3:37:45 PM
As a non-web dev, I have a question about this part:> There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.”
Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard <input> components for the form, have a submit button at the bottom. When I was making my own websites many years ago now, that's how it worked, and it wasn't that hard. Maybe it's reflecting my ignorance in this field, but doing fancy front-ends seems much harder to me.
by OskarS
6/10/2026 at 3:56:26 PM
Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a new React project, mostly out of familiarity and a desire to get the job done.A few of them would outright not know how to do anything else. No knowledge of how to stand up a boring HTTP server to send pure HTML. No experience building a form that validates or submits without JavaScript. These are not the people who post here on HN. They are not engaged in online discussions of new tools and skills (or old tools and skills!). These are people who learned just enough from a bootcamp, or their uni's single "web apps" course, to get a job. Since then, they have just-in-time learned whatever their employer required, or whatever particular tools someone else on their team chose for a project.
As an old, it took me a while to recognize/realize it, but I understand them now. Depending on their career path, someone will encounter the simplest aspects of HTML, CSS and vanilla JavaScript after they learn the complex, framework-specific aspects of each. It feels (to them) like more esoteric, advanced, or tertiary knowledge.
Tying it back to to the quote "that’s a lot more work for us", that's not necessarily an intentionally false claim. It probably does feel like a lot more work to perform a task using unfamiliar tools, even if they are less-complex tools.
by chao-
6/10/2026 at 4:07:30 PM
You are far too empathetic to them. They should not hold the jobs they have.These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form.
It’s a culture of not giving a shit, that’s the deeper issue.
by concinds
6/10/2026 at 6:05:54 PM
I had a contract once to save a government website that had serious performance issues, it was so unusable that people preferred to go in-person and wait 4h in a queue rather than try to fill the forms online.The frontend was in React because the company that got the contract initially used React for everything. The frontend was a 5MB SPA, but it could've been (mostly static) HTML files with some interactivity for forms like TFA. Everyone working on the project agreed React didn't make sense, but we couldn't do anything about it because someone from the government IT department would have to admit they made a mistake. There was no budget for rewrites in the contract. The few times a developer attempted to remove any "React monstrosity" they got in trouble.
Sometimes developers care, but the people in charge don't, and in government environments every change must go through them first.
by igsomething
6/10/2026 at 8:43:49 PM
> Sometimes developers care, but the people in charge don't, and in government environments every change must go through them first.To be fair, the same thing happens in private companies. How many UI changes have people gone through that didn't actually make anything better and just made everybody relearn everything? We would have been better of scrapping many of those and let people continue to use what's already familiar, but that too would have to involve someone admitting failure, which is a hard thing to do for some people.
by Telaneo
6/10/2026 at 8:56:56 PM
I've used many a government website in the Navy, and they were almost invariably bad, but it had nothing to do with React per se.A very slow website I can think of had something like 200 GET requests required to load the landing page, and it used Liferay with Material Design Bootstrap. That was closer to the "style at the time". React is the style of this time, but you can write very slow websites in anything, I'm convinced.
by mpyne
6/10/2026 at 10:22:03 PM
> That was closer to the "style at the time".So I tied an onion to my belt.
by alsetmusic
6/11/2026 at 11:43:18 AM
Ref: https://youtu.be/yujF8AumiQoby pards
6/10/2026 at 9:29:42 PM
I’m curious if - and when - LLMs change this. They’re very good at web apps. And they’re great at rewriting existing stuff. Just give them a well scoped /goal and go get coffee.Theres lots of open questions about the future of our profession in the age of AI. But, playing with opus and fable, I think the future will be bright for our users. There is no reason any more for teams to put out junk that’s worse than what an LLM can do.
by josephg
6/10/2026 at 9:43:34 PM
Unfortunately the LLMs are trained on what we've made, and there's going to be a ton more React garbage[1] in the training set than there are carefully-crafted websites like the article describes, so I don't expect a decrease in overengineered, bloated junk. If anything, I predict that the fact that you can shit one out in less time than before will have a different effect: A modest increase in bloat since an LLM won't mind adding a half dozen redundant and competing ways to do the same things in a large codebase, combined with a shorter mean-time-between-full-rewrites.I think most of us have seen incredibly creaky codebases that are too buggy to be maintained any longer, where we make the hard choice to wipe the slate clean and build a new one.
We might find those rewrites happening every 12-24 months instead of after a decade.
[1] Frontend people, I mean no disrespect -- just that React & friends are (ab)used for nearly every website now, even those which map perfectly onto the "Simple document viewing with occasional submission of incredibly simple form data" model that plain HTML has always been perfect for.
by xp84
6/11/2026 at 9:59:17 AM
> Unfortunately the LLMs are trained on what we've madeThis.
As I’ve pointed out in other posts, I work in two languages: Swift (my main language), for native app clients, and PHP, for backend work.
I have a lot of experience, with each language (12 years for Swift, and 25, for PHP).
My experience with an LLM, is that I get very good PHP, and fairly mediocre Swift. The Swift often looks like fancy tricks, that newer enthusiasts like to demonstrate. Lots of unnecessary threading, and complex, dogmatic, overengineered approaches to simple problems.
I suspect that this has a great deal to do with the availability of high-Quality public repositories. PHP is more than twice as old as Swift, and, by nature, is a much more open language.
by ChrisMarshallNY
6/11/2026 at 1:27:36 AM
It doesn't take that much effort to put guardrails around your prompt to solve problems in a certain way and with certain frameworks and excluding certain others.by VincePlatt
6/11/2026 at 3:43:09 AM
Who will be doing that? Only a small minority of developers pre-ai cared to attempt using HTML, so I don’t see them urging Claude to create efficient and lean websites in the future either.by xp84
6/11/2026 at 6:04:11 AM
Claude is remarkably good at performance engineering and ports. It only takes one person on your team to ask claude to do a round of performance profiling and tuning. Or ask claude to take your react site and set up a server to render parts of your site as static, cache friendly HTML.You barely need domain expertise any more. Just ask claude to make it go faster and it will.
by josephg
6/11/2026 at 12:00:39 PM
You also need to ask Claude not to make any mistakes /sby N_Lens
6/11/2026 at 6:25:51 AM
You can order LLMs to use other patterns. I had an LLM recreate an app in a different stack with reasonable successby tobyhinloopen
6/11/2026 at 9:12:00 AM
You can, if you know what you want.by XajniN
6/11/2026 at 12:49:59 AM
Lolby lotsoweiners
6/11/2026 at 1:25:30 AM
Better than a lot of web dev teams at least.by josephg
6/10/2026 at 5:42:59 PM
In Canada you can't call yourself an engineer unless you have some kind of association behind it; the title holds meaning including partially accountability. Something that is lacking in the tech world. I'm not saying I want to live in that world but also I worked hard for the knowledge I have starting in the IE days of web dev; it was hard earned experience making things work across the web without loosing performance. The idea that we have developers out there now getting paid higher than me that are clueless on how auth works, how the browser works, why css and browsers maintain backwards comparability for a reason.. well it's sad; but good for them I guess?The behaviours of developers as well being beholden to their managers rather than the craft; meaning not saying No we will not move forward without proper unit tests, or pushing back when business demands quick corner cutting solutions.
Anyway, decades of bitterness. I wish we had associations to uphold some level of accountability on developers as much as protect developers. I think things would be a lot more expensive and slow if we did that though.
Fundamentally I agree with your take, not just on dev side but just the web/dev/produce' a culture of not giving a shit.
by jessyco
6/11/2026 at 11:14:15 PM
Always be a doubled edged sword, why would a startup with an optional product like a fitness tracking app ever rise to level of regulation that requires developers that are beholden to associations to uphold some level of accountability on developers.A lot of products don’t come close to rising to the level of a government website, industrial control systems, financial transactions, etc. in terms of needing structure accountability.
by aiisjustanif
6/10/2026 at 4:28:03 PM
I use to have an old pentium 2 computer for testing websites. Sometimes you cant make things fast enough for the old box. A fun trick is/was to have <script>elm.textContent="loading images"</script> between each "heavy" section, all targeting the same elm. If the computer, network or server is truly extremely slow you will get a nice message at the top describing what they are waiting for. On a normal slow computer you won't see the messages unless something went wrong.by 6510
6/10/2026 at 7:54:25 PM
Oooh! Like a status bar!shit, I'm too old to remember those...
by rescbr
6/11/2026 at 5:48:28 PM
haha right, I forgot the word for it.by 6510
6/10/2026 at 5:30:35 PM
Junior and midlevel devs aren't decision makers for government benefit websites. The culture of not giving a shit is real, but the responsibility goes far beyond these roles.by goosejuice
6/10/2026 at 7:27:34 PM
If we're talking a government site, chances are you don't have the budget to be able to hire much above junior or midlevel devs. And the project manager probably has a small budget [^1] and little experience with what the web design choices really mean (and what the trade off are).I think you'd be surprised who ends up making those decisions.
Which goes back to the original point (that's valid for any project) - keep your user in mind. If your users will be using recent-ish iOS or Android devices, use as much flair as you'd like. If your users will be using mass-market low-end devices or used devices from 4+ years ago, then maybe dial down the interface.
Knowing your user is important, no matter what level you're at.
[1] Unless we're talking about some kind of large system that's being redesigned by a consulting company on a cost-plus contract. Who knows how those decisions are made.
by mbreese
6/10/2026 at 9:31:38 PM
Even if this were the case, and I wouldn't be surprised, it's still misplaced blame.> Knowing your user is important, no matter what level you're at.
I agree, but it's absolutely ridiculous to expect a junior dev to make excellent decisions on this. Software development is a massive industry with no prescribed methods. It's not like these folks are going through a residency before getting the job. Even if they went to uni for CS those programs don't teach these skills.
by goosejuice
6/10/2026 at 5:48:08 PM
I am always baffled by people who blame developers. Like some mid dev or junior would calling shots what stack should be used for project.by ozim
6/10/2026 at 7:09:41 PM
You'd be surprised, then. Some managers don't know squat. I rolled onto a project once and found that an entire application was being delivered as a 300MB ActiveX control, to run in a browser because that was cool and "cutting-edge" at the time.Looking at the code, I found it was using UI elements for data storage and other such nonsense. A colleague and I had to tell the manager that the entire thing had to be rewritten. I'm not sure he actually went pale, but that's how I remember it.
by MoonWalk
6/10/2026 at 7:37:44 PM
It is EXACTLY the type of people that are hired to make decisions, because of either nepotism or impressing with portfolio filled with overcomplicated, 3.js frontpages.by high_priest
6/10/2026 at 7:17:12 PM
When you give the project to a bunch of junior devs the stack is necessarily decided by one or more of them since there's nobody else to decide it...by inigyou
6/10/2026 at 10:12:56 PM
The tech stack is almost always decided by someone in leadership that has no developer experience. Or by the consultant company that will chose the most complicated and difficult to maintain stack because then they can invoice more and will win all future contracts. The trick is to hire someone that is not corrupted by money, someone like the author of this post, who cares more for the users then how much he gets paid.by z3t4
6/11/2026 at 4:45:49 PM
Not in my experience. If they're throwing it to a group of junior devs they're throwing it to a group of junior devs.by inigyou
6/10/2026 at 7:09:04 PM
Preach! Amen! Hallelujah!by 0x59
6/10/2026 at 11:04:20 PM
> These are the people writing React monstrosities for government benefit websites, and testing them on fast iPhones and fast 4G, without realizing that every page load for actual users will take 30 seconds on their old $200 Android on 3G, and users won’t complete the form.@concinds, you yourself are being too empathetic. I am trying to view these websites on my $2,000 PC on high speed internet, and it still is maddeningly slow.
by Shellban
6/10/2026 at 10:59:48 PM
Most companies actively punish you for giving a shit. The more shit you give, the worse things get for you. Not giving a shit is a form of self-preservation.by preg_match
6/10/2026 at 6:08:52 PM
New cheap android phones are just as slow as old cheap android phones. The bottom of the market has been stuck in performance limbo for years, and modern web dev frameworks are ill designed to meet them where they are at.by Joeri
6/10/2026 at 7:17:53 PM
My cheap phone has 6 cores and 8GB I think. My first cheap phone had 1 core and 256MB. Both ran Android. I think you're mistaken.by inigyou
6/10/2026 at 9:11:07 PM
old != oldestThey are referring to this:
https://us-east-1-shared-usea1-02.graphassets.com/cluuijofv0...
by arcanemachiner
6/10/2026 at 10:53:09 PM
> single-core scores> only goes back to 2015
by inigyou
6/11/2026 at 7:27:36 PM
This data is from a series I publish; the latest update is here and includes multi-core scores:https://infrequently.org/2025/11/performance-inequality-gap-...
Mobile devices rarely last beyond the 5 year mark, although the age span has been increasing in the past several years and the resale market is booming thanks to inflation, geopolitical instability, and a global cost-of-living crisis.
by slightlyoff
6/11/2026 at 8:42:52 AM
Are you saying a phone from 2015 isn't old?by arcanemachiner
6/10/2026 at 10:45:49 PM
Oh, I know it's not the point but I find it a bit disingenuous going from iPhone base model to the Pro in the last 3 years and still comparing to the base model Samsung S series. Though maybe I'm missing something non obvious.But yeah, generally I've seen a better experience buying used phones (in good condition) instead of budget/cheap new ones.
by aquariusDue
6/11/2026 at 7:32:54 PM
The data is from my blog series, the latest installment of which is here:https://infrequently.org/2025/11/performance-inequality-gap-...
The top two lines are the fastest devices available in the iOS and Android ecosystems each year, and when using Samsung S-series devices, I have made sure to pick the faster of the Qualcomm vs. Samsung Semi parts (both are used historically, but Qualcomm is most prevalent in the US). As explained in the piece, the bottom two lines are taken from representative devices in the mid-range and low-end price categories. There's wild variation in those market segments due to short-run discounting, and the most meaningful uplift in CPU speeds has coincided with 5G radios (for obvious signal-processing reasons). Because the lowest-priced segment doesn't yet feature 5G, those processors have remained stubbornly slow, even if they get cheaper every year.
by slightlyoff
6/12/2026 at 11:36:43 AM
Thank you for clarifying and sharing the full blog post! It was actually an error on my part because until now I didn't realize that the S-series base model and the Ultra model actually share the same CPU. I should've checked my assumptions first.I also saw you addressed in your blog post the growing market for refurbished phones and in the last year or so I've noticed a similar thing in Romania where a e-commerce giant is involved with a company that refurbishes and resells old user devices to try and corner a big piece of the pre-owned (second-hand) market where previously you'd be stuck hunting for good deals on the national Craigslist equivalent or searching for small-ish repair shops that sold refurbished devices.
by aquariusDue
6/10/2026 at 4:55:30 PM
It's more of a culture of "but everybody else does it".I like how HTMX does SPAs. It straddles the divide nicely between simple and capable.
by pydry
6/11/2026 at 12:38:42 PM
I have been coding for several decades and still haven't delved into assembly.This is how things goes when the employers ask for a list of technologies...
Not their fault.
by aatd86
6/10/2026 at 5:38:02 PM
I've found what works really well on 3G an MPA with streaming HTML with brotli compression rendering the whole page on every change.by andersmurphy
6/10/2026 at 8:39:27 PM
I just had one of these people, a contractor working for a state government, argue vocally with me in a meeting stating that "500 JavaScript requests is not a problem" for a single page. Un-cached, of course, despite there being a CDN in front of the site.You can't win against cargo-cult coders because they just assume you're from a different, competing cult.
They have no concept of engineering or science, they have never encountered it.
by jiggawatts
6/10/2026 at 9:36:33 PM
Heh this is one nice thing about doing engineering work in Australia. Our round-trip time to US data centers is often about 200ms. There’s no hiding from sloppy choices in the performance panel.I had an argument a few weeks ago because our page took 4 serial requests before content appeared. I argued - with solid data - that it should be 1. If we could manage that, cold load time would ~ halve.
by josephg
6/11/2026 at 11:51:38 AM
> argue vocally with me in a meeting stating that "500 JavaScript requests is not a problem" for a single pageWhere's the benchmark or at least the numbers? If not, that's not proof of anything. Nothing to argue about. I'd just laugh.
> You can't win against cargo-cult coders
You don't need to. Unless you're not in control or don't have influence then whatever. It shouldn't be about "winning". It's either some vote (hence influence) or there's a process e.g. PoC with backed numbers.
by re-thc
6/12/2026 at 2:11:00 PM
“The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.” -- Alberto BrandoliniI like to fight this kind of asinine "push back" by simply reversing the time order:
Here's an app that does 5 CDN-cached requests of its JavaScript. Demonstrate why disabling the CDN cache and splitting that into 500 individual requests is better.
by jiggawatts
6/10/2026 at 9:04:29 PM
This is a leadership failure. People who want to do a good job always get fired for taking too long.by dmurvihill
6/11/2026 at 3:58:55 AM
I mean there are web programmers that do not know C. C! The substrate of all computing! The bedrock, surely…by mlsu
6/10/2026 at 4:30:52 PM
I see no reason not to be empathetic. The frustration is fair, but it's aimed at the wrong layer. These people were guided into this spot by bootcamps and curricula that start at React and never go down the stack.My experience was the reverse. I learned HTML and CSS first, then Rails in college to serve templated pages. I understood the client/server boundary fine as a concept, what I couldn't see was where it actually sat in a web context. I sort of knew JavaScript ran in the browser, but then I'd see ERB templates stamping values directly into script tags, so the server was writing the JavaScript that ran on the client, and my mental model fell apart. Where does my code actually execute? Why does this variable exist here but not there? Why does the page have data the network tab never fetched? Nobody ever sat me down and explained the request/response lifecycle as its own thing. I had to assemble it from fragments over years. This was around 2017 for context.
How you learn something shapes how you keep learning. If your mental model is misaligned, everything downstream is friction. The thing that finally made it click for me was reading the actual HTTP RFCs, which is apparently a weird thing to do, because HTTP itself is absent from nearly every guide and curriculum. Tutorials teach you the framework, maybe the language, and just assume the protocol underneath. These days I make newbies read the MDN docs like a book and skim the HTTP wiki page, learn the history of the protocol. It's short! It's not even a book! That gives you a firm foundation. But if your foundation starts at React, drilling down is like digging past bedrock. People don't know where to start, and Googling only shows them wrong answers because they don't yet know how to ask the question.
by yesco
6/10/2026 at 4:48:33 PM
Are you sympathetic to a doctor who specialized in surgery and now always recommends surgery, even for a common cold? Or would you say they are in the wrong job, if they are anywhere but surgery?by luckylion
6/10/2026 at 4:53:21 PM
Well that's horribly reductive. I certainly do not expect everyone in a given field to know absolutely everything there is to know in that field.Crazy enough, I also hold doctors and surgeons to higher standards than web developers.
by hext
6/10/2026 at 9:47:17 PM
If those web developers fail a critical government service, or online pharmacy or financial service, it can mess up peoples life pretty badly as well.by lukan
6/11/2026 at 2:33:16 AM
Yes it's truly a shame when the people responsible for critical infrastructure only hire the cheap inexperienced software engineers to build it.Much like how relying on a resident nurse instead of a cardiologist when you are experiencing a heart attack can end your life pretty badly as well.
by yesco
6/10/2026 at 4:57:20 PM
Ridiculous example that does nothing to argue the original, fair point. Obviously health interventions demand more finely tuned solutions than information technologyFWIW, maintaining at least a moderate degree of empathy even in systemically frustrating situations is good for the empathizer and thus in one’s interest
by shnock
6/10/2026 at 5:28:24 PM
Kinda sorta analogous to the cloud engineers who can standup complex monstrosities in AWS-land, but don’t know the first thing about how to troubleshoot say a connectivity or simple problem where they have to ssh to an ec2 box and do the needfulby indigodaddy
6/10/2026 at 7:30:45 PM
well... just because you know how to ssh into the prod DNS host and manually update the prod zone files in vim to remove orphan A records + duplicate CNAME records, in order to fix an ip address exhaustion issue that is blocking new VM's from spinning up for your customers... it doesnt mean that you should, lol.that was 8 years ago in my first gig. now i kinda wonder... having those skills made it easier to put off implementing a robust long term solution. it was playing with fire, sure, but i was a rookie
by lazystar
6/10/2026 at 5:55:01 PM
or the materials engineers who are great at making mems tools, but couldnt for the life of them design an aircraft propby 8note
6/10/2026 at 4:16:27 PM
Don't you think they have a legit skill issue here and should they be better off upskilling themselves?This is a direct effect of being a low barrier industry to enter. Most of the ppl among us are mostly here because of a good paycheck. And it SUCKS!
by opem
6/10/2026 at 4:24:24 PM
>Don't you think they have a legit skill issue here and should they be better off upskilling themselves?Absolutely agree! Just because I understand how they got there doesn't mean I think it's a good state of affairs ;)
My post was already quite long, and I didn't want to append a treatise on what one should do when encountering those engineers. It depends on many details. Avoid hiring them, if that's a power you have. If you are stuck working with them, depending on your authority, encourage them to learn or force them to learn. If you're coming in to clean up after them... well, hopefully your comp is worth the annoyance.
We are all simultaneously in the position of encountering "the world as it is", understanding it, and doing what we can to improve it.
by chao-
6/11/2026 at 10:49:22 AM
Why should you necessarily avoid hiring them? You yourself said that they are not stupid. Maybe some of them are very good, hardworking employees. And if all your company needs is a react app, does it matter that much that those people are unfamiliar with building websites without react? Maybe they've spent all their working hours doing work for their employer's company, leaving no time to learn other ways of building websites.The thing is, people often assume that bootcampers/self-taught devs are only in it for the money and do not "care about the craft", or else they would have studied CS in the first place. But this is not true: There are many reasons why someone could have found their passion for software engineering only later in life. Some of the best engineers I know are self-taught or bootcampers.
by bronkic
6/10/2026 at 5:36:03 PM
Yep. It’s also an attitude problem. A lot of devs are able to up-skill just fine, but some are downright demeaning towards anything they don’t understand, or towards anything that doesn’t come from a FAANG.“HTML only? Nobody is doing it!”
by whstl
6/10/2026 at 5:11:36 PM
In the olden days, people wouldn't take office jobs or factory job necessarily because they thought: "Yes! That's my passion! That's exactly what I've always wanted to do." Passion isn't your first and foremost thought when you have a family to feed.A few decades ago, IT jobs were for the most part done only by people who were in it for the kick they got out of working with computers. They already hacked at their dad's computer in their early teens (or sometimes even younger), and just could just never let go. It was for people who loved it because it was a niche.
But today, IT is no longer that. It's the backbone of much of our society. And so the field no longer attracts just the die hard fans, the nerds. It attracts ordinary "career people", who just need to have a job to feed the family. Who turn the machine off after 8 hours. Who don't go on coding all through the evening on their hobby project. Who don't try out new tech just for the heck of it.
I think it's hard to understand if you belong to the first group, the nerds, that anyone working in the field isn't like you. Because they all used to be! But those days are gone. We live in the times of enshitification for a reason. If you have the hacker spirit, you don't enshitify because you simply can't. You know what is the right way to do it. Sometimes that's a React app but sometimes it's just an HTML page.
You're not just in it for the money. You care. Not necessarily for the end user, although that would be nice. You care for the tech. And when - like in this article - both come together, sweet things can happen.
by kleiba2
6/11/2026 at 2:16:34 AM
> If you have the hacker spirit, you don't enshitify because you simply can't.Not me, if they want shit I give them shit. I used to care 30 years ago, but they beat it out of me. Now its all for the money, HODLing to retirement.
by le-mark
6/11/2026 at 6:45:00 AM
Beaten by the system. Thanks for adding that, it's not uncommon. I should have added that to my post above.by kleiba2
6/10/2026 at 6:22:13 PM
AbsolutelyI'm not a web developer. I built a few websites in high school, but these days I write safety-critical real-time code for robots.
A few years ago I was back in grad school and I took a class with undergrad senior CS students. We had to write a fairly simple web service, and I was blown away by how complicated they were making it. Based on the requirements we easily could have written 90% of it in plain HTML, but everyone else insisted it should be 100% react. Part of that is honors students wanting to do everything the most complex way possible to impress teacher, and part of it is them simply not knowing that other options exist.
by jfaliwejrliawj
6/10/2026 at 6:24:17 PM
I’ve long thought frontend web developers are the ones most threatened by LLM-assisted programming for a bunch of reasons and now I can add “many don’t understand web fundamentals” to the list.by cgh
6/10/2026 at 9:14:02 PM
Yup. It’s exactly like the dismal state of CSS frameworks we're mired in.All these new kids walk in and learn the CSS framework du jour first, then find themselves stranded when things move on. If they had just learned CSS the first time, they'd be set for life.
Nobody should learn React before learning HTML and vanilla javascript.
HN last week: Learn SQL Once, Use It for 30 Years https://news.ycombinator.com/item?id=48347483
by Eric_WVGG
6/10/2026 at 9:43:33 PM
The practical question most face is which is more likely to land them a good role. Does standards level CSS knowledge meet that bar?(I’m team CSS standards although my knowledge is a bit tilted towards late 2010s, currently revisiting)
by wwweston
6/10/2026 at 10:57:31 PM
Yeah but at least now we don't argue about Bootstrap or Foundation, it's just go with Tailwind.I still remember when a good chunk of the web took Bootstrap's defaults and ran with it.
That said I've still got a bone to pick with Tailwind but I understand it's a good compromise in a world where BEM and CUBE and other methodologies require more effort up front and if done incorrectly impose a bigger burden.
by aquariusDue
6/10/2026 at 5:15:12 PM
A few of them would outright not know how to do anything else.It's like how a lot of people these days reach for an electric drill/driver for even the most simple projects like tightening a screw. It never occurs to them to use a screwdriver, or even a butter knife.
by reaperducer
6/10/2026 at 9:50:36 PM
Yeah, my dad is like this. But even just for one screw I am at least 10x faster with the electric option.But I also achieve faster HTMl with vanilla and never touched react, so .. I will continue to stick with using the right tool for the job.
by lukan
6/10/2026 at 5:51:18 PM
Try to get a Java developer to do something without Spring.by JackFr
6/11/2026 at 2:57:22 AM
They may not be stupid people, but they are bad at their jobs. One needs to be able to at least try other approaches to a problem, and not have a one size fits all approach. The latter isn't engineering, it's cargo culting.by bigstrat2003
6/10/2026 at 11:35:21 PM
My wife used to maintain a website for a non profit organization that was just HTML/CSS. After that she started building a lot of stuff in HTML without javascript.by protocolture
6/11/2026 at 2:39:34 AM
And (now that I'm in management I understand this better than I used to) this problem becomes self-reinforcing. If every candidate out there only knows react and doesn't actually know how to do a simple front-end without it, you need to use React because at some point you'll need to hire someone to replace the person doing it. Even when management understands why the design is bad, if that's what the labor market supports it exerts a definite pressure.by bandrami
6/10/2026 at 6:07:59 PM
There is a reason we use React today - if you want dynamic and complex site, HTML is PITA to work with. Either you reload everything on any change (not good), or end up with a maze of partial reloads in event handlers (not good either). It was done, it was bad, React (and similar frameworks) was the solution. If you don't need complexity of React, fine, use HTML. But if you do, who can guarantee that 5 min later someone will not start requesting site not to reload here and there, but update this bit here. So I don't blame people for just using React. And in this case the issue wasn't that react was used, but that it was used poorly.by fiedzia
6/10/2026 at 6:12:08 PM
Two years ago, I started a new company, and decided at the outset to avoid using any heavy JavaScript SPA framework. We stuck to simple server-rendered html and only use progressive-enhancement style JavaScript.Our app was fast, and simple, but it also came at a cost: we were limited in our ability to take rich UI elements off the shelf with an npm package. We had to do a lot more work to provide a rich user experience. Everything took longer, and the user experience was worse as a result. We cared, but sometimes you don't have time to carry through.
The company failed, and I don't think react would have saved it. But I can tell you first hand that righteous adherence to "simplicity" didn't help either. It's always a trade-off.
by iamjs
6/10/2026 at 7:26:20 PM
I also prefer simple web tech, but I'm really glad you brought these points up! Ecosystems matter more than a lot of purist devs think.by aturek
6/11/2026 at 4:00:48 AM
I feel like there is some context missing in your story here. There is a lot of middleground between heavy SPA frameworks and creating everything from scratch. More importantly, I am left wondering what sort of functionality was your team trying to build that requires that much interactivity? At least that is what I assume with "rich user experience"?by creesch
6/11/2026 at 9:40:41 AM
If I had to guess, they were probably wanting to implement something like animations into the UI. Animating a list of items onload in a staggered format is still basically impossible unless 100% of your users are using Chrome. With a JS animation+component library, this type of animation is pretty much plug-n-play.When the startup is trying to attract customers and also impress investors, sometimes there is a lot of effort spent on the investors just so they keep putting money into the machine. "See! We have an ultra modern/sleek site so it must be some other variable that is causing customers to churn..."
by yurishimo
6/10/2026 at 5:08:47 PM
A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge.It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard form" with a multiple sub-forms to get through the full "form" process), not just accept a "finished" or "complete" submission. If a sub-form needs a change the backend, the backend's storage, and the frontend all need to change. The backend and frontend have to agree on validation logic for each small piece of the form. The backend and the frontend need to both validate every small piece of the form, and maybe can't share that validation logic (depending on what language the backend is written in), especially if one of the goals is to do as much of the frontend validation as possible with Browser native validation tools (`<input required` and `<input type="email"` and so forth) so that you get the most benefits of progressive enhancement.
The original ways of making websites were "full stack" and from a full stack perspective it shouldn't seem that hard to have a coordinated frontend and backend, especially when a progressive enhancement approach likely means a smaller more agile frontend, but current siloed world where frontend and backend are different teams with different goals and alignment makes that seem like way too much work.
by WorldMaker
6/11/2026 at 2:34:14 AM
I have had issues where the Frontend team is unable to explain how to communicate with their SPA, they say "just use this package/just run node" and are unable to explain the workflow in primitives.Then they just validate on the front end, and we validate on the backend.
by hacker_homie
6/11/2026 at 11:40:01 AM
> they say "just use this package/just run node" and are unable to explain the workflow in primitivesNow it's worse. It's "just run <claude or codex>"
by re-thc
6/10/2026 at 5:58:06 PM
> Why is it more work?As someone that reads a lot of code written by others, I'm confident that "learning a new way to do something" is perceived by many as the hardest thing in the world.
by bachmeier
6/10/2026 at 3:48:30 PM
By this point people don't appear to have any real clue how to write HTML anymore. Writing semantic HTML isn't significantly harder than say writing Markdown. You copy some HTMl skeleton and you literally just stack your elements into the body. I managed to do that as a 13 year old on MySpace without any deep instruction. Sure you have to close elements as well so the syntax is slightly harder than markdown, but that allows you to differenciate between for example <article>, <section> and <aside>.I am convinced the one single thing that made HTML unusable over the time was that people wanted or needed a way to re-use parts of the page across multiple pages, like headers, navigational elements and footers.
This meant people used frames, PHP, templating engines or any other new technology mainly for the purpose of creating shared elements, simply because HTML failed (and to this day: fails) to offer a way to include one HTML file in another without having it suck (like frames definitely did, since the browser treated each subpart of the page like its own entity including caching).
by atoav
6/10/2026 at 4:36:50 PM
I think it was... SHTML? that allowed for server includes. My recollection from... 25ish years ago was that it was generally quite well supported and worked quite well (and was dead simple to implement). Not sure why, if that was the issue, the fix didn't quite catch on (but it's totally possible I'm mis-remembering the state of browser support).by jmye
6/10/2026 at 4:42:39 PM
Server-side includes worked fine but weren't enabled by default in any of the mainstream web servers. I think the lack of default-enabled status hampered their adoption. Joe User couldn't just FTP a bunch of ".shtml" files up to their shared web space and expect it to work right.I certainly used the heck out of them in the late 90s, though.
It would have been very cool if HTML had been created with the ability to do client-side includes without having to resort to using a Turing-complete VM in the client to do it.
by EvanAnderson
6/11/2026 at 1:11:23 PM
Ahh, yeah! That rings a vague bell of having to futz with IIS at some point to figure out why a page wasn't working. I can't quite recall if it worked in Geocities, but I think some of the gaming websites I was building (maybe xoom? That sounds familiar for some reason) had it on.by jmye
6/10/2026 at 4:46:40 PM
[delayed]by atoav
6/10/2026 at 5:28:55 PM
> (and to this day: fails)The `<template>` tag has gotten very close. Right now you still need JS (optionally wrapped as a Web Component) to load a `<template>` from an outside HTML file (at which case, yeah, it's so easy to just use a JS-based HTML renderer instead of a template today), but discussions are ongoing about closing that loop for simpler "JS-free Web Components".
I don't know when that will be accepted into the web platform, but it still feels more like a matter of time that it may happen eventually.
I've found at least some of my static page generation has moved to just dumbly appending `<template>` tags to the bottom of a page rather than use some other template language, so it feels like we are closer every day to finally having "HTML-native" simple part reuse.
by WorldMaker
6/11/2026 at 6:49:35 AM
I used SSIs to include menus and footers back in the day.If you wanted to reduce server load you could “compile” those includes at publish time.
by hdgvhicv
6/10/2026 at 4:15:32 PM
Large websites resorted to PHP and server side includes to get headers and footers. Smaller websites resorted to frames and copy/paste. It wasn't perfect, but it also wasn't horrible or unusable either.by autoexec
6/10/2026 at 7:59:41 PM
Ikea relies heavily on Edge Side Includes, assembling static pages from parts at the CDN level and then having small islands of JS interactivityby youngtaff
6/10/2026 at 6:00:46 PM
<div><div><div><div><div><div><span></div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>></div></div></div></div></div></div></div></div></div>writing straight html and css sucked. building reddit css themes sucked
by 8note
6/10/2026 at 6:21:39 PM
But I believe the point is: if you were writing HTML by hand, you would never have written the above.by radiator
6/11/2026 at 6:41:26 AM
Yes you used HTML to design a website in a way that was the opposite of semantic. Semantic HTML is about just writing your content and then using CSS and js for everything else (as far as possible).Also: the meaning of the word semantic is that the used elements give you context about the contents. So if you place text in an <aside> that tells you that this is additional information as opposed to the stuff in <content> for example.
If you use a hundred nested divs, there is probably a better way to do it.
by atoav
6/10/2026 at 11:00:49 PM
This is not semantic HTML.by zelphirkalt
6/10/2026 at 4:46:45 PM
yeah editing all the footers and navigation parts in html is too annoying to me so i've resorted for my websites to just a back button to a page that has links to everything else lmaoby p-t
6/10/2026 at 4:19:11 PM
I think the problem is hearing just one side.Someone is saying that they delivered a very reasonable solution that's simpler than most would come up. Person taking over was not happy.
Do we know if the code being handed over was high quality? Were they reacting to the fact that it was "not React"? Maybe they have a template they enforce in the company about how apps are built?
We don't know.
by egeozcan
6/11/2026 at 6:02:29 AM
The author open sourced the validation library: https://gitlab.com/alistairldavidson/validation-enhancerby electromech
6/10/2026 at 5:13:23 PM
This was the jQuery way. It was called Graceful Degradation.The entire approach went out of style with the advent of single page apps, React, Angular, VueJS, etc.
by brightball
6/10/2026 at 5:28:36 PM
That's generous. I always heard people espouse that ideal, but I rarely saw them actually do it. And I never saw it at work.There were always certain UX requirements that required JS, and that meant the company wasn't interested in testing to make sure it worked without JS. None of their customers were going to use it that way.
Angular, React, etc helped force it further, but they didn't cause it.
by wccrawford
6/10/2026 at 5:33:04 PM
I know I always did. CakePHP and Rails made it really easy to determine if a request came from AJAX or direct and you could slightly tweak the response to match the medium.Agree that most people didn't, but I was always an advocate.
by brightball
6/10/2026 at 5:44:59 PM
jQuery and graceful degradation are different things. The vast majority of sites in the jQuery era that used jQuery did not gracefully degrade.by IshKebab
6/10/2026 at 5:56:21 PM
the shockwave and flash way was simpler.download the whole app and run it in browser. you can even run it off line!
by 8note
6/10/2026 at 3:46:28 PM
It probably has to do with what technology people are used to. There has been a couple of generations of web developers who have only known javascript and its ecosystem for building webapps, and so anything other than pure javascript solution looks foreign.by theflyinghorse
6/10/2026 at 4:55:54 PM
As an application becomes more stateful it gets harder to keep that state aligned across the frontend and backend, especially if they're in different languages.by c-hendricks
6/10/2026 at 6:02:10 PM
I used to do web dev. (Got out of it due to js frameworks and their bloat.)I'd pee myself in happiness to take over a project like this.
by nosioptar
6/10/2026 at 8:34:00 PM
The short and sad answer is that most people that work in web development do not understand how the web works or how web apps work.by pbalau
6/10/2026 at 6:37:38 PM
I'm risking being wrong here, but I think the difficulty is getting conforming behavior across all device and browser combos.by gosub100
6/10/2026 at 10:55:14 PM
This is the only correct answer in this entire thread! Congrats!by sublinear
6/10/2026 at 7:20:49 PM
It is harder to do more with less. There is a reason React and other is used so much. Makes it easier to make interactive websites. It’s like asking why backend engineers think it’s harder to code an api using C instead of using Django.by victorbjorklund
6/11/2026 at 3:02:59 AM
> There is a reason React and other is used so much.Yes, it's because many people are quite bad at their jobs and reach for the same tool regardless of whether it's the right one. Let's not make excuses for incompetence.
by bigstrat2003
6/11/2026 at 8:41:59 AM
I take Astro with React over manually editing 1000 html files.by victorbjorklund
6/10/2026 at 8:14:54 PM
I used to think that was true but I now think it’s only true for very interaction-heavy apps: if you have hundreds of interactions on a page over many minutes, using an SPA is amortized across a lot of time, but if it’s something you could do with e.g. a simple Django app you’ll not only be done faster but will spend an order of magnitude less time on maintenance and accessibility work.by acdha
6/10/2026 at 10:58:35 PM
That's usually not even in the books of a typical SPA: It doesn't have fallbacks at all, and just shows a blank white page. Accessibility is always taking a rear seat with such SPAs.by zelphirkalt
6/11/2026 at 2:08:15 AM
It can be really difficult for people with screen readers: focus jumps, inconsistent update flow, too many or not enough announcements, etc. People just want to live their lives, not have to threaten 508 to be able to pay their cable bill as easily as it was 20 years ago.by acdha
6/11/2026 at 8:40:59 AM
Alright but Django isn’t a pure HTML file only solution. If you have a site with no interactivity it seems like Django is the wrong choice if everything is static.by victorbjorklund
6/11/2026 at 12:29:20 PM
Who said it was? My point was simply that if you’re doing something like getting data in and out of a SQL database using web forms, you can avoid a ton of overhead and deliver a better user experience without using an SPA, and of course there’s a lot to be said for not needing to install security patches weekly due to having fewer, simpler moving parts.by acdha
6/11/2026 at 2:37:38 AM
my most recent website is fully static html and css. it contains several pages and a menu that is duplicated in all pages.that menu is maintained manually, and every time a page is added, all copies of the menu have to be updated. at some point that will get tedious. then i have a few options:
i generate the menu using a backend framework. the downside: the website is no longer fully static. i now depend on a backend framework for hosting. static hosting is out. i also have to edit the content through the backend, and i have to continuously maintain the backend for the lifetime of the site.
i generate the menu using a static site builder. the downside: i can no longer edit the content directly in html. i have to keep a source version for the static site generator, and more critically, i have to keep a copy of the site generator in my repo because i want to be able to make changes to this site 10 years from now and not find that the version of the site generator i was using is no longer available for download and my source is not compatible with the new version of the site generator.
i generate the menu using xslt. works, but xslt is no better than javascript security wise. it's possibly even worse. and xslt support may be removed from browsers in the future.
the final option is javascript. using some framework that doesn't need build tools, or something homegrown. i am afraid javascript is the only option that is futureproof while letting me avoid manual work to maintain the menu.
by em-bee
6/11/2026 at 4:10:56 AM
While purists will disagree, a little bit of javascript is fine. Having said that, you are talking about a personal website. Most companies will have a backend of some sort anyway.Also, here is a little secret. If you want something that is future proof, try something that has been around for decades and still runs large parts of the internet. People will scoff at this, but PHP is actually really neat for personal websites and has been for decades.
A while ago I also found myself looking at static site generators, workflows from github to my host, etc. Eventually I realized I don't update things nearly enough, don't blog, etc.
For similar reasons as you I didn't want to go completely static as that is just too much hassle when doing multiple pages. So I decided to utilize that good old lamp stack to basically do something like this.
<?php
$pages = json_decode(file_get_contents('pages.json'), true);
$page = $_GET['page'] ?? 'home';
if (!isset($pages[$page])) {
$page = 'home';
}
$pageData = $pages[$page];
$contentFile = basename($pageData['file']);
$contentFilePath = "content/{$contentFile}";
?>
<html>
<head>
<title><?= htmlspecialchars($pageData['title']) ?></title>
</head>
<body>
<main>
<?php include $contentFilePath; ?>
</main>
</body>
</html>
As a bonus I also rediscovered PHP in itself works really well as a templating language (as you can see) so no need for extra stuff like handlebars. As an extra extra bonus, I can just go to any shared webhosting party and get it running with no issue at all.
I am not saying you'd need to go down this road. But I just want to illustrate how stupidly simple a website can be with "old" basic technologies even if you want some form of backend.
by creesch
6/11/2026 at 10:20:06 AM
This seems like a very complicated way to maintain a menu on a static website. Have you considered using old school server side includes? It’s what they were designed for.by thedays
6/11/2026 at 11:39:07 AM
server side includes are just a variant of the backend framework. they have the same problem. i'd still be locked in. and i'd depend on and have to maintain a backend for the lifetime of the site.by em-bee
6/10/2026 at 5:47:38 PM
They don’t know how to compose and style elements without someone providing them with a prebuilt library of $framework components.by apothegm
6/11/2026 at 1:52:44 PM
> Why is it more work?People expect the entire screen not to redraw whenever they interact with an app and expect behaviour asides from the HTML defaults.
by nailer
6/10/2026 at 10:10:01 PM
As someone who has built both react based frontends and html based ones (with htmx), there is a law of diminishing returns at play.To start off, writing a basic crud website with forms is much easier with htmx.
But when you start building more complex components, and integrate with other systems (OAuth for e.g.) there are tons of libraries and SDKs for the react ecosystem, but not many for pure html components.
At this point, it's much easier to use off the shelf components than it is to manually write html to handle all the bizarre UI edge cases.
by meander_water
6/11/2026 at 1:44:18 AM
Really curious to understand why I'm being downvoted. I don't think it's a particularly spicy take - Just choose the right tool for the job.by meander_water
6/11/2026 at 9:58:12 AM
I think a lot of people here don't seem to understand or appreciate the diversity of systems that "web developers" have to work in.Some people might say, "Why do you need all that oAuth complexity? Rip it out and use a cookie like God intended."
We, the devs/ICs, don't often get to make those decisions. We're placed into teams working on specific features/apps/tools and we often have to integrate with a myriad of business systems by default.
Yea, I would love to work on a simpler system, but I don't get to make that decision. Especially not when my company has been acquired by unbounded VC cash three times in the past 5 years and now I'm forced to fold in my lovingly crafted baby into the behemoth.
by yurishimo
6/10/2026 at 9:16:40 PM
Modern web/frontend devs do NOT understand whole page navigating form POST calls from a pre JS era.by Traubenfuchs
6/10/2026 at 6:02:28 PM
I was confused by that too, but then I thought maybe the new replacement was commenting that using javascript in the app would provide more work for contractors, which he perceives as a good thing. So not using javascript provides less work. I could be wrong though.by duderific
6/10/2026 at 3:54:08 PM
I suspect they are both more familiar with client-side rendering, and also thinking of things being able to share components, reuse existing libraries, and so on. So re-implementing everything with vanilla HTML and forms feels like reinventing the wheel to a team used to an SPA component library, it's not that it's intrinsically harder, it's that they don't have the existing building blocks they'd normally reach for.Modern frameworks such as Astro allow for a similar development experience (and can optionally use JS, React and other client-side libraries) while still being able to generate a static site if desired.
I think server-side rendering and static site generation are less familiar to many web devs who came up in the React/Vue/Svelte era. The patterns and mental model are just different. In an ideal world we combine both: fast static HTML that works everywhere, with progressive enhancement for interactivity. Astro does this well; Next.js supports it too, though the SSR parts have a learning curve.
by rhelmer
6/10/2026 at 8:40:39 PM
[dead]by austin-cheney
6/10/2026 at 3:46:50 PM
Because before there was AI Slop, there was React.by LNSY
6/10/2026 at 3:57:47 PM
I think Facebook with their money and Vercel with their VC funding tried hard to push the React and then the Next.js everywhere. So it arrived in time for AIs to all train on it. And now it’s the one true way :)But do we really need all that stuff? Build steps, bundling, tree shaking, all for what? And is it really simpler… hmm
by EGreg
6/10/2026 at 5:59:41 PM
There are some advantages, but the main one is probably that it stops everyone from using NoScript and breaking tracking.by literalAardvark
6/10/2026 at 3:56:30 PM
As a web dev a lot of this is simply ongoing maintenance of a largely unknown quantity. Most web devs know React and use it extensively; Astro is something they'll have to learn on the job or hire for specifically.It's akin to writing a backend in Haskell. Chances are you could write something performant that leverages FP in a way that serves as a magic bullet for your domain. But now everyone after you needs to learn Haskell and how to model all future problems in a way that conforms with it - or rewrite things again.
by seangrogg
6/10/2026 at 4:24:08 PM
Not a web-dev myself and I was wondering if, apart from unfamiliarity with astro or HTML being treated as unknown technology, it also has to do with having to handle fallback cases, eg the 3 point validation (web component, browser default, server), esp when one is used to have react (libraries) just handling it all without any more considerations.by freehorse
6/11/2026 at 4:38:24 PM
I don't know about you, but my team uses React and we also have to handle validation on front end and back end, in different ways.by chipsrafferty
6/10/2026 at 4:10:41 PM
> Astro is something they'll have to learn on the job or hire for specifically.Before LLMs I would have agreed.
by oldandboring
6/10/2026 at 4:14:31 PM
LLM + framework you don't understand goes in ... unmaintainable garbage comes out.by hungryhobbit
6/10/2026 at 4:21:15 PM
Before LLMs, learning on the job looked like reading documentation. Now it’s a guided tour with verification. When I produce things in this way, I’m not just blindly accepting it. The goal is that by the end of it I have learned more about the codebase and architecture, not less. I feel that’s important.by CSSer
6/10/2026 at 5:09:30 PM
Many people don't understand this, even big tech engineers. They see LLMs as a bottleneck. It's more that they don't understand how to use it to multiply their skills, just basics and code gen.by skellera
6/10/2026 at 5:31:05 PM
I use multiple Claudes at a time, daily. It's precisely because of that experience that I wrote: LLM + framework you don't understand goes in ... unmaintainable garbage comes out.
If you just have it built something with a framework you don't understand, it will do so just fine! But over time every "vibe coded" change you make will drift it further and further, until you are left with a mess of vibe-coded spaghetti.
by hungryhobbit
6/10/2026 at 5:10:19 PM
Using it to understand a framework is fine.by 6510
6/10/2026 at 5:25:10 PM
I agree that's fine in that at least it's doesn't cause unmaintainable garbage. And might even get you up to speed quicker that reading the docs old school.But the GP point, that you're better off finding people that already, truly understand and are familiar with the tech (ie. Astro), imo still stands.
by repelsteeltje
6/10/2026 at 5:54:35 PM
We cant all be wise enough to use php.I read a fun comment the other day from a frustrated windows user who failed to configure linux in previous attempts but now with LLMs it was very easy for him.
by 6510
6/11/2026 at 12:28:04 AM
LLMs are a lifesaver for configuring Vim. I could not be happier to get that drudgery out of the way.by arcanemachiner
6/13/2026 at 1:21:26 PM
> We cant all be wise enough to use php.I would love to know what this is supposed to mean.
by oldandboring
6/13/2026 at 7:30:19 PM
it refers to> the GP point, that you're better off finding people that already, truly understand and are familiar with the tech (ie. Astro), imo still stands.
by 6510
6/10/2026 at 3:45:42 PM
Simpler doesn't mean easier. Consider a chef who at their previous job started using a wood-burning stove. This is an objectively simpler tool than a gas or electric stove, yet it would be very difficult (even impossible, depending on local architecture and regulations) for a new kitchen to add one.by simpaticoder
6/10/2026 at 6:07:14 PM
90% of the SPAs I use could be Django/Rails/Flask apps with no noticeable difference, other than that they'd be many times more responsive on slower devices."Old" SSR apps are mature, not obsolete. It's ridiculous when they're not considered even when they'd be the right tool for the job. I wouldn't try to clone Google Docs in Django, but something like Linear could 100% be modeled as a CRUD app with new page loads on click without a substantial loss of functionality from the user's POV. Not to mention built-in, automatic support for pervasive "deep linking", aka "linking", because you access a URL's contents by GETting and rendering that URL is just how it works.
by kstrauser
6/10/2026 at 6:39:10 PM
I agree but you and I aren't the audience and I think experts in general should be a little more holistic when critiquing other people's choices. For any given problem there always exists a perspective from which your solution is over-engineered. People who (like us, I presume) understand processes, files, the command line, compilers, a computer language or two, a bit about computation theory (e.g. Turing, big-O, Knuth..) can get to a very broad swath of places along many different (often shorter!) paths. This is not where most people are starting from.Speaking of Knuth, imagine being asked to "write a program to add two numbers" and using something like Python instead of assembler, or because really that's complex too, machine code. Do you think that the amount of housekeeping and computer activity is justified for adding two numbers? Objectively, it is not, its just that steady-state dominates the transient over time.
by simpaticoder
6/10/2026 at 4:02:27 PM
I'm interested to hear what architecture and regulations prevent the use of something that is foundational to web develpment and backwards compatible by design? Which also, by the way, comes with the advantage of not incinerating other parts of the restaurant (accessibility, user experience...), forcing expensive countermeasures or total rebuilds of the things destroyed every time you turn it on.by squidbeak
6/10/2026 at 3:52:21 PM
I don't understand how having to pay 20 different vendors so hackers can run commands on your server barely impeded is somehow simpler.by LNSY
6/10/2026 at 4:00:32 PM
The message you just wrote involved how many complex systems, from your keyboard switches and firmware to your BIOS and OS interrupts, to your browser, the internet and middle boxes, just to say one sentence to someone. It would be much simpler (and more secure!) if you just told me with your mouth, but you didn't do that.by simpaticoder
6/10/2026 at 4:31:29 PM
Of course, and if you use all these services you can be a pedantic ass who never has to actually ship a product.by LNSY
6/11/2026 at 1:27:03 AM
How is that objectively simpler?by inigyou
6/10/2026 at 6:50:57 PM
Computers are very good at repeating a known "recipe". They can add numbers billions of time per second. Yes, billions with a bee.The hard part is coming up with a recipe that solves your problem and that the machine can run without breaking things when it runs around with a few billion steps per second. You have to think ahead for it and handle edge cases in the recipe.
That is the really hard part.
by dapperdrake