Live data from Hacker News

If not React, then what?

infrequently.org

271–280 of 756 posts

Re: If not React, then what?

#271

I hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’r…

I generally agree (that the React isn't the main culprit), but what does Tailwind have to do with templating? It's still just CSS classes, but with specific names. Also, I bet you could have strongly typed class name strings using TypeScript's template literal type somehow.

Re: If not React, then what?

#272

I honestly think this conversation gets overly complex because we fail to define the kind of websites we are talking about. These are my definitions, so I'll just share them upfront: - a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket - a web application -- which has high interactivity requirements. Things like Gmail, Linea…

> and an enormous amount of SaaS apps fit in this bucket of things.

Let’s not get ahead of ourselves. An enormous amount of SaaS’s _wish_ they were a web app. A good chunk of them would probably have a net-better UX by dispensing of this delusion.

Re: If not React, then what?

#273
post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

> But front end performance issues are almost never the most pressing issue

Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D

Re: If not React, then what?

#275

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward: • A large portion of the cost of maintaining a code repository goes toward maintaining the build. • Multiple builds per repo create significant costs. • Any web application with a UI _requires_ a frontend build f…

> Any web application with a UI _requires_ a frontend build for CSS/JS. Except it really doesn't. Core web technologies have gotten so much better since the jQuery/pre-SASS days that you can absolutely get by without a build step. - http/2 makes bundling a questionable choice - polyfills are pretty much no longer a thing - CSS now has most (all?) of the features that people used SASS for (variables, nesting, etc.) -…

[deleted]

Re: If not React, then what?

#276

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward: • A large portion of the cost of maintaining a code repository goes toward maintaining the build. • Multiple builds per repo create significant costs. • Any web application with a UI _requires_ a frontend build f…

He works (worked?) for Google. I think he knows what it takes to build a site on a large team and the trade-offs.

Works for MS now

Re: If not React, then what?

#277

Earlier quoted context omitted.

My constant problem with React-based tools is that they don't support deep links properly. You want to right-click on a product description to open it in a different tab to check later, and you can't. Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.

I'm not sure how much experience you have with react, but it doesn't need to "support" links, they function exactly the same as with vanilla js, there's nothing about react that prevents their use. Using JavaScript for links is entirely a developer decision.

Sure is odd that a good number of react-and-friends websites can’t manage to support it all then.

Just like how routing and history is “solved” but I encounter websites every other day that completely break my browser history.

Re: If not React, then what?

#278

Great, another misinformed rant about React; meanwhile React developers get stuff done without inventing yet another template language. Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.

Why do you think bad developers or teams without sufficient budget may produce bad experiences when using React? What should those teams be caring about that React doesn't solve for them?

Re: If not React, then what?

#279
post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

I urge you to read Alex's Reckoning series. > performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds. > it doesn’t create issues visible to my users What do your users look like? What kind of devices are they on? Is it mostly mobil…

Curious, is this the series https://infrequently.org/2024/08/the-landscape/ ?

Re: If not React, then what?

#280
post #191

Earlier quoted context omitted.

>React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend. Respectfully, I disagree on all of these points.

Care to elaborate?

Other commenters have elaborated as well, but to summmarize: hundreds of Ms on a dev machine a) does matter and b) is likely much much more in less than ideal computing environments, I disagree that the backend usually is where more time is spent (at least in maaaaany apps I have worked on) And re: specialized domains, I think most users of most software appreciate speed even if it isn’t a stated objective
Post reply on HN