5 ms·

Everything old is new again, and I'm not even that old to know that you can return HTML fragments from AJAX call. But this is worse from any architectural point

Everything old is new again, and I'm not even that old to know that you can return HTML fragments from AJAX call. But this is worse from any architectural point view. Why? The old way was to return HTML fragments and add them to the DOM. There was still a separation of concern as the presentation layer on the server didn't care about the interface presented on the client. It was just data generally composed by a template library. The advent of SPA makes it so that we can reunite the presentation layer (with the template library) on the frontend and just send the data to be composed down with the request's response. The issue with this approach is to again split the frontend, but now you have two template libraries to take care of (in this case one, but on the two sides). The main advantages of having a boundary is that you can have the best representation of data for each side's logic, converting only when needs. And the conversion layer needs to be simple enough to not introduce complexity of its own. JSON is fine as it's easy to audit a parser and HTML is fine, because it's mostly used as is on the other layer. We also have binary representation, but they also have strong arguments for their use. With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot.

tshaddox 2y ago
> The old way was to return HTML fragments and add them to the DOM. There was still a separation of concern as the presentation layer on the server didn't care about the interface presented on the client. I doubt there were many systems where the server-generated HTML fragments were generic enough that the server and client HTML documents didn't need to know anything about each other's HTML. It's conceivable to build such a system, particularly if it's intended for a screen-reader or an extremely thinly-styled web page, but in either of those cases HTML injection over AJAX would have been an unlikely architectural choice. In practice, all these systems that did HTML injection over AJAX were tightly coupled. The server made strong assumptions about the HTML documents that would be requesting HTML fragments, and the HTML documents made strong assumptions about the shape of the HTML fragments the server would give it.
- skydhash 2y ago
  > where the server-generated HTML fragments were generic enough that the server and client HTML documents didn't need to know anything about each other's HTML. > all these systems that did HTML injection over AJAX were tightly coupled That's because the presentation layer originated on the server. What the server didn't care about was the transformation that alters the display of the HTML on the client. So you can add add an extension to your browser that translate the text to another language and it wouldn't matter to the server. Or inject your own styles. Even when you do an AJAX request, you can add JS code that discards the response.
danabramov 2y ago
It feels like you haven't read the article and commented on the title. >The old way was to return HTML fragments and add them to the DOM. Yes, and the problem with that is described at the end of this part: https://overreacted.io/jsx-over-the-wire/#async-xhp https://overreacted.io/jsx-over-the-wire/#async-xhp >JSON is fine [..] With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot. I really don't know what you mean; the transport literally is JSON. We're not literally sending JSX anywhere. That's also in the article. The JSON output is shown about a dozen times throughout, especially in the third part. You can search for "JSON" on the page. It appears 97 times.
- whalesalad 2y ago
  to be fair this post is enormous. if i were to try and print it on 8.5x11 it comes out to 71 pages
  - danabramov 2y ago
    I mean sure but not commenting is always an option. I don't really understand the impulse to argue with a position not expressed in the text.
    - phpnode 2y ago
      it happens because people really want to participate in the conversation, and that participation is more important to them than making a meaningful point.
    - pixl97 2y ago
      Yet because of that the issue they were concerned about was shown to the thread readers without having to read 75 pages of text. Quite often people read the form thread first before wasting their life on some large corpus of text that might be crap. High quality discussions can point out poor quality (or at least fundamentally incorrect) posts and the reasons behind them enlightening the rest of the readers.
rapnie 2y ago
> Everything old is new again An age ago I took interest in KnockoutJS based on Model-View-ViewModel and found it pragmatic and easy to use. It was however at the beginning of the mad javascript framework-hopping marathon, so it was considered 'obsolete' after a few months. I just peeked, Knockout still exists. https://knockoutjs.com/ https://knockoutjs.com/ Btw, I wouldn't hop back, but better hop forward, like with Datastar that was on HN the other day: https://news.ycombinator.com/item?id=43655914 https://news.ycombinator.com/item?id=43655914
- tshaddox 2y ago
  Knockout was a huge leap in developer experience at the time. It's worth noting that Ryan Carniato, the creator of SolidJS, was a huge fan of Knockout. It's a major influence of SolidJS.
- kilroy123 2y ago
  I was a big fan of knockoutjs back in the day! An app I built with it is still in use today.
aylmao 2y ago
> The main advantages of having a boundary is that you can have the best representation of data for each side's logic, converting only when needs. RSC doesn't impede this. In fact it improves it. Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire. > With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot. JSX is syntactic sugar for a specific format of JavaScript object. It's a pretty simple format really. From ReactJSXElement.js, L242 [1]: element = { // This tag allows us to uniquely identify this as a React Element $$typeof: REACT_ELEMENT_TYPE, // Built-in properties that belong on the element type, key, ref, props, }; As far as I'm aware, TC39 hasn't yet specified which shape of literal is "ok" and which one is "wrong" to run on a computer, depending on wether that computer has a screen or not. I imagine this is why V8, JSC and SpiderMonkey, etc let you create objects of any shape you want on any environment. I don't understand what's wrong about using this shape on the server. [1] https://github.com/facebook/react/blob/e71d4205aed6c41b88e3689c76b41da65f5c04c0/packages/react/src/jsx/ReactJSXElement.js#L242 https://github.com/facebook/react/blob/e71d4205aed6c41b88e36...
- jdkoeck 2y ago
  > Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire. I can't let go of the fact that you get the exact same thing if you just render html on the server. It's driving me crazy. We've really gone full circle, and I'm not sure for what benefit.

