4 ms·

No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. React seems

No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. React seems like a bubble to me, created by fancy code that seems good at first glance but doesn't make a huge difference. What's it supposed to be amazing at, simple stuff or complex stuff? If simple stuff then why are people downloading 200K for Hello, World? If for complex stuff why isn't something like VSCode, Monaco, CodeMirror written with React? Those have state galore, and React's one-way data binding is no revelation for them. In fact inside React things like the ironically named react-hook-form get around React's one-way data binding by letting the form inputs be uncontrolled* (ironically named because react hooks makes it sound like it's going with the grain of react when it's thankfully going against it). Maybe ChatGPT will pop the bubble by churning out vanilla js that beats it. :) * https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw... React Hook Form embraces uncontrolled components but is also compatible with controlled components.

endisneigh 4y ago
There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world? It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.
- benatkin 4y ago
  I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense. https://bestofjs.org/projects?tags=vdom https://bestofjs.org/projects?tags=vdom FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.
nicoburns 4y ago
It’s good when you want interactivity that’s technically straightforward but in high volume. It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.
- benatkin 4y ago
  It works but clearly it's not needed, and to me I don't see a whole lot of innovation from a computer science standpoint because the most complex js projects don't use it.
  - nicoburns 4y ago
    Well something is needed. The alternative is: 1. Building apps with manual mutations (which is what we did before in the jQuery era). This involves a lot of boilerplate code, and it is hard to ensure that the UI state stays in sync with the app state properly. 2. Re-render the world on every state change. This works and allows you write simple code that is react-like in that it is pure transformation of app state into UI state, but it's slow and quickly runs into performance issues even in small apps. 1 still makes sense in the most performance sensitive scenarios. And 2 can work for the very simplest apps. But React and similar frameworks are great for everything in between. > I don't see a whole lot of innovation from a computer science standpoint because the most complex js projects don't use it. That seems silly. You could make the same argument for something like SQL. The most complex data manipulations won't use it. But it's still useful for the 90% that aren't that complex.
waboremo 4y ago
Is the discussion about frameworks or just React? They seem to be treated as interchangeable but React's foundations are not shared among other frameworks.
- benatkin 4y ago
  It's really about hype. I think React is good but overrated. Edit: I thought about it some more and the problem is that in order to see adoption, frameworks need to convince devs that they need something. With Vue what you have is reactive() and ref(). So they're convincing a lot of devs that they need MobX. Where in reality most devs don't need React's useState one-way bindings and they don't need MobX-like reactive objects either, nor do you need Signals from Solid. That said, if you prefer one of these, go for it! Ergonomics of binding events and setting attributes/properties/styles is useful and I like how Lit, snabbdom, and Svelte provide ergonomics without one of these state management paradigms.
  - waboremo 4y ago
    React is perfectly hyped, the introduction and complete absorption of flux architecture proves this. It's changed how we even write vanilla javascript. Most of the lessons we're talking about right now about questioning whether we even need state management paradigms to such a degree would not have happened without React. So if a problem exists about this scenario, it isn't about React, but how teams decide on tools. And unfortunately, most teams that aren't building their own solutions, go with the tool that has the largest "safest" community, not the one that accurately solves their issue.
    - benatkin 4y ago
      That's not how I remember it. People were thinking a great deal about state management with Backbone, Angular.js, and Knockout.js. It intensified with React. I wonder what would have happened with Angular.js if not for React...
kitkat_new 4y ago
> No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. What do you think about frameworks like Leptos that take the best of both worlds? > progressively-enhanced single-page apps that are rendered on the server and then hydrated on the client, enhancing your <a> and <form> navigations and mutations seamlessly when WASM is available. https://docs.rs/leptos/latest/leptos/ https://docs.rs/leptos/latest/leptos/
- benatkin 4y ago
  I think they're pretty neat, and that Svelte is one. "I used this technique in my own emoji-picker-element. If you’re already using Svelte in your project, then you can import 'emoji-picker-element/svelte' and get a version that doesn’t bundle its own framework, ensuring de-duplication. This saves a paltry 1.4 kB out of 13.9 kB total (compressed), but hey, it’s there. (Potentially I could make this the default behavior, but I like the bundled version for the benefit of folks who use <script> tags instead of bundlers. Maybe something like Skypack could make this simpler in the future.)" https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/ https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp... Thing is I actually like coding in Vanilla JS, at least some of the time.
zbtaylor1 4y ago
It may interest you to know that React was first used in production in 2011 and the library was subsequently open-sourced in 2013. As far as programming tools go I don't think we can call it a fad anymore.
- benatkin 4y ago
  I disagree. Every time something is hyped that extends the time it can be called a fad*. React gets hyped up freshly again with every announcement from Vercel**. * well maybe a collection of fads rather than a fad in itself ** I say this lovingly, it's similar to the magic of Steve Jobs and Apple. That said Vercel wouldn't interest me that much at this point if it was React-only. But the DX works for many different sorts of projects.
