If you've heard of Million JS (from Aiden Bai, its creator, or Tobi Adedeji's React puzzles on Twitter), you've probably been intrigued by the head...
For further actions, you may consider blocking this person and/or reporting abuse
Serious question... Why use React?
I know this is about Millions.js but... that only exists because React exists, it's solving a problem that shouldn't be solved but removed entirely.
The best way to optimize a React app is to stop using React (or anything that's forked from it or follows the same bad design principles).
I also ask the same question. It is as if developers are just bound to torture themselves with a library that is just beyond repair.
Million.js sounds very interesting. Its compiler approach and the use of fine-grained reactivity is refreshing. You know which framework already does this? Svelte.
Svelte already fixed what Million.js is coming to fix, and it does it right from the get-go. Svelte 4 lacks Solid's fine-grained reactivity, but Svelte 5 Runes will close this gap, making Svelte the top choice, at least of us developers that don't want to continue down ReactJS' rabbit hole.
React has an excellent API. Why is it beyond repair?
There are many issues with it.
<Suspense>. It is eye-opening to see that documentation, and then going into Svelte and taking the lesson on the{#await}block. My Good Lord In Heaven.That's just from the top of my head coming from me, someone that rarely work with it (I'm mostly a back-end developer). Imagine all the things that escape me.
React: Fine-grained reactivity should be the norm
Gabriel Afonso ・ Sep 15
There are a few problems in your understanding.
react-alternatives beat react in performance. However,react-based codebases tend to be easier to understand and follow, especially if they employ the excellent ELM architecture.reactis only a view library.Having said all of the above, the issue with
reactis that in recent years it started to try to cater for things beyond DOM manipulation:<Suspense />, RSC, data fetching and so on. This is a mistake and will probably spell the end ofreactbecause it makes it difficult to understand and maintain.However, there are alternatives that are still focused like
preact.Pretty contradictory for a state-driven library, wouldn't you say? Isn't React about declarative programming? Isn't state the heart of declarative programming?
Isn't data fetching part of viewing? Or is React content by just showing empty boxes? Fetching has always been an asynchronous operation, yet React never prepared for asynchronous programming.
Here's your evidence: Interactive Results. Tip. Look for React on the right, far away from Vanilla JS, Solid, Svelte...
I leave you a preview of LIghthouse results (results used by Google to promote search results):
So, are you saying that we should ignore results like the ones I am presenting, because maybe (but maybe not!) are based on "faulty assumptions or fictional workloads"? No sir, that's not the way it goes. Surely there may be tests like that, but even "faulty" tests can tell you a story. Furthermore, it is my strong belief that justifications like "computers are very fast and have a lot of RAM nowadays, so this is a non-issue" come from people unwilling or unable to actually make it better.
And yet other libraries have come to embrace it so beautifully that leave React in shame.
Without trying to be mean or anything, I believe you are trying to defend what cannot be defended. Overall, people need something that works. We don't want a library that is based on state that cannot effectively handle state. We want something that performs so our grievances are minimum with people in the lower end of the technology spectrum. We want something that can be programmed fast and error-free. React doesn't check any of these checkboxes.
I'm not for or against React, seeing comment below, however the fact that React is big, in terms of community, support and provably, it's future is no joke. Of the many many frameworks out there, many compare themselves to React and each is addressing something. This is just another one of them addressing that. And everyone of them is contributing to a future where we have fast, dynamic, safe and performant code. The framework is not the point, it's how it's used and what it achieves.
This is fabulously written. Thank you.
There's definitely a network effect going on, and the fact that it's the biggest framework in terms of usage also means that knowing it is an advantage (or a commodity) for new devs looking to get employed or experienced devs completing a project at work, which further grows the network effect!
Thanks for the kind words!
Awesome article!!!
You block and block DOM links are broken.