My main contention with the OP’s point was the assertion that React is almost always the right answer. One of my biggest bugbears about any web dev discussion (particularly on HN) is that everyone treats it as a one size fits all argument and it isn’t.
If you’re making a webapp with interactivity levels like Gmail has then React is a sensible choice. The page reloads very irregularly. But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
This is not the case. RSC solves the hydration problem, in which hydration is profoundly expensive (larger bundle sizes, more client JS to parse and execute, and slower time to interactive), when most of the UI on any website can be non-hydrated. This also gives you the ability to write server only code (which as it would turn out, reduces sending third party deps to the client even more) for free with beautiful composability to client side hydration when you need it.
Everyone hydrates at some point. Maybe you write isomorphic javascript or maybe you render a rails or python app and sprinkle in some JS. RSC enables you to do this with complete composition and re-usability.
I'll put my money where my mouth is: RSC will continue to grow in adoption and its patterns will be adopted across many UI frameworks and libraries. This wasn't a solution in search of a problem, this was a large step forward in giving us more optionality as to how we architect websites.
> There are too many devs out there only expert in the way React does things and can’t step outside of it.
This is a weird ad hominem, attacking developers' skill instead of the actual technology. There are millions upon millions of React developers, and many of us have been building successful software for a long time and step outside of React every day.
> But if you’re making something like a blog with lots of drive by visits and only small islands of reactive content IMO it’s the wrong choice.
For some use-cases it is not the best choice, and for others it's the correct one. No one is hailing React as a one-size-fits-all solution, rather it remains a great balance that scales remarkably well to many needs.
I’m surprised to see people still misusing the word isomorphic.
More recently though — over the past decade or so — JavaScript enthusiasts have been using this word to describe code sharing, which isn't quite right.
I'm struggling to understand also how it came to be [ab]used in this context. To take an old Greek mathematics word and use it to mean something that it doesn't really mean? Why? Isn't that silly? Isn't it pretentious?
Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebase with a well architected set of css and the markup and css actually do work for you. They are clarifying and reinforce structure. There are levels of productivity you gain based solely on things being clear and not convoluted that many people in our industry cannot recognize because they are fixated on the wrong thing. Whether that be what other people are using, or what gives dopamine hits (hot reloading, cool tech, etc)
It is a common saying, not to be taken "literally."
> The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful.
Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript on both the client and the server, meaning there are greater abstractions that can be leveraged.
> Have you ever looked at the css output?
Not sure what CSS in JS library you used but with something like Typestyle or PandaCSS, you write CSS but in JS objects, so the generated CSS is simply turning those objects into the CSS you already wrote, not sure why it would be any different.