4 ms·

>I don't see the advantages of having JSX representation of JSON objects on the server side. That's not what we're building towards. I'm just using "breaking J

>I don't see the advantages of having JSX representation of JSON objects on the server side. That's not what we're building towards. I'm just using "breaking JSON apart" as a narrative device to show that Server Components componentize the UI-specific parts of the API logic (which previously lived in ad-hoc ViewModel-like parts of REST responses, or in the client codebase where REST responses get massaged). The change-up happens at this point in the article: https://overreacted.io/jsx-over-the-wire/#viewmodels-revisited https://overreacted.io/jsx-over-the-wire/#viewmodels-revisit... If you're interested in the "final" code, it's here: https://overreacted.io/jsx-over-the-wire/#final-code-slightly-edited https://overreacted.io/jsx-over-the-wire/#final-code-slightl.... It blends the previous "JSON-building" into components.

skydhash 2y ago
I'm pointing out that this particular pattern (Server Components) is engendering more complexity than necessary. If you have a full blown SPA on the client side, you shouldn't use ViewModels as that will ties your backend API to the client. If you go for a mixed approach, then your presentation layer is on the server and it's not an API. HTMX is cognizant of this fact. What it adds are useful and nice abstractions on the basis that the interface is constructed on one end and used on the other. RSC is a complex solution for a simple problem.
- danabramov 2y ago
  >you shouldn't use ViewModels as that will ties your backend API to the client. It doesn’t because you can do this as a layer in front of the backend, as argued here: https://overreacted.io/jsx-over-the-wire/#backend-for-frontend https://overreacted.io/jsx-over-the-wire/#backend-for-fronte... Note “instead of replacing your existing REST API, you can add…”. It’s a thing people do these days! Recognizing the need for this layer has plenty of benefits. As for HTMX, I know you might disagree, but I think it’s actually very similar in spirit to RSC. I do like it. Directives are like very limited Client components, server partials of your choice are like very limited Server components. It’s a good way to get a feel for the model.
  - megaman821 2y ago
    With morphdom (or one day native DOM diffing), wouldn't HTMX fufill 80% of your wishlist? I personally find HTMX pairs well with web components for client components since their lifecycle runs automatically when they get added to the DOM.
    - pier25 2y ago
      What if the internal state of the web component has changed? Wouldn't an HTMX update stomp over it and reset the component to its initial state?
      - megaman821 2y ago
        Not when using morphdom or the new moveBefore method. Although you would have to give your element a stable id.
        pier25 2y ago
        Even when using shadow DOM? What about internal JS state that isn't reflected in the DOM?
        megaman821 2y ago
        If it is new to the DOM it will get added. If it is present in the DOM (based on id and other attributes when the id is not present) it will not get recreated. It may be left alone or it may have its attributes merged. There are a ton of edge cases though, which is why there is no native DOM diffing yet.
        pier25 2y ago
        Thanks I need to look closer at this!

skydhash 2y ago

I'm pointing out that this particular pattern (Server Components) is engendering more complexity than necessary. If you have a full blown SPA on the client side, you shouldn't use ViewModels as that will ties your backend API to the client. If you go for a mixed approach, then your presentation layer is on the server and it's not an API. HTMX is cognizant of this fact. What it adds are useful and nice abstractions on the basis that the interface is constructed on one end and used on the other. RSC is a complex solution for a simple problem.

danabramov 2y ago
>you shouldn't use ViewModels as that will ties your backend API to the client. It doesn’t because you can do this as a layer in front of the backend, as argued here: https://overreacted.io/jsx-over-the-wire/#backend-for-frontend https://overreacted.io/jsx-over-the-wire/#backend-for-fronte... Note “instead of replacing your existing REST API, you can add…”. It’s a thing people do these days! Recognizing the need for this layer has plenty of benefits. As for HTMX, I know you might disagree, but I think it’s actually very similar in spirit to RSC. I do like it. Directives are like very limited Client components, server partials of your choice are like very limited Server components. It’s a good way to get a feel for the model.
- megaman821 2y ago
  With morphdom (or one day native DOM diffing), wouldn't HTMX fufill 80% of your wishlist? I personally find HTMX pairs well with web components for client components since their lifecycle runs automatically when they get added to the DOM.
  - pier25 2y ago
    What if the internal state of the web component has changed? Wouldn't an HTMX update stomp over it and reset the component to its initial state?
    - megaman821 2y ago
      Not when using morphdom or the new moveBefore method. Although you would have to give your element a stable id.
      - pier25 2y ago
        Even when using shadow DOM? What about internal JS state that isn't reflected in the DOM?
        megaman821 2y ago
        If it is new to the DOM it will get added. If it is present in the DOM (based on id and other attributes when the id is not present) it will not get recreated. It may be left alone or it may have its attributes merged. There are a ton of edge cases though, which is why there is no native DOM diffing yet.
        pier25 2y ago
        Thanks I need to look closer at this!