5 ms·

To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people

by untog 7y ago

To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. <body> tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. But for fully interactive webapps, React is great.

IggleSniggle 7y ago
...aren't the static portions uh...rendered server side? And possibly even the dynamic ones cached when common? If not, I'm confused about what SSR means in this scenario.
- untog 7y ago
  They are rendered statically... then hydrated client side, needlessly, because they’ll never change.
mr_toad 7y ago
I don’t understand why you would serve up the React library if you’ve already rendered on the server. I use React server side and then serve the static HTML.
- untog 7y ago
  Because you still need interactivity of some sort. Even if it’s just a navigation menu.
dgb23 7y ago
>So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. You hydrate the markup because you want to render subsequent state changes in the client. Meaning much smaller downloads (just the relevant data) between route changes and so on.
- untog 7y ago
  That’s often a bad bet though. Obviously it depends on what kind of site you’re operating but a lot of places have a very steep drop off after a single page view. If that’s your case then you’re optimising for an edge case at the expense of the majority.
  - dgb23 7y ago
    I see you concern but right off the bat here is a very good example of where this kind of frontend pattern works very well, even for site that is essentially just static content from a user perspective: https://reactjs.org/ https://reactjs.org/ I suggest you open the network inspector and see what happens when you hover over links, navigate and so on. The experience is very fast and responsive on initial page loads and even faster on subsequent navigation: The initial page load is as fast despite of hydration because many of the requests are non-blocking and/or happen after the raw page content is loaded, including JS scripts. Further navigation triggered loads just load small amounts of JSON while many of the assets and common UI elements are already there. In this case the data is even loaded while you hover over a navigation link. Yes, this assumes that you actually navigate through the site and yes it does more than you sometimes need if you just view a single page. But the trade-off seems to be very good here from my perspective, especially because one cannot know if the visitor will navigate on the site past the initial page load or not. The content on this site is also structured into small subject-pages (see: the docs sections), which synergizes well with this frontend pattern. On top of that comes ease of development, tooling and automation around the react ecosystem (you'll find similar in other frameworks). And the mere fact that there is much less coupling between the rendering/gui side and the data/server side, even though most of the site is rendered on a server, because the frontend code lives in one cohesive framework.
    - untog 7y ago
      Perhaps unsuprisingly, React's own web site is a great example of how to do React right. By the looks of it it's not loading the entire page into Virtual DOM, it's got code splitting, loading on demand... all the absolutely right things. A lot of React sites I see in the wild have none of this. They have a multi-MB JS blob that gets downloaded immediately on load and parses a giant JSON blob stored in the HTML that represents the page state. I'm not saying React isn't useful or that it can't be done well. I'm saying that in a lot of cases it just isn't done well. Whether that's down to a lack of education or a lack of care I don't know.

by untog 7y ago

IggleSniggle 7y ago

...aren't the static portions uh...rendered server side? And possibly even the dynamic ones cached when common? If not, I'm confused about what SSR means in this scenario.

untog 7y ago
They are rendered statically... then hydrated client side, needlessly, because they’ll never change.

mr_toad 7y ago

I don’t understand why you would serve up the React library if you’ve already rendered on the server. I use React server side and then serve the static HTML.

untog 7y ago
Because you still need interactivity of some sort. Even if it’s just a navigation menu.

dgb23 7y ago

>So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. You hydrate the markup because you want to render subsequent state changes in the client. Meaning much smaller downloads (just the relevant data) between route changes and so on.

untog 7y ago
That’s often a bad bet though. Obviously it depends on what kind of site you’re operating but a lot of places have a very steep drop off after a single page view. If that’s your case then you’re optimising for an edge case at the expense of the majority.
- dgb23 7y ago
  I see you concern but right off the bat here is a very good example of where this kind of frontend pattern works very well, even for site that is essentially just static content from a user perspective: https://reactjs.org/ https://reactjs.org/ I suggest you open the network inspector and see what happens when you hover over links, navigate and so on. The experience is very fast and responsive on initial page loads and even faster on subsequent navigation: The initial page load is as fast despite of hydration because many of the requests are non-blocking and/or happen after the raw page content is loaded, including JS scripts. Further navigation triggered loads just load small amounts of JSON while many of the assets and common UI elements are already there. In this case the data is even loaded while you hover over a navigation link. Yes, this assumes that you actually navigate through the site and yes it does more than you sometimes need if you just view a single page. But the trade-off seems to be very good here from my perspective, especially because one cannot know if the visitor will navigate on the site past the initial page load or not. The content on this site is also structured into small subject-pages (see: the docs sections), which synergizes well with this frontend pattern. On top of that comes ease of development, tooling and automation around the react ecosystem (you'll find similar in other frameworks). And the mere fact that there is much less coupling between the rendering/gui side and the data/server side, even though most of the site is rendered on a server, because the frontend code lives in one cohesive framework.
  - untog 7y ago
    Perhaps unsuprisingly, React's own web site is a great example of how to do React right. By the looks of it it's not loading the entire page into Virtual DOM, it's got code splitting, loading on demand... all the absolutely right things. A lot of React sites I see in the wild have none of this. They have a multi-MB JS blob that gets downloaded immediately on load and parses a giant JSON blob stored in the HTML that represents the page state. I'm not saying React isn't useful or that it can't be done well. I'm saying that in a lot of cases it just isn't done well. Whether that's down to a lack of education or a lack of care I don't know.