30 ms·

> "There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder. T

> "There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality." What is "old-fashioned data loading"?

svachalek 5y ago
The truly old fashioned way is to load your data and render the page with it in the server. A simplicity that was lost in the SPA, but that's what SSR gives back to you. But since this is an anti-SSR piece I'm not sure what it's getting at.
- epistasis 5y ago
  The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks, resulting in the need to override all the basics with bulky JavaScript that doesn't load until some time after rendering. Which, as a user, has bitten me many times. I hate hate hate when a page seems loaded, but something has stalled, and I can't interact with anything. As much as I hate Java, I still kind of long for old fashioned Tomcat web apps that sent out fully formed and usable HTML with small bits of JavaScript enhancements.
  - deleted 5y ago
    [deleted]
  - madeofpalk 5y ago
    > The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks This is not true. SSR React still returns HTML. You can set hrefs on a tags. They all work fine.
    - epistasis 5y ago
      Aha, thanks. So when the author writes: > So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive. Does this mean that one could make the page interactive with server side rendering, but it's not normally done? Or did I completely misunderstand this paragraph.
      - masswerk 5y ago
        > Does this mean that one could make the page interactive with server side rendering, but it's not normally done? It can be done, it is actually, how things were done a quarter of a century ago: server-side rendered content with tiny triggers for interactivity directly embedded in the code. In the next step, as complexity grew and as an attempt at separating concerns, you would send the content and along with it a bundle of code for interactivity (which may have been sent in the same request or as a separate resource). Then, we got frameworks. Technically, these could do this as well, but it doesn't match their basic pattern.
      - tshaddox 5y ago
        If you click on an <a> tag before the JavaScript has loaded and React has hydrated, the browser will do a full page load of the URL that you clicked on. Assuming that new page is also rendered on the server, it should work fine and feel just as good as if it was a traditional server-rendered HTML web site or if you had JavaScript turned off. (Of course, things that do require JavaScript for interactivity, like custom tooltips on hover, custom form validation, etc. won't work until the JavaScript has loaded.)
        hmsimha 5y ago
        Just to add to the above, this is specifically when your pages are server-side rendered. Hydration is a concept of taking a server-rendered page and making it interactive with Javascript. You can have your NextJS/React app server-rendered, and then users visiting a page will get the page. Clicking links within the application will use Javascript routing to load the part of the application that needs to be displayed (and prevent the default navigation from clicking said links). I think in practice it's more likely for users to fall back to default navigation which then relies on full server rendering when they have Javascript disabled, than it is because they've clicked before the front-end router has started working. Also, before this thread I didn't realize React itself could be server-rendered (I thought that was the distinguishing point of Nextjs). Is it common to use non-next React for SSR?
z3t4 5y ago
JSON or XML, using REST or websocket maybe? One request per "page load" is an anti-pattern in SPA's though - you should send all static data once, lazy load large assets like images, and sync only the dynamic non cacheable data.
- shadowgovt 5y ago
  It kind of depends on your mental model for your user. For mobile devices in many countries outside the United states, you're doing your user no favors shipping them a bunch of static data that they don't actually need yet because you've wasted their bandwidth if they never use it and bandwidth costs money.
qbasic_forever 5y ago
JQuery document ready handler that makes a XMLHttpRequest and then a pile of jquery DOM manipulation calls to make the DOM state reflect the data you just got back from the server. Basically just a lot of imperative DOM manipulation calls. No templating, no MVC patterns, etc. This is the kind of frontend JS that was all over the web in the early 2000's.

svachalek 5y ago

The truly old fashioned way is to load your data and render the page with it in the server. A simplicity that was lost in the SPA, but that's what SSR gives back to you. But since this is an anti-SSR piece I'm not sure what it's getting at.

epistasis 5y ago
The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks, resulting in the need to override all the basics with bulky JavaScript that doesn't load until some time after rendering. Which, as a user, has bitten me many times. I hate hate hate when a page seems loaded, but something has stalled, and I can't interact with anything. As much as I hate Java, I still kind of long for old fashioned Tomcat web apps that sent out fully formed and usable HTML with small bits of JavaScript enhancements.
- deleted 5y ago
  [deleted]
- madeofpalk 5y ago
  > The problem with SSR, as I understand it according to this article, is that it still removed native link handling from clicks This is not true. SSR React still returns HTML. You can set hrefs on a tags. They all work fine.
  - epistasis 5y ago
    Aha, thanks. So when the author writes: > So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive. Does this mean that one could make the page interactive with server side rendering, but it's not normally done? Or did I completely misunderstand this paragraph.
    - masswerk 5y ago
      > Does this mean that one could make the page interactive with server side rendering, but it's not normally done? It can be done, it is actually, how things were done a quarter of a century ago: server-side rendered content with tiny triggers for interactivity directly embedded in the code. In the next step, as complexity grew and as an attempt at separating concerns, you would send the content and along with it a bundle of code for interactivity (which may have been sent in the same request or as a separate resource). Then, we got frameworks. Technically, these could do this as well, but it doesn't match their basic pattern.
    - tshaddox 5y ago
      If you click on an <a> tag before the JavaScript has loaded and React has hydrated, the browser will do a full page load of the URL that you clicked on. Assuming that new page is also rendered on the server, it should work fine and feel just as good as if it was a traditional server-rendered HTML web site or if you had JavaScript turned off. (Of course, things that do require JavaScript for interactivity, like custom tooltips on hover, custom form validation, etc. won't work until the JavaScript has loaded.)
      - hmsimha 5y ago
        Just to add to the above, this is specifically when your pages are server-side rendered. Hydration is a concept of taking a server-rendered page and making it interactive with Javascript. You can have your NextJS/React app server-rendered, and then users visiting a page will get the page. Clicking links within the application will use Javascript routing to load the part of the application that needs to be displayed (and prevent the default navigation from clicking said links). I think in practice it's more likely for users to fall back to default navigation which then relies on full server rendering when they have Javascript disabled, than it is because they've clicked before the front-end router has started working. Also, before this thread I didn't realize React itself could be server-rendered (I thought that was the distinguishing point of Nextjs). Is it common to use non-next React for SSR?

z3t4 5y ago

JSON or XML, using REST or websocket maybe? One request per "page load" is an anti-pattern in SPA's though - you should send all static data once, lazy load large assets like images, and sync only the dynamic non cacheable data.

shadowgovt 5y ago
It kind of depends on your mental model for your user. For mobile devices in many countries outside the United states, you're doing your user no favors shipping them a bunch of static data that they don't actually need yet because you've wasted their bandwidth if they never use it and bandwidth costs money.

qbasic_forever 5y ago

JQuery document ready handler that makes a XMLHttpRequest and then a pile of jquery DOM manipulation calls to make the DOM state reflect the data you just got back from the server. Basically just a lot of imperative DOM manipulation calls. No templating, no MVC patterns, etc. This is the kind of frontend JS that was all over the web in the early 2000's.