I am not a React.js person anymore.

Vaibhav Rai
2 min readMay 8, 2024

--

Not a react.js person

Saying “no” to the React because of few of my personal reasoning.

JSX:
Yes, jsx, most people would love the jsx syntax, but when it comes to frontend development the first thing, we learn is HTML and how all the semantic elements make the webapp possible.

Considering the pattern React follows for CSR, i.e., index.html and then populate/mount all the node and then attach listeners or callback to the node, its itchy to see that all of this is happening via JavaScript, meaning the initial index.html is just blank.

I realize very late that the syntax of svelte makes absolute sense and the ecosystem is just too lazy to adapt, when we already have a structure i.e., head, script, body then why not leverage it.

APIs

Now React has too many APIs, it's not as simple as useEffect and useState now it has hooks like use which can easily confuse new developers, thinking from the fact that they are getting the synchronous behavior, without thinking in what conditions.

In the past I have found bugs in projects where provider function call was wrapped in useCallback which was accessing some state of the provider but state itself was set on mount, that means the state is always undefined because of useCallback and it led into creating a huge bug inside the project.

In React 18, RSC one of the most popular concepts came into the picture, and but no blog talked about the fact that it is still CSR, it's just reduced the bundle size, my initial thought when I started experimenting the RSC was that it is introducing SSR with RSC i.e., if I disable the javascript then the page is just blank, until an unless, I specifically configure my project to use the react-dom/serverApi and hydrate it but then again, it requires understanding of how to configure and setup the project over node or any other middleware.

Frequent releases

I didn’t understand, that how come React became so un-reliable, that major releases became frequent releases i.e., patching the global, then removing the patching, just because there is a hydration mismatch because of library like Date, should React start patching everything, or there should be a configurable option given to the developer to choose between the two obvious behaviors with warnings?

--

--