Hacker News Reader

Comment by 4ntiq | Hacker News Reader

I read through this to hopefully save all of you the clickbait and mid-way through nonsensical philosophical diatribe. It's a bit ranty and devoid of technically-caloric content. The author is advocating for use of plain HTML/SSR patterns and avoiding SPAs and complicated frameworks/libraries ala Angular/React/etc. It's an old thought that lines up with the "you don't need JS" crowd.

Oh, and the author would like to kindly point out that React is legacy now. Because they said so. In case you didn't know.

View on HN

You can read it that way if you ignore the rest of the article, I guess. They simply are saying many (most?) sites do not need to be SPAs and the baggage that entails with load times and latency. Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.

In most cases later frameworks are slow and bulky. I certainly hate using sites like X or Target on mobile. Random delayed loading of things, loss of scrolling position when going back, things just not loading the first time it delayed reactions. It sucks.

Nah, the rest of the article is not insightful either.

eg React Native is dismissed in 5 sentences, with no real solution at all given to the basic problem of wanting to have a website and mobile apps without writing your app 3 times. Let alone a website + mobile apps + windows + mac clients. The suggested solutions do not address this need -- eg there's some Apache crap that no one I've heard of uses (it's renamed Adobe Phonegap crap that Adobe bailed on and tossed over to Apache); some random link to a 5 year old google i/o presentation; etc.

As far as I know, there's basically 3 toolkits that offer this: React + derivates; Rails with Hotwire; and Flutter, which means trusting Google (fools only), and which has recently deprioritized desktop... so that's a rock solid foundation to pour millions of dollars of eng time into. And I guess Xamarin, if anyone is using that.

I think sadly to that point there’s no solution given because there isn’t one. And the ones that promise it (RN) still has you doing tons of platform specific code and in some cases supporting even more platforms than just going native.

I've been at orgs that wrote 3x apps and at orgs that shipped via RN. RN was a significantly superior choice ime. While yes, it wasn't 100% write once, it was pretty good and also avoided some of the ugly single-platform-only bugs I experienced at choice one, eg in core data libs (subtly different validations on data), that made the write 3 apps strategy be more like 4x work.

As for the article, honesty probably would have just had the author write something like: "RN: an unfortunate but maybe your best choice in these circumstances" instead of pretending there's serious alternatives eg the Apache garbage dump.

> Follow a process to determine what is really needed based on objective requirements and then use objective measures to ensure it does not degrade the experience.

This is how you end up with an amalgam of legacy crap that no one wants to touch. I can’t read guarantee you that outside of big tech and a couple of unicorns started by experienced devs this will NEVER work reliably.

React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have.

The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks.

Before anyone mentions Custom Elements and Web Components, I must say I tried it. Gave it a lot of effort to be a solution but it is not!

"React works because I can hire engineers that can be productive quickly. A lot of tech conversations leave the talent pool aside as if it's easy to find good engineers in all of the options you might have."

That's covered in this section: https://infrequently.org/2024/11/if-not-react-then-what/#%22...

"The ecosystem is another aspect. You have so many great options for off the shelf components and libraries with React that you might not have with other frameworks."

That's covered here: https://infrequently.org/2024/11/if-not-react-then-what/#%22...

I think people prefer ecosystem with many resourceful components

https://github.com/brillout/awesome-react-components

This point is not directly covered in the article.

Heartily concur. It's a classic of an essay written by one of those tortured souls who cannot understand why everyone so blithely moves past the incisive, obvious, truths they share.

With a topping of how this is all just solved by "giving a toss about the user", followed by a cloying apology for being vulgar

I'm not in web and am amenable to a good web dev hot take but this simply isn't worth the time, it's an array of generic wisdom delivered as if it's specific, written with the effort of someone who is proud of themselves when you disagree.

I mean the graph in the article of Amazon vs Target vs Wayfair is pretty damning. And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.

Yep! Made me remember my bad target experiences as well. Love how that’s all ignored by some.

> And honestly you don't even need the graph, just go to their sites. Target is dog slow while Amazon loads instantly.

I was not able to notice any difference between them

Were you using a ~$2000 laptop on a broadband connection?

Out of curiosity I checked on iPhone 14/4g and 2018 Intel MBP.

I don't get what the point of these comments is ? If you're using RPI with a 2g connection you'll have a bad experience shopping at the site ? And somehow that's supposed to factor in to my tech stack decisions ?

Alex's position is that the average consumer is on a cheap Android phone, which has severe CPU weaknesses compared to any iPhone from the last ~five years: https://infrequently.org/2024/01/performance-inequality-gap-...

Software engineers tend not to experience the web on the same class of device as most of their users.

But is the average Target shopper on a cheap Android phone accessing over non-broadband? Wayfair?

It's a fair point to note devs and users might have different devices, but in some cases they don't and the decision to use React might be well-founded with that fact.

Do you not care about most of your potential customers, or do you only cater to high net worth people? If so, then sure, substandard devices and connections can be ignored. If you’re Target, on the other hand, you probably shouldn’t ignore them.

I find it extremely odd that this was even a question on this site. Do you think the problem you’re solving should impact your tech stack at all, or is your tech stack more important than the problem?

You're making the same mistake as the author. I get unnecessarily aggro too, but a plain reading of their comment isn't "they only cater to high net worth people" or they're advocating for such. Its "hey we're talking about 3G connections at this point, which are mostly shut down, and we don't cover developing markets"

Note most of this is nonsensical too.

His primary thing is "you don't need client side code because JS = (HTML + CSS) * x, where X >= 1"

We can start sneering about not caring about users there, too, having a one time client side download of that magnitude can certainly be much better on the poors than 10 page loads with SSR.

I keep hearing the "SPA is actually lightweight" argument but it's never materialized for me, the fastest sites are SSRs that are mostly static. The saving from HTML vs JSON just isn't that much over the wire and mobile CPUs and memory are a bottleneck.

I have a newer iPhone and Safari is still full-refreshing pages constantly due to memory.

> "SPA is actually lightweight"

With utmost respect, that's not what I'm saying :)

