Hacker News Reader

Comment by simonw | Hacker News Reader

A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses.

Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly predicted by his writing.

I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research... and then to have nobody believe him. https://en.wikipedia.org/wiki/Cassandra

View on HN

I think most responses to his posts are missing that this is the most important part:

> In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user.

> In less vulgar terms, the struggle is to convince managers and tech leads that they need to start with user needs. Or as Public Digital puts it, "design for user needs, not organisational convenience"

This is the most important thing. The entire article series is making this point in great detail, and also being very angry at orgs (especially public services!) that don't get this.

I think this message does get a bit buried under invective against React. Surprise surprise, if you do start with user needs, then sometimes that does lead to you building a React-based SPA. I think from Alex's perspective working with organisations, looking at it from the other direction: for any given React SPA, it is unlikely that React was chosen because of user needs.

The problem is that this fundamental claim undermines the entirety of the argument. You can build a good web experience in React if you care about the user experience.

I don't find the argument to be undermined by this. From my perspective, his strong statements against React read as deliberately lacking in nuance just like the conventional wisdom of "just use React and don't think too hard about it". It's a deliberate overvorrection away from the status quo. There can be room for nuance once the default assumption has been shaken.

I get why people are offended or find it unhelpful. If you read through his Reckoning series, I hope you'll understand some of the righteous anger he has for organisations that fail to serve the user, even when public service is their explicit purpose.

Blaming it on React may not be the most effective strategy. Who knows. But I still find value in the message.

If you try something for a decade and it doesn't work, maybe a change in style is necessary! An article exceeding 20 pages doesn't sound like the best persuasion strategy.

I’m not a front end engineer and I read most of this, at first for sheer morbid curiosity about the drama, then I kept reading because it looked like deep knowledge and detailed exposition of a complex subject, then I kept reading because I was wondering who listens to a guy like this and why?

In my experience, regardless of your skill at communication, coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare. If you need to communicate a subtle point or detailed argument, then you’ve already lost. This is because for any technical decision the opposite argument from FUD is easier to make and easier to digest, regardless of whether the FUD advice is to stay/defect on the tech stack or the design decision or whatever. IOW the winning strategy is basically to always go 2nd after what TFA calls the “thoughtful engineer” burns out the audience by being rational and thorough. Even more bluntly.. most people are just showing up to work and have no interest (and much less passion) for craftsmanship.

I wish it was different, since I believe in architecture / design. But, there’s a good chance no one cares about your detailed analysis at all and you’re much better off producing more shallow demos/diagrams/decks regardless of whether your audience is engineers or management.

This is a very underrated comment.

My only quibble is that it’s certainly possible to choose React (or any popular solution to a problem) without considering other options too much, and still care about craft.

> coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare

I agree! In general, people are resistant to change, period. Some are particularly wary of facts and logic (see: politics). Successfully getting points across, even when one "is right," often requires a lot of strategizing and non-technical effort.

Whole books have been written on this subject [1]. For those attempting to navigate the challenge, just remember that it's all too easy to burn out in the office while "chasing your ideals.". Doing this while keeping your sanity is an art :-).

1: https://pragprog.com/titles/trevan/driving-technical-change/

Good point, but you should take a look at a post where he does exactly this: https://infrequently.org/2024/08/object-lesson/

I doubt it's a matter of style. There's a lot of tribalism and irrational opinions around React.

I strongly dislike React on pragmatic and philosophical grounds. I don't feel particularly irrational.

I was arguing the opposite. That there's a lot of irrationality in devs using React.

> A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses.

The sad part is that it's the same increasingly hostile arguments he's making while he spent the decade making sure that browsers remain bloated and tech requires Javascript to even barely function: see his entire work on web components.

> I see him as something of a Cassandra at this point, doomed to see the truth about web performance based on many years of research

He's not the only one speaking about web performance, or doing research. He's not Casaandra. At best, he's a false prophet.

His series on web performance gaps is good, though.

> and tech requires Javascript to even barely function: see his entire work on web components.

I'm confused by this characterization of web components. While they can minimally work without JS now (i.e., declarative shadow DOM), the whole premise builds atop of how the web and the browser works, and that is progressive enhancement. Your browser starts showing you the content before all of the content has finished downloading, and as it finishes, it progressively enhances the content of the page. Web components is a part of that story.

Why do you want web components to work without JS? Do you also put the same constraints on frameworks?

> the whole premise builds atop of how the web and the browser works

Of course not. They need Javascript to participate in forms (though a button on WCs still can't work as a submit button), they need JS to handle global styles, they need JS to handle ARIA (there are at least two different proposals for this), they need JS to fix text selection etc. etc.

Nothing in web components two dozen specs builds on top of basic browser functionality.

> Why do you want web components to work without JS? Do you also put the same constraints on frameworks?

That's bot what I wrote. I'm calling Alex Russel's hypocrisy. He's ranting against web frameworks while he's spent the past decade creating tech that needs more and more JS for basic functionality (and more JS to fix issues previous designs and patches) and is literally advised to be used as only through libraries and frameworks

Yes, I think you’re right. I overwhelmingly agree with his articles, but when I share the content with my colleagues it gets at best a careless shrug, but most often what amounts to “but [technology referenced] is good because it’s popular.” React is one of those problematic choices companies continue to make.

I happen to agree with most of what he said, but man, that tone was insufferable ...

(non-wrapping extra long lines have not helped but maybe that's on my user agent)

My rules of thumb:

* informational website / blog - static frontend (Django! :heart:)

* some interactivity - htmx

* a lot of interactivity (app that happens to libe in the browser) - spa (React and weep)

For a very strong assertion he makes (even if you need spa, react is obsolete), he dismisses finding a good alternative as an exercise to the reader. The ones listed offhandedly in a side note look all the same (as react) to me.

Or maybe he's just complaining about things that most people don't care about. Because they're not relevant for the day to day jobs

For me, when he said this:

"In short, nobody should start a new project in the 2020s based on React. Full stop."

He lost me. My React web app of medium complexity is statically exported and gets cached by the user's browser. All the data it needs for the main page is fetched by a single graphql call. The UI code renders in less than 10ms even on old machines. Network and the backend are the primary bottlenecks for me.

Could I redesign and rearchitect it such that the frontend is very slow to render even on modern machines? Yes, quite easily. And I suspect, many people complaining about React's performance are doing just that.

Maybe because they start with this tldr:

> In short, nobody should start a new project in the 2020s based on React. Full stop.

Good arguments here but the dogma doesn't help.

Sometimes you have to fight fire with fire. The fact that some people reach for React before even considering what they are building requires some corrective polemics.

I disagree. The author can make the "perfect argument" but it won't matter if the individuals who need convincing bounce before the first section.

Reply on news.ycombinator.com