6 ms·

I assume that HTML Dom would be fastest. Statically generated. And that working w/ DOM/CSS would make it easier for team's designers to be more engaged.

bsimpson 10y ago
Gibbon is Netflix's proprietary form of the DOM. They found that the standard DOM was too hard to optimize for embedded hardware, but that it was much easier if they removed the parts they didn't need. I believe Jafar gave a talk at one of the React Confs about it.
- deleted 10y ago
  [deleted]
jeremiep 10y ago
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.

bsimpson 10y ago

Gibbon is Netflix's proprietary form of the DOM. They found that the standard DOM was too hard to optimize for embedded hardware, but that it was much easier if they removed the parts they didn't need. I believe Jafar gave a talk at one of the React Confs about it.

deleted 10y ago
[deleted]

jeremiep 10y ago

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.