3 ms·

Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. Thes

by jiofih 6y ago

Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).

nawgz 6y ago
This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an orchestrator for remote systems which can somehow inject interactivity into my stateful client. It's spaghetti architecture and I don't see what the gain is. Why do my servers need to know how to describe my layout!?
- jiofih 6y ago
  You are not listening. You don’t need round trips. The same way your SPA receives its initial data from the server, you can send it as HTML (hidden) and just use JS to switch between the views. And there is nothing special about “understanding layout” on the server, you can run the exact same rendering code in the server with node. I’m not going to bother mentioning streaming html / progressive rendering, SEO, caching, semantic content or accessibility since you obviously won’t care much for that. We’ve been doing this on the web for over two decades now. Tell me about spaghetti architecture once you work on a real world project using React.
  - nawgz 6y ago
    >You are not listening. You don't need round trips. Ok, so you've already proposed to me that my server not only needs to know how to load all the data, it also has to have an HTML renderer baked in, AND in your haste to say my SPA doesn't have any advantages, you've already forced your server to execute a layout algorithm on N graphs of unknown complexity, on your own machine & dime instead of your client's, just in order to accomplish what my SPA got for free: instantly rendering the next content when the user clicked. The fact that you can come up with a list of things orthogonally related to serving web content that aren't solved any more gracefully with server-side rendering than an SPA - SEO, semantic content, accessibility - it's just silly. Same with this idea that you're going to pre-render the HTML into an ingenious layout where the user makes a series of actions that uncover nested HTML and don't require round-trips. It's as if you're ignoring that a primary benefit of SPAs is you can hide data loading really easily with prefetching JSON blobs and writing JS to navigate the tree. It's literally the language for the task. It's exactly why I've not been shy to say this: anti-JS anti-SPA users get so bent out of shape that SPAs build nice UIs that they throw the baby out with the bathwater.

by jiofih 6y ago

nawgz 6y ago

This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an orchestrator for remote systems which can somehow inject interactivity into my stateful client. It's spaghetti architecture and I don't see what the gain is. Why do my servers need to know how to describe my layout!?

jiofih 6y ago
You are not listening. You don’t need round trips. The same way your SPA receives its initial data from the server, you can send it as HTML (hidden) and just use JS to switch between the views. And there is nothing special about “understanding layout” on the server, you can run the exact same rendering code in the server with node. I’m not going to bother mentioning streaming html / progressive rendering, SEO, caching, semantic content or accessibility since you obviously won’t care much for that. We’ve been doing this on the web for over two decades now. Tell me about spaghetti architecture once you work on a real world project using React.
- nawgz 6y ago
  >You are not listening. You don't need round trips. Ok, so you've already proposed to me that my server not only needs to know how to load all the data, it also has to have an HTML renderer baked in, AND in your haste to say my SPA doesn't have any advantages, you've already forced your server to execute a layout algorithm on N graphs of unknown complexity, on your own machine & dime instead of your client's, just in order to accomplish what my SPA got for free: instantly rendering the next content when the user clicked. The fact that you can come up with a list of things orthogonally related to serving web content that aren't solved any more gracefully with server-side rendering than an SPA - SEO, semantic content, accessibility - it's just silly. Same with this idea that you're going to pre-render the HTML into an ingenious layout where the user makes a series of actions that uncover nested HTML and don't require round-trips. It's as if you're ignoring that a primary benefit of SPAs is you can hide data loading really easily with prefetching JSON blobs and writing JS to navigate the tree. It's literally the language for the task. It's exactly why I've not been shy to say this: anti-JS anti-SPA users get so bent out of shape that SPAs build nice UIs that they throw the baby out with the bathwater.