3 ms·

This is my usual experience with react. Also i am just not liking the code… I really don‘t understand why it became so popular except for Facebook marketing it

This is my usual experience with react. Also i am just not liking the code… I really don‘t understand why it became so popular except for Facebook marketing it so much hence people bought into the hype. And now it has the big ecosystem, which is one of the main arguments to use react for many people…

snowl 5y ago
Because it's amazing to develop in and if you are good at development it's not hard to make performant applications. Don't blame the framework for a lack of skill
- bsagdiyev 5y ago
  If the trigger goes off just being looked at, maybe the manufacturer shares blame…
- mikojan 5y ago
  This is breathtakingly wrong. Performance bottlenecks are notoriously hard to fix in ReactJS. Once you've exhausted memoization, hoisting, even propagating state via message passing, you have to fight tooth and nail to rip a hot path out of ReactJS' grip. It's horrible. And it's the prize you pay for using a framework everybody and their grandmother can learn reading only a 5 minute blog post (the true value proposition here).
jraph 5y ago
On my PinePhone, I can immediately tell whether an app is built with React. - the app usually takes several dozens of seconds to load - the phone becomes warm - any text I typed is not restored after a crash or a page reload if the developers have not explicitly saved my keystrokes in the local storage. - each key press in an input takes a good fraction of a second (if not one full second) to appear on the screen For the last one, I feel the lag on a decent laptop too (even if the lag is shorter). I know why: it is good practice to feed back any input into the state of the React component so everything is in sync. This triggers a re-render and if the devs were not careful, a good chunk of the app is re-rendered, which does not necessarily lead to a browser re-render / a blink, but definitely makes React execute a lot of render methods and re-diff virtual DOM trees. So each key press makes the browser run some JS that makes useless computation and accesses to the DOM. It's called "controlled component" [1]. Well, this is good practice for the devs, but it is user hostile. I wish more things were designed user-first instead of dev-first. React + React-dom alone is around 130 KiB, 42 KiB Gziped [2]. It's without counting the usual dependencies (classname, Redux, browserlist, polyfills…). It's also more than three times the size of the entire frontend of the SMS app I'm building with Svelte. The heaviness is insane. It is probably possible-ish to build an almost lean app with React. Signal seems to be kind of an exception and feels quite fast on my laptop (can't tell on the phone). It leaks memory and gets OOM killed quite often but React might not be to blame here. But React apps usually come with a awful lot of dependencies, to add insult to the injury. It's render and diff'ing lags, fan takeoffs and RAM exhaustion all the way down. [1] https://reactjs.org/docs/forms.html#controlled-components https://reactjs.org/docs/forms.html#controlled-components [2] taken there, as linked in the tutorial (https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html): https://unpkg.com/react-dom@17/umd/react-dom.production.min.js https://unpkg.com/react-dom@17/umd/react-dom.production.min.... and https://unpkg.com/react@17/umd/react.production.min.js https://unpkg.com/react@17/umd/react.production.min.js
- nafey 5y ago
  > I know why: it is good practice to feed back any input into the state of the React component so everything is in sync. I used to this. A better approach is to use the onBlur event of the input field to update the text to state. The text itself can be accessed via a reference to the input field in the onBlur event (created with useRef). This makes it so that not every typing action rerenders the whole component.

snowl 5y ago

Because it's amazing to develop in and if you are good at development it's not hard to make performant applications. Don't blame the framework for a lack of skill

bsagdiyev 5y ago
If the trigger goes off just being looked at, maybe the manufacturer shares blame…
mikojan 5y ago
This is breathtakingly wrong. Performance bottlenecks are notoriously hard to fix in ReactJS. Once you've exhausted memoization, hoisting, even propagating state via message passing, you have to fight tooth and nail to rip a hot path out of ReactJS' grip. It's horrible. And it's the prize you pay for using a framework everybody and their grandmother can learn reading only a 5 minute blog post (the true value proposition here).

jraph 5y ago

On my PinePhone, I can immediately tell whether an app is built with React. - the app usually takes several dozens of seconds to load - the phone becomes warm - any text I typed is not restored after a crash or a page reload if the developers have not explicitly saved my keystrokes in the local storage. - each key press in an input takes a good fraction of a second (if not one full second) to appear on the screen For the last one, I feel the lag on a decent laptop too (even if the lag is shorter). I know why: it is good practice to feed back any input into the state of the React component so everything is in sync. This triggers a re-render and if the devs were not careful, a good chunk of the app is re-rendered, which does not necessarily lead to a browser re-render / a blink, but definitely makes React execute a lot of render methods and re-diff virtual DOM trees. So each key press makes the browser run some JS that makes useless computation and accesses to the DOM. It's called "controlled component" [1]. Well, this is good practice for the devs, but it is user hostile. I wish more things were designed user-first instead of dev-first. React + React-dom alone is around 130 KiB, 42 KiB Gziped [2]. It's without counting the usual dependencies (classname, Redux, browserlist, polyfills…). It's also more than three times the size of the entire frontend of the SMS app I'm building with Svelte. The heaviness is insane. It is probably possible-ish to build an almost lean app with React. Signal seems to be kind of an exception and feels quite fast on my laptop (can't tell on the phone). It leaks memory and gets OOM killed quite often but React might not be to blame here. But React apps usually come with a awful lot of dependencies, to add insult to the injury. It's render and diff'ing lags, fan takeoffs and RAM exhaustion all the way down. [1] https://reactjs.org/docs/forms.html#controlled-components https://reactjs.org/docs/forms.html#controlled-components [2] taken there, as linked in the tutorial (https://reactjs.org/docs/add-react-to-a-website.html https://reactjs.org/docs/add-react-to-a-website.html): https://unpkg.com/react-dom@17/umd/react-dom.production.min.js https://unpkg.com/react-dom@17/umd/react-dom.production.min.... and https://unpkg.com/react@17/umd/react.production.min.js https://unpkg.com/react@17/umd/react.production.min.js

nafey 5y ago
> I know why: it is good practice to feed back any input into the state of the React component so everything is in sync. I used to this. A better approach is to use the onBlur event of the input field to update the text to state. The text itself can be accessed via a reference to the input field in the onBlur event (created with useRef). This makes it so that not every typing action rerenders the whole component.