4 ms·

> React is a small rendering library Sorry, can't agree. React is a state management library that also implements efficient rendering on top of the DOM diff it

by nine_k 2y ago

> React is a small rendering library Sorry, can't agree. React is a state management library that also implements efficient rendering on top of the DOM diff it computes as it propagates the state changes. This allows React apps to remain so simple (one mostly linear function per component) and so composable without turning into an unmanageable dish of callback / future spaghetti. There is a number of other VDOM libraries, but what sets React apart is the data / state flow strictly in one direction. This allows to reap many of the benefits of functional programming along the way, like everything the developer sees being immutable; not a coincidence. Regarding the size, preact [1] is mostly API-compatible, but also absurdly small (3-4 kB minified), actually smaller than HTMX (10 kB). But with preact you likely also want preact-iso, so the size grows a little bit. [1]: https://preactjs.com/ https://preactjs.com/

mplewis 2y ago
React notoriously doesn't come with enough state management to properly manage state in anything larger than trivial.
- nine_k 2y ago
  React comes with useState, useMemo, and useCallback, which is actually enough, but it may be too low-level when you think e.g. in terms of a huge interactive form. It's easy to write your own useWhatever based on these which would factor out your common boilerplate. I suspect HTMX also does not come with every possible battery included, judging by the proliferation of libraries for HTMX-based projects. Modularity is a strength.
  - agos 2y ago
    it is enough in the sense that NAND gates are enough to build computers. Yes, you can write a complex application using only those, and yes it's easy to write hooks to keep the boilerplate low - although Context still feels like too much boilerplate - but as complexity grows it's quite natural to want to share state between distant parts of the application, and then you're left choosing between lifting staten and prop drilling (not great) or Context and massive, frequent rerenderings. Hence the need for third party state management solutions
    - strogonoff 2y ago
      Are you sure contexts causing rerenders is not solvable by moving useContext() calls into hooks that each return only the part of the context that is required and ensure reference equality of returned value (meaning any component will not have a reason to rerender unless there is an actual change in that part of the context)?
      - nine_k 2y ago
        Also, should not memo [1] suffice? [1]: https://react.dev/reference/react/memo https://react.dev/reference/react/memo
        strogonoff 2y ago
        I thought about it more and my reasoning is as follows (I may be wrong): — useContext() returns an object. This object is new any time anything in the context changes. If the object has a nested sub-object, it may be new as well even if it did not change, though I suppose it may depend on how context provider works. — All components where you use that context therefore will render any time it changes. (Takeaway 1: apply loose coupling & high cohesion principle to contexts, such that if you use the context and it changes in any way there is a high chance the change is relevant to wherever you use the context.) — The render at that stage may be fine[0], especially if contexts are nicely organized, but care is needed because a downstream child that receives a nested sub-object from the context may render as well even if the sub-object is unchanged but referentially new (unless the child is wrapped in memo() and the memo handles reference equality, which may well be what you meant). (Takeaway 2: always remember that JavaScript is full of pointers and referential equality is important in React.) — However, if part of the context is useMemo()ed for reference equality before being passed to a child, then the child will not have a reason to render from other unrelated context changes. [0] It may make sense not to use context in large numbers of downstream leaf components (e.g., not use it in an item rendered in a map, but use it in parent list and pass relevant props to list items). This may be frustrating to deal with in a large project, but it may be that the effort put into organizing contexts strategically and using them with care would lead to a more solid, refactorable and reusable architecture compared to state sprinkled around the place as essentially an equivalent of global variables. It depends.
- skinkestek 2y ago
  I have yet to see a single case of any state management library actually improve state handling. Lately I have started removing these libraries were possible and the maintainability has improved a lot. Thankfully at my latest place there was no one when I came and I haven't seen a more productive team doing frontend.
  - ricardobeat 2y ago
    It always works nicely when things are small, but becomes extremely painful for large products or teams (100+).
    - strogonoff 2y ago
      Which always seemed a bit ironic, considering those libraries are presumably intended to make state management work better if you really have to do a lot of it (i.e., have a large product).
      - deleted 2y ago
        [deleted]
    - nine_k 2y ago
      At MPOW we have a bunch of state-managing components for complex cases, like multi-page forms or API-backed grids with tons of filters, etc. They take some effort to get the hang of them, but after that they save large amounts of boilerplate.
strogonoff 2y ago
> implements efficient rendering on top of the DOM diff Here your definition of React diverges from reality, I believe. React does implement state management—it sort of has to to be of any use. It is a flavour of immediate mode GUI, and some way of managing what changes and what does not change between renders is necessary. However, React famously does not know about DOM or even Web. (Unless you meant DOM in some more general sense?) People use React to make command-line interfaces, output to embedded LCD screens, etc. Yes, coupling it to Web and DOM and abandoning the separation of concerns that makes core React so general-purpose could probably make React a bit smaller, but I think projects like Preact are welcome to do it instead.
- nine_k 2y ago
  Makes sense: React itself is independent from a particular rendering method. There's react-dom that does the DOM rendering. I was trying to point at the fact that rendering occurs on top of state management, as opposed to saying that "React is a rendering library".
  - strogonoff 2y ago
    You are right, and my calling it imGUI is a stretch since actually it does rely on state to know when to render. If you think about it, the end goal is rendering, and React facilitates that, but the actual rendering (as in, changing page DOM, terminal buffer, etc.) happens outside of React. So my definition may need to be adjusted. I still think it’s a stretch to call React a framework, though!

