zlacker

till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ?

mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.

>>dzonga+(OP)
easier/more reactivity, doesnt require your api responses to be text parsable to html

>>dzonga+(OP)
They lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly.

It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the developer with more grounded flexibility than RSCs. I wrote a blog post about this[0].

To answer your question, htmx solves this by leaning on the server immensely. It doesn't provide a complete client-side framework when you need it. RSCs allow both the server and the client to co-exist, simply composing between the two while maintaining the full power of each.

[0] https://saewitz.com/server-components-give-you-optionality

>>dzonga+(OP)
>now cz of the complexity I refuse to work with react.

What do you like to work with now?

>>dzonga+(OP)
You can optionally enhance it and use React on the client. Doing that with HTMX is doable with "islands" but a bit more of a pain in the ass - and you'll struggle hard if you attempt to share client state across pages. Actually there are just a lot of little gotchas with the htmx approach

I mean it's a lot of complexity but ideally you shouldn't bring it in unless you actually need it. These solutions do solve real problems. The only issue is people try to use it everywhere. I don't use RSC, standard SPAs are fine for my projects and simpler

>>lepton+qb
Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.

>>switz+fb
But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.

>>ptx+Ul
Yep! It’s really hard to reason in Next about when things happen on the server vs client. This makes it harder to make things secure.

You can create clean separation in your code to make this easier to understand but it’s not well enforced by default.

>>Tranqu+6l
Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.

They don't address the exact same markets.

>>ethanw+4p
Yeah… one of them addresses a market populated by hundreds of thousands of developers with extensive professional experience in the framework, and the other addresses a niche of Python developers who refused to learn JavaScript until somebody hid it from them and called it hypermedia.

>>dzonga+(OP)
React lets you inflate your salary.

>>switz+fb
Just because something is made possible and you can do it doesn't mean you should!

The criticism is that by allowing you to do something you shouldn't, there isn't any benefit to be had, even if that system allows you to do something you couldn't before.

>>chatma+ma1
100’s of thousands used to use php too :) most developers (roughly 97.56% are terrible/incompetent so going with the herd should tell you you are on the wrong train :)

>>bdangu+Oz1
Thousands of developers still use PHP… and even more users… Wordpress (43% of web), Facebook (billions of users), Wikipedia (billions of users)…. all PHP.

htmx is a a toy, mildly amusing to play with, built on an insecure foundation that bypasses basic browser security controls and hands a blob of JavaScript to a bunch of backend developers who can’t be bothered to learn it because they think they know better…

No serious project uses htmx and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development.

>>chatma+MA1
“No serious project uses [insert any framework/language/…] and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development” if team is incompetent

>>switz+fb
It also gives you a 10 cve