IMO what has ruined React is the emergence of meta frameworks that are tied to vested interests of corresponding hosting platforms.
React docs themselves recommend starting with Next, Remix, or Gatsby. I can't imagine how Next or Remix is supposed to be a beginner friendly option. Imagine learning about state and JSX, and then now having to decide whether to use Next App Router or Pages router.
Devs should be able progressively _add_ stuff to a React app easily when they need it rather than having to make those decisions at the time of `npm init`
React is the Spring of frontend frameworks. If you have used Spring framework around 2010ish with Hibernate as ORM, you'd know what I am talking about.
React with its component ideas was a smart and the first of its kind, yes. But its evolution is regrettable. The idea of hooks is so.... that it would be considered spaghetti code in any other realm of software engineering.
I have switched to Svelte. I don't like everything about SvelteKit but it is better than NextJS and simpler to reason about with its page, layout load functions and error components.
With Svelte, I am rarely thinking about framework at all. I am thinking about my business domain.
React is currently like Spring Framework before Spring Boot. A 'React Boot' would be welcome. Also note that Spring Boot is a small wrapper interface for Spring Framework, which adds rather than subtracts from the implementation. I've run into the limitations of Spring/Boot (mostly but not only around Hibernate) and wouldn't use it again by choice.
> React with its component ideas was a smart and the first of its kind, yes.
Tldr: React is just a port (the original version).
Just as an FYI, The main concepts of react were first created in PHP. It was called XHP and was latter ported to JavaScript by Facebook. This is why old React was class-based (because php is a class-based OO language).
Never understood this posts. React as a whole and state management became many times easier over the years (been working with it, vue and a bit of angular for 6+ years now).
Function components removed stuff like getDerivedStateFromProps and many other things, introduced clear and simple way of component updating (as in "prop reference changed, I'm gonna render now").
For state we got redux toolkit, which simplified reducers, zustand and recoil/jotai and mobx which allow you to pick based on your needs instead of writing million reducers or passing state to children when you don't really need it.
Its not "react got hard", its people unable to adapt to changing world. Every mainstream framework in reality got streamlined, simpler and more effecient to create apps.
> React as a whole and state management became many times easier over the years
This to me is exactly the problem actually. React was an object oriented framework; it leaned into that for managing state for components. Then they introduced stateful functional components in 16.8, and React became an entirely new paradigm. 16.8 should have been an entirely new framework, and yet it was merely a minor version bump. I can't find myself blaming users for finding it difficult to keep up with the whims of Facebook.
I rather like React, but its names for things (like "getDerivedStateFromProps") are always just godawful. They're wordy, and even all of those words really don't make the purpose clear.
I was always particularly aggrieved by "mapStateToProps", which obfuscates that it's referring to the Redux state rather than the thing that's actually called "state" in the component. And why the heck are we mapping it into the props? (Not that "useSelector" is any great model of clarity, but at least it's a compact verb-noun pair.)
Nothing wrong with plain js. Now with Web Components, View Transition API, and Plain old Event + addEventHandler() you can do a lot.
You may want to consider HTMx and its hx-boost which is akin to Turbolinks if you've ever used that.
The addition of Hooks, HOC, Redux, etc. are for large teams, complex apps and/or varying skill levels.
Keep in mind plain js means no enforcement of standard patterns. This may cause problems with onboarding new devs and/or keeping the app manageable as complexity grows.
Also React and plain js are not mutually exclusive.
I also started around 2007ish, MooTools, jQuery, Backbone, Ember, Angular JS, Angular, React and now Nextjs. But for basic projects I usually start with plain js.
React is still the best IMO. It's crazy how much you cover with setState and useEffect alone, I barely use the other hooks. Combined with adjacent tooling and paradigms like JSX, React Native, Next.js, I find the others can't quite keep up with the React ecosystem.
I had to use new Angular on a project recently, it's come a long way and it's actually not too bad especially with GPT-4 explaining the reasoning behind Angular, etc. However, it's no React! It's still just too complex, and I can't be bothered to get into decorators, and other quirks that come along with the Angular world.
If you're liking vanilla JS right now, you might like Node - do some backend stuff. It's just regular JavaScript. I think it's always good to stay brushed up on vanilla JS, I do one-off FE stuff all the time in classic HTML/CSS/JS, but for websites my go-to is definitely still React (Next.js typically). I prefer the declarative style, think it works well for FE state, you end up needing some kind of state management usually.
I genuinely can't think of anything Angular does that I felt was strictly better than what React does.
The closest is probably that Angular is batteries-included, whereas React is just a view library. This argument I would be more sympathetic with if those batteries did not include observables for (almost) everything.
The strange is, how long will it be just a view library. I‘m a beginner and was frustrated that the official react documentation advises to use next.js or some other react framework instead of vanilla react (because react is just a view library and you need routing, state management and other stuff anyway)
First thing which came to my mind was „huh, angular was right“.
And yes, vite and vanilla react is still possible…
I tried to learn React for one of my websites. I wasn't ever able to get past the guide on the site due to it being so, so, so complex. I stuck with Vue and it worked fine.
React is nice as a UI library, the thing is that people keep adding more stuff inside the components, making it look more like an application framework, which it's not good at. It takes discipline to design a good interface between your UI and your business logic (even if it's UI related) and keep it that way. If the local state of your component is becoming too complex, extract it to its own store and link it to the child components that are using it. If you do that, it's relatively easy to handle. I have tried Svelte and Vue and I like them, just because the way to write them don't let you add big processing logic on them. So you have cleaner code. Redux-Toolkit, Next.js,… it's just making things complex for no reason.
I'm using Alpine right now and it's still feel like React (in a conceptual manner), but that's because I've never liked to introduce processing in my own code base, preferring services and other stateful stuff to be outside of my React components.
I still think that if you don't have a lot of states to manage, and plenty of pages, going Vanilla is better. If there's only one single page, but plenty of interactive elements, I'd go with Svelte just because I like declarative more. But that's a matter of balancing whether I want to interact with a build system or not.
I think VanillaJs is fine until you forget about your codebase or have to work with other people unfamiliar with your code. It may work, but you will have to be very well organised, as everyone working with you.
Over the years, I used quite a few frameworks and Vanilla JS, and today, I would start a new project with React. It's not perfect, but it's the best choice for most projects since a decade.
I don’t enjoy React much, but (as I’ve commented before) I do love Mithril (https://mithril.js.org). Immediate-mode UI via a vDOM, like React, but small, simple, and with none of the reactivity complications. I’d never go back to building apps with pure JS.
Recently tried Svelte and feel the same way about React.
I dread the idea of ever working on a React project again. (React 19 might mitigate these feelings)
I learned vanilla Javascript first. Spent a few years building various frontends / websites that way.
Then came React. I thought knowing Javascript meant I'd know React. Oh boy was I wrong.
I started around the time that class-based components were replaced with hooks and function-based components only.
That meant I had to work in the latter, while all the SO posts were about the former, so I couldn't find any solutions to problems I was facing.
About three years in, I still couldn't explain to you wtf a hook is. I've looked at countless tutorials, used countless hooks from various libraries, but I've never felt the need to make one. Which tells me that I still don't know what problem is fundamentally solved by using / making a hook specifically.
All I understand is writing a function that returns a value or a function that returns a bunch of JSX. I've never needed some sort of mystical third concept that somehow requires me to call it 'use'-something, before I'm allowed to call other things called 'use'-something within it. I wish I could somehow wrap my head around it.
Anyway, learning React, I felt I spent more time trying to work out why things sometimes got updated and sometimes not. It felt insanely arbitrary.
Then comes the joy of trying to force the incredibly non-deterministic rendering of the stack of components into something reasonably deterministic. If you have to call multiple endpoints and track the state of those calls and ensure a component only renders when that data is available in its correct form (which has to happen in a specific sequence), you will spend what seems like an insane amount of time forcing something that is inherently non-sequential into executing sequentially. Seems wild to me.
The amount of time some component tries to access 'undefined' is just astounding.
How about closures? It took me so long to finally understand that useEffect doesn't have access to updated state variables unless they are in the dependency array. So much time spent banging my head against the wall, wondering why my variable is always 'behind' by exactly one state update.
Let's assume you've managed to set all this up, you suddenly find out that React literally re-renders the ENTIRE tree of components sitting on top of any child component, every time anything changes.
Let's imagine a form with multiple inputs:
<form>
<input1>
<input2>
<input3>
</form>
If I make a change to input2, the form and all the other inputs are re-rendered. Unless, of course, I wrap each and every input in React.Memo(). If I want my form to handle errors properly, for example by using react-hook-form, I then need to add a custom compare-function for each prop handed into the input, to ensure it updates correctly, but only when needed. What used to be a one-liner <input> has suddenly become 15 lines of code dedicated to working out when to re-render this one input instead of the entire form.
I still haven't used useCallback successfully anywhere in any of my applications, because I'm still not sure I understand what it does or how it works.
Suspense makes sense. Error boundaries are still elusive. I've tried implementing them, but most of the time the only error boundary that really triggers is the one all the way up the tree, which is only one step better than crashing the whole interface when a component encounters an error.
Anyway, so you've finished that whole journey, good job. Enter Next.js. Guess when I started using Next.js? Yup, right around when page-router became the app-router. Same story again, all SO issues are about page-router, so none of the problems I'm encountering have been addressed yet.
How about initialising a Next.JS app in dark-mode to start with? Not possible, because half your app is now server-based components that don't have access to cookies, so it always flashes white first before jumping to dark mode. I suppose I could build my app dark-mode first or save the user's preference in the DB.
Sometimes, it is nice to just store something in localStorage. But, persisting state with Zustand is suddenly hopelessly broken and no amount of hacks around delaying hydration have worked for me so far.
How about changing meta-data of pages, especially if the meta-data relies on a fetch call? How about the fact that the data from that fetch call can't be used in your components, meaning that the fetch call has to be repeated in your component? (But don't worry, Next.js includes black magic to deduplicate fetch calls, pinky-promise that we won't hit every endpoint twice, blowing up your free-tier quota on [insert platform here]).
Caching? Completely arbitrary. Some parts of your app will fetch new data from the server every time, other parts of the app will never update correctly. All depends on who's doing the fetching. If it's a 3rd party service (say, google firebase), then you have to force your api-routes into dynamic rendering before you actually see updated data coming back from fetch calls.
To this day, I haven't managed to get caching working predictably in my app. I literally have no idea when things will revalidate and when not. I've managed to force it into never caching, but a combination of caching when I need it to cache or revalidating every time seems to be impossible to achieve.
So now I am sitting on top of a framework, for a framework, for Javascript, where I neither know when components will update, nor when data will be cached, all because these things are hiding behind magic that is extremely poorly documented (and never seems to include real-world examples of sufficient complexity). It's quite a frustrating experience.
I wouldn't know what the solution to this is. Feels like we've arrived here through years of developer effort and I don't feel qualified to judge it. Therefore, I just put up with it and hope to learn more about it as I build more apps.
It’s just a personality game. Consider who these abstractions appeal to by the phrases people utter most:
* something about reinventing wheels
* easier
* mvp in 30ms
To me it’s always sounded like whiny bullshit. How do you get your MVP up fast? You build a starter template and then copy/paste from it. How do you make it easier? You avoid the bad practices. How do you avoid reinventing wheels? You build libraries.
These giant abstractions are created to appeal to people who are emotionally insecure about how to proceed. If you want to create the next big super framework that’s both your premise and your audience. This was the exact original sales pitch for Angular, btw.
Instead of being able to get autocomplete and normal refactoring you would get from plain js.. now you need to add typescript to supplement the mess...
IMO what has ruined React is the emergence of meta frameworks that are tied to vested interests of corresponding hosting platforms.
React docs themselves recommend starting with Next, Remix, or Gatsby. I can't imagine how Next or Remix is supposed to be a beginner friendly option. Imagine learning about state and JSX, and then now having to decide whether to use Next App Router or Pages router.
Devs should be able progressively _add_ stuff to a React app easily when they need it rather than having to make those decisions at the time of `npm init`
React is the Spring of frontend frameworks. If you have used Spring framework around 2010ish with Hibernate as ORM, you'd know what I am talking about.
React with its component ideas was a smart and the first of its kind, yes. But its evolution is regrettable. The idea of hooks is so.... that it would be considered spaghetti code in any other realm of software engineering.
I have switched to Svelte. I don't like everything about SvelteKit but it is better than NextJS and simpler to reason about with its page, layout load functions and error components.
With Svelte, I am rarely thinking about framework at all. I am thinking about my business domain.
EDIT: Fixed typos
Disclaimer: All opinions are subjective.
I've been using Spring Boot since 2017 and haven't noticed any "evolution" that I would regret.
React on the other hand is insane. SolidJS is what react should've evolved in.
React is currently like Spring Framework before Spring Boot. A 'React Boot' would be welcome. Also note that Spring Boot is a small wrapper interface for Spring Framework, which adds rather than subtracts from the implementation. I've run into the limitations of Spring/Boot (mostly but not only around Hibernate) and wouldn't use it again by choice.
I see a lot of similarities in how Boot to Spring Framework is like React to Next.js or other metaframeworks.
The main difference is that Spring side is handled by the same company.
> React with its component ideas was a smart and the first of its kind, yes.
Tldr: React is just a port (the original version).
Just as an FYI, The main concepts of react were first created in PHP. It was called XHP and was latter ported to JavaScript by Facebook. This is why old React was class-based (because php is a class-based OO language).
https://web.archive.org/web/20130821190221/https://github.co...
Never understood this posts. React as a whole and state management became many times easier over the years (been working with it, vue and a bit of angular for 6+ years now).
Function components removed stuff like getDerivedStateFromProps and many other things, introduced clear and simple way of component updating (as in "prop reference changed, I'm gonna render now").
For state we got redux toolkit, which simplified reducers, zustand and recoil/jotai and mobx which allow you to pick based on your needs instead of writing million reducers or passing state to children when you don't really need it.
Its not "react got hard", its people unable to adapt to changing world. Every mainstream framework in reality got streamlined, simpler and more effecient to create apps.
> React as a whole and state management became many times easier over the years
This to me is exactly the problem actually. React was an object oriented framework; it leaned into that for managing state for components. Then they introduced stateful functional components in 16.8, and React became an entirely new paradigm. 16.8 should have been an entirely new framework, and yet it was merely a minor version bump. I can't find myself blaming users for finding it difficult to keep up with the whims of Facebook.
I rather like React, but its names for things (like "getDerivedStateFromProps") are always just godawful. They're wordy, and even all of those words really don't make the purpose clear.
I was always particularly aggrieved by "mapStateToProps", which obfuscates that it's referring to the Redux state rather than the thing that's actually called "state" in the component. And why the heck are we mapping it into the props? (Not that "useSelector" is any great model of clarity, but at least it's a compact verb-noun pair.)
Nothing wrong with plain js. Now with Web Components, View Transition API, and Plain old Event + addEventHandler() you can do a lot.
You may want to consider HTMx and its hx-boost which is akin to Turbolinks if you've ever used that.
The addition of Hooks, HOC, Redux, etc. are for large teams, complex apps and/or varying skill levels.
Keep in mind plain js means no enforcement of standard patterns. This may cause problems with onboarding new devs and/or keeping the app manageable as complexity grows.
Also React and plain js are not mutually exclusive.
I also started around 2007ish, MooTools, jQuery, Backbone, Ember, Angular JS, Angular, React and now Nextjs. But for basic projects I usually start with plain js.
React is still the best IMO. It's crazy how much you cover with setState and useEffect alone, I barely use the other hooks. Combined with adjacent tooling and paradigms like JSX, React Native, Next.js, I find the others can't quite keep up with the React ecosystem.
I had to use new Angular on a project recently, it's come a long way and it's actually not too bad especially with GPT-4 explaining the reasoning behind Angular, etc. However, it's no React! It's still just too complex, and I can't be bothered to get into decorators, and other quirks that come along with the Angular world.
If you're liking vanilla JS right now, you might like Node - do some backend stuff. It's just regular JavaScript. I think it's always good to stay brushed up on vanilla JS, I do one-off FE stuff all the time in classic HTML/CSS/JS, but for websites my go-to is definitely still React (Next.js typically). I prefer the declarative style, think it works well for FE state, you end up needing some kind of state management usually.
I genuinely can't think of anything Angular does that I felt was strictly better than what React does.
The closest is probably that Angular is batteries-included, whereas React is just a view library. This argument I would be more sympathetic with if those batteries did not include observables for (almost) everything.
(I know about Signals. Not a fan of that either)
The strange is, how long will it be just a view library. I‘m a beginner and was frustrated that the official react documentation advises to use next.js or some other react framework instead of vanilla react (because react is just a view library and you need routing, state management and other stuff anyway)
First thing which came to my mind was „huh, angular was right“.
And yes, vite and vanilla react is still possible…
The main thing that next.js gives over React is a backend, something that Angular by itself doesn't give you.
Observables are painful, especially when they should just be available Promises.
But Signals? That's just what everybody is converging on, hence making Angular no worse and no better than the competition in that regard.
I tried to learn React for one of my websites. I wasn't ever able to get past the guide on the site due to it being so, so, so complex. I stuck with Vue and it worked fine.
You need to try Svelte, it's even easier
React is nice as a UI library, the thing is that people keep adding more stuff inside the components, making it look more like an application framework, which it's not good at. It takes discipline to design a good interface between your UI and your business logic (even if it's UI related) and keep it that way. If the local state of your component is becoming too complex, extract it to its own store and link it to the child components that are using it. If you do that, it's relatively easy to handle. I have tried Svelte and Vue and I like them, just because the way to write them don't let you add big processing logic on them. So you have cleaner code. Redux-Toolkit, Next.js,… it's just making things complex for no reason.
I'm using Alpine right now and it's still feel like React (in a conceptual manner), but that's because I've never liked to introduce processing in my own code base, preferring services and other stateful stuff to be outside of my React components.
I still think that if you don't have a lot of states to manage, and plenty of pages, going Vanilla is better. If there's only one single page, but plenty of interactive elements, I'd go with Svelte just because I like declarative more. But that's a matter of balancing whether I want to interact with a build system or not.I think VanillaJs is fine until you forget about your codebase or have to work with other people unfamiliar with your code. It may work, but you will have to be very well organised, as everyone working with you.
Over the years, I used quite a few frameworks and Vanilla JS, and today, I would start a new project with React. It's not perfect, but it's the best choice for most projects since a decade.
I don't get the argument that you don't know when react will rerender, as that hasn't fundamentally changed since react v1
I don’t enjoy React much, but (as I’ve commented before) I do love Mithril (https://mithril.js.org). Immediate-mode UI via a vDOM, like React, but small, simple, and with none of the reactivity complications. I’d never go back to building apps with pure JS.
A bit offtopic, but that's how I feel with Svelte and SvelteKit. Early SvelteKit was peak SvelteKit
I love React. Hooks only made it better. Although they are not, I think, the final perfect solution to the problems they solve.
I tried to like React, but was never able to. It all seemed needlessly complex.
For larger applications, it is needfully complex
Recently tried Svelte and feel the same way about React. I dread the idea of ever working on a React project again. (React 19 might mitigate these feelings)
I learned vanilla Javascript first. Spent a few years building various frontends / websites that way.
Then came React. I thought knowing Javascript meant I'd know React. Oh boy was I wrong.
I started around the time that class-based components were replaced with hooks and function-based components only.
That meant I had to work in the latter, while all the SO posts were about the former, so I couldn't find any solutions to problems I was facing.
About three years in, I still couldn't explain to you wtf a hook is. I've looked at countless tutorials, used countless hooks from various libraries, but I've never felt the need to make one. Which tells me that I still don't know what problem is fundamentally solved by using / making a hook specifically.
All I understand is writing a function that returns a value or a function that returns a bunch of JSX. I've never needed some sort of mystical third concept that somehow requires me to call it 'use'-something, before I'm allowed to call other things called 'use'-something within it. I wish I could somehow wrap my head around it.
Anyway, learning React, I felt I spent more time trying to work out why things sometimes got updated and sometimes not. It felt insanely arbitrary.
Then comes the joy of trying to force the incredibly non-deterministic rendering of the stack of components into something reasonably deterministic. If you have to call multiple endpoints and track the state of those calls and ensure a component only renders when that data is available in its correct form (which has to happen in a specific sequence), you will spend what seems like an insane amount of time forcing something that is inherently non-sequential into executing sequentially. Seems wild to me.
The amount of time some component tries to access 'undefined' is just astounding.
How about closures? It took me so long to finally understand that useEffect doesn't have access to updated state variables unless they are in the dependency array. So much time spent banging my head against the wall, wondering why my variable is always 'behind' by exactly one state update.
Let's assume you've managed to set all this up, you suddenly find out that React literally re-renders the ENTIRE tree of components sitting on top of any child component, every time anything changes.
Let's imagine a form with multiple inputs:
<form> <input1> <input2> <input3> </form>
If I make a change to input2, the form and all the other inputs are re-rendered. Unless, of course, I wrap each and every input in React.Memo(). If I want my form to handle errors properly, for example by using react-hook-form, I then need to add a custom compare-function for each prop handed into the input, to ensure it updates correctly, but only when needed. What used to be a one-liner <input> has suddenly become 15 lines of code dedicated to working out when to re-render this one input instead of the entire form.
I still haven't used useCallback successfully anywhere in any of my applications, because I'm still not sure I understand what it does or how it works.
Suspense makes sense. Error boundaries are still elusive. I've tried implementing them, but most of the time the only error boundary that really triggers is the one all the way up the tree, which is only one step better than crashing the whole interface when a component encounters an error.
Anyway, so you've finished that whole journey, good job. Enter Next.js. Guess when I started using Next.js? Yup, right around when page-router became the app-router. Same story again, all SO issues are about page-router, so none of the problems I'm encountering have been addressed yet.
How about initialising a Next.JS app in dark-mode to start with? Not possible, because half your app is now server-based components that don't have access to cookies, so it always flashes white first before jumping to dark mode. I suppose I could build my app dark-mode first or save the user's preference in the DB.
Sometimes, it is nice to just store something in localStorage. But, persisting state with Zustand is suddenly hopelessly broken and no amount of hacks around delaying hydration have worked for me so far.
How about changing meta-data of pages, especially if the meta-data relies on a fetch call? How about the fact that the data from that fetch call can't be used in your components, meaning that the fetch call has to be repeated in your component? (But don't worry, Next.js includes black magic to deduplicate fetch calls, pinky-promise that we won't hit every endpoint twice, blowing up your free-tier quota on [insert platform here]).
Caching? Completely arbitrary. Some parts of your app will fetch new data from the server every time, other parts of the app will never update correctly. All depends on who's doing the fetching. If it's a 3rd party service (say, google firebase), then you have to force your api-routes into dynamic rendering before you actually see updated data coming back from fetch calls.
To this day, I haven't managed to get caching working predictably in my app. I literally have no idea when things will revalidate and when not. I've managed to force it into never caching, but a combination of caching when I need it to cache or revalidating every time seems to be impossible to achieve.
So now I am sitting on top of a framework, for a framework, for Javascript, where I neither know when components will update, nor when data will be cached, all because these things are hiding behind magic that is extremely poorly documented (and never seems to include real-world examples of sufficient complexity). It's quite a frustrating experience.
I wouldn't know what the solution to this is. Feels like we've arrived here through years of developer effort and I don't feel qualified to judge it. Therefore, I just put up with it and hope to learn more about it as I build more apps.
It’s just a personality game. Consider who these abstractions appeal to by the phrases people utter most:
* something about reinventing wheels
* easier
* mvp in 30ms
To me it’s always sounded like whiny bullshit. How do you get your MVP up fast? You build a starter template and then copy/paste from it. How do you make it easier? You avoid the bad practices. How do you avoid reinventing wheels? You build libraries.
These giant abstractions are created to appeal to people who are emotionally insecure about how to proceed. If you want to create the next big super framework that’s both your premise and your audience. This was the exact original sales pitch for Angular, btw.
> These giant abstractions are created to appeal to people who are emotionally insecure about how to proceed.
"Using libraries considered baby behavior"
Another "I hate hooks" sentiment. Nothing new, or unlike countless other takes online.
Post and comments have to be unique or unheard of, otherwise the can't be made or are invalid. What???
just from pure api perspective how is setA, setB, setC better than...
this.setState({this.state: val})
which was already pushing limit of normal behavior which is
state.A = val
just to be revise
i went from having to do
state.onlineStatus = 'active'
to
const [onlineStatus, setOnlineStatus] = useState('active')
Instead of being able to get autocomplete and normal refactoring you would get from plain js.. now you need to add typescript to supplement the mess...
const obj = {
onlineStatus: 'inactive', shoppingCart: '3899x', lastActive: 1834393939 }
obj. [autocomplete anywhere in the project]
vs MORE Boilerplate