by nine_k 2y ago

mplewis 2y ago

React notoriously doesn't come with enough state management to properly manage state in anything larger than trivial.

nine_k 2y ago
React comes with useState, useMemo, and useCallback, which is actually enough, but it may be too low-level when you think e.g. in terms of a huge interactive form. It's easy to write your own useWhatever based on these which would factor out your common boilerplate. I suspect HTMX also does not come with every possible battery included, judging by the proliferation of libraries for HTMX-based projects. Modularity is a strength.
- agos 2y ago
  it is enough in the sense that NAND gates are enough to build computers. Yes, you can write a complex application using only those, and yes it's easy to write hooks to keep the boilerplate low - although Context still feels like too much boilerplate - but as complexity grows it's quite natural to want to share state between distant parts of the application, and then you're left choosing between lifting staten and prop drilling (not great) or Context and massive, frequent rerenderings. Hence the need for third party state management solutions
  - strogonoff 2y ago
    Are you sure contexts causing rerenders is not solvable by moving useContext() calls into hooks that each return only the part of the context that is required and ensure reference equality of returned value (meaning any component will not have a reason to rerender unless there is an actual change in that part of the context)?
    - nine_k 2y ago
      Also, should not memo [1] suffice? [1]: https://react.dev/reference/react/memo https://react.dev/reference/react/memo
      - strogonoff 2y ago
        I thought about it more and my reasoning is as follows (I may be wrong): — useContext() returns an object. This object is new any time anything in the context changes. If the object has a nested sub-object, it may be new as well even if it did not change, though I suppose it may depend on how context provider works. — All components where you use that context therefore will render any time it changes. (Takeaway 1: apply loose coupling & high cohesion principle to contexts, such that if you use the context and it changes in any way there is a high chance the change is relevant to wherever you use the context.) — The render at that stage may be fine[0], especially if contexts are nicely organized, but care is needed because a downstream child that receives a nested sub-object from the context may render as well even if the sub-object is unchanged but referentially new (unless the child is wrapped in memo() and the memo handles reference equality, which may well be what you meant). (Takeaway 2: always remember that JavaScript is full of pointers and referential equality is important in React.) — However, if part of the context is useMemo()ed for reference equality before being passed to a child, then the child will not have a reason to render from other unrelated context changes. [0] It may make sense not to use context in large numbers of downstream leaf components (e.g., not use it in an item rendered in a map, but use it in parent list and pass relevant props to list items). This may be frustrating to deal with in a large project, but it may be that the effort put into organizing contexts strategically and using them with care would lead to a more solid, refactorable and reusable architecture compared to state sprinkled around the place as essentially an equivalent of global variables. It depends.
skinkestek 2y ago
I have yet to see a single case of any state management library actually improve state handling. Lately I have started removing these libraries were possible and the maintainability has improved a lot. Thankfully at my latest place there was no one when I came and I haven't seen a more productive team doing frontend.
- ricardobeat 2y ago
  It always works nicely when things are small, but becomes extremely painful for large products or teams (100+).
  - strogonoff 2y ago
    Which always seemed a bit ironic, considering those libraries are presumably intended to make state management work better if you really have to do a lot of it (i.e., have a large product).
    - deleted 2y ago
      [deleted]
  - nine_k 2y ago
    At MPOW we have a bunch of state-managing components for complex cases, like multi-page forms or API-backed grids with tons of filters, etc. They take some effort to get the hang of them, but after that they save large amounts of boilerplate.

strogonoff 2y ago

> implements efficient rendering on top of the DOM diff Here your definition of React diverges from reality, I believe. React does implement state management—it sort of has to to be of any use. It is a flavour of immediate mode GUI, and some way of managing what changes and what does not change between renders is necessary. However, React famously does not know about DOM or even Web. (Unless you meant DOM in some more general sense?) People use React to make command-line interfaces, output to embedded LCD screens, etc. Yes, coupling it to Web and DOM and abandoning the separation of concerns that makes core React so general-purpose could probably make React a bit smaller, but I think projects like Preact are welcome to do it instead.

nine_k 2y ago
Makes sense: React itself is independent from a particular rendering method. There's react-dom that does the DOM rendering. I was trying to point at the fact that rendering occurs on top of state management, as opposed to saying that "React is a rendering library".
- strogonoff 2y ago
  You are right, and my calling it imGUI is a stretch since actually it does rely on state to know when to render. If you think about it, the end goal is rendering, and React facilitates that, but the actual rendering (as in, changing page DOM, terminal buffer, etc.) happens outside of React. So my definition may need to be adjusted. I still think it’s a stretch to call React a framework, though!