88913527 4y ago
For there to be a bubble, it has to be pierced. We haven't seen that with React. We did see that with Angular. I think the reason why the bubble did burst with Angular is because it made many opinions about things, and the more opinions you make, the fewer people in aggregate are going to agree with your total outlook. It's easy to convince people of 1 thing, and less easy to convince people of N things. React being less opinionated and not a batteries-included option means it won't be going away for awhile.
- benatkin 4y ago
  > React being less opinionated and not a batteries-included option means it won't be going away for awhile. That's what they love to say, but it has never seemed that way to me. One way data flow seems to be a huge opinion. Also dangerouslySetInnerHTML, htmlFor, className, etc, etc. That last one was handled by the community, partly coming from Facebook, with stuff like GraphQL, but now they've gone more with batteries included route even on their website by suggesting to use a big framework: https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project Also their opinions don't align with those of a lot of the community. A lot of glitches stem from controlled components. "In most cases, we recommend using controlled components to implement forms" https://legacy.reactjs.org/docs/uncontrolled-components.html https://legacy.reactjs.org/docs/uncontrolled-components.html ( which they might have finally changed their position on https://react.dev/reference/react-dom/components/input#controlling-an-input-with-a-state-variable https://react.dev/reference/react-dom/components/input#contr... ) "React Hook Form embraces uncontrolled components but is also compatible with controlled components." https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw...
  - 88913527 4y ago
    A more fruitful way to think about the degree of opinionated would be to compare to alternatives. If "className" versus "class" is too much 'opinion' maybe vanilla JS is best for your eclectic taste. Also, you'd absolutely find stuff like Angular to be maddening in its degree of opinionatedness.