tshaddox 2y ago

> The old way was to return HTML fragments and add them to the DOM. There was still a separation of concern as the presentation layer on the server didn't care about the interface presented on the client. I doubt there were many systems where the server-generated HTML fragments were generic enough that the server and client HTML documents didn't need to know anything about each other's HTML. It's conceivable to build such a system, particularly if it's intended for a screen-reader or an extremely thinly-styled web page, but in either of those cases HTML injection over AJAX would have been an unlikely architectural choice. In practice, all these systems that did HTML injection over AJAX were tightly coupled. The server made strong assumptions about the HTML documents that would be requesting HTML fragments, and the HTML documents made strong assumptions about the shape of the HTML fragments the server would give it.

skydhash 2y ago
> where the server-generated HTML fragments were generic enough that the server and client HTML documents didn't need to know anything about each other's HTML. > all these systems that did HTML injection over AJAX were tightly coupled That's because the presentation layer originated on the server. What the server didn't care about was the transformation that alters the display of the HTML on the client. So you can add add an extension to your browser that translate the text to another language and it wouldn't matter to the server. Or inject your own styles. Even when you do an AJAX request, you can add JS code that discards the response.

danabramov 2y ago

It feels like you haven't read the article and commented on the title. >The old way was to return HTML fragments and add them to the DOM. Yes, and the problem with that is described at the end of this part: https://overreacted.io/jsx-over-the-wire/#async-xhp https://overreacted.io/jsx-over-the-wire/#async-xhp >JSON is fine [..] With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot. I really don't know what you mean; the transport literally is JSON. We're not literally sending JSX anywhere. That's also in the article. The JSON output is shown about a dozen times throughout, especially in the third part. You can search for "JSON" on the page. It appears 97 times.

whalesalad 2y ago
to be fair this post is enormous. if i were to try and print it on 8.5x11 it comes out to 71 pages
- danabramov 2y ago
  I mean sure but not commenting is always an option. I don't really understand the impulse to argue with a position not expressed in the text.
  - phpnode 2y ago
    it happens because people really want to participate in the conversation, and that participation is more important to them than making a meaningful point.
  - pixl97 2y ago
    Yet because of that the issue they were concerned about was shown to the thread readers without having to read 75 pages of text. Quite often people read the form thread first before wasting their life on some large corpus of text that might be crap. High quality discussions can point out poor quality (or at least fundamentally incorrect) posts and the reasons behind them enlightening the rest of the readers.

rapnie 2y ago

> Everything old is new again An age ago I took interest in KnockoutJS based on Model-View-ViewModel and found it pragmatic and easy to use. It was however at the beginning of the mad javascript framework-hopping marathon, so it was considered 'obsolete' after a few months. I just peeked, Knockout still exists. https://knockoutjs.com/ https://knockoutjs.com/ Btw, I wouldn't hop back, but better hop forward, like with Datastar that was on HN the other day: https://news.ycombinator.com/item?id=43655914 https://news.ycombinator.com/item?id=43655914

tshaddox 2y ago
Knockout was a huge leap in developer experience at the time. It's worth noting that Ryan Carniato, the creator of SolidJS, was a huge fan of Knockout. It's a major influence of SolidJS.
kilroy123 2y ago
I was a big fan of knockoutjs back in the day! An app I built with it is still in use today.

aylmao 2y ago

> The main advantages of having a boundary is that you can have the best representation of data for each side's logic, converting only when needs. RSC doesn't impede this. In fact it improves it. Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire. > With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot. JSX is syntactic sugar for a specific format of JavaScript object. It's a pretty simple format really. From ReactJSXElement.js, L242 [1]: element = { // This tag allows us to uniquely identify this as a React Element $$typeof: REACT_ELEMENT_TYPE, // Built-in properties that belong on the element type, key, ref, props, }; As far as I'm aware, TC39 hasn't yet specified which shape of literal is "ok" and which one is "wrong" to run on a computer, depending on wether that computer has a screen or not. I imagine this is why V8, JSC and SpiderMonkey, etc let you create objects of any shape you want on any environment. I don't understand what's wrong about using this shape on the server. [1] https://github.com/facebook/react/blob/e71d4205aed6c41b88e3689c76b41da65f5c04c0/packages/react/src/jsx/ReactJSXElement.js#L242 https://github.com/facebook/react/blob/e71d4205aed6c41b88e36...

jdkoeck 2y ago
> Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire. I can't let go of the fact that you get the exact same thing if you just render html on the server. It's driving me crazy. We've really gone full circle, and I'm not sure for what benefit.