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.
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.
> 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.
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.
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.
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.
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.
So I tied an onion to my belt.
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.
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.
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.
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.
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.
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.
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.
Crazy enough, I also hold doctors and surgeons to higher standards than web developers.
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
They are referring to this:
https://us-east-1-shared-usea1-02.graphassets.com/cluuijofv0...
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.
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.
@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.
I like how HTMX does SPAs. It straddles the divide nicely between simple and capable.
This is how things goes when the employers ask for a list of technologies...
Not their fault.
