3 ms·

While old school PHP might look like this it is not the same thing by far. The code in this screenshot is a stateful component and is supposed to encapsulate al

by throwaway2016a 10y ago

While old school PHP might look like this it is not the same thing by far. The code in this screenshot is a stateful component and is supposed to encapsulate all the logic on how it should be displayed in one place. It is close to a view in a MVC framework than true old-school spagetti code. But unlike a view component in an MVC framework the stateful components can update themselves automatically when data changes much more elegantly than they could in older systems. Granted some people write React and include business logic in their components but you're not really supposed to do it that way.

aantix 10y ago
Curious on your take; for a component, why do I need the virtual dom diffing? If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total). The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got this.."
- Chris_Newton 10y ago
  (I’m not the person you replied to, but I’ll offer some thoughts anyway.) for a component, why do I need the virtual dom diffing? React allows you to build relatively large and complicated DOM trees by composing smaller components, and it is designed so you can then (re)render the entire tree as a single operation when any relevant underlying state changes, without having to manage (re)rendering each individual component within that tree manually. This is useful because now you only need to define one absolute way to render from a given set of underlying data. You no longer need to give a relative specification for all possible transitions from one state to another, which can be a huge reduction in complexity and edge cases if you’re working on a large, complicated UI. However, other things being equal, rerendering your entire DOM tree on the slightest change in the underlying data would become painfully slow for any system that isn’t very small. That is partly because there are costs to regenerating the DOM tree itself, as with any template-based system. However, the tightest bottleneck in today’s browsers is usually the consequential costs that result from updating the DOM in terms of regenerating layout and so on. The virtual DOM diffing is essentially a performance optimisation that lets you mitigate those consequential costs, because now only the parts of the DOM that actually change as a result of changes in the underlying data will lead to rerendering in the browser and the costs that incurs. In other words, virtual DOM diffing isn’t the point of React, declarative/absolute rendering is, but the former is what makes the latter fast enough to be viable. As an aside, React’s answer to the other half of the performance problem, the cost of regenerating the entire DOM tree, is the `shouldComponentUpdate` function. That lets components, including child components deep within a large tree, perform any quick tests they can to determine whether their rendered output will actually change, and to skip the rerendering if not. That leads on to various other ideas that have become popular in connection with React, such as using immutable data models for the underlying data. With immutable underlying data, a shallow comparison between a couple of object references that can be performed in moments acts as a “dirty check”. However, you don’t have to use React in that way. Some people are wary of relying too much on `shouldComponentUpdate`, which inherently violates the “single source of truth” principle and risks introducing bugs if its assumptions differ from those of the same component’s `render` method. Others find the arguments for building your entire data store around immutable objects, which itself carries a hefty performance overhead, less compelling. There are certainly other reasonable architectures you could choose for supplying the underlying data to React components and triggering rerendering when that data changes, including more traditional designs where view components observe the underlying data model in some way and trigger their own rerendering on any relevant change. Going down this path is effectively using React as a reasonably efficient and composable template rendering engine, so you can still have the advantages of absolute rendering logic, and you bypass some of the potential performance problems caused by doing large-scale rerenders with React, but in return you take back some of the responsibility to set up explicit dependencies between your view components and the data they depend on. As ever, there are trade-offs, and usually there will be multiple quite different designs that will do a decent job as long as you understand their pros and cons.
- mikewhy 10y ago
  No one brought up DOM diffing, the React team have even suggested it be considered an implementation detail. React means composable components, the browser implementation uses DOM diffing.
- throwaway2016a 10y ago
  For a solo project I think React doesn't offer quite as much benefit (although I think I am faster in it). But for team projects the team members can stop worrying about where the data comes from and just worry about their component. In your shopping cart example, say the project manager decides they want to display how may of an item you have in your cart next to the item in the catalog. Then a feature is added to remove items from any page by having a dropdown on the cart logo. So is it the responsibility of the person writing the cart dropdown to update the catalog listing or the responsibility of the person writing the catalog listing to know about the drop-down? In React you only need to bind to the data. If the data changes and your DOM then changes as a result then you update. You don't need to know why or how it changed. As far as the virtual DOM being perhaps heavy handed. It is a performance optimization and not really a core concept. The React team found it was faster to update only the parts of the DOM that changed rather than redraw the entire screen and came up with a clever way to do that without having to know the implementation details of each component. Contrast that with the naive approach (using innerHTML) which would make even a "update the character count every time a key is pressed" UI grind to a halt.
- coldtea 10y ago
  >The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got this.." If you don't do DOM diffing for small components then you have to keep control of the whole logic state AND view state of your app. Complete diffing allows for automatic one way bindings and easier to reason UIs. It's like functional programming.
- slowrabbit 10y ago
  ReactJS is currently the fastest, most scalable frontend solution available so compared to all that has come before it, it can seem heavy handed. But if you want to build highly scalable apps like Facebook, Instagram, Pinterest, Reddit and Twitter mobile, then losing easy speed gains with every one of the hundreds to thousands of components you build is unacceptable.
  - neilellis 10y ago
    The problem is that 99.99% of developers aren't (writing Twitter etc) but they still apply techniques used by unicorns to handle their own very exceptional needs. We should always be wary of applying skyscraper building techniques when building a house or a shed. I honestly bet that 99.99% of people who read Hacker News could write their applications with a drop of jQuery and some basic ES6 code. I have nothing bad to say about these frameworks, more caution that we don't apply techniques needed at scale to small scale products.

