4 ms·

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a sim

Meh, React is great for more reasons than modularity. One way data flow combined with automatic updating and rendering is really really nice. I just wrote a simple UI for a terminal and having to manually call a function to paint to the screen felt rather...quaint. We've had modular templates for years. It's only recently that we've had the ability to think of UI elements as functions that automatically get called when their arguments update. This article also doesn't delve into why Facebook supports React so much. Or why Twitter, Reddit and the rest are switching to React. The answer being that React lets developers make really smooth, really addictive websites. I wouldn't be surprised if there was some studies showing that any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative if you care about having your users on your site. Multiply it by Facebook's revenue and paying the few million to fund a team of developers is a really good deal.

ricardobeat 6y ago
> One way data flow combined with automatic updating and rendering React did not bring that. Flux, released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. > React lets developers make really smooth, really addictive websites As someone who has been doing it for a decade, I don't see an inch of a difference. Browsers got more capable, our tools got more sophisticated, but there is nothing really you couldn't do a decade ago. If anything, React leads to bloated and inefficient SPAs. > any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative There is no 'round trip' for server render, it is the exact opposite - a client-side app will have no content to show in initial render until it boots in the client. Hence you need SSR + hydration to make it faster.
- _hardwaregeek 6y ago
  Did Flux really bring one way data flow? Because that's a pretty essential part of React. Even if React adopted it later, it's a core part of React's appeal. Do you legitimately see no difference in websites from 2012 and 2020? I'm honestly baffled if that's true. Payments are a massive difference that I've noticed. Every decent ecommerce site these days uses quite a lot of slick tricks to make the purchase flow really easy. Whether it's autocomplete based on Google Maps address data or being able to do everything without any obvious page refreshes, payments are significantly slicker. React definitely facilitates this. > There is no 'round trip' for server render Uhh there is a round trip. You click on a link, the new page does a request, loads new HTML, new CSS and paints the new page. Sure, an SPA takes longer to load up front, but you can now ensure that everything past that point is seamless. On a site like Facebook where the initial load won't kill conversions (because people are already addicted), you can take a 500ms hit so that stuff like infinite scroll and seamless notifications keep people on the site.
- jjeaff 6y ago
  >React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. My understanding is that react will calculate the diff of your changes and what is already rendered and then only render the difference.
  - ricardobeat 6y ago
    It will diff the virtual dom, but you'll still be running the `render()` method again for every component. That is, unless you replace it with a PureComponent that does shallow diffing, write your own `shouldComponentUpdate` (if still using classes), or use something like Redux that will actually manage updates outside of React's component lifecycle and take advantage of immutable data structures.

ricardobeat 6y ago

> One way data flow combined with automatic updating and rendering React did not bring that. Flux, released a few months later, brought the unidirectional data-flow to it; we were already building similar architectures using event buses, though with looser abstractions. The 'automatic rendering' is a bit deceptive. Unless you manually optimize it, React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. > React lets developers make really smooth, really addictive websites As someone who has been doing it for a decade, I don't see an inch of a difference. Browsers got more capable, our tools got more sophisticated, but there is nothing really you couldn't do a decade ago. If anything, React leads to bloated and inefficient SPAs. > any flash of unstyled content, i.e. a server render round trip, lowers conversions by x%. Therefore having a client side app is imperative There is no 'round trip' for server render, it is the exact opposite - a client-side app will have no content to show in initial render until it boots in the client. Hence you need SSR + hydration to make it faster.

_hardwaregeek 6y ago
Did Flux really bring one way data flow? Because that's a pretty essential part of React. Even if React adopted it later, it's a core part of React's appeal. Do you legitimately see no difference in websites from 2012 and 2020? I'm honestly baffled if that's true. Payments are a massive difference that I've noticed. Every decent ecommerce site these days uses quite a lot of slick tricks to make the purchase flow really easy. Whether it's autocomplete based on Google Maps address data or being able to do everything without any obvious page refreshes, payments are significantly slicker. React definitely facilitates this. > There is no 'round trip' for server render Uhh there is a round trip. You click on a link, the new page does a request, loads new HTML, new CSS and paints the new page. Sure, an SPA takes longer to load up front, but you can now ensure that everything past that point is seamless. On a site like Facebook where the initial load won't kill conversions (because people are already addicted), you can take a 500ms hit so that stuff like infinite scroll and seamless notifications keep people on the site.
jjeaff 6y ago
>React will simply re-render everything all the time which is the same as calling `App.render()` after every data change. My understanding is that react will calculate the diff of your changes and what is already rendered and then only render the difference.
- ricardobeat 6y ago
  It will diff the virtual dom, but you'll still be running the `render()` method again for every component. That is, unless you replace it with a PureComponent that does shallow diffing, write your own `shouldComponentUpdate` (if still using classes), or use something like Redux that will actually manage updates outside of React's component lifecycle and take advantage of immutable data structures.