7 ms·
I feel like there are 2 Reacts (at least 2 that I know of, if not more). I learned jQuery long ago, then how to get most of what I wanted done via document.que
by MuffinFlavored 3y ago
I feel like there are 2 Reacts (at least 2 that I know of, if not more).
I learned jQuery long ago, then how to get most of what I wanted done via document.querySelector/etc instead since it was more "lightweight", then I learned React "class components" with render() and componentWillMount() and it was a big leap forward.
The "major breaking changes" (semantic versioning wise) to move components to functions (instead of implying it's just a class with render()) and then hooks on top, it almost invalidates most of what I learned about React initially. Which is fine. The community reserves the right to grow however they want. I was just surprised when I recently revisited it. The only common concept was basically JSX and "view/render state/props + actions on events".
I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. It would help. Saying "I know React/I have React experience" is basically in need of nuance like "I have React in 2018 experience, and 0 React in 2023 experience, therefore I don't actively/actually know current React best practices or how to even do a small TODO hello world list example".
- shams93 3y agoThis is a kind of career violence intentional radical constant change such that experience doesn't matter maybe those of us pushed out of industry over react should hit meta with a lawsuit.
- SketchySeaBeast 3y agoI can't tell - is this satire? Good faithing it - this could only be (partially) valid if the old ways didn't work, which they still do. If you've been pushed out, you haven't been pushed out of the industry because of the change.
- baron816 3y ago> I was just surprised when I recently revisited it. You can STILL write React like you used to (with class components). There haven’t been any major breaking changes. The transition was very slow. It was only recently that they even changed the docs. You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was.
- pier25 3y ago> You’re complaining that they made changes to it half its lifetime ago after you walked away from it and now you can’t just go back to the way it was. Wouldn't you expect jQuery to keep using the same fundamental methodology a couple of years later?
- bobthepanda 3y agoI mean, Java was the stereotype of boring enterprise language, and has certainly changed a lot in the last ten years in terms of its shift towards functional-friendly programming.
- pier25 3y agoHow is this even comparable? Not only React changed completely almost overnight, but the changes in the methodology were fundamental.
- baron816 3y agoThis is just blatantly untrue. The changes were definitely not overnight. Not even close. You’re still free to write React in the old way. The docs were there for half a decade. If they had just made a different project, we’d still be talking about the same thing. You would still be complaining that things changed and you didn’t feel like bothering to learn a new thing.
- bobthepanda 3y agoSo are the Java 8 changes? Java lambda functions, streams and futures look nothing at all like traditional Java methods and threads, yet you're still free to write them, but nearly every Java Stack Overflow question has a dedicated Java 8+ answer because it is so different.
- bcrosby95 3y agoNote that Java futures are from 2004. By the time Java 8 rolled around they definitely were "traditional". But lambdas and everything coming in project amber, yeah, there will increasingly be many styles of Java out there.
- butterfi 3y agoThis is such a common problem these days. I have almost 15 years of experience with another framework, but the latest iteration is almost a complete re-write and most of what I knew in the past isn't that helpful. To say I have "x" years of experience doesn't really acknowledge my current level of understanding.
- Capricorn2481 3y agoThere are no breaking changes. Class components are still supported and used at Facebook
- pier25 3y agoClass components are deprecated. They only appear in the legacy section of the reference. https://react.dev/reference/react/legacy https://react.dev/reference/react/legacy
- rozenmd 3y ago> These APIs are exported from the react package You can still write React the old way.
- trgn 3y agoSure. But search anything about React, and you'll see examples in hooks. I don't even understand the reason why class-based is "legacy". Why are hooks inherently better? Code-reuse is a factoring concern, not a paradigm concern. And component-life-cycle bugs are now replaced with nearly impossible to understand callback stacktraces.
- Capricorn2481 3y agoThat doesn't mean classes are deprecated, it means people prefer hooks, and I understand why, as someone that codes in both. It's like saying "All Javascript things I search are only in ES2020." It doesn't mean javascript is deprecating features.
- andrewmcwatters 3y agoOh also certain concepts and strategies are only written about in the legacy documentation. Good luck new devs!
- zoover2020 3y ago
- devjab 3y agoI think it’s more a matter of how the JS community has grown in general. The whole “class” thing is something a lot of us brought into it when we came from other OOP languages, but in 2023 it is very rare that it is “better” to build a “class” than to simply build the functions you need. As far as I know you can still trundle on with some of the old react, but at the same time, things change. It’s not like you’re coding C# similar to how you were 10 years ago either. I know that having been away from it, it was interesting to see everyone using “var” instead of types as an example.
- yamtaddle 3y agoI dunno... when you're building a hierarchical tree of nameable components and several, ahem, instances of each nameable component might exist, and these need to respond to signals, that seems like a case when it's non-crazy to use classes.
- deleted 3y ago[deleted]
- tshaddox 3y agoBut that’s not ever what you had in React even when using JavaScript class components.
- andrewmcwatters 3y agoClasses and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, or files. Try stepping outside of JavaScript for a while, broaden your experience.
- c-hendricks 3y agoSo you're just gonna ignore that whole "the JS community" bit then, ok. Is this what $200/hour consultancy looks like?
- 3y ago
- pier25 3y ago> I don't think many would agree to this but I'd argue the changes are so radical that they almost should've called this new React something entirely different. Absolutely and I've been saying the same thing for years. IMO it was an extremely irresponsible thing to do considering React is critical infrastructure at this point. And by completely changing the methodology they made obsolete A LOT of educational content (books, tutorials, videos, etc) in an instant. I'm sure people making money of React education were very happy with this. Don't get me wrong, I'm not against evolution. But if you're going to make such a drastic change just create a new project. Plus I wonder what other improvements/changes they could have made if they had started from scratch.
- davedx 3y agoNobody is forcing you to use it. The react devs made a bunch of code migration tools, used semantic versioning, slowly deprecated old APIs over multiple versions, maintained vids and documentation. Honestly compared with some projects they handled the changes and evolution of the API extremely responsibly.
- andrewmcwatters 3y agoPeople are forcing you to use it. It's called employment. God forbid you're a principal running into some junior engineers and they don't understand that you've forgotten more than they know, and the migration to functional components is just another part of your extended career timeline.
- plugin-baby 3y agoIf you’re a principal, just ask your juniors to explain their useEffect()-based mess. When they can’t, mandate class components.
- ipaddr 3y agoThen you get a security audit that you are not using the latest whatever and c-suites panic
- nfRfqX5n 3y agothe core concepts are the same. the implementation details have changed, but I think it's a stretch to call it a radical change. you could probably learn how to convert a component from class -> functional in a few hours.
- frou_dh 3y agoIs it really that much of a crisis to have the "0 React in 2023 experience ... don't even know the modern hello world" when one can just spend some time on their (excellent) documentation site and get back up to speed?
- tunesmith 3y agoI sometimes feel like there are three. The class components way, the hooks way that everyone has been doing it up until a few months ago, and the hooks way that the beta docs say you should do it. Maybe those last two aren't different enough, but the clashing philosophies around useEffect are enough to require massive refactors. EDIT: I'm referring to how the proper use of useEffects is to almost never use them. They're for side effects, and they're not a tool to just "re-render when these dependencies change". But to do this right, it requires a re-wiring of the mental model of how to do React, at least for many people I've come across.
- Apotheos 3y agoWhat's the new way as of a few months ago? The docs way?
- rkuykendall-com 3y agoThey may be referring to React 18 + Strict Mode meaning all useEffects can be called as many times as React wants. People before were writing code where useEffect on [] worked like onMount and was only called once.
- andrewmcwatters 3y agoWhat's so infuriating about that is the documentation basically told people, hey instead of doing this, use useEffect the way you were using these methods. So are the users wrong, or did you screw up?
- deleted 3y ago[deleted]
- c-hendricks 3y agoIf you're ignoring dependencies that should be on a call to `useEffect`, you're just making room for bugs. If you're not properly tearing down what you're doing in an effect, you're just making room for bugs. These have always been true of useEffect.
- kdrag0n 3y agoReact Server Components (RSC) feels like the third React. https://nextjs.org/docs/getting-started/react-essentials https://nextjs.org/docs/getting-started/react-essentials
- __float 3y agoI'm not sure I agree with this. It's "different" in that you don't need to learn the intricacies of some new data loading and state management library (we've seen _so many_ of these over the years!). But the concepts themselves are much closer to "just plain React".
- kdrag0n 3y agoTrue, not as radical as the transition to hooks.
- nawgz 3y agoI fully disagree. It's the exact same internal mechanisms lending themselves identically to rerender semantics and so on. They were exposed with new names and access methods, but enabled you to perform virtually the same component update logics, except with a few antipatterns made more difficult. HOWEVER it is also fully backwards compatible, you can run these old versions. So, what stayed the same? * Could still use classes * Still had the same props & state semantics * Components still could own state and receive props * Some renamed code paths were used, a couple of the "componentShouldRender" style ones were dropped to prevent programmers making fatal errors * Still wrote the same markup * Still could use the same libraries I never really understand this complaint; React achieved gold standard backwards compat. Either that or my 2016 era tools building in 2023 on the newest React with old ass libraries would've caused a lot more pain points!
- paulddraper 3y agoAkin to JS replacing callbacks with async/await: 1. You can use both styles, even interchangeably. 2. The latter is superior. Async/await allows you to write asynchronous code in a synchronous style. Hooks allow you to write stateful code in a stateless style.