6 ms·

Its quite easy to do server-side rendering of react pages, then only mount the dynamic views once in the browser.

djm_ 10y ago
It's possible but 'quite easy' does it a disservice as it is often not the case at any reasonable scale. Pinterest wrote a great article [1] on how they've handled it recently. [1] https://engineering.pinterest.com/blog/how-we-switched-our-template-rendering-engine-react https://engineering.pinterest.com/blog/how-we-switched-our-t...
- jeremiep 10y ago
  It really depends on your tech stacks. Running python on the backend and JS on the frontend will create enough impedance mismatch to indeed make server-side rendering of react rather difficult. Clojure's reagent and re-frame remove most of the complexity and tools from the equation. You run the same (mostly) code on the backend and frontend. This is what I meant by quite easy :) http://davidtanzer.net/server_side_rendering_with_re_frame http://davidtanzer.net/server_side_rendering_with_re_frame http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html
intrasight 10y ago
I often hear that approach mentioned. But it seems so counter to my experience - that computers are plenty fast to run even complex display logic and that I'd never notice the difference. Is there really a benefit for well-written code? Or is this just an easy workaround for poor code?
- jeremiep 10y ago
  I really don't like that argument because it assumes your program is important enough to be the only one running on your user's machines; it rarely ever is. Everything easily wastes 90% of the CPU resources it touches and the task manager is completely oblivious to it, happily reporting high usage. When you have 20+ tabs open and 10+ apps all those "its fast enough" apps combine to create their own variant of hell. And that isn't even a big workload. Its no wonders computers have increased many orders of magnitude in performance over the last decade, yet user experiences are still generally mediocre.
  - intrasight 10y ago
    We're talking here about the time to render JSON to HTML for one page - the page that this user is presumably looking at. If that takes 90% of your CPU for more that a few milliseconds, then it's time to refactor.
    - jeremiep 10y ago
      Its a bit more complicated. Its that JSON data, the request to API endpoint(s) to get it, the JavaScript to drive it, the request to fetch that JS and whatnot. That may not waste much CPU indeed, but instead wastes bandwidth and time. This is quite easy to notice on mobile devices. Your servers now have to serve these API endpoints; static pages can be deferred to proper CDNs. For larger deployments this can drive the server costs to eat your profits rather quickly. Not even considering the fact that the dynamic route was much more development than the static one in the first place. About the 90% wasted CPU, I was talking about how the CPU constantly waits for memory because very, very few programmers optimize for cache misses and lots of dynamic languages make it impossible to. Waiting on memory still shows as activity in the task manager, but the CPU isn't computing anything.
- ecnahc515 10y ago
  Most computers, sure, but Netflix runs on a variety of devices which includes pretty slow/dumb "smart" devices. An example is the Roku stick, where your resources might be quite limited.
- diggan 10y ago
  Well, sometimes is not much that it's poor code but a lot of data to render. For example, imagine rendering a form with 100 elements. If it takes 0.1 second to render that on a average computer, you can make that 0.01 by rendering it on the server instead.
  - intrasight 10y ago
    But your server has to render it for the thousands of visitors to you site. I still don't get the rationale.
    - Sanddancer 10y ago
      Smart rendering would involve using a mostly static template that's updated with the relatively few dynamic elements as the page is being readied to be sent over the wire. If 90% of your dynamic content is the same, why put that through your app processes at all?
      - intrasight 10y ago
        Static stuff is static at either end, and doesn't add to rendering time.
  - jeremiep 10y ago
    And then you can cache it. Whats the point of downloading megabytes of javascript, calling 80 different endpoints and then generating what could've been statically saved from the beginning and sent in a single request?

djm_ 10y ago

It's possible but 'quite easy' does it a disservice as it is often not the case at any reasonable scale. Pinterest wrote a great article [1] on how they've handled it recently. [1] https://engineering.pinterest.com/blog/how-we-switched-our-template-rendering-engine-react https://engineering.pinterest.com/blog/how-we-switched-our-t...

jeremiep 10y ago
It really depends on your tech stacks. Running python on the backend and JS on the frontend will create enough impedance mismatch to indeed make server-side rendering of react rather difficult. Clojure's reagent and re-frame remove most of the complexity and tools from the equation. You run the same (mostly) code on the backend and frontend. This is what I meant by quite easy :) http://davidtanzer.net/server_side_rendering_with_re_frame http://davidtanzer.net/server_side_rendering_with_re_frame http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html http://yogthos.net/posts/2015-11-24-Serverside-Reagent.html

intrasight 10y ago

I often hear that approach mentioned. But it seems so counter to my experience - that computers are plenty fast to run even complex display logic and that I'd never notice the difference. Is there really a benefit for well-written code? Or is this just an easy workaround for poor code?

jeremiep 10y ago
I really don't like that argument because it assumes your program is important enough to be the only one running on your user's machines; it rarely ever is. Everything easily wastes 90% of the CPU resources it touches and the task manager is completely oblivious to it, happily reporting high usage. When you have 20+ tabs open and 10+ apps all those "its fast enough" apps combine to create their own variant of hell. And that isn't even a big workload. Its no wonders computers have increased many orders of magnitude in performance over the last decade, yet user experiences are still generally mediocre.
- intrasight 10y ago
  We're talking here about the time to render JSON to HTML for one page - the page that this user is presumably looking at. If that takes 90% of your CPU for more that a few milliseconds, then it's time to refactor.
  - jeremiep 10y ago
    Its a bit more complicated. Its that JSON data, the request to API endpoint(s) to get it, the JavaScript to drive it, the request to fetch that JS and whatnot. That may not waste much CPU indeed, but instead wastes bandwidth and time. This is quite easy to notice on mobile devices. Your servers now have to serve these API endpoints; static pages can be deferred to proper CDNs. For larger deployments this can drive the server costs to eat your profits rather quickly. Not even considering the fact that the dynamic route was much more development than the static one in the first place. About the 90% wasted CPU, I was talking about how the CPU constantly waits for memory because very, very few programmers optimize for cache misses and lots of dynamic languages make it impossible to. Waiting on memory still shows as activity in the task manager, but the CPU isn't computing anything.
ecnahc515 10y ago
Most computers, sure, but Netflix runs on a variety of devices which includes pretty slow/dumb "smart" devices. An example is the Roku stick, where your resources might be quite limited.
diggan 10y ago
Well, sometimes is not much that it's poor code but a lot of data to render. For example, imagine rendering a form with 100 elements. If it takes 0.1 second to render that on a average computer, you can make that 0.01 by rendering it on the server instead.
- intrasight 10y ago
  But your server has to render it for the thousands of visitors to you site. I still don't get the rationale.
  - Sanddancer 10y ago
    Smart rendering would involve using a mostly static template that's updated with the relatively few dynamic elements as the page is being readied to be sent over the wire. If 90% of your dynamic content is the same, why put that through your app processes at all?
    - intrasight 10y ago
      Static stuff is static at either end, and doesn't add to rendering time.
- jeremiep 10y ago
  And then you can cache it. Whats the point of downloading megabytes of javascript, calling 80 different endpoints and then generating what could've been statically saved from the beginning and sent in a single request?