anileated 4y ago
React 16 is about 5 KB uncompressed, it’s a tiny agnostic library that does very little and can be used to render to anything from a DOM to a native GUI to a dot matrix LCD screen (https://github.com/doodlewind/react-ssd1306/blob/master/docs/tutorial.md https://github.com/doodlewind/react-ssd1306/blob/master/docs...). Together with React-DOM it is about 100 KB, 30 KB gzipped (DOM library is bulky in part because it needs to support all of the default HTML and SVG elements). It’s not supposed to be amazing at anything except what it does, build complex or simple stuff it is up to you.
- Daishiman 4y ago
  But of course nobody uses just those and instead bring megabytes of dependencies.
  - anileated 4y ago
    They don’t have to. This indiscriminate piling on of dependencies is a problem, but React isn’t at fault as if it was somehow encouraging it.
    - benatkin 4y ago
      > Together with React-DOM it is about 100 KB That's a surprisingly high amount. I had to check again, and yep, it's true... Not that you would have to change how you code if you prefer React. Pretty clear why Fresh defaults to Preact. https://fresh.deno.dev/docs/introduction https://fresh.deno.dev/docs/introduction

endisneigh 4y ago

There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world? It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.

benatkin 4y ago
I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one. https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense. https://bestofjs.org/projects?tags=vdom https://bestofjs.org/projects?tags=vdom FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.

nicoburns 4y ago

It’s good when you want interactivity that’s technically straightforward but in high volume. It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.

benatkin 4y ago
It works but clearly it's not needed, and to me I don't see a whole lot of innovation from a computer science standpoint because the most complex js projects don't use it.
- nicoburns 4y ago
  Well something is needed. The alternative is: 1. Building apps with manual mutations (which is what we did before in the jQuery era). This involves a lot of boilerplate code, and it is hard to ensure that the UI state stays in sync with the app state properly. 2. Re-render the world on every state change. This works and allows you write simple code that is react-like in that it is pure transformation of app state into UI state, but it's slow and quickly runs into performance issues even in small apps. 1 still makes sense in the most performance sensitive scenarios. And 2 can work for the very simplest apps. But React and similar frameworks are great for everything in between. > I don't see a whole lot of innovation from a computer science standpoint because the most complex js projects don't use it. That seems silly. You could make the same argument for something like SQL. The most complex data manipulations won't use it. But it's still useful for the 90% that aren't that complex.

waboremo 4y ago

Is the discussion about frameworks or just React? They seem to be treated as interchangeable but React's foundations are not shared among other frameworks.

benatkin 4y ago
It's really about hype. I think React is good but overrated. Edit: I thought about it some more and the problem is that in order to see adoption, frameworks need to convince devs that they need something. With Vue what you have is reactive() and ref(). So they're convincing a lot of devs that they need MobX. Where in reality most devs don't need React's useState one-way bindings and they don't need MobX-like reactive objects either, nor do you need Signals from Solid. That said, if you prefer one of these, go for it! Ergonomics of binding events and setting attributes/properties/styles is useful and I like how Lit, snabbdom, and Svelte provide ergonomics without one of these state management paradigms.
- waboremo 4y ago
  React is perfectly hyped, the introduction and complete absorption of flux architecture proves this. It's changed how we even write vanilla javascript. Most of the lessons we're talking about right now about questioning whether we even need state management paradigms to such a degree would not have happened without React. So if a problem exists about this scenario, it isn't about React, but how teams decide on tools. And unfortunately, most teams that aren't building their own solutions, go with the tool that has the largest "safest" community, not the one that accurately solves their issue.
  - benatkin 4y ago
    That's not how I remember it. People were thinking a great deal about state management with Backbone, Angular.js, and Knockout.js. It intensified with React. I wonder what would have happened with Angular.js if not for React...

kitkat_new 4y ago

> No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them. What do you think about frameworks like Leptos that take the best of both worlds? > progressively-enhanced single-page apps that are rendered on the server and then hydrated on the client, enhancing your <a> and <form> navigations and mutations seamlessly when WASM is available. https://docs.rs/leptos/latest/leptos/ https://docs.rs/leptos/latest/leptos/

benatkin 4y ago
I think they're pretty neat, and that Svelte is one. "I used this technique in my own emoji-picker-element. If you’re already using Svelte in your project, then you can import 'emoji-picker-element/svelte' and get a version that doesn’t bundle its own framework, ensuring de-duplication. This saves a paltry 1.4 kB out of 13.9 kB total (compressed), but hey, it’s there. (Potentially I could make this the default behavior, but I like the bundled version for the benefit of folks who use <script> tags instead of bundlers. Maybe something like Skypack could make this simpler in the future.)" https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/ https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp... Thing is I actually like coding in Vanilla JS, at least some of the time.

zbtaylor1 4y ago

It may interest you to know that React was first used in production in 2011 and the library was subsequently open-sourced in 2013. As far as programming tools go I don't think we can call it a fad anymore.

benatkin 4y ago
I disagree. Every time something is hyped that extends the time it can be called a fad*. React gets hyped up freshly again with every announcement from Vercel**. * well maybe a collection of fads rather than a fad in itself ** I say this lovingly, it's similar to the magic of Steve Jobs and Apple. That said Vercel wouldn't interest me that much at this point if it was React-only. But the DX works for many different sorts of projects.

88913527 4y ago

For there to be a bubble, it has to be pierced. We haven't seen that with React. We did see that with Angular. I think the reason why the bubble did burst with Angular is because it made many opinions about things, and the more opinions you make, the fewer people in aggregate are going to agree with your total outlook. It's easy to convince people of 1 thing, and less easy to convince people of N things. React being less opinionated and not a batteries-included option means it won't be going away for awhile.

benatkin 4y ago
> React being less opinionated and not a batteries-included option means it won't be going away for awhile. That's what they love to say, but it has never seemed that way to me. One way data flow seems to be a huge opinion. Also dangerouslySetInnerHTML, htmlFor, className, etc, etc. That last one was handled by the community, partly coming from Facebook, with stuff like GraphQL, but now they've gone more with batteries included route even on their website by suggesting to use a big framework: https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project Also their opinions don't align with those of a lot of the community. A lot of glitches stem from controlled components. "In most cases, we recommend using controlled components to implement forms" https://legacy.reactjs.org/docs/uncontrolled-components.html https://legacy.reactjs.org/docs/uncontrolled-components.html ( which they might have finally changed their position on https://react.dev/reference/react-dom/components/input#controlling-an-input-with-a-state-variable https://react.dev/reference/react-dom/components/input#contr... ) "React Hook Form embraces uncontrolled components but is also compatible with controlled components." https://react-hook-form.com/advanced-usage/#ControlledmixedwithUncontrolledComponents https://react-hook-form.com/advanced-usage/#Controlledmixedw...
- 88913527 4y ago
  A more fruitful way to think about the degree of opinionated would be to compare to alternatives. If "className" versus "class" is too much 'opinion' maybe vanilla JS is best for your eclectic taste. Also, you'd absolutely find stuff like Angular to be maddening in its degree of opinionatedness.

anileated 4y ago

React 16 is about 5 KB uncompressed, it’s a tiny agnostic library that does very little and can be used to render to anything from a DOM to a native GUI to a dot matrix LCD screen (https://github.com/doodlewind/react-ssd1306/blob/master/docs/tutorial.md https://github.com/doodlewind/react-ssd1306/blob/master/docs...). Together with React-DOM it is about 100 KB, 30 KB gzipped (DOM library is bulky in part because it needs to support all of the default HTML and SVG elements). It’s not supposed to be amazing at anything except what it does, build complex or simple stuff it is up to you.

Daishiman 4y ago
But of course nobody uses just those and instead bring megabytes of dependencies.
- anileated 4y ago
  They don’t have to. This indiscriminate piling on of dependencies is a problem, but React isn’t at fault as if it was somehow encouraging it.
  - benatkin 4y ago
    > Together with React-DOM it is about 100 KB That's a surprisingly high amount. I had to check again, and yep, it's true... Not that you would have to change how you code if you prefer React. Pretty clear why Fresh defaults to Preact. https://fresh.deno.dev/docs/introduction https://fresh.deno.dev/docs/introduction