Just Fucking Use React
justfuckingusereact.comI'm waiting for an article entitled: "Just Use X" Considered Harmful. The Web is complex (i.e. has many parts) because it is meant to satisfy a very wide range of needs. Most websites use WordPress, because that's an especially easy option to host, configure, and add/update content. But "Just Use WordPress" would be nonsense; a lot of people need more (e.g. Google Maps) or less (e.g. static personal pages) than what WordPress is appropriate for.
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.
This style of abrasive language works best when promoting the simple thing. Like Grug brain, etc. You use simple language to show how little thought is needed to get to the good stuff.
Each of the many paragraphs here requires thought to understand. That's React for you.
Why not Vue? Unlike React it doesn't recalculate everything on every mouse move event.
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.
> Unlike React it doesn't recalculate everything on every mouse move event.
Where did you ever get the idea react does this?
The react's algorithm of detecting changes is based on rebuilding a Virtual DOM tree (i.e. recalculating all components) and comparing that tree to the previous one. It is done, as I understand, every time someone calls update() or similar method on a component.
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.
This is the virtual DOM mental model of react, and it is pretty much entirely wrong.
- 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.
> If a component is memoized with `memo(...)`, then a re-render will be stopped if it has the same props as before
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).
Yes, immutability is a requirement. And if you think that's a "special style of coding" then you probably haven't run into situations where that is a necessity, like optimistic updates with rollback, or undo/redo systems.
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.
You’re right, memo is a lazy thing to do and often fails to optimize. At best it reduces rerenders but doesn’t speed up slow behavior.
That comparison is apples to oranges, because React components are typically much smaller than Vue components (think 20 components in one file). So while its true that a state update will rebuild an entire component, that diff might still only impact 2-3 dom nodes.
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.
> So while its true that a state update will rebuild an entire component
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.
Put that computation in a useMemo and you're good.
This example just sounds like it was coded poorly. I would assume that experienced React developers would know to avoid something like this.
For inexperienced developers, you don’t need a framework to do something dumb.
> The react's algorithm of detecting changes is based on rebuilding a Virtual DOM tree
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.
React can be very performant with little optimization if you apply FP principals to it, which makes sense since it was built with the goal of using FP to do frontend work.
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.
FP principle is that functions are first-class objects and one can pass a function to a function. I don't see how it helps programming the UI. Maybe you meant using immutable data structures? I mentioned that and noted that they have their own issues and generally are a pain to use.
> 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?
Thats the 1-sentence summary of FP, but there’s a lot more to it. Immutable data structures are part of it, although less important because of how props are scoped.
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.
The article says "use React (or Vue, or Svelte, or Angular if you're a masochist - the point is a modern framework"
> modern framework
Modern usually doesn't last long.
Dunno. React has been around for 12 years, Angular’s current incarnation for 8 (older than React if you count <1.5), and Vue for 10.
> and unly packer like Webpack
Huh? People are still using Webpack?
Some time ago I myself was in camp of people who preferred minimal web as opposed to all these "bloated" frameworks. But one thing that changed me is Tailwind, it improves the complicated stupid old way I wrote CSS classes so much that all people who keep hating it just because it's one of those "bloated" things of modern webdev are just ridiculous.
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.
Jarring title but 100% agree! You very quickly hit a point building a modern web app where you need advanced functionality. Rolling your own everything in raw javascript is not a sane approach. I think the just use html crowd is composed mainly of backend devs who struggle to comprehend that a web UI is more than just a pretty crud layer on top of their backend. Fight me :)
I use React or vanilla js or server side rendering or all three together, depending what the situation requires.
I found this website aggressive and not funny.
Bear in mind that this is a response to another website: https://justfuckingusehtml.com/
> Try building a dashboard with a dozen filters, real-time updates from ten different sources, user preferences that change everything, and collaborative editing where five assholes are mashing keys at once. Your "simple" JavaScript will turn into a spaghetti monster that'll make Cthulhu look like a fucking Teletubby having a tea party.
amazing that literally every single thing in this post would make me NOT want to use React (or another framework) :)
I don't trust anyone who pretends their framework of choice is always the correct choice. Real competency is knowing the right tool for the job. Or something like that.
Yep, that's what we're saying in the article.
"sometimes, complexity is not a choice, it's a fucking requirement."
Complexity is never a requirement, and almost always self-inflicted.
This just means that complex projects exists. Complexity refers to the domain or business problem that needs to be solved and software complexity is a consequence of that. If you can anticipate a certain level of complexity by various factors, then you are better off with React/Vue/Whatever.js that makes your life easier.
uness you're solving something complex...
It may be worth investing in a vocabulary-expanding thesaurus, either HTML- or React-based.
No thank you.
JSX sucks and VUE Templates are better and if your a masochist you can still use JSX
So, I should just use vanilla JavaScript? Well if you say so.
Actually data-binding UIs (UIs that automatically update themselves when model variable changes) allow to do more in less time. So you just spend more time to reach the same result.
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.
customElements with attributeChangedCallback are reactives.
it would be pleasing to read if you remove those cuss words.
Well, that’s just like your opinion, man.
FUCK YOU I WON'T DO WHAT YOU TELL ME
Killing In the Name Of! https://www.youtube.com/watch?v=bWXazVhlyxQ
MOTHER FUCKER!
HUH!
Goes to show that the "just do x, dipshit" (HTML, vanilla JS, etc.) rhetoric/framing carries literally zero weight.