Just Fucking Use React(justfuckingusereact.com) |
Just Fucking Use React(justfuckingusereact.com) |
I know, I'll write an article entitled "Just Fucking Use C, You Yellow-bellied Sapsuckers". It'll be about using good-old CGI with C. Imagine a web framework in C, which generates HTML, CSS, and JS. It'll be sleek, easy-to-deploy, portable, fast, and you can optimize to your heart's content. Plus, it will future-proof your career, because your boss will make you spend a chunk of your career re-writing it in Rust: CGI + Rust is the future that nobody is aware of (read: dreading) yet.
Each of the many paragraphs here requires thought to understand. That's React for you.
Also I would like something that doesn't require to install Node.JS and unly packer like Webpack which invents its proprietary syntax instead of using standard EcmaScript. I like to make small apps that I run by clicking on HTML file and I don't have time to go to console and install things or type commands just to open a webpage.
Where did you ever get the idea react does this?
So React won't cause performance issues only if you have few model variables or manually optimize the code by using immutable data structures (which have their own performance issues) and pure components.
For comparison, Vue detects changing by wrapping all model variables with proxies and linking them to UI components that use them. This has an advantage of not having to recalculate everything and disadvantage of having an overhead for using proxies and creating a dependency graph. Also, having to deal with proxies adds more pain for the programmer.
Modern usually doesn't last long.
Huh? People are still using Webpack?
Then I tried React, quite liked it but preference for something as small and fast as possible lead me to Preact. And as I have no need for hosting websites with backend (I just want client-side interactivity so static pages) I found how to do prerender workflow where all necessary html is generated at build time and interactivity gets hydrated on top of that by bundled js module. It's so much better than trying to figure out pure js interactions in site made with static generator with some obscure templating.
Though for some reason people nowadays mainly focus on running site as SSR through Node rather than just hosting static pages and figuring out static build workflow in those frameworks can be very challenging.
I found this website aggressive and not funny.
Complexity is never a requirement, and almost always self-inflicted.
For example, I don't want to use non-reactive UIs (like vanilla JS or GTK) anymore. And it's sad to see that many (or maybe even most of) open-source projects still manually write code to update the UI and lose time on this. It's like trying to build a house using ancient tools.
- React doesn't really distinguish between DOM components and your own components in how it evaluates. It's all part of the same "VDOM" tree. Creating and updating HTML tags doesn't flow differently from updating the props on your own components.
- React does sparse updates, starting at the topmost component(s) whose state changed. Frequently this is just one widget or a button. Full tree re-evaluation is rare.
- If a component has the _exact_ same `children` prop as before (`===`), as is often the case with e.g. context providers, because it was assigned by a parent, then React will skip re-rendering the children entirely with no effort from the developer.
- If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before. This means even if your state lives high up in the tree, judicious use of memo can make it zippy af.
TLDR: If your react app is re-calculating the entire tree, you suck at react and you never bothered to learn it. Skill issue, git gud, etc. You're welcome.
This works only with immutable data structures. Am I wrong? Because a modified array will pass the identity test (=== operator). If you are using mutable data structures, you cannot use identity operator to detect changes.
Also if "memo" optimization is that good why does one have to add it manually?
> If your react app is re-calculating the entire tree, you suck at react
The point of UI framework is to do the optimization for me and not require me to use some special style of coding like immutable structures or manually write functions like componentShouldUpdate. What I write is how UI variables depend on model variables and the rest is framework's job. I don't want to use weird patterns like a function with a giant switch that processes update events and clones the whole model graph to change a single variable.
Vue of course has its own set of issues, caused by using proxies (for example when adding on object to the set you must "unwrap" it manually to prevent adding a proxy to the set).
Mutable code is code that destroys the paper trail of what happened.
>The point of UI framework is to do the optimization for me
No, the point of the UI framework is to allow you to build applications that work correctly and perform well. The React style of coding is designed to scale up to large applications of e.g. a Figma or Excel caliber, while eliminating entire categories of subtle bugs. If you've never coded something like that, React will seem like it is getting in your way.
>Also if "memo" optimization is that good why does one have to add it manually?
Because the compute vs memory trade-off isn't always free, especially in a world where CPU computations are much faster than accessing uncached memory.
For high frequency updates such as reacting to mouse interactions, you can compose components in such a way that only one small component handles the high-frequency update, while it's siblings and children remain static.
In this way, React-components are closer to Vue's computed properties than Vue-components.
What if the component does some long computations, for example, calculating a sum of 10000 elements of an array? React will do the computation only to find that nothing changed.
For inexperienced developers, you don’t need a framework to do something dumb.
Not exactly. This is the "mental model" but not how the algorithm works internally. There are a lot of optimizations to do as little work as possible while "appearing" to rerender everything.
This is not to say one is better than the other - each has its own benefits. But that's not a reason to choose Vue over React.
If your whole tree is recalculating on every mousemove event, that is a giant code smell to say the least. You’d have to architect the app to work that way.
> If your whole tree is recalculating on every mousemove event
If you update a variable in the root component, that will happen. Am I wrong?
Composition, my friend. That’s the key. If your whole tree is rerendering whenever your state changes, it’s a failure to compose your components properly.
FP includes strategies for limiting side effects, relying on architectural patterns that push side effects to the edges of your application. This is a very sane way of working in react.
And a lot of prop drilling can be reduced by passing down closure functions with curried values in them.