161–170 of 553 posts
In game dev you run millions or even billions of computations 60 times a second. If running toTitleCase three times every key stroke is an example of a compounding performance problem in React then surely the problem must lie deeper.
There is this niche movement that argues that good code should be very long lived. It should solve problems in a fundamentally efficient way that makes it hard to turn into obsolete and throwaway code. There are not many examples of such code bases. Maybe numerical algebra libraries come close. Reading through the comments it seems that providing (fairly basic by now) UI functionality on cross-platform basis has not…
We should have all stayed on backbone or Prototype.js with that logic.
People look for alternatives because the status quo is awful (slow, verbose, footgunful).
You’re saying “who needs cars when we got horses? Cars break down all the time”
Earlier quoted context omitted.
"Performance" matters a lot less than many other things like collaborating with other people, or getting the DOM manipulation right.
I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.
Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.
I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…
I understand that sentiment, but it's part of the reason why computers today don't feel faster than in the past and why we waste sooooo incredibly much energy.
Earlier quoted context omitted.
I find it's best (if side effects and state mutation make you nervous) to think of hooks as essentially part of the function signature of a react component, both on the parameter side, as well as on the return side. They are not written as such, because of syntactic limitations of JavaScript, but essentially a react component that starts off like this: function MyComponent({}) { const [count, setCount] = useState(0);…
Don't call this functional programming. If you call setCount() then this is not functional because your function is doing something besides returning a value. In fact, it is setting state, which is against FP principles.
Earlier quoted context omitted.
"Performance" matters a lot less than many other things like collaborating with other people, or getting the DOM manipulation right.
I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.
Back with components, it was trivial to compare old and new values and change the state based on that.
Earlier quoted context omitted.
All blow up events come from a loud and extremely small minority. But whether they are making noise or signal, does not depend on number of people! React continues to dominate others because it meets baseline criteria for a js framework. And has corporate backing while Vue doesn't. Angular 1 was also popular because it was average js framework with google's backing before angular 2. Implying that React remains popula…
Vue is more akin to the old way of doing things with static templates (Jinja, Mustache, Erb, PHP), just with a dynamic twist. React is not perfect, it's bloated, but the reason it took off is that it brought something new to the table as a general and programmatic way to construct UIs. Being a child of Facebook helped it achieve dominance but considering that before React we had angular (shudder) and jquery, React's…
I've been feeling the same sentiment as the author. Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain. The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected…
React definitely continues to innovate. Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library. That was only a few years ago. The team is actively working on RSC (react server components) which will have a similarly large impact on react's capabilities. Frameworks like remix and next will be able to leverage and build on this to create even…
Not to start an unholy flame war, but if you were to start a new project and didn’t need to worry about the ecosystem or workforce, what framework would you choose? Vue? Svelte? Something else?
Not a single one of the many projects I’ve worked on in the last 10 years needed such a level of interactivity that it justified the trade offs of using react or any other frontend-heavy frameworks.
I’ve seen entire CRUD spas that would have been built in 20% the time if we didn’t have to build a graphql api, figure outs authentication and permissions, integrate that with a custom validation setup, integrate all of the above with the translations systems, coordinate deploys or do forward compatible migrations, etc, etc. so much energy (and money) wasted.