[concinds]

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.

[igsomething]

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.

[Telaneo]

> 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.

[mpyne]

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.

[alsetmusic]

> That was closer to the "style at the time".

So I tied an onion to my belt.

[pards]

Ref: https://youtu.be/yujF8AumiQo

[josephg]

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.

[xp84]

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.

[ChrisMarshallNY]

> Unfortunately the LLMs are trained on what we've made

This.

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.

[VincePlatt]

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.

[xp84]

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.

[josephg]

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.

[tobyhinloopen]

You can order LLMs to use other patterns. I had an LLM recreate an app in a different stack with reasonable success

[XajniN]

You can, if you know what you want.

[lotsoweiners]

Lol

[josephg]

Better than a lot of web dev teams at least.

[jessyco]

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.

[aiisjustanif]

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.

[6510]

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.

[rescbr]

Oooh! Like a status bar!

shit, I'm too old to remember those...

[6510]

haha right, I forgot the word for it.

[goosejuice]

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.

[mbreese]

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.

[goosejuice]

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.

[ozim]

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.

[MoonWalk]

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.

[high_priest]

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.

[inigyou]

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...

[z3t4]

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.

[inigyou]

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.

[0x59]

Preach! Amen! Hallelujah!

[Shellban]

> 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.

[preg_match]

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.

[Joeri]

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.

[inigyou]

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.

[arcanemachiner]

old != oldest

They are referring to this:

https://us-east-1-shared-usea1-02.graphassets.com/cluuijofv0...

[inigyou]

> single-core scores

> only goes back to 2015

[slightlyoff]

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.

[arcanemachiner]

Are you saying a phone from 2015 isn't old?

[aquariusDue]

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.

[slightlyoff]

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.

[aquariusDue]

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.

[pydry]

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.

[aatd86]

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.

[andersmurphy]

I've found what works really well on 3G an MPA with streaming HTML with brotli compression rendering the whole page on every change.

[jiggawatts]

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.

[josephg]

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.

[re-thc]

> argue vocally with me in a meeting stating that "500 JavaScript requests is not a problem" for a single page

Where'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.

[jiggawatts]

“The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.” -- Alberto Brandolini

I 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.

[dmurvihill]

This is a leadership failure. People who want to do a good job always get fired for taking too long.

[mlsu]

I mean there are web programmers that do not know C. C! The substrate of all computing! The bedrock, surely…

[yesco]

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.

[luckylion]

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?

[hext]

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.

[lukan]

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.

[yesco]

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.

[shnock]

Ridiculous example that does nothing to argue the original, fair point. Obviously health interventions demand more finely tuned solutions than information technology

FWIW, maintaining at least a moderate degree of empathy even in systemically frustrating situations is good for the empathizer and thus in one’s interest