i think every react developer should watch this talk. if you want to cut to the chase, here is a timestamp where it kicks into high gear. (the stuff before is also very interesting, so maybe you'll rewind and watch the whole talk). but just listen for a few minutes and then keep watching if curious?
Comments
But it also terrifies the shit out of me that these boundaries are becoming so blurred. And it feels like *ignorance* of interconnect is now the expected norm.
And my gut tells me that the broadly awesome state of the web being made of JSON APIs we users can just do stuff with is being critically backstabbed!!
I do wish the machinery in between was more in focus, was more something we could touch, see, manipulate.
everyone talks about the component and props serialization but very little about server functions which are more interesting.
I'd be really curious to see more real-world case studies of implementing RSCs and especially what benefits were gained.
I’d love to pair program on this with you to better understand it. You actually did me a favor 15 years ago that I deeply appreciate.
1. I have all the data I need already
2. Or I have more data than I’m fetching and need to go back to the server anyway.
Still moving state to the URL gives you object permanence and the data fetching can continue to exist on the server.
Or a combination of the two. I don’t understand why you’d need parallel tracks for data fetching (assuming you mean server AND client).
6 months later you realize 2 of these places need to paginate the data on the server – now you need API endpoints and a network back-and-forth.
For context this is not at the htmx conference and this talk is not trying to say htmx doesn't solve these problems in a way that is simpler to think about than React does.
https://conffab.com/presentation/how-react-router-became-a-framework/?gl=zCBWFoBZr5CR
what about HTTP cache control?
how do I add some headers?
or what if I want to rerun the request? abort the request?
abstracting away the entire network layer also means you have no control of it, doesn't it?
also why is this even tied to React? Meteor used to do this, I think?
both try to bridge the network in some way, but that seems to be where the similarity ends as far as i can tell
it's probably more similar to Opa, if you remember that? it had literal client and server functions. (and also "client server" functions, which would run anywhere.)
(from https://github.com/MLstate/opalang/wiki/Developing-for-the-web)
As usual JS devs are biased and only think about the frontend, rendering, etc.
Backend apps are a lot more than just rendering HTML.
I'm writing an article about this. I'll ping you once I publish it if you're interested.