I always think of it as a gateway drug that gets people into using other languages. Most fullstack developers I know are transitioning to things like Rust, Go, Swift, Kotlin, etc. Once javascript interoperability stops being a goal, there are many other languages that suddenly become attractive.
The irony with the Javascript ecosystem is that most of it is now written in typescript or other languages. That includes mainstream frameworks, tools, etc. Basically anything that matters to large numbers of developers. And of course for frontend development people don't actually ship a whole lot of third party dependencies in any case (for code size reasons). So our need for interoperability with all of that is actually pretty low. Most of the dependency hell that is NPM is really about pulling in layers of tooling that fix and work around each other in very odd and convoluted ways (i.e. webpack). React is a comparatively tiny framework of which several compatible even smaller versions exist that people tend to use when they don't care about supporting obsolete versions of javascript. What it does is pretty clever but you can recreate it in your language of choice with not too much effort (and people do this for lots of different languages). There are react inspired frameworks for Kotlin, Rust, and probably Swift, C# and a few other languages.
Typescript is pretty neat if you are coming from the giant Stockholm syndrome in our industry that is Javascript. It's held us captive by being the only choice for browser based development. Thankfully that wasted 2 decades of captivity is coming to an end now. So we can get back on track improving our tooling, languages, and practices. Things like refactoring and code completion are not exactly science fiction (both worked great in the nineties already). I think it's wonderful that e.g. VS Code allowed JS/TS developers to join this millennium two decades late but it's hardly the final answer in developer productivity. Time to move on.
IMHO, using Javascript these days is something to avoid. It's a compilation target at best and as such a stopgap solution until we can target WASM instead, which is possible now, will become very practical soon, and a mainstream/defacto thing to do soon after (2-3 years?). Most of this is pending on some ongoing work on fleshing out features for threading, memory management, apis, etc. Languages like typescript have a transitional role in the brief period of time that remains where transpiling to and interoperating with javascript is still better/easier/more convienient than compiling to WASM. Beyond that, unless you have a lot of javascript legacy that needs to be preserved/worked around, there are probably other languages that you might prefer to use instead. And as I argue above, there isn't actually that much code to rewrite if you consider what little of the NPM ecosystem actually ends up in your application on browsers. A few thousand lines of React code don't justify being held captive by that ecosystem. Also, most frontend code doesn't actually survive its first birthday in any case. So, what legacy?
I sometimes think wasm was invented to rid this glorious js ecosystem of people who always moan about it so the rest of us can get back to 'improving tooling and best practices'.
The irony with the Javascript ecosystem is that most of it is now written in typescript or other languages. That includes mainstream frameworks, tools, etc. Basically anything that matters to large numbers of developers. And of course for frontend development people don't actually ship a whole lot of third party dependencies in any case (for code size reasons). So our need for interoperability with all of that is actually pretty low. Most of the dependency hell that is NPM is really about pulling in layers of tooling that fix and work around each other in very odd and convoluted ways (i.e. webpack). React is a comparatively tiny framework of which several compatible even smaller versions exist that people tend to use when they don't care about supporting obsolete versions of javascript. What it does is pretty clever but you can recreate it in your language of choice with not too much effort (and people do this for lots of different languages). There are react inspired frameworks for Kotlin, Rust, and probably Swift, C# and a few other languages.
Typescript is pretty neat if you are coming from the giant Stockholm syndrome in our industry that is Javascript. It's held us captive by being the only choice for browser based development. Thankfully that wasted 2 decades of captivity is coming to an end now. So we can get back on track improving our tooling, languages, and practices. Things like refactoring and code completion are not exactly science fiction (both worked great in the nineties already). I think it's wonderful that e.g. VS Code allowed JS/TS developers to join this millennium two decades late but it's hardly the final answer in developer productivity. Time to move on.
IMHO, using Javascript these days is something to avoid. It's a compilation target at best and as such a stopgap solution until we can target WASM instead, which is possible now, will become very practical soon, and a mainstream/defacto thing to do soon after (2-3 years?). Most of this is pending on some ongoing work on fleshing out features for threading, memory management, apis, etc. Languages like typescript have a transitional role in the brief period of time that remains where transpiling to and interoperating with javascript is still better/easier/more convienient than compiling to WASM. Beyond that, unless you have a lot of javascript legacy that needs to be preserved/worked around, there are probably other languages that you might prefer to use instead. And as I argue above, there isn't actually that much code to rewrite if you consider what little of the NPM ecosystem actually ends up in your application on browsers. A few thousand lines of React code don't justify being held captive by that ecosystem. Also, most frontend code doesn't actually survive its first birthday in any case. So, what legacy?