aantix 10y ago

Curious on your take; for a component, why do I need the virtual dom diffing? If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total). The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got this.."

Chris_Newton 10y ago
(I’m not the person you replied to, but I’ll offer some thoughts anyway.) for a component, why do I need the virtual dom diffing? React allows you to build relatively large and complicated DOM trees by composing smaller components, and it is designed so you can then (re)render the entire tree as a single operation when any relevant underlying state changes, without having to manage (re)rendering each individual component within that tree manually. This is useful because now you only need to define one absolute way to render from a given set of underlying data. You no longer need to give a relative specification for all possible transitions from one state to another, which can be a huge reduction in complexity and edge cases if you’re working on a large, complicated UI. However, other things being equal, rerendering your entire DOM tree on the slightest change in the underlying data would become painfully slow for any system that isn’t very small. That is partly because there are costs to regenerating the DOM tree itself, as with any template-based system. However, the tightest bottleneck in today’s browsers is usually the consequential costs that result from updating the DOM in terms of regenerating layout and so on. The virtual DOM diffing is essentially a performance optimisation that lets you mitigate those consequential costs, because now only the parts of the DOM that actually change as a result of changes in the underlying data will lead to rerendering in the browser and the costs that incurs. In other words, virtual DOM diffing isn’t the point of React, declarative/absolute rendering is, but the former is what makes the latter fast enough to be viable. As an aside, React’s answer to the other half of the performance problem, the cost of regenerating the entire DOM tree, is the `shouldComponentUpdate` function. That lets components, including child components deep within a large tree, perform any quick tests they can to determine whether their rendered output will actually change, and to skip the rerendering if not. That leads on to various other ideas that have become popular in connection with React, such as using immutable data models for the underlying data. With immutable underlying data, a shallow comparison between a couple of object references that can be performed in moments acts as a “dirty check”. However, you don’t have to use React in that way. Some people are wary of relying too much on `shouldComponentUpdate`, which inherently violates the “single source of truth” principle and risks introducing bugs if its assumptions differ from those of the same component’s `render` method. Others find the arguments for building your entire data store around immutable objects, which itself carries a hefty performance overhead, less compelling. There are certainly other reasonable architectures you could choose for supplying the underlying data to React components and triggering rerendering when that data changes, including more traditional designs where view components observe the underlying data model in some way and trigger their own rerendering on any relevant change. Going down this path is effectively using React as a reasonably efficient and composable template rendering engine, so you can still have the advantages of absolute rendering logic, and you bypass some of the potential performance problems caused by doing large-scale rerenders with React, but in return you take back some of the responsibility to set up explicit dependencies between your view components and the data they depend on. As ever, there are trade-offs, and usually there will be multiple quite different designs that will do a decent job as long as you understand their pros and cons.
mikewhy 10y ago
No one brought up DOM diffing, the React team have even suggested it be considered an implementation detail. React means composable components, the browser implementation uses DOM diffing.
throwaway2016a 10y ago
For a solo project I think React doesn't offer quite as much benefit (although I think I am faster in it). But for team projects the team members can stop worrying about where the data comes from and just worry about their component. In your shopping cart example, say the project manager decides they want to display how may of an item you have in your cart next to the item in the catalog. Then a feature is added to remove items from any page by having a dropdown on the cart logo. So is it the responsibility of the person writing the cart dropdown to update the catalog listing or the responsibility of the person writing the catalog listing to know about the drop-down? In React you only need to bind to the data. If the data changes and your DOM then changes as a result then you update. You don't need to know why or how it changed. As far as the virtual DOM being perhaps heavy handed. It is a performance optimization and not really a core concept. The React team found it was faster to update only the parts of the DOM that changed rather than redraw the entire screen and came up with a clever way to do that without having to know the implementation details of each component. Contrast that with the naive approach (using innerHTML) which would make even a "update the character count every time a key is pressed" UI grind to a halt.
coldtea 10y ago
>The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got this.." If you don't do DOM diffing for small components then you have to keep control of the whole logic state AND view state of your app. Complete diffing allows for automatic one way bindings and easier to reason UIs. It's like functional programming.
slowrabbit 10y ago
ReactJS is currently the fastest, most scalable frontend solution available so compared to all that has come before it, it can seem heavy handed. But if you want to build highly scalable apps like Facebook, Instagram, Pinterest, Reddit and Twitter mobile, then losing easy speed gains with every one of the hundreds to thousands of components you build is unacceptable.
- neilellis 10y ago
  The problem is that 99.99% of developers aren't (writing Twitter etc) but they still apply techniques used by unicorns to handle their own very exceptional needs. We should always be wary of applying skyscraper building techniques when building a house or a shed. I honestly bet that 99.99% of people who read Hacker News could write their applications with a drop of jQuery and some basic ES6 code. I have nothing bad to say about these frameworks, more caution that we don't apply techniques needed at scale to small scale products.