5 ms·

The premise of React isn’t at all about performance optimization, it’s about components.

by nwienert 6y ago

la_fayette 6y ago
Yes true, but why should one favor react over e.g. web-components if it is so much slower?
- acemarke 6y ago
  React and web components are different tools trying to solve different problems. Web components are primarily about trying to add new virtual HTML tags to "extend the platform". React and other frameworks are about trying to build interactive applications that require larger-scale UI management, efficiently, on top of the DOM, by defining pieces of that UI as a tree of reusable components (and using techniques that web components don't have available to them). If I want to add a color picker to an otherwise static HTML page, I might use a color picker web component. If I want to build a meaningful-sized app, I'd reach for React.
- kaoD 6y ago
  Web components are not built declaratively.
  - la_fayette 6y ago
    This declarative narrative is more or less a marketing gag, isn't it? Mixing Logic and Markup has always been an antipattern in web development. However, react calls this declarative and this is the new black now?
    - ricksharp 6y ago
      I’ve been doing web since 1990s and I‘ve always thought spreading a UI element across 3 separate files (often in different locations) was an anti-pattern (or 5+ files In 5 different folders if you want MVC). React is awesome because it allows feature-aligned separation of concerns (each component has a single job - render everything about a specific element - which is usually a well defined part of a specific use case). Jsx is the best UI system ever in terms of productivity - speaking from experience: I’ve implemented production apps using dozens of UI frameworks/platforms - Html, WYSIWYG, Flash, WindowsForms, WebForms, Ajax, Asp.Net Mvc, Razor, WPF, Xaml, Silverlight, Knockout, Handlebars, PhoneGap, Ionic, Bootstrap, MaterialUI, Angular2, React w/ Class Components, React w/ Mobx, React w/ Hooks I can tell you pros/cons of each of those. But at the end of the day I can develop an entire app in days in React+Hooks which would take me weeks in most any other.
      - pkkm 6y ago
        Have you written up your views about various UI frameworks somewhere? I'd be very interested in reading a comparison from someone who's used so many.
        ricksharp 6y ago
        No, but it's a great ideal for a blog post! When I have a chance, I'll let you know.
blackoil 6y ago
Yes, the original pitch was you can use components, declarative code and one way data flow and it is not slow becuase we use virtualdom.
rektide 6y ago
Components were an implementation detail, to an immediate-mode rendering paradigm for DOM. Previously we had been doing retained-mode rendering. We would modify & shuffle around the pieces of the page. React's components were there to let you re-render the app quickly. When state changed, a new render happened, with new elements emitted. You didn't think of what elements used to be there. React was about the virtual dom. It was about creating an abstraction to let us not have to regard what was on the page, when we were deciding what is on the page. Incidentally, imo, that involved components, but components, while comprising numerous html elements, serve a very similar function to html elements (especially to web components), and were not, imo, a particularly novel part of React. Yes, there was a lot to their creation & implementation, there was a lot of tech work that went into making Components a thing. But components, to me, are far outshadowed by the vdom, by the performance & speed of a data-system designed to go diff & en-act desired state into the live DOM tree. In kubernetes world, we'd call the vdom a controller. It reads the canonical state, the component tree, and insures the target DOM machinery is kept up to date & reflects this desired state.
- nwienert 6y ago
  You've got it backwards. The creators of React have clarified this many times as well. The vdom is an implementation detail, components and declarative render are the motivation. The vdom is interesting, but the right history isn't starting there. The premise was the ability to build bigger, better, more reliable, easier to understand/maintain/refactor apps. Components with declarative render + top down data flow enable that, vdom is just the only way to make it work without being too slow.
  - rektide 6y ago
    I disagree. Not that the vdom is an implementation detail. But to me, the fact that there is an immediate-mode rendering API for the web is far more notable than "Components" take the place of HTML elements. Everything interesting & notable about components relates to the fact that they are immediate-mode things. Nothing else is particularly notable or interesting or important about them, has parity with what HTML Elements did/do. Regardless of intent or deliberation, this, to me, is the clear & obvious technical difference that underpins whatever goals the team thought they were shooting for. It's the major characterization of how React was different from other webdev we'd tried. Everything else is downstream of that specific choice, for how to "draw" HTML: immediate-mode.

The premise of React isn’t at all about performance optimization, it’s about components.

la_fayette 6y ago

Yes true, but why should one favor react over e.g. web-components if it is so much slower?

acemarke 6y ago
React and web components are different tools trying to solve different problems. Web components are primarily about trying to add new virtual HTML tags to "extend the platform". React and other frameworks are about trying to build interactive applications that require larger-scale UI management, efficiently, on top of the DOM, by defining pieces of that UI as a tree of reusable components (and using techniques that web components don't have available to them). If I want to add a color picker to an otherwise static HTML page, I might use a color picker web component. If I want to build a meaningful-sized app, I'd reach for React.
kaoD 6y ago
Web components are not built declaratively.
- la_fayette 6y ago
  This declarative narrative is more or less a marketing gag, isn't it? Mixing Logic and Markup has always been an antipattern in web development. However, react calls this declarative and this is the new black now?
  - ricksharp 6y ago
    I’ve been doing web since 1990s and I‘ve always thought spreading a UI element across 3 separate files (often in different locations) was an anti-pattern (or 5+ files In 5 different folders if you want MVC). React is awesome because it allows feature-aligned separation of concerns (each component has a single job - render everything about a specific element - which is usually a well defined part of a specific use case). Jsx is the best UI system ever in terms of productivity - speaking from experience: I’ve implemented production apps using dozens of UI frameworks/platforms - Html, WYSIWYG, Flash, WindowsForms, WebForms, Ajax, Asp.Net Mvc, Razor, WPF, Xaml, Silverlight, Knockout, Handlebars, PhoneGap, Ionic, Bootstrap, MaterialUI, Angular2, React w/ Class Components, React w/ Mobx, React w/ Hooks I can tell you pros/cons of each of those. But at the end of the day I can develop an entire app in days in React+Hooks which would take me weeks in most any other.
    - pkkm 6y ago
      Have you written up your views about various UI frameworks somewhere? I'd be very interested in reading a comparison from someone who's used so many.
      - ricksharp 6y ago
        No, but it's a great ideal for a blog post! When I have a chance, I'll let you know.

blackoil 6y ago

Yes, the original pitch was you can use components, declarative code and one way data flow and it is not slow becuase we use virtualdom.

rektide 6y ago

Components were an implementation detail, to an immediate-mode rendering paradigm for DOM. Previously we had been doing retained-mode rendering. We would modify & shuffle around the pieces of the page. React's components were there to let you re-render the app quickly. When state changed, a new render happened, with new elements emitted. You didn't think of what elements used to be there. React was about the virtual dom. It was about creating an abstraction to let us not have to regard what was on the page, when we were deciding what is on the page. Incidentally, imo, that involved components, but components, while comprising numerous html elements, serve a very similar function to html elements (especially to web components), and were not, imo, a particularly novel part of React. Yes, there was a lot to their creation & implementation, there was a lot of tech work that went into making Components a thing. But components, to me, are far outshadowed by the vdom, by the performance & speed of a data-system designed to go diff & en-act desired state into the live DOM tree. In kubernetes world, we'd call the vdom a controller. It reads the canonical state, the component tree, and insures the target DOM machinery is kept up to date & reflects this desired state.

nwienert 6y ago
You've got it backwards. The creators of React have clarified this many times as well. The vdom is an implementation detail, components and declarative render are the motivation. The vdom is interesting, but the right history isn't starting there. The premise was the ability to build bigger, better, more reliable, easier to understand/maintain/refactor apps. Components with declarative render + top down data flow enable that, vdom is just the only way to make it work without being too slow.
- rektide 6y ago
  I disagree. Not that the vdom is an implementation detail. But to me, the fact that there is an immediate-mode rendering API for the web is far more notable than "Components" take the place of HTML elements. Everything interesting & notable about components relates to the fact that they are immediate-mode things. Nothing else is particularly notable or interesting or important about them, has parity with what HTML Elements did/do. Regardless of intent or deliberation, this, to me, is the clear & obvious technical difference that underpins whatever goals the team thought they were shooting for. It's the major characterization of how React was different from other webdev we'd tried. Everything else is downstream of that specific choice, for how to "draw" HTML: immediate-mode.