I hold no hot take position on anything web dev, or any firm declarative position.

What I'm trying to get at is, indicia of an article being half-baked includes things like asserting all that's required to agree is to care about the user.

This feels good to say, but doesn't say anything, other than there's been at least some short-circuiting of thought. We can come up with many trivial cases where "caring about users" involves requiring client-side logic during rendering.

And it doesn’t even have to be that. Just someone at the wrong end from a cell phone tower or in a clogged one from a sports event or something.

o7 thanks, people like this who do not work in contexts with problems that React solves yet insist React is not solving problems are profoundly boring.

I spent a lot of time working on react applications of one kind or another and I think most businesses don’t have “problems that React solves” for their frontends. Somewhere that’s actually an application might, but most line of business applications would be better as something like Rails views rather than React

> I think most businesses don’t have “problems that React solves” for their frontends.

that is neither here nor there. you are replying to an article whose thrust is that react ought never be used.

> Somewhere that’s actually an application might

might, lol? wait are you the author?

> most line of business applications would be better as something like Rails views rather than React

why?

Because, for most business applications I've worked on, React just complicates the frontend code compared to serving up simple HTML views and for no real benefit aside from "using React"

No need for personal attacks.

And there's also the other side: people who insist in overusing React. Perhaps that's what the author refers to.

I for one have see HTMX eat React for breakfast in a few of my clients during consulting.

> No need for personal attacks.

i don't know about all that, but this is an incredibly tired diatribe.

> Perhaps that's what the author refers to.

they are clearly not.

They are clearly not.

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

Really? HTMX for me brings spaghetti code on the server side. Fine for small projects but not so for large ones. I would prefer the clear separation between frontend and backend beyond small scale projects.

React does not create a clear separation. Anyone who claims that hasn’t worked on any react bigger than a todo list.

If you struggle with backend code then you’re just not a good backend developer. Maybe just stick to HTML/CSS.

> I for one have see HTMX eat React for breakfast in a few of my clients during consulting.

What about the rest of them?

Reply on news.ycombinator.com