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…
If not React, then what?
271–280 of 756 posts
Re: If not React, then what?
#272I 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…
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?
#273Reading 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…
Tell me your websites are unbearably slow without telling me your websites are unbearably slow :D
Re: If not React, then what?
#274Re: If not React, then what?
#275I 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.) -…
Re: If not React, then what?
#276I 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.
Re: If not React, then what?
#277Earlier 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.
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?
#278Great, 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.
Re: If not React, then what?
#279Reading 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…
Re: If not React, then what?
#280Earlier 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?