[jaapbadlands]

No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the industry forward, not by building less, more basic, and shittier applications in a some faux-noble quest to use inline event handlers.

[wheelerof4te]

"No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions."

Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.

[pault]

The chances of this happening before your project is obsolete are pretty slim.

Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily using it at their day jobs. React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens.

[codeptualize]

When there are so many projects that run on React, and so many companies rely on React, it's inevitable that it will be supported for a long time to come, even if it would go out of fashion.

And speaking from experience maintaining React apps is quite nice. React has great backwards compatibility, and where it doesn't there are usually codemods available. Dependencies can be tricky, but that's not exclusive to React.

Also don't forget React evolves, backed by multiple #huge companies, and still innovating.

[fsckboy]

I love maintaining and cleaning up code (I will insist on cleaning up according to my taste even if it already works fine in production, just like when I carve the turkey I eat some crispy and fatty pieces hot from the oven) It takes a great weight off my short term memory and ADD that I know that the code already worked, so if it stops working, I did it, recently.

But here's the thing, hot-shot devs, and hot-shot dev wannabes look down on maintenance; and humans are social creatures, me included. So I'm not going to do a job for you that you look down on, unless you carry me in (and out) on a sedan chair.

Same for writing doc, I'm good at it and enoy it, but there's no pleasure in doing something that other people don't really value.

[docmars]

Better than maintaining vanilla JS applications that reinvented React for no d*mn reason. At least there's a massive pool of engineers who could jump into an old project and work on it right away, rather than wading through some clever engineer's buggy attempt at a view state management system.

Popular backend templating systems face the same problem with possible sunsetting and decay of collective knowledge over time.

React is a great investment, and is here to stay for a long time because its team (and community) are massive, and are keeping pace with newer libraries/frameworks that are in a lot of ways doing things better. React's market share has hardly been touched by Vue, Svelte, Solid, etc. and less so by HTMX and other new attempts at un-frameworking the web.

[jaapbadlands]

I'll enjoy that a hell of a lot more than I'll enjoy doing the same thing on bullshit vanilla code I scratched together myself under the pressure of a deadline, lol.