4 ms·

How many apps actually benefit from reactivity, i.e. 1,000 people can post to a feed realtime and the app fetches data from 200 other backend services? I believ

by bitL 3y ago

How many apps actually benefit from reactivity, i.e. 1,000 people can post to a feed realtime and the app fetches data from 200 other backend services? I believe for vast majority apps, a basic HTML/JS/CSS is all one needs. It's fairly trivial to make your own SPA in ES7.

geraldwhen 3y ago
Try having 15 committers in the same codebase. It won’t scale.
- bitL 3y ago
  That might be true but React has the same issue with larger teams and everyone using a different part of it; the pace of development drops rapidly and apps become complex monsters for little reason.
nawgz 3y ago
If you don't know the use-case for reactivity and are going to advocate for "vast majority apps" being authored in "HTML/JS/CSS", I don't really understand why you're debating me. Frontends - that are clearly more complex than the ones you use - are state machines managing asynchronously-accessible state stored in external services. Due to the nature of how many resources an application might use, it quickly becomes cumbersome to map out that state machine manually, and it is more beneficial to just write declarative display logic that will automatically execute when the necessary preconditions are present and a change has occurred within the state management. Now, mind you, nothing I've said really involves reactivity yet; and, even worse, most solutions - especially your custom SPA - will rerender the entire tree of objects relying on each changed resource in order to accomplish what I listed. The beauty of reactivity is that you as a developer simply write modular code - whether it's state or view, the more modular the better - and then your system ensures changes to the underlying state tree flush updates to the view modules attached exactly to the parts of the state tree what changed. It's optimal performance by default, you run the least amount of your own code each time a change happens. Of course, it brings its own challenges and issues, but it really means that your general answer to "how can I scale this UI" is just "write it in smaller chunks", and that scales pretty dang finely across a team. Unlike a hand-rolled ball of JS. Come on folks, it's 2023, put your tired arguments away.
- bitL 3y ago
  Maybe you can consider that on HN you are talking to experts who in their lives experienced dozens different UI paradigms and frameworks including deep experience with React, its ecosystem, its benefits and its warts. I am pointing out that the problem of "how can I scale this UI" is experienced by a very small percentage of apps. For Meta or Uber it makes sense as they need to coordinate overlapping real-time feeds where dependency graph is insane; why should however most apps bother jumping on this paradigm? There are complex yet performant apps like draw.io that never touched anything reactive and aren't missing it in the slightest.
  - nawgz 3y ago
    > Maybe you can consider that on HN you are talking to experts who in their lives experienced dozens different UI paradigms and frameworks Maybe you can consider that on HN you are talking to people who spend their working lives answering the question of "how can I scale this UI" and think that reactivity is a good approach. > why should however most apps bother jumping on this paradigm I stated pretty clearly the benefits above - it has great performance in general due to minimal redraws, and those minimal redraws are accomplished "automatically" / via runtime construction so you don't even need to think about optimizing accesses, it's already the least possible. More to the point, I don't see why we shouldn't laud Angular for delivering an opinionated reactivity implementation when their opinionated, batteries-included approach has enabled a lot of teams to hop in and build apps. I also don't think you have any fucking clue what goes into UI development if you propose rolling your own SPA, so there's also that.

by bitL 3y ago

geraldwhen 3y ago

Try having 15 committers in the same codebase. It won’t scale.

bitL 3y ago
That might be true but React has the same issue with larger teams and everyone using a different part of it; the pace of development drops rapidly and apps become complex monsters for little reason.

nawgz 3y ago

If you don't know the use-case for reactivity and are going to advocate for "vast majority apps" being authored in "HTML/JS/CSS", I don't really understand why you're debating me. Frontends - that are clearly more complex than the ones you use - are state machines managing asynchronously-accessible state stored in external services. Due to the nature of how many resources an application might use, it quickly becomes cumbersome to map out that state machine manually, and it is more beneficial to just write declarative display logic that will automatically execute when the necessary preconditions are present and a change has occurred within the state management. Now, mind you, nothing I've said really involves reactivity yet; and, even worse, most solutions - especially your custom SPA - will rerender the entire tree of objects relying on each changed resource in order to accomplish what I listed. The beauty of reactivity is that you as a developer simply write modular code - whether it's state or view, the more modular the better - and then your system ensures changes to the underlying state tree flush updates to the view modules attached exactly to the parts of the state tree what changed. It's optimal performance by default, you run the least amount of your own code each time a change happens. Of course, it brings its own challenges and issues, but it really means that your general answer to "how can I scale this UI" is just "write it in smaller chunks", and that scales pretty dang finely across a team. Unlike a hand-rolled ball of JS. Come on folks, it's 2023, put your tired arguments away.

bitL 3y ago
Maybe you can consider that on HN you are talking to experts who in their lives experienced dozens different UI paradigms and frameworks including deep experience with React, its ecosystem, its benefits and its warts. I am pointing out that the problem of "how can I scale this UI" is experienced by a very small percentage of apps. For Meta or Uber it makes sense as they need to coordinate overlapping real-time feeds where dependency graph is insane; why should however most apps bother jumping on this paradigm? There are complex yet performant apps like draw.io that never touched anything reactive and aren't missing it in the slightest.
- nawgz 3y ago
  > Maybe you can consider that on HN you are talking to experts who in their lives experienced dozens different UI paradigms and frameworks Maybe you can consider that on HN you are talking to people who spend their working lives answering the question of "how can I scale this UI" and think that reactivity is a good approach. > why should however most apps bother jumping on this paradigm I stated pretty clearly the benefits above - it has great performance in general due to minimal redraws, and those minimal redraws are accomplished "automatically" / via runtime construction so you don't even need to think about optimizing accesses, it's already the least possible. More to the point, I don't see why we shouldn't laud Angular for delivering an opinionated reactivity implementation when their opinionated, batteries-included approach has enabled a lot of teams to hop in and build apps. I also don't think you have any fucking clue what goes into UI development if you propose rolling your own SPA, so there's also that.