Unpopular opinion: I prefer the function keyword for declaring functions instead of const arrow functions, I think they are easier to read whereas const arrow functions I don’t immediately recognize them as functions because they could be a normal variable until you read the right hand side of the assignment .
In my company in the style-guide we have, to always use "function" if we can - for code readability. In my experience, it greatly improves the speed of reading.
and its the convention in every other language to have anonymous/lamda functions only inside expressions and not in the global space. plus it makes your code uglier because its more noisy with all the symbols plus its longer to write than a normal function keyword no reason to use arrow functions in global space, its a bad javascript mindset.
the only advantage to writing arrow function components in React is when you're using typescript and there is a cleaner way to write interface for props
I'd recommend that anyone who hates all the cruft and bloat of react to try out SolidJS. It's really refreshing using something that doesn't feel like everything was bolted on, but rather designed from the ground up to do what react tries to do.
God I pray svelte becomes more and more mainstream in the future. using Svelte after React was like "Wait, it's this simple? why is this so complicated in React"
I AGREE 100% WITH THAT. I'm learning and people tell me to look in the documentation but they use classes in the documentation, not hooks... I hate that.
vue is the same with its options/composition apis for vue 3, and the vue 2 docs never using single file components as examples when that's how any modern front end was being built. So yeah, same shit different framework.
I've been learning react and am currently building out a full stack app, and I was wondering this almost immediately when beginning to learn. The docs are nearly useless, they've been useful to highlight specific quirks of js itself, but seeing classes everywhere when I'm using functional components has been frustrating. Thankfully I'm not braindead and know how to ask questions and extrapolate good information from answers.
The key insight of the last year for me has been that each major version of a framework is a framework by itself. Many of our jobs have devolved to constant “porting” just to keep things in place.
I've had to spend weeks on upgrading to new versions of these new frameworks, it's quite sad actually. I feel like sometimes it's a race we upgrade to the latest version and then a few months later a new major version is released and the cycle goes on. The crazy thing is this is an issue in the JS world and nowhere else
Whilst I agree with almost everything you said (including the fact that it's weird they start with the older class based approach, which may or may not be because it's mental model is less weird than hooks), just to let you know that if you are writing for enterprises there is a very good change you absolutely write for es5, especially if they're updating the browser through some shit domain policy. Function declaration vs arrow functions is also a stylistic choice (in terms of react as top level functions), and plenty of use cases remain for class based components, such as error boundaries, but also integrations with external systems. This comment is also for those who listen to this video and think "shit should I stop writing class components"... No. You're fine.
Sorry Chris, but I completely disagree with you about arrow syntax. There is nothing wrong with normal `function` keyword. I would say that in fact it's even more readable. I don't hate arrow functions, because they're cool for stuff like callbacks, but I'm mad when people say it's some kind of deprecated way of declaring functions 😅it's just simply false
as someone who JUST started react.. The fact that in the middle of my learning, the .createRoot method came out and changed everything was onfusing. Also, trying to figure out if I should learn to manually bundle my own build or just use something like vite. It just seems so daunting. Like, maybe I should just LEARN React first, then go back and try to setup webpack and rollup myself and do it all myself. But then I go down that rabbit hole and feel like I am missing the whole "CREATING" part while figure out how to deploy a working dev and productiong build! It's tough.
I'd say for a personal project just use something like vite! If you care about the project it's going to do a better job for you than you will do by yourself. It's good to learn the other stuff too, but you ABSOLUTELY can learn how to use react without learning how to setup a react project by yourself from scratch.
Thanks for making this video - somebody's gotta address this. In my personal experience, using Vite with its React plugin is an excellent replacement for CRA that's just as easy to get a project started with. The issue, of course, is that you have to be so far into this rabbit hole of frameworks and build systems to know that... Although Next.js might also be a good tool to start a new React project with, but it too basically requires that you already know what you're doing.
I started development seriously at the start of Covid, I now work at a pretty big company working on react everyday, and I have never once looked at the react docs. The webpack stuff is definitely a foot gun but beginner end up using CRA or vite or even next js because that’s what they see on RUclips I think these are all really none issues as react is still the biggest framework so people are still learning it no problem
@@Isaac-eh6uu Vue has stellar documentation! But the difference is that Vue has a "recommended" way of doing everything. From animation to statemanagement. React doesn't, it's more a thing that you can use and build on however you want since is doesn't have a lot of technical assumptions and requirements after setup. I think React can't have the same quality of docs as Vue, even if they tried to
I've been learning React since end of 2021 and not once have I even been directed to the React official documentation, that says a lot about how poor their documentation is. I would classify myself as still fairly new to React and just got the hang of things. I remember starting of 2022 when react-router-dom updated and I was still in the process of learning the basics of navigating within my app. Most tutorials and guidelines were completely outdated and I found that extremely disruptive especially while still learning the inner working of React. However, I completely agree with you don't change what isn't broken and keeping things simple is the way forward. I really love React and do hope it keeps growing and hopefully someday update their documentation.
Migrate to Vue3/Vite, or Svelte. React's not worth it that much. Also are node_modules size jokes still relevant? A similar React project weighs like 3 times more than a Vue project.
Completely agree. I learned React less than a year ago and I couldn't understand why the documentation didn't use the newest way(functional components).
Lambdas (arrow functions) are anonymous, and so they are usually calculated during runtime on the heap. This means the compilers may not be able to "inline" the calls to these lambdas. This degrades the performance of lambdas compared to normal free pure functions that have a much higher chance of inlining.
Are you sure you know what pure functions are? And lambdas don't necessarily have to be performance intensive. JS is not a properly compiled language. Compare this to something like Rust or Haskell where closures (lambdas included) are very fast. Depends on the language.
There's no difference between top level arrow function variable declaration and function keyword (other than `this` binding). Most JS engines optimize for this during JIT compilation. Even when passing it as an inline argument there's very (very!) little overhead since engines, again, optimizes for it. No need to bikeshed.
I don't think this is valid in javascript. Well, at least not in the browser environments. Maybe NodeJS runtime is behaving like this, but that wouldn't make sense to me since this is engine level and the V8 engine in the browser, where node is based on, behaves differently. But I would love to be wrong, please share your source :)
I have tried to share the reference multiple times. But RUclips removes the comments that have links. The reference included benchmarks, quotes from the developers of V8 and TypeScript, and how/when the engines try to optimize things.
When I started using typescript with react, I had a hell of time trying to figure out typing for react libraries, it just in general with react. The docs are terrible state with react website
ye i mainly just type the data moving through or generated by components. But typing React functions themselves is something I wouldn't bother doing. I own the data shapes, no the React API
The one major gripe I have with programming is that while we are expected to do things that provide good UX, UX of programming itself is broken. I remember while I started learning javascript years ago how mind boggling to me were syntax changes between ES versions. Why would you do that? What's the actual benefit of having few different ways of defining functions for e.g.? Nowadays when I parse js code it's like completely different language depending on who wrote that. Coming from networking background where API and protocol specifications were usually fore fought and engineered exactly to fit the purpose it pains me to see those decisions made seemingly on a whim. With javascript I always felt like it's written in this way: "we have this feature to implement, let's get whatever available syntax for it" instead of "we have this feature to implement, what would be the best way to implement it, so it's clear, easy to understand". I then found python and life was never the same. Migration from python2 to python3 was explicit (started learning it in the transition period). All the syntax changes were clearly laid down, sensible and easy to understand. There was a clear cutoff point for the old syntax. They say python is easy to understand as its most important feature, just like some claim that macOS is for less tech savvy people due to it being easy to understand too. Python is as capable as any other language in most usecases, macOS is as capable as any other OS (obviously), but the user friendliness is sometimes used as an argument against those, for some stupid twisted reasons. The UX is what makes them userfriendly - it's not the fact, that Python is dynamic. Types and classes don't do any impression on me since beginning of my programming (more like scripting tho - devops guy here) journey. It's that it reads like plain english if everything is named according to its role. When I see seemingly random characters with semantic meaning I die inside every time I need to get back to language I have not used for some time. (Don't even get me started on bash 😉) What you showed here has basically the same roots. It's that lack of UX focus on the tooling itself, this weird lack of technical empathy so often seen from some members of Linux Desktop community, where it's you who needs to learn ins and outs of linux, terminal, etc. for basic usage and it's not that the Linux's UX is still lacking [tho this part of community slowly dies thankfully]). When I was learning javascript I was like "nope" at some point - not because I had some technical issues with it - it was just that I couldn't believe the bs around it. It felt like working with knife and ducktype everywhere I looked and I simply left that path completely because i really despised decisions made for this language, how it's constructed and how you need to work with it. I know it's easy to say as all of this basically comes from the fact that js runs the web for ages now, so backward compatibility is necessary, but it's like the Windows all over again. Because of it's backward compatiblity with even DOS, you pay a lot with OSs stability and overall inconsistencies with how it works and looks. Obviously nothing will be done with that, but the fact that I need to restart Windows for it to work properly so often, because it has to work with some archaic software on oil drilling platforms just pains me. When MacOS for example cut support for 32bit, it was slightly painful in the beginning, but transition was almost instant for anything still running x32 and shortly forgotten - you don't get any emulation related issues like on windows with its WoW64 thanks to cleanups such as those. Too often we are too scared of such major decisions in IT and just glue whatever is we want to existing solutions without taking a step back and fixing problems for as long as they don't completely halt further progress. I really hope for JS to be replaced (pretty much impossible at this stage), or some sensible abstraction over it in the future. I won't touch webdev until that.
Apparently Dan Abranov is the only person who is allowed to write the new react docs that have been in beta for over 2 years. And he takes breaks months at a time.
Yeah I don't know what's up with that. That whole new documentation effort is just taking too long. I like Dan and I know he definitely tries to really polish docs and put a lot of useful information there, but it's just ridiculous how long it's taking at this point. Someone else was in charge of this whole docs effort but she left the company in the meantime as far as I know.
I've noticed React is having a lot of growing pains going on, such as the whole useEffect "issue" that left tons of devs completely confused & tons of other things like having to add a boatload of packages to have an app even close to production ready. The following has been extremely annoying for a Indie dev such as me that mainly focuses on sever logic. I recently decided to move away from ReactJS & have started using SolidJS & it is so much better than React. Solid has solved the state management issue that React has had for the longest time. I can't even tell you how many developers will just use React with Redux without even understanding whether they need Redux or not or whether a global store would even benefit their application. This in my option comes down to the awful documentation that the React team has put together.
@@keylanoslokj1806 Normally in React, you store state in you component, and if you had to access said state in a child component you would pass it directly from the parent. But what if you wanted to access state from a nested component? The prop drilling method would be too inefficient and hard to maintain. This is where a state management system like Redux or React Context comes in play. It will allow you to get and set these "global" states without having to pass it down. Think authentication state: any component could need to access that info so it could be used there.
vue 2 to vue 3 migration had a lot of this as well but at least It was all well documented. Vue documentation is so good in fact that you realize you don't even need it very soon after you start because you learn so fast. Vue will be my #1 framework for a long time
Hey Chris you make very solid points, which are not talked about enough. The lack of proper documentation and backwards compatibility, as well as the wrong learning approach of copy+paste. I been using React since years, while I loved it in the beginning over the years I just found more and more things that just annoy me. I would love if you would do a video about Svelte, I cannot find one on your channel so far. Just take a glimpse at it and give us your thoughts about it. Keep it up!
The front-end space is a Libertarian Utopia, absolutely free market, and no regulations. For sure there is plenty of innovation and progress, but you will never sleep well at night.
"We're doing all this stuff, it's whatever", and all that stuff is why I made a big push for us to use a pure static site generator for our company docs instead of using React. Yeah, the pages now load when you click between them, but I know that I'm not gonna come back in a year, try to upgrade, and find out that I wasn't tuned into the dev cycle well enough to not shoot myself in the foot with React. The thing that I hate about react (and making it a dependency for projects on non frontend teams) is it feels like there's a way to shoot yourself in the foot, and if you're not a seasoned FE, when it breaks, it's gone.
This was exactly my experience. I started learning React with their tic-tac-toe project with class components and got extremely frustrated because it's not even a good teaching tool. RUclips strangers are infinitely more helpful than official documentation in this case, sadly.
I definitely think it's cleaner to write your components with the function keyword. I use a snippet plugin that lets me pull in a skeleton function using the function keyword with a return statement for JSX, and export it in one go. It's clean, easy to read and makes sense. You can immediately identify props as well.
Hey Chris is there a discount for the all access bundle for people living in developing countries? I checked the price and it's really expensive for me. Wes bos has these kinds of discounts
I tried to learn react and flask the same time to see which one I understand and feel comfortable. Flask became more easy to see understand the route and render and html and css with jgnix was much better than jsx. Now react has become hell for me.
You are bikeshedding a lot. Use whatever syntax you want; React doesn't force you to write function components in a specific syntax, because in the end it doesn't matter for 99% of the time. Unless you need to forward refs, at which point when you need that you're opting into that API allowing direct DOM access to your underlying component. You don't need to know every inch of React to get started with it, just like you don't need to know every inch of JavaScript to build web applications. React also have new docs in beta. It takes a long time to write good documentation and right now there's only a handful of people who actually contribute (not just React Core team). The old documentation missed a lot of gotchas that was fairly easy to run in to once you wanted to write more complex components that did more than just rendering. These gotchas was mostly discovered afterwards due to more complex components being developed by the community; which is partially also why they changed the lifecycle API in React 16.3. The new docs tries to catch most of those gotchas and provide conventions to avoid pitfalls when working with low-level hooks like useEffect. These types of gotchas are not unique to React either. Additionally with the new React 18's Concurrent Mode, there are some more things to consider why ReactDOM changed its API. I strongly encourage you to do the research before you make presumptions that "they just change it for the sake of it"-there's a very well documented RFC in reactwg repo around the subject that I'm sure you can find. And saying that React.render is not going to work in React 18 is false. It's a _warning_ and it explains perfectly well what is going on; Your app is going to run just like React 17, not being able to take advantage of concurrent mode. That's expected if all you wanted was just to update the semantic version number with no changes to your codebase. The warning only happens during development, so that you are aware of it, but it doesn't block you or break your app.
As a bootcamp instructor it's so damn annoying to encourage students to read documentation -- until we get to React and have to make our own mock-documentation for it
I just submitted an Issue for some weird wording on the RN docs, I spent hours of looking for a solution only to realise what I wanted already existed as a prop. I skipped over the prop because the documentation implied it did something totally different to what I needed. Turns out the prop does exactly what I needed.
I think, pretty much the only reason why React is so popular, is because of its simplicity. Developers new to component-based frontend architectures can get used to it quite easily. Personally, as someone who prefers Angular in pretty much any circumstance and who had to supervise junior developers, that had to learn Angular, its nuts compared to React. Learning not only functional programming, but also reactive, getting used to RxJS syntax, learning about dependency injection and "inversion of control", the MVVM or MVC principles, NgRx if you want reliable state management in your business scale app, etc.. Let alone the very complex but oh so powerful modules system of Angular. All that is stuff that you can, more or less, omit when learning React. The learning curve of React is way way less steep. Also, why should someone new to web development learn VueJS or Svelte if React isn't much more difficult but has 100-times the exposure?
@@danieldarko6495 I absolutely think this is one of the main reasons, yes! There is not that much behind the React library itself, and you can start a new project and write your first components in mear seconds without having to worry about modules, layer separation or routing for example.
4:00 I mean nobody had to rewrite class components into functional components. React team even mentioned explicitly that class components will continue working and that it's not advised to rewrite stuff, but rather use functional components going forward. Not sure why rewrite is always mentioned in the context of hooks being introduced because it wasn't necessary to rewrite stuff for any functionality. It would only be done because developers wanted to rewrite stuff, not because it will work better or something like that. Although I do agree in general that React team should maybe take a stand and have more opinion, but I also think that allowing the community to create bunch of packages probably brought a lot of innovation into this space. As far as Create React App goes, that project should be archived and not suggested for any new projects in my opinion. It served its purpose, but we have better tools now.
Exactly. First minute of this video goes on about the beauty of backwards-compatibility, then suddenly switches gears and ignores the same effort in React. I have projects from 2015 that still run fine today and if I want I can use hooks in them with no problems at all. And if I use hooks, I'm not hurt by understanding what is happening with the lifecycle under the hood.
I feel you on the ineffectiveness of programming tutorials. I still can't get the results of an SQL query sent to the client in NodeJS with mssql2 no matter how many tutorials I watch. And none of the tutors are responding to comments asking for clarification. It's really frustrating.
I've mostly seen function keyword components over arrow syntax. For me, arrow syntax has a specific use, that is to refer to `this` in the current context in which it was defined, thus solving the old school `var self = this` workaround. There's a bunch of other differences as well to be sure. They can make a good shorthand, one-liner function since they return implicitly. But in the case of components I see no reason to prefer them over function keyword. As for the class documentation, it is very curious React has not updated their docs. The class syntax already feels like an endangered species. I actually liked it and think it has several benefits over hooks but can see why most people think hooks is the way forward and I'm okay with that overall. But completely agree, having two totally different ways of writing components sucks. There's a whole generation of devs that never learned the Class syntax and will potentially get a job in some enterprise React setting that still uses classes and feel completely in the dark.
Hi Chris, just started learning React 3 days ago and the most annoying thing is after you install React using npm and after I go to VS-CODE and click on the tab of VSCODE to save my file. All the files like App.js and anything with a js file gets all screwed up. All the files that which have a break apart after you click the save option on VSCODE. Why is that? the tag will end up looking something like: < div/ > It ends up looking this way for all the js files. Very confusing? Have you seen anything like this? Anyways I am googling and looking for resources to figure this shit out, very frustrating, thank you.
Just don't use CRA - everyone I know avoids CRA like the plague. Just use Vite to bootstrap your react app, or if you plan to use some framework for SSR like next or remix, just use their respective bootstrapping packages.
hi, i agree with majority what you said. Vue did same thing with composition api and related libs and tools, at least the docs are updated and better than react, vue is also for now keeping options api, which for new dev is kind of confusing to choose between ways like in react between class and fn for state. About arrow fn, that is more like dev experience like you do with exports, should you put at the end as default or inline, should you even use default or named expor? About react docs, they mention on their blog, on react lab post, that they are working on new docs. What i see, they only use function way, no class, may be you can do a video about it. I dont know why they did not release it with react 18. About CRA, are you still using it? why ? why not try react with vite for new projects? i see, you have, not watched, two videos about leaving react, advice: try SolidJS and later on astroJS
It's always your choice to update. Just because a npm package you're using has a newer version doesn't automatically make your project start using that newer version.
@@AA-Crow Not typically. Like instances where that's the case, and instances where upgrading a package would require some significant refactor are very very rare.
Agreed! Go Vanilla, that's the true modern framework. The only thing that could kill vanilla at this point is browser monopolys, so we need more clever people thinking on actual JavaScript, instead of wasting their minds learning the 20 ways of doing the same thing in a framework that under the control of a few lads that probably laugh every time they find a critical bug...
this is a good video, ive had my gripes with react that i didnt have with vue and the fact that is almost the industry standard is getting on my nerves. i only ever read react docs when i know the codebase is stuck in react 16 other wise its completely useless. i feel like instead of beating around the bush and sugarcoating javascript with new frameworks and configs we either need to fix javascript at its core or get completely rid of it.
Completely agree about documentation being out of date (although there is a *still* beta version for hooks/functions. Btw I've just started a side project using vanilla react (I'm a SharePoint guy making custom webparts using the SPFX toolchain) and getting to grips with Webhooks - wow what a fking mess as you said, SPFX is a piece of cake compared to this shite
this was the reason i picked angular as my 2nd language after vue ...react had multiple ways to write the same thing and the tutuorials we see sometime use hook sometime class and sometime some are written in typescript .. these all had me confused . i would rather follow a standard approach of angular which everyone is forced to follow , this makes us all dev in team to be on same page.
They working on it. They are 80% done, I think. Maybe they should have advertised it on their current doc. Because only those who follow react that much would no it
2:30 I don't agree with arrow fuctions being the tried and true way of defining a functional component. There's no reason true as far as I know. (especially since the react team is now discouraging the use of React.FC to type your component) Maybe you could explain why you disagree with this? Thanks!
imo functions explicitly declared with the `function` keyword are just easier and clearer to read. especially when you're just skimming through code. seeing "const Comp = () => {}; export default Comp;" everywhere is kind of an eyesore.
@@TheyCallMeIce definitely, I also partly disagree with the second part of your comments. But that also proved my point, there’s no industry standard because opinion is the only part differentiating it (when used to declare React component that is)
I have been writing Angular exclusively for the past two plus years until about 2 months ago when I converted a Gatsby 2 site to 4 and then created a Next.js personal project and this very thing in the documentation got me frustrated. I didn’t see functional components, knew about hooks but they weren’t being used and couldn’t find anything about typescript and giving props types anywhere… very frustrating.
The same way I have no idea why this garbage "library" gained any traction at all. It's scattered all over the place and the code is just a spaghetti mess and each file has an import hell on top where everything is so segregated that you can't even track nothing anymore. Like the whole Ecosystem of react is just fixing things that shouldn't be a problem in the first place. For the sake of yourself and other - Please use Vue or switch to Svelte.
When nanoid updated to version 4, it broke all our tests because they dropped support for commonjs. I also got hit with react18 must use version 6 of react-router.
can someone help me to a get job? is kinda impossible, companies want to me to have a least 2 years of experience, but... how to gain experience without a job?
I almost feel like it's too far gone at this point to turn back from so many companies using react. Popularity doesn't mean it's always the best and if they can't even get their docs right that is pretty lame
Yeah the official documentation isn't the best -- but they're many other sources available on the web to learn React. I don't get why people complain about React and it's ecosystem and what it's become. On RUclips it's like the flavour of the year to complain about React. I propose a simple solution and that is to use something else and not to use CRA if your working with React. I only say this because if you don't like it, don't use it. If you have to use it, propose a better solution.
I got burned out of Web Development when all these JS libraries and Frameworks started to update like crazy and break compatibility, I was having to relearn everything basically every month, I was just going nuts, so I quit Web Development for good. After 20 years of career. >_
Does anbody know why react was created? What was it meant to solve? I think I'd prefer to write in plain html/js. I agree with perl being a 'write only' language , I'd hate to have to look at my perl code from the 90's. No way.
Next.js is way better than React. I mean to be fair it runs off of React but I think it's a far better platform for making React App. I think the only thing I don't like about it is wants you to use CSS Modules out of the box. I prefer vanilla CSS. I ended up just switching over to SASS
I agree that the React docs are awful. The beta docs are way better but they cover way less ground. That being said once you learn how to use React, it's alright.
Improving the documentation is literally the best way to begin to get involved in an open source project.
Unpopular opinion: I prefer the function keyword for declaring functions instead of const arrow functions, I think they are easier to read whereas const arrow functions I don’t immediately recognize them as functions because they could be a normal variable until you read the right hand side of the assignment .
In my company in the style-guide we have, to always use "function" if we can - for code readability. In my experience, it greatly improves the speed of reading.
and its the convention in every other language to have anonymous/lamda functions only inside expressions and not in the global space.
plus it makes your code uglier because its more noisy with all the symbols
plus its longer to write than a normal function keyword
no reason to use arrow functions in global space, its a bad javascript mindset.
the only advantage to writing arrow function components in React is when you're using typescript and there is a cleaner way to write interface for props
function creates its own "this." => used parent this.
@@alb12345672 and u shouldnt use the parents this in global space
I'd recommend that anyone who hates all the cruft and bloat of react to try out SolidJS. It's really refreshing using something that doesn't feel like everything was bolted on, but rather designed from the ground up to do what react tries to do.
Also, try out svelte if you're willing to try out a new, more terse syntax.
@@FinaISpartan i like svelte
God I pray svelte becomes more and more mainstream in the future. using Svelte after React was like "Wait, it's this simple? why is this so complicated in React"
@@unorthodox1430 Vue have been that way for long too. Especially Vue 3
@@unorthodox1430 I second that. God I love Svelte
I AGREE 100% WITH THAT. I'm learning and people tell me to look in the documentation but they use classes in the documentation, not hooks... I hate that.
Lmao true 💯
Very true
vue is the same with its options/composition apis for vue 3, and the vue 2 docs never using single file components as examples when that's how any modern front end was being built. So yeah, same shit different framework.
I've been learning react and am currently building out a full stack app, and I was wondering this almost immediately when beginning to learn. The docs are nearly useless, they've been useful to highlight specific quirks of js itself, but seeing classes everywhere when I'm using functional components has been frustrating. Thankfully I'm not braindead and know how to ask questions and extrapolate good information from answers.
are u going to get paid doing that?
@@pepi8433 It's my own project, so hopefully!
The key insight of the last year for me has been that each major version of a framework is a framework by itself. Many of our jobs have devolved to constant “porting” just to keep things in place.
I've had to spend weeks on upgrading to new versions of these new frameworks, it's quite sad actually. I feel like sometimes it's a race we upgrade to the latest version and then a few months later a new major version is released and the cycle goes on. The crazy thing is this is an issue in the JS world and nowhere else
Svelte baby! And if you want TS, just use the derive-type library. Effortless TypeScript annotation for JavaScript 🎉
Whilst I agree with almost everything you said (including the fact that it's weird they start with the older class based approach, which may or may not be because it's mental model is less weird than hooks), just to let you know that if you are writing for enterprises there is a very good change you absolutely write for es5, especially if they're updating the browser through some shit domain policy.
Function declaration vs arrow functions is also a stylistic choice (in terms of react as top level functions), and plenty of use cases remain for class based components, such as error boundaries, but also integrations with external systems.
This comment is also for those who listen to this video and think "shit should I stop writing class components"... No. You're fine.
Sorry Chris, but I completely disagree with you about arrow syntax. There is nothing wrong with normal `function` keyword. I would say that in fact it's even more readable. I don't hate arrow functions, because they're cool for stuff like callbacks, but I'm mad when people say it's some kind of deprecated way of declaring functions 😅it's just simply false
I agree 100% with you, I don't see any issue with the use of "function" keyword to declare a new component
as someone who JUST started react.. The fact that in the middle of my learning, the .createRoot method came out and changed everything was onfusing. Also, trying to figure out if I should learn to manually bundle my own build or just use something like vite. It just seems so daunting. Like, maybe I should just LEARN React first, then go back and try to setup webpack and rollup myself and do it all myself. But then I go down that rabbit hole and feel like I am missing the whole "CREATING" part while figure out how to deploy a working dev and productiong build! It's tough.
I'd say for a personal project just use something like vite! If you care about the project it's going to do a better job for you than you will do by yourself. It's good to learn the other stuff too, but you ABSOLUTELY can learn how to use react without learning how to setup a react project by yourself from scratch.
That's why it's a high paying position in most countries haha. I think I do prefer it this way overall
Thanks for making this video - somebody's gotta address this.
In my personal experience, using Vite with its React plugin is an excellent replacement for CRA that's just as easy to get a project started with.
The issue, of course, is that you have to be so far into this rabbit hole of frameworks and build systems to know that... Although Next.js might also be a good tool to start a new React project with, but it too basically requires that you already know what you're doing.
Honestly I think that in the case of components actually using the function keyword is better.
I started development seriously at the start of Covid, I now work at a pretty big company working on react everyday, and I have never once looked at the react docs. The webpack stuff is definitely a foot gun but beginner end up using CRA or vite or even next js because that’s what they see on RUclips
I think these are all really none issues as react is still the biggest framework so people are still learning it no problem
If only React could have documentation like Vue 😅
@@Isaac-eh6uu Vue has stellar documentation! But the difference is that Vue has a "recommended" way of doing everything. From animation to statemanagement. React doesn't, it's more a thing that you can use and build on however you want since is doesn't have a lot of technical assumptions and requirements after setup. I think React can't have the same quality of docs as Vue, even if they tried to
I've been learning React since end of 2021 and not once have I even been directed to the React official documentation, that says a lot about how poor their documentation is. I would classify myself as still fairly new to React and just got the hang of things. I remember starting of 2022 when react-router-dom updated and I was still in the process of learning the basics of navigating within my app. Most tutorials and guidelines were completely outdated and I found that extremely disruptive especially while still learning the inner working of React. However, I completely agree with you don't change what isn't broken and keeping things simple is the way forward. I really love React and do hope it keeps growing and hopefully someday update their documentation.
Migrate to Vue3/Vite, or Svelte. React's not worth it that much. Also are node_modules size jokes still relevant? A similar React project weighs like 3 times more than a Vue project.
since Hooks are so easy and powerful, React team decided to protect our job by making learning react from official documentation really hard :D
Completely agree. I learned React less than a year ago and I couldn't understand why the documentation didn't use the newest way(functional components).
Lambdas (arrow functions) are anonymous, and so they are usually calculated during runtime on the heap. This means the compilers may not be able to "inline" the calls to these lambdas. This degrades the performance of lambdas compared to normal free pure functions that have a much higher chance of inlining.
Are you sure you know what pure functions are? And lambdas don't necessarily have to be performance intensive. JS is not a properly compiled language. Compare this to something like Rust or Haskell where closures (lambdas included) are very fast. Depends on the language.
Shaving bits like that in JS of all languages seems absurd. I doubt JS engines, specially JITs don't optimize for that
There's no difference between top level arrow function variable declaration and function keyword (other than `this` binding). Most JS engines optimize for this during JIT compilation. Even when passing it as an inline argument there's very (very!) little overhead since engines, again, optimizes for it. No need to bikeshed.
I don't think this is valid in javascript. Well, at least not in the browser environments. Maybe NodeJS runtime is behaving like this, but that wouldn't make sense to me since this is engine level and the V8 engine in the browser, where node is based on, behaves differently. But I would love to be wrong, please share your source :)
I have tried to share the reference multiple times. But RUclips removes the comments that have links. The reference included benchmarks, quotes from the developers of V8 and TypeScript, and how/when the engines try to optimize things.
When I started using typescript with react, I had a hell of time trying to figure out typing for react libraries, it just in general with react. The docs are terrible state with react website
ye i mainly just type the data moving through or generated by components. But typing React functions themselves is something I wouldn't bother doing. I own the data shapes, no the React API
The one major gripe I have with programming is that while we are expected to do things that provide good UX, UX of programming itself is broken. I remember while I started learning javascript years ago how mind boggling to me were syntax changes between ES versions. Why would you do that? What's the actual benefit of having few different ways of defining functions for e.g.?
Nowadays when I parse js code it's like completely different language depending on who wrote that. Coming from networking background where API and protocol specifications were usually fore fought and engineered exactly to fit the purpose it pains me to see those decisions made seemingly on a whim. With javascript I always felt like it's written in this way: "we have this feature to implement, let's get whatever available syntax for it" instead of "we have this feature to implement, what would be the best way to implement it, so it's clear, easy to understand".
I then found python and life was never the same. Migration from python2 to python3 was explicit (started learning it in the transition period). All the syntax changes were clearly laid down, sensible and easy to understand. There was a clear cutoff point for the old syntax. They say python is easy to understand as its most important feature, just like some claim that macOS is for less tech savvy people due to it being easy to understand too. Python is as capable as any other language in most usecases, macOS is as capable as any other OS (obviously), but the user friendliness is sometimes used as an argument against those, for some stupid twisted reasons. The UX is what makes them userfriendly - it's not the fact, that Python is dynamic. Types and classes don't do any impression on me since beginning of my programming (more like scripting tho - devops guy here) journey. It's that it reads like plain english if everything is named according to its role. When I see seemingly random characters with semantic meaning I die inside every time I need to get back to language I have not used for some time. (Don't even get me started on bash 😉)
What you showed here has basically the same roots. It's that lack of UX focus on the tooling itself, this weird lack of technical empathy so often seen from some members of Linux Desktop community, where it's you who needs to learn ins and outs of linux, terminal, etc. for basic usage and it's not that the Linux's UX is still lacking [tho this part of community slowly dies thankfully]). When I was learning javascript I was like "nope" at some point - not because I had some technical issues with it - it was just that I couldn't believe the bs around it. It felt like working with knife and ducktype everywhere I looked and I simply left that path completely because i really despised decisions made for this language, how it's constructed and how you need to work with it.
I know it's easy to say as all of this basically comes from the fact that js runs the web for ages now, so backward compatibility is necessary, but it's like the Windows all over again. Because of it's backward compatiblity with even DOS, you pay a lot with OSs stability and overall inconsistencies with how it works and looks. Obviously nothing will be done with that, but the fact that I need to restart Windows for it to work properly so often, because it has to work with some archaic software on oil drilling platforms just pains me. When MacOS for example cut support for 32bit, it was slightly painful in the beginning, but transition was almost instant for anything still running x32 and shortly forgotten - you don't get any emulation related issues like on windows with its WoW64 thanks to cleanups such as those. Too often we are too scared of such major decisions in IT and just glue whatever is we want to existing solutions without taking a step back and fixing problems for as long as they don't completely halt further progress.
I really hope for JS to be replaced (pretty much impossible at this stage), or some sensible abstraction over it in the future. I won't touch webdev until that.
Just use Svelte bro
Won’t touch webdev till that… lmao
any opinion stated on the internet more than 10 lines is something retarded, so skipped reading this
Bro wrote whole book
A great book
Apparently Dan Abranov is the only person who is allowed to write the new react docs that have been in beta for over 2 years. And he takes breaks months at a time.
That’s actually quite dumb. Why would he be the only one allowed?
@@ogreeni
Coz he created it..
Yeah I don't know what's up with that. That whole new documentation effort is just taking too long. I like Dan and I know he definitely tries to really polish docs and put a lot of useful information there, but it's just ridiculous how long it's taking at this point. Someone else was in charge of this whole docs effort but she left the company in the meantime as far as I know.
@@girirajrdx7277 still doesn’t mean he has to be the only one allowed to ever touch the docs.
Source?
As someone who uses React, I'm surprised no one has talked about the docs sooner. I found them to be complete crap.
It is not just react and react-dom docs every doc in the react family is crap.
Thanks for sharing your experience. You make some really GOOD points!
I've noticed React is having a lot of growing pains going on, such as the whole useEffect "issue" that left tons of devs completely confused & tons of other things like having to add a boatload of packages to have an app even close to production ready. The following has been extremely annoying for a Indie dev such as me that mainly focuses on sever logic.
I recently decided to move away from ReactJS & have started using SolidJS & it is so much better than React. Solid has solved the state management issue that React has had for the longest time. I can't even tell you how many developers will just use React with Redux without even understanding whether they need Redux or not or whether a global store would even benefit their application. This in my option comes down to the awful documentation that the React team has put together.
still need it for a job,
@@pepi8433 Will React for food. Unfortunately
What's state management
@@keylanoslokj1806 Normally in React, you store state in you component, and if you had to access said state in a child component you would pass it directly from the parent. But what if you wanted to access state from a nested component? The prop drilling method would be too inefficient and hard to maintain. This is where a state management system like Redux or React Context comes in play. It will allow you to get and set these "global" states without having to pass it down. Think authentication state: any component could need to access that info so it could be used there.
@@pepi8433 Lmao... people still prefer Angular for enterprise application. So technically you can get a job
I also hate CRA, for the same reasons. What kind of bs is react scripts, it always ends up with eject
vue 2 to vue 3 migration had a lot of this as well but at least It was all well documented. Vue documentation is so good in fact that you realize you don't even need it very soon after you start because you learn so fast. Vue will be my #1 framework for a long time
Hey Chris you make very solid points, which are not talked about enough.
The lack of proper documentation and backwards compatibility, as well as the wrong learning approach of copy+paste.
I been using React since years, while I loved it in the beginning over the years I just found more and more things that just annoy me.
I would love if you would do a video about Svelte, I cannot find one on your channel so far.
Just take a glimpse at it and give us your thoughts about it.
Keep it up!
The front-end space is a Libertarian Utopia, absolutely free market, and no regulations. For sure there is plenty of innovation and progress, but you will never sleep well at night.
"We're doing all this stuff, it's whatever", and all that stuff is why I made a big push for us to use a pure static site generator for our company docs instead of using React. Yeah, the pages now load when you click between them, but I know that I'm not gonna come back in a year, try to upgrade, and find out that I wasn't tuned into the dev cycle well enough to not shoot myself in the foot with React.
The thing that I hate about react (and making it a dependency for projects on non frontend teams) is it feels like there's a way to shoot yourself in the foot, and if you're not a seasoned FE, when it breaks, it's gone.
This was exactly my experience. I started learning React with their tic-tac-toe project with class components and got extremely frustrated because it's not even a good teaching tool.
RUclips strangers are infinitely more helpful than official documentation in this case, sadly.
I definitely think it's cleaner to write your components with the function keyword. I use a snippet plugin that lets me pull in a skeleton function using the function keyword with a return statement for JSX, and export it in one go. It's clean, easy to read and makes sense. You can immediately identify props as well.
Hey Chris is there a discount for the all access bundle for people living in developing countries? I checked the price and it's really expensive for me. Wes bos has these kinds of discounts
Fun fact, if its built with JavaScript, and you know JavaScript, you can just do it yourself, no library or dependencies needed
I tried to learn react and flask the same time to see which one I understand and feel comfortable. Flask became more easy to see understand the route and render and html and css with jgnix was much better than jsx. Now react has become hell for me.
You are bikeshedding a lot. Use whatever syntax you want; React doesn't force you to write function components in a specific syntax, because in the end it doesn't matter for 99% of the time. Unless you need to forward refs, at which point when you need that you're opting into that API allowing direct DOM access to your underlying component. You don't need to know every inch of React to get started with it, just like you don't need to know every inch of JavaScript to build web applications.
React also have new docs in beta. It takes a long time to write good documentation and right now there's only a handful of people who actually contribute (not just React Core team). The old documentation missed a lot of gotchas that was fairly easy to run in to once you wanted to write more complex components that did more than just rendering. These gotchas was mostly discovered afterwards due to more complex components being developed by the community; which is partially also why they changed the lifecycle API in React 16.3. The new docs tries to catch most of those gotchas and provide conventions to avoid pitfalls when working with low-level hooks like useEffect. These types of gotchas are not unique to React either.
Additionally with the new React 18's Concurrent Mode, there are some more things to consider why ReactDOM changed its API. I strongly encourage you to do the research before you make presumptions that "they just change it for the sake of it"-there's a very well documented RFC in reactwg repo around the subject that I'm sure you can find.
And saying that React.render is not going to work in React 18 is false. It's a _warning_ and it explains perfectly well what is going on; Your app is going to run just like React 17, not being able to take advantage of concurrent mode. That's expected if all you wanted was just to update the semantic version number with no changes to your codebase. The warning only happens during development, so that you are aware of it, but it doesn't block you or break your app.
As a bootcamp instructor it's so damn annoying to encourage students to read documentation -- until we get to React and have to make our own mock-documentation for it
Please share you bootcamp videos 🙏
I am from Third world country trying to improve my life
I decided to stop frontend dev and now I'm writing x86 assembly to build my hobby OS. It's amazing that assembly codes for i386 work on latest Ryzen.
Like the idea of React, but hate that it's a heaping pile of garbage? Try Solid!!
I just submitted an Issue for some weird wording on the RN docs, I spent hours of looking for a solution only to realise what I wanted already existed as a prop. I skipped over the prop because the documentation implied it did something totally different to what I needed. Turns out the prop does exactly what I needed.
Thank you so much!
I think, pretty much the only reason why React is so popular, is because of its simplicity. Developers new to component-based frontend architectures can get used to it quite easily. Personally, as someone who prefers Angular in pretty much any circumstance and who had to supervise junior developers, that had to learn Angular, its nuts compared to React. Learning not only functional programming, but also reactive, getting used to RxJS syntax, learning about dependency injection and "inversion of control", the MVVM or MVC principles, NgRx if you want reliable state management in your business scale app, etc.. Let alone the very complex but oh so powerful modules system of Angular.
All that is stuff that you can, more or less, omit when learning React. The learning curve of React is way way less steep. Also, why should someone new to web development learn VueJS or Svelte if React isn't much more difficult but has 100-times the exposure?
you think it's because of simplicity ?
@@danieldarko6495 I absolutely think this is one of the main reasons, yes! There is not that much behind the React library itself, and you can start a new project and write your first components in mear seconds without having to worry about modules, layer separation or routing for example.
4:00 I mean nobody had to rewrite class components into functional components. React team even mentioned explicitly that class components will continue working and that it's not advised to rewrite stuff, but rather use functional components going forward. Not sure why rewrite is always mentioned in the context of hooks being introduced because it wasn't necessary to rewrite stuff for any functionality. It would only be done because developers wanted to rewrite stuff, not because it will work better or something like that.
Although I do agree in general that React team should maybe take a stand and have more opinion, but I also think that allowing the community to create bunch of packages probably brought a lot of innovation into this space.
As far as Create React App goes, that project should be archived and not suggested for any new projects in my opinion. It served its purpose, but we have better tools now.
Any particular alternative project generating tool(s) you think is strictly better?
Exactly. First minute of this video goes on about the beauty of backwards-compatibility, then suddenly switches gears and ignores the same effort in React. I have projects from 2015 that still run fine today and if I want I can use hooks in them with no problems at all. And if I use hooks, I'm not hurt by understanding what is happening with the lifecycle under the hood.
Those perl one liners were nuts lol.
I feel you on the ineffectiveness of programming tutorials.
I still can't get the results of an SQL query sent to the client in NodeJS with mssql2 no matter how many tutorials I watch. And none of the tutors are responding to comments asking for clarification. It's really frustrating.
Man, how's that going? Don't give up, maybe there's a small misunderstanding somewhere
I've mostly seen function keyword components over arrow syntax. For me, arrow syntax has a specific use, that is to refer to `this` in the current context in which it was defined, thus solving the old school `var self = this` workaround. There's a bunch of other differences as well to be sure. They can make a good shorthand, one-liner function since they return implicitly. But in the case of components I see no reason to prefer them over function keyword.
As for the class documentation, it is very curious React has not updated their docs. The class syntax already feels like an endangered species. I actually liked it and think it has several benefits over hooks but can see why most people think hooks is the way forward and I'm okay with that overall. But completely agree, having two totally different ways of writing components sucks. There's a whole generation of devs that never learned the Class syntax and will potentially get a job in some enterprise React setting that still uses classes and feel completely in the dark.
I like the carbon approach, make breaking changes but provide tool assisted upgrades
So true. God I hate when big companies don’t even give the time of day to update the most basic documentation. So tough for beginners.
A $430 billion dollar company and it’s taking them years to update their docs.
lazy maybe
Hi Chris, just started learning React 3 days ago and the most annoying thing is after you install React using npm and after I go to VS-CODE and click on the tab of VSCODE to save my file. All the files like App.js and anything with a js file gets all screwed up. All the files that which have a break apart after you click the save option on VSCODE. Why is that? the tag will end up looking something like:
<
div/ >
It ends up looking this way for all the js files. Very confusing? Have you seen anything like this? Anyways I am googling and looking for resources to figure this shit out, very frustrating, thank you.
just turn off on save in your editor with this option: "editor.formatOnSave": false
@@nububu Great thank you! popsky19, I was ripping my hair off trying to figure this out. I will try this out now, thanks.
Its amazing how ugly and stupid react was just a couple of years ago, and even so, it was amazing compared to the options we had.
Just don't use CRA - everyone I know avoids CRA like the plague. Just use Vite to bootstrap your react app, or if you plan to use some framework for SSR like next or remix, just use their respective bootstrapping packages.
hi, i agree with majority what you said.
Vue did same thing with composition api and related libs and tools, at least the docs are updated and better than react, vue is also for now keeping options api, which for new dev is kind of confusing to choose between ways like in react between class and fn for state.
About arrow fn, that is more like dev experience like you do with exports, should you put at the end as default or inline, should you even use default or named expor?
About react docs, they mention on their blog, on react lab post, that they are working on new docs. What i see, they only use function way, no class, may be you can do a video about it. I dont know why they did not release it with react 18.
About CRA, are you still using it? why ? why not try react with vite for new projects?
i see, you have, not watched, two videos about leaving react, advice: try SolidJS and later on astroJS
Coming from angular and nuxt. React docs have been throwing me in loops for sure.
48hrs in, found beta docs. Slightly less triggered now.
Dude: If you go through the tutorial, it _starts_ with class based components, and _ends up_ with functional components. It shows the refactoring.
How can people work like this when one package or update breaks everything?
It's always your choice to update. Just because a npm package you're using has a newer version doesn't automatically make your project start using that newer version.
@@sigmachadgigamale Sometimes you have no choice as it's for security reasons or you need to used the latest version
@@AA-Crow Not typically. Like instances where that's the case, and instances where upgrading a package would require some significant refactor are very very rare.
Agreed! Go Vanilla, that's the true modern framework. The only thing that could kill vanilla at this point is browser monopolys, so we need more clever people thinking on actual JavaScript, instead of wasting their minds learning the 20 ways of doing the same thing in a framework that under the control of a few lads that probably laugh every time they find a critical bug...
this is a good video, ive had my gripes with react that i didnt have with vue and the fact that is almost the industry standard is getting on my nerves. i only ever read react docs when i know the codebase is stuck in react 16 other wise its completely useless. i feel like instead of beating around the bush and sugarcoating javascript with new frameworks and configs we either need to fix javascript at its core or get completely rid of it.
Completely agree about documentation being out of date (although there is a *still* beta version for hooks/functions.
Btw I've just started a side project using vanilla react (I'm a SharePoint guy making custom webparts using the SPFX toolchain) and getting to grips with Webhooks - wow what a fking mess as you said, SPFX is a piece of cake compared to this shite
Vue has similar problems. I'm glad I learned it originally in 2017. It was much easier back then.
this was the reason i picked angular as my 2nd language after vue ...react had multiple ways to write the same thing and the tutuorials we see sometime use hook sometime class and sometime some are written in typescript .. these all had me confused . i would rather follow a standard approach of angular which everyone is forced to follow , this makes us all dev in team to be on same page.
They working on it. They are 80% done, I think. Maybe they should have advertised it on their current doc. Because only those who follow react that much would no it
Great video! I'm using react as my main framework but I agree with all you said. Whats your favorite & well documented framework these days?
Totally agree!!! Please update your docs React!
Examples on stackoverflow also are outdated in class way.. just frustrating
2:30 I don't agree with arrow fuctions being the tried and true way of defining a functional component. There's no reason true as far as I know. (especially since the react team is now discouraging the use of React.FC to type your component) Maybe you could explain why you disagree with this? Thanks!
imo functions explicitly declared with the `function` keyword are just easier and clearer to read. especially when you're just skimming through code. seeing "const Comp = () => {}; export default Comp;" everywhere is kind of an eyesore.
@@TheyCallMeIce definitely, I also partly disagree with the second part of your comments. But that also proved my point, there’s no industry standard because opinion is the only part differentiating it (when used to declare React component that is)
What is wrong with function keyword ?? . Arrow syntax has a different purpose. Don’t mix them
I prefer svelte thank you. I have always been puzzled why so many people use react.
I have been writing Angular exclusively for the past two plus years until about 2 months ago when I converted a Gatsby 2 site to 4 and then created a Next.js personal project and this very thing in the documentation got me frustrated. I didn’t see functional components, knew about hooks but they weren’t being used and couldn’t find anything about typescript and giving props types anywhere… very frustrating.
If you only need to target modern browsers and use vite instead of webpack you can save some overhead config imo
The same way I have no idea why this garbage "library" gained any traction at all.
It's scattered all over the place and the code is just a spaghetti mess and each file has an import hell on top where everything is so segregated that you can't even track nothing anymore.
Like the whole Ecosystem of react is just fixing things that shouldn't be a problem in the first place.
For the sake of yourself and other - Please use Vue or switch to Svelte.
I thought react was going to update their documentation soon
This video needs more up votes.
having a textcases makes the codebase upgrade easier, that what i believe
Facebook sucks at documentation
I tried using their Graph API, so many things are deprecated but the docs imply 👌
Svelte is the future. React is now bloated and too complex, naturally what comes with 10 years - legacy tech
When nanoid updated to version 4, it broke all our tests because they dropped support for commonjs.
I also got hit with react18 must use version 6 of react-router.
This is the business dude. You have to be in the loop...
can someone help me to a get job? is kinda impossible, companies want to me to have a least 2 years of experience, but... how to gain experience without a job?
I would not advice react for a beginner. Angular is better for beginners.
Chris why are you not using vite?
I almost feel like it's too far gone at this point to turn back from so many companies using react. Popularity doesn't mean it's always the best and if they can't even get their docs right that is pretty lame
i got rejected from an internship interview cuz i’ve used class based components. i started with docs 😿
The docs have been like this for at least 2 years
Why not use arrow functions everywhere? One simple answer - the benefits of hoisting
I noticed this months ago and it pissed me off. I literally can't learn how to use YOUR product properly from you.......the creator.
How about vite I heard there is a vite react plugin that removes all of that headache webpack brings
I just learned of React Beta docs, its alot easier to read.
Yeah the official documentation isn't the best -- but they're many other sources available on the web to learn React. I don't get why people complain about React and it's ecosystem and what it's become. On RUclips it's like the flavour of the year to complain about React. I propose a simple solution and that is to use something else and not to use CRA if your working with React. I only say this because if you don't like it, don't use it. If you have to use it, propose a better solution.
I got burned out of Web Development when all these JS libraries and Frameworks started to update like crazy and break compatibility, I was having to relearn everything basically every month, I was just going nuts, so I quit Web Development for good. After 20 years of career. >_
As far as I know react team made an announcement about it and they must be updating the documentation
Does anbody know why react was created? What was it meant to solve? I think I'd prefer to write in plain html/js. I agree with perl being a 'write only' language , I'd hate to have to look at my perl code from the 90's. No way.
I refuse nodejs and projects that has nodejs dependencies.
Next.js is way better than React. I mean to be fair it runs off of React but I think it's a far better platform for making React App. I think the only thing I don't like about it is wants you to use CSS Modules out of the box. I prefer vanilla CSS. I ended up just switching over to SASS
It's an internal tool!
I agree that the React docs are awful. The beta docs are way better but they cover way less ground. That being said once you learn how to use React, it's alright.
A very good observation Chris!
They are doing new docs from end of 2020 and its still beta 😑
Agree 💯
Unpopular opinion: I like HTML better
I NEVER used official react docs, like wtf am I going to do with classes ?? I'd rather functional component.
I am not a huge fan of React 18. The version of React 17 that was out before 18 dropped was my favorite version of React.