> React, since hooks, includes a full state management solution - Context, Provider, and hooks. Sure, but that hasn't been around even 2 years. Prior to that,

> React, since hooks, includes a full state management solution - Context, Provider, and hooks. Sure, but that hasn't been around even 2 years. Prior to that, there was a different approach and philosophy to doing things. I remember when higher order components were all the rage till suddenly they weren't. I'm not advocating for stagnation, but at the same time, everything in JS land feels experimental, even in established frameworks, and the entire community keeps marching along as things keep changing. Which if you are a full-time developer doing that, is fine I guess, but it is not the norm compared to pretty much any other software engineering field. > Second, even if you want an actual state management library, both mobx and Redux are quite stable I cannot say enough nice things about MobX (although I was using it back when it didn't use Proxies so you had to deal with a lot of cloning back to native JS objects which got a bit ugly at times), and I don't disagree with you on this point for state management, although I personally could not stand redux despite 90% of the community vehemently singing its praise. > This is a comical take. Facebook is powered by React. Large, complex, enterprise, and fully powered by the cutting edge of JS frameworks. I should have perhaps qualified that better. Yes, I know there are people writing complex apps, but I was viewing it from the POV of a non FAANG type place with tons of engineers to throw at a problem. If I was a single person or a very small team trying to develop something complex, I would place a much higher emphasis on a more stable development environment/language/framework. > Is it not true the entire ML ecosystem has been reinvented in the last 5 years? My React code still builds & runs from 2016. I really feel like this is a case of "external person overestimates complexity in external domain, underestimates complexity in internal domain" because everything you're saying sounds like you dipped your toes, and didn't actually build applications. Let's take Pytorch as a comparison framework. It's had tons of releases, but at a fundamental level, the core API has stayed the same. I've ported 3 year old code to the latest version with pretty much negligible effort. And at its heart, it is because APIs are kept very stable and people aren't deciding each year that they need an entirely new way of doing ML or performing automatic gradient estimations, etc. Similarly with Python... there have been a bunch of Python 3 releases in the past few years but they each add new things that are useful without making big changes that suddenly change how everyone would tackle building a new piece of software. On the other hand, porting a 2+ year old React app to the latest version of React (along with bringing dependencies along) would be a very painful process. I know this, because we've done this at the company I work at. There is also this implicit assumption in JS/React land that you are going to come marching along with all the latest changes. Heck, less than 2 years back, their documentation site wouldn't even let you view older versions of React documentation, so the moment they released a new version of React, the docs would only ever show you the new docs. What's funny, is that today they supposedly have links to their older docs...but every fucking link is broken :-/ example: https://reactjs.org/version/16.8 https://reactjs.org/version/16.8 And nobody probably even knows that, because there is a general expectation in the field that everyone just keeps staying up to date with the latest and greatest and deals with whatever pain points come along with that and no one has probably even tried to access older documentations or raise issues about it. Which is fine, like I've said many times before if you've made your peace with it and that is your full-time job, but it is not the expectation or norm in most other fields. Finally, I should state for the record (because you stated otherwise in another reply to me), that I actually love javascript...well at least ES6+ JS. I greatly enjoy(ed) JS, JSX, developing in VsCode, and even building things with React, Mobx, etc. I'm not a software engineering snob who looks down on JS and the ecosystem. But I also have a more diverse viewpoint because I work at a small company and get to wear many hats and have been able to do lots of different things (ML Engineer, Front-end work, write and deploy pretty complex software, etc.). And while I have a lot of fun doing front-end stuff, It still feels like there is a lot of constant overhead to it, and that is pretty unique to this one field compared to most everything else.