4,781 karma · joined October 11, 2010
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.
You may want to consider whether you're doing the back end devs' work for them. :) I'm a FE dev working with a lot of microservice back ends for the last 3 years, and a realization that I had early on was that the back end devs were reducing the back end complexity by pushing it into the front end. Whenever I find myself writing transaction logic for an operation that cuts across multiple services, I suggest we use a backend for frontend (BFF) service that performs those transactions instead. There is an incredible amount of complexity in the front end already, and things like read/write transactions and data consistency are not front end concerns. At my current gig we use an event driven saga architecture[0] (inspired by but no relation to redux-saga) to keep multi-service transactions out of the front end, and it just feels like everything is where it should be. Instead of using a front end saga, the front end sends a graphql mutation to a back end saga and gets back a transaction id, which it can subscribe to and get status updates on the transaction (ie. state and errors). It wouldn't make sense to have your back end devs manage the state of a dropdown, so why are they always asking us to manage their data transactions? :)
[0]: https://github.com/social-native/kafka-sagas (this is a purely back end library; the front end queries the saga state with plain graphql operations).
https://www.amazon.ca/Viral-Search-COVID-19-Matt-Ridley/dp/0...