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.
With all due respect, it's clear you are ignorant about what
reactis.State management and data fetching is not part of DOM manipulation. These are add-ons that the react team added. Anyone familiar with how
reactevolved would know that.With all due respect, it's clear you are out of arguments.
Clearly React cannot fulfill the duties required by today's applications. Clearly, React is an underperformer, bloated and overall lacking library that was great 5 years ago, and now has been surpassed by several others. I see no shame in admitting reality. It was a good run, but that run is no more.
I know very well what React is: The past. I even brought numbers to the table. Whether or not you want to admit it, is entirely up to you (I see you disregarded the source of my data, even when you were so emphatic about asking for it, in bold and all).
It's clear we have reached an impasse in our discussion and will merely degrade in quality and facts from this point forward. Feel free to keep your own opinion, as I'll do the same with mine.
Have a good day.
A good video why you may choose React. youtu.be/uEx9sZvTwuI?si=xVokk-YsoN...
This is a really bad take and the reason why tech is in really bad shape now that the bubble has popped.
There are no logical reasons to use React, it's inefficient, bloated, unintuitive, badly designed and promotes bad design. It does not solve a problem but creates one and provides a subpar solution to that problem they created.
(They only thing that might be somewhat useful is JSX, but you can use it without React)
There are only "social" reasons to use React. It's all peer pressure and people in charge who don't know about system design making bad decisions only on the basis of "it's what everybody is using" or "it's the future".
What would you recommend instead of React?
I'm against frameworks in general. In all my years I've used a lot of them and they all share the same fate. The short term benefits are always out-weighted by the long term drawbacks, and there will always be a new one in a few years that becomes the "current thing", at which point everything you invested in the previous one becomes just a lot of wasted resources.
I'd rather use a tool stack where each tool requires little investment from your team, that even if they become obsolete you didn't waste much by having used them. Things that are so simple in nature they can be learnt in a few days, that are intuitive enough that even if you have never used them, the code can be understood.
Most of your basic needs in web development are already covered by the current state of vanilla Javascript and HTML+CSS. I'm not saying that should be the way, but you can work from there adding tools, each specifically helping in a different aspect of the development. You don't need a one-size-fits-all framework that does everything.
I have a preferred tool for almost everything I think I would need for developing a web project in a relatively sane way, the exception being something like JSX, which I must admit it's quite convenient to handle HTML within a Javascript context. I'd rather have JSX create an HTMLElement I could use directly instead of React stuff. I don't need nor want the rest of React's functionality, it just makes the app slow and the code unnecessarily harder to write.
Definitely don't disagree with this take, and in fact, I've been leveraging lighter weight frameworks (SolidJS/Svelte) for quick projects and/or vanilla JS/web components where possible lately purely for the better performance and lower bandwidth overhead if it's necessary.
However, the network effect is real, and a ton of companies are going to continue to write/maintain React codebases, not only because devs are familiar with it and the codebases are huge, but also because the ecosystem has just grown too much to throw those codebases away in favor of a more performant, simpler library.
Server components are getting closer to this goal, albeit with the same caveat of not outputting HTMLElements (React Elements still). I fully agree that we're solving already solved problems that React created, but rather than push for vanilla JS, Million is trying to close the gap even more between vanilla JS performance and memory usage to the point where it's easier to make a performant React app than it is to make a vanilla JS/HTML/CSS app, because, again, React likely isn't going anywhere anytime soon.
Writing JSX is just a quicker experience than
document.querySelector()...,document.getElementById(), etc. + DOM manipulation. It's a better idea (for Million.js at least) that people keep their codebases, put in almost no effort, and just increase performance by ~2x without anything but a CLI run and a dependency and get near vanilla JS performance. Caveat, of course, being you're still shipping a lot of kb's of dependencies for just React + Million.js. Baby steps!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.