5 ms·
> Whatever framework you choose will be obsolete in 5 years. I've been writing React professionally for over a decade at this point. I don't know what this guy
by ng12 2y ago
> Whatever framework you choose will be obsolete in 5 years.
I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
- olliepop 2y agoComponent lifecycle methods to hooks and HOCs, does that ring a bell?
- ng12 2y agoYeah, and I'm not anywhere near as distressed about it as this article implies I should be.
- figassis 2y agoAs a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
- the_other 2y agoFront-end dev here. I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET. I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
- lezojeda 2y ago[dead]
- skydhash 2y agoMore often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
- figassis 2y agoThe beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
- michpoch 2y agoMost likely because you work on apps in active development. Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new. Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
- crab_galaxy 2y agoClass components and HOCs aren’t deprecated though.
- only-one1701 2y agoThey're very much not "best practices", and will be deprecated soon (if they're not already).
- hajile 2y agoYou still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove. HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
- zero_shift 2y agoI'm not aware of any indication that class components will be deprecated.
- deleted 2y ago[deleted]
- madeofpalk 2y agoBut they're not deprecated. Where's the forced churn? Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
- only-one1701 2y agoMea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
- 2y ago
- regularjack 2y agoThe transition to hooks was worth it.
- the_other 2y agoI'm not convinced. - they're much harder to learn and understand than the callback hooks from class components - The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them - The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others) - the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm - they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return) - the mental model for how to put them together when you're writing custom ones is a little bit funky too. - the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
- deleted 2y ago[deleted]
- figassis 2y agoDidn't React deprecate itself entirely circa 2018?
- pelagicAustral 2y agoThey just keep stirring his slop and he keeps eating it, that's all I'm reading here
- metadat 2y ago"That was some good slop, sir. Can I come back here for lunch every day for the next 10 years?" Hilarious, and accurate.
- kerkeslager 2y agoI've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods... Even a well-maintained project like React can't escape the squalor of its ecosystem. I don't always have this option, but usually these days I choose vanilla JS, imported with no build system, do as much as I can with Python/Django on the backend, and opt out of the JavaScript ecosystem entirely. I haven't regretted it.
- incrudible 2y ago> To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. That's a problem with your build system then, not React. There is (or was) indeed a lot of churn in build systems, but you wouldn't have been spared unless you had chosen to not use a build system - which is still possible with React, but not with Svelte, Vue or Angular. My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
- kerkeslager 2y ago> That's a problem with your build system then, not React. Did you read the sentence that you're "correcting"? > My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after. Your optimism is admirable.
- kerkeslager 2y agoI just had a thought and decided to look it up. This side conversation started as an objection to the comment, "Whatever framework you choose will be obsolete in 5 years." The first release of esbuild was November 2020, i.e. it didn't exist 5 years ago. And that release fixed... conditional statements in TypeScript--a pretty basic feature to be broken. Does that sound like something you want to use in production? So maybe your strategy of only using things that work with esbuild doesn't address the problem as much as you think it does.
- deleted 2y ago[deleted]
- TimTheTinker 2y agoHow many dependencies does your package.json file declare? Which versions of node/npm does your team use? If you're on recent-enough versions and are using any popular libraries, you will have seen the deprecation notices pile up during npm install for downstream dependencies.
- jwr 2y agoNone? I use it from ClojureScript. I've been maintaining a React-based app with Semantic UI for 10 years now.
- jf22 2y agoThen you aren't doing what the author is talking about.
- DangitBobby 2y agoThe new insight then is if you do things then bad things will happen?
- TimTheTinker 2y agoDo you mean your package.json literally has no dependencies declared (or you don't even have package.json)? If so, you're not using frontend tooling like 98% of development teams.
- jwr 2y agoI don't have a package.json. I don't use npm. But I do use React. Yes, I am not like [insert scientifically determined very very high percentage] of teams out there — but that's exactly my point. There are ways to do frontend development without the treadmill. Thing is, we are the reason for the treadmill being there: we love the new shiny, we call software that is stable "dead", we actively mock software that doesn't have a lot of churn as "not being developed". So I guess we deserve what we get.
- Sateeshm 2y ago
- michpoch 2y agoHow's your Create React App support in 2025? Are you still keeping your app on React 15?
- robertoandred 2y agoIt takes ten minutes to switch from CRA to Vite.
- recursive 2y agoI think that's only if you've rehearsed it several times. Although now that I think about it, you will probably have to do it multiple times, so once you get good at it, that may be a reasonable estimate.
- ebiester 2y agoMy current firm is still on 16 and just trying to make it to 18 because of the deprecations. All of the WYSIWYG editors that work on 16 are no longer supported. it's a "cross your fingers" in case someone found a security issue (or don't use them) React 16 is still supported, but it's definitely obsolete.
- davidmurdoch 2y agoIdiomatic Reacts historical changes pretty often. In large codebases major version upgrades can take teams multiple quarters to complete.
- deleted 2y ago[deleted]
- vinnymac 2y agoSame I’ve been writing React for 11 years now. Before that I used Backbone on top of jQuery. Before that I used jQuery. Before that I used the document, but I still use the document. I have barely had to learn anything each decade.
- dagorenouf 2y agoI have too and the react of today is vastly different from the react of 5 years ago. Which itself was vastly different from the original react. It’s different paradigm, best practice, file organization, etc. So it’s close to learning a new language. And I won’t even go into the fact that Next is replacing React as the standard.