3 ms·
This article seems completely filled with nonsense. After YEARS and THOUSANDS of projects proving that 2-way binding causes massive problems, the author insist
by hajile 3y ago
This article seems completely filled with nonsense.
After YEARS and THOUSANDS of projects proving that 2-way binding causes massive problems, the author insists I shouldn't believe my lying eyes. This may sucker devs with only a handful of years writing frontend code, but any dev who lived through those years won't be buying what is being sold.
"Hooks are outdated" is also false. I used Knockout and signals YEARS before React. Signals are NOT better. At a large scale, they are fragile and nearly impossible to debug because EVERYTHING in your entire app is a moving/mutating target. Just because they "aren't afraid" doesn't mean they aren't coding horrible bugs everywhere that will come home to roost from seemingly unrelated code changes in another part of the app.
The author claims that you can port libraries between other frameworks easily. This is absolutely false. The only "portable" solutions are going completely headless then making wrappers for various frameworks and if you do this, then React is no different than any other framework.
Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author.
Benchmarks are another interesting area. The actual delta between React and other systems isn't as massive as some seem to believe. More importantly, React's ability to defer rendering of some elements gives it the potential to feel faster to the user (which is the important metric).
I find the React is "hard to learn" claim fascinating. When I used AngularJS, it took 1-2 MONTHS to write basic stuff. Becoming an expert required 6 months to a year as you slowly learned the entire AngularJS codebase debugging stuff like the digest cycle. I taught a LOT of people to code React. 1-2 days to learn those basics and 1-2 weeks to know everything. The core React API has grown, but it's still not very complicated. Other frameworks may be quicker to learn, but in my experience, the difference is not huge upfront and there are almost always weird edge cases that haven't been documented that you'll run into (and that's without the signals edge cases).
- dragonwriter 3y ago> Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) isn't a dig at the framework so much as an indictment of the author. Yeah, it is fairly obvious (though, to be fair, it wouldn't hurt to point it out) that: useCallback((...args) => { <*statements*> }, [<*deplist*>] ); is effectively identical to: useMemo(() => (...args) => { <*statements*> }, [<*deplist*>]);
- arrowsmith 3y agoAre they "effectively" identical or they just identical? What's the difference?
- 243423443 3y agoEffectively as in "they have the same effect". The difference was stated in the comment that you replied to: One is for general memoization, the other just for functions. You can use useMemo exclusively if you prefer.
- rhaway84773 3y agoBut it does reflect so much that’s wrong with the React development. Creating a first class hook whose only purpose is to wrap another first class hook, all so you can pass in a function rather than a function that returns a function.
- jsunderland323 3y agoI hear what you’re saying. I think in the abstract it seems like an unnecessary helper function. But in a historical context it makes sense. About a year before hooks was introduced it was discovered by multiple teams that inline anonymous JSX functions could create big performance issues. This was particularly felt in react native development. The solution back then was to do the whole .bind(this) to your callback methods in your react classes. Because of this (my guess) is the react team wanted to make it extremely obvious how you could use closure state as opposed to private method callbacks when they went intro hooks, without teams having to worry about taking a performance penalty with inline callbacks. It was not obvious to me (and I’m sure many others) when hooks came out that you could memoize functions before rendering. Again, I get the redundancy point and maybe at this point it could be deprecated but I think you have to think about where the community was before hooks.
- WorldMaker 3y agoMemoization is saving things in memory, it's a tradeoff of memory for fewer function calls. It doesn't work with all possible callback functions (because they need to be pure based on their inputs and dependencies for the saved values to still make sense), and also you don't always want to spend the memory on it (some smart memory use is going to be more performant than the function calls, too much memory use is its own performance problem). The two hooks have different names because they make different trade-offs.
- satvikpendem 3y agoThank you. I never understand why frameworks have two way data binding and signals, both are heavily bug prone. React still reigns supreme.
- rhaway84773 3y agoReact is ridiculously hard to “self learn”. Not because React is necessarily confusing, but because React docs are extremely confusing and the transition from class components to function hook based components means you can search for a problem and find answers only for class components, whereas the function component solution is buried deep if it even exists. And we know it’s confusing because the React docs themselves reflect the confusion. A great example is useEffect, where the original docs quite clearly state that useEffect can be used to handle side effects, whereas the new docs say it’s used to “sync” components (and I don’t remember if it explicitly says not to use it for side effects, but that’s the common understanding people have now).
- test098 3y ago> whereas the new docs say it’s used to “sync” components (and I don’t remember if it explicitly says not to use it for side effects, but that’s the common understanding people have now). other way around. useEffect is for side effects (hence the name) and are _not_ needed for "syncing" state with props.
- repsilat 3y ago> Bragging that you can't understand the difference between useMemo and useCallback after reading the docs (one is general memoization and the other is function-specific) Right, the first argument to useMemo must be a function, but the first argument to useCallback need not. That's what you meant, right?
- ShellfishMeme 3y agouseCallback makes sure that you don't recreate a function you need in a component at every re-render but only when its dependencies change. It returns a function. useMemo returns a value which is the result of calling the function it is given once the dependencies change. So useCallback is basically useMemo called with a function that returns a function.
- repsilat 3y ago> useCallback ... returns a function. It returns something with the same type you gave it. If you give it a function it gives you a function back. In typescript it's declared to take a function but in practice it doesn't check, and can be used to stabilize the identity of anything. useMemo otoh _does_ only take functions.
- yojo 3y agoTwo-way data binding is a foot-gun for sure (I also worked in a large knockout codebase circa 2010), but man is the alternative a PITA when you’re just filling in a form. And the problem only shows up when you start propagating two-way data back up the tree. If someone wants to invent a framework where two-way form binding is easy, but the data can’t leave the component without being dispatched as an action, I’m in.
- cjblomqvist 3y agoThe framework you're looking for is more or less Vue. (some will probably disagree, but I think most that have used Vue significantly won't)
- brianfryer 3y agoI too thought Vue would be a solid fit for what they described.
- test098 3y agouseReducer is what you're looking for