161–170 of 756 posts
Yes it’s hard to learn the mental model but worth the effort.
My one tip to make your life with react easier …. don’t use state except within a component, instead send document events …… makes react 10X easier.
Having said the above I don’t do any SSR and not a fan of it.
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…
Mithril.js beats it in my opinion.
I’m sure many developers would argue in favor of other libraries over React.
React is simply the most popular.
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…
But is that not the crux of the article? So much of the web is the former but is built and distributed as if it's the latter, with all the end-user downsides that entails.
Earlier quoted context omitted.
If React is so great how come Amazon isn't using it in their store? I think last year an Amazon frontend engineer wrote some tweets explaining they tried React and it was too slow. So they keep using Java for SSR and sprinkle vanilla JS. They were still using jQuery until a couple of years ago and probably still are in some parts of their site.
React is in use in many heavily used frontends at Amazon, maybe not the retail site But there's no inherent reason React couldn't be used for a page that basically shows pictures of products with a description next to them, the bottlenecks will have nothing to do with the frontend in a well engineered system for that type of site
Even freaking Google (who really should know better) suffers from that. Amazon's retail frontend uses plain HTML, so it works fine.
Earlier quoted context omitted.
I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…
So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with. What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer o…
If your use case is a simple website, React is just a nice templating lib and you won't need to use any of the things people generally dislike about it. That AND your experience when you inevitably have to add some interactivity is going to be 100x better than vanilla JS.
As for the build step, there are many turn key solutions nowadays that "just work". And isn't a small build step a plus, compared to being at the mercy of a typo breaking everything? To me that piece of mind if worth a lot, compared to whatever manual testing you'd have to do if you work with "text" files.
I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.
And perhaps most important of all: it's the tool we know.
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…
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.)
- es6 modules work
This has been a big talking point in the Rails community lately — one of the big selling points of Rails 8 was the fact that you can, by default, ship a whole webapp without a build step, and that this is considered the "happy path".
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. 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.
The second reason the author says is that it’s based on a legacy eventing system which supports IE. The author goes on for quite a while to say how bad this is, but I question the assumption it’s predicated on: the legacy eventing system never bothers me, and it doesn’t create issues visible to my users. As far as it seems to me, this argument is akin to saying that React hasn’t bothered refactoring an old part of the code base. Yes, that’s not great, but it hardly strikes me as a reason to drop a framework entirely.
Finally, the author doesn’t actually give a prescription as to what to use instead of React. This is, personally, where the argument really falls apart. React does make a set of tradeoffs, I don’t deny that, but most alternatives I’ve seen make a worse set of tradeoffs that shift more work onto the engineer. Of course, since the author doesn’t actually highlight any alternative, we can’t have a discussion about what you’re trading away, but I suspect that the author makes no proposal because he knows that any alternative would immediately be shot down as obviously worse than React.
Earlier quoted context omitted.
Cannot agree more! Mastering React is ridiculously hard for what it is. There are so many “buts,” “it depends,” and subtle differences to navigate, like useEffect vs. useLayoutEffect. But don't forget useEffect is an evil in the first place and so on, and so on. It feels like a clever proof of concept with a leaky abstraction at its core, one that no amount of effort can truly fix, no matter how much they throw at it…
You shouldn't write a single useEffect in the first year or two of your career in React. Why people are so keen on stabbing themselves just because there's one or two weird shaped forks in the kitchen drawer. Why do suddenly everyone tries to use it for spreading butter or peeling eggs? Just understand what unidirectional data flow is and you are golden. You know the entirety of React you should be using for your fir…
As for your question, “Why does everyone suddenly try to use it for spreading butter or peeling eggs?”
I guess part of the reason is that many people rely on older tutorials and patterns where the usage of useEffect was much more tolerated or even encouraged as a catch-all solution. There’s still a lot of inertia from the old componentDidThis/componentDidThat paradigm, with useEffect being its direct replacement.
I feel it is only a recent tendency to finally abandon the overuse of effect hooks.
Just open an average Stack Overflow React question, and you’ll see how many useEffects are crammed in there.