I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
Amen. I adopted react for the first time in around 2014. It’s now “boring” and various predictable groups of people are desperate to replace it with /something/, while I’m getting on with my job of delivering software using a nice set of reasonably standardized tools, not having problems hiring, and just generally enjoying life.
Long may the reign of typescript, nodejs and react continue.
Last time I looked at react was 2016 or so and every tutorial was referencing some different mutually incompatible version of some component (router, redux, flux, some other alphabet soup) and everyone had their own list of essential ingredients in a basic hello world app. I came away from the whole experience thinking here’s an ecosystem that needs to mature another 10 years or so before I want to even look at it (I’m not a frontend person, it’s all academic to me.)
Is there a consensus on any of it yet? How to do routing, state, builds, etc? Or is there still as many combinations of components as there are tutorials?
Routing: react router (not very good imo but widely accepted and good enough)
state: No libraries. Just use “useState” and if necessary “useReducer”
Builds: vite
Then pick a query caching library so you don’t need to treat fetched data like its application state… ReactQuery is widely accepted and very good. Apollo if you’re using graphql
> Routing: react router (not very good imo but widely accepted and good enough)
Unnecessarily complicated and confusing, with odd choices in the most recent version (that IIRC are not backwards compatible). I went with wouter after searching around.
> state: No libraries. Just use “useState” and if necessary “useReducer”
useState is the same thing as the old setState, and useReducer not much different - they're not sufficient for building an app because you just revert back to the original state antipattern, prop drilling.
I don’t see how prop drilling is an anti pattern. Passing data around via props is a feature of the library, it’s totally fine if you need to pass a lot of props.
If you really have too many props or need to widely disperse the same prop you can refactor using higher order components or use a context. A separate state management library isn’t necessary unless you are building something with a ton of complex UI state like a photo editor or a music production workbench.
Prop drilling refers to depth, not width - you had to add the props to every intermediate component between where the state is stored and where it's used. Some of us tried to come up with nested usage patterns so at least the intermediate components didn't need to know about the structure and it wouldn't be a pain when moving things around, but it still wasn't very good.
> with odd choices in the most recent version (that IIRC are not backwards compatible)
This exact sentence could have been said about react router 8 years ago when I last looked at react, lol. And IIRC it was react router that turned me off the most, as every react tutorial that stressed working permalinks/URLs (which I believe to be essential) was teaching me react-router, but with sample code that was incompatible with the latest version. Because documentation and tutorials would last like a month tops before they were all horribly broken and out of date. Sounds like this hasn’t changed much.
I'd throw in the occasional context provider store. However, the point absolutely stands that most likely don't need a state library in React anymore unless you're learning it to maintain an older codebase.
The best way to learn a library is to learn it by itself without bringing in other things. I encourage you to learn React without any router, redux, or any alphabet soup indeed. Don't even need a build step, since JSX is optional.
You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.
I'm having trouble forgiving Vue for the backwards compatibility issues and short support period from Vue 2.x => Vue 3.x. I'm now faced with unnecessary cost to upgrade line of business apps built with Vue that in full maintenance mode but now have critical security vulnerabilities popping up in scanners with no way to fix them other than large scale code migration. I saw they are now dropping support for Vue 2 even in the DevTools, so even migration is going to be harder, if we can't easily introspect the pages we are migrating.
I'm suspecting they are going to drop backwards compatibility again in the near future by deprecating support for the options API - leaving me with another headache.
What I like about React is that generally speaking, it has rock solid backwards compatibility support (class components are still supported for example), presumably due to Meta using it at scale such that they cannot scrap everything immediately. Vue, being not used in any large company, does not have the same sense of responsibility to preserve backwards compatibility, it seems. This has its pros and cons though but for many people, backwards compatibility is a big deal.
That's actually fair and my one gripe with Vue, and I just spent the past week and a half porting over my old project that I wanted to resurrect. If they screw with my vue3 using composition API then I'll dust off my pitchfork.
Has gitlab finished upgrading yet? Last time I checked they spent 2+ years and that’s with codemod tools and super smart engineers.
At work, I spent a month upgrading one project to work with the compatibility build and we’ve been slowly migrating for the past 18 months. After the end of this year, we should be out of the woods for that project but then we have 3 more so…
Luckily, Evan has said that he has zero interest in fracturing the community again and I believe him. The new architecture of Vue 3 also makes it very easy to adopt almost any new paradigm into Vue as evidenced by the numerous demos Evan has made to compare Vue to other JS frameworks like Svelte and Solid.
I only responded because they said they're using vanilla React which for some reason in my head instantly translated to "old version of React before it started sucking", and replied accordingly.
>But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem?
They’ll love something that loads fast and feels fast even if they’re on a cellular connection at the gas station. Such as me trying to load a gas station app to pay at the pump in a rural area and waiting forever for each step due to the size.
I started with Vue and switched to React, because of better library and TypeScript support. Every other framework pales in comparison to React due to its ecosystem, and I'm not gonna spend time building new packages to bridge that gap when I have my own work I need to get done, so I'll just use React and npm install what I need.
Back when I switched, I was looking for a good drag and drop library as well as a node based diagramming library. React Flow for the latter is best in class, and it's simply unavailable for other frameworks.
I think i'm passed splitting html, js and css into separate files.
Having logic, presentation and styling all in one spot addressable via js and jsx feels so much more ergonomic for apps of reasonable complexity.
I will say though that solidjs seems like an improvement on react though.
To me, the best part of react/jsx is that if you know HTML, and you know JavaScript, you can easily write JSX. I'm primarily a backend engineer, but I grokked JSX pretty much instantly. Anything in scope in JS is available in the JSX.
Vue templates are, well, yet another funny little template language. The hello world example already seems way too magical. Just let me use the language I already know.
Fun fact, you can use JSX with Vue and get the benefit of its built-in reactivity framework. I've done this for small prototypes and it's quite nice. My favourite part was that without .vue files, I could compile the whole app using esbuild instead of fiddling with webpack (yes yes I will try Vite one day).
Java is way way better than React (hooks) in this regard. Boring tech is good, but React is the opposite of boring tech, it innovates new way to write software, but ends up in disaster.
Have you heard of HTML, CSS and forms? They are even more boring, more mature, more stable, often faster, have a huge community, massive resources and ecosystem. React is even built on one of these technologies!
Back in 2013 there was a nifty little library that everyone, absolutely everyone ended up using called https://vanilla-js.com. They even had a size calculator depending on the features, amounting to zero bytes every time (25 bytes gzipped).
