"Rethinking from first principles" and "reinventing the wheel" are pretty easy to conflate. Proceed with caution. My recommendation is to choose boring technol

"Rethinking from first principles" and "reinventing the wheel" are pretty easy to conflate. Proceed with caution. My recommendation is to choose boring technologies that are widely deployed so that people will have to support them for decades to come. If there isn't a mature, well-supported option in a space, it's better to roll your own than to spend a bunch of time learning a technology and writing code, and then have to relearn and rewrite in 2 years when that technology is no longer supported. The bigger and more complex something is, the more you should let it get boring before you commit to it. Here's what I'm using: * Django * Django REST Framework * Celery * React/React DOM * ImmerJS * Postgres * Redis * Nginx For the most part, if it's not on this list, I try not to use it. There are other libraries I'm using, but nothing I would recommend. There are a lot of things I hate about Django. But it's a boring technology and that outweighs the other concerns. It works and I have no doubts that it will continue to work well. The one thing on this list that's not a "boring" technology is ImmerJS. This is not a complex technology, so I'm a bit less worried about adding it to my stack. And it allows me to avoid the global state that Redux or similar tools force you into[1]. If a better solution emerges, I don't think switching from Immer will be very difficult, and if Immer loses support, I don't think there will be much difficulty in continuing to use it. [1] Yes, I understand how reducers work. If you don't understand that reducers are a way of pulling out one part of global state, you do not understand how reducers work. Sure, reducers make using global state less painful, but introducing complex tools to deal with problems created by your other complex tools is not a good strategy.