There’s plenty to improve still, but like you said, it’s stable and improving in all the right places.
The main issue was that it was hard to prevent various levels of rendering in the page even though I knew it was redundant.
When using remix this is trivial to accomplish. I’m not sure I’m sold on remix entirely, but the routing capabilities are far better than Next’s.
Also some recent tweets from vercel suggest to me that they might be resolving this soon. Here’s hoping!
I also briefly looked at Remix and love the routing, but do not necessarily want Remix to dictate how I mutate my data.
I think it’s a special circumstance but still important to support. I’m not aware of a work around at this point.
How does remix dictate how you mutate your data?
I think a big part of this problem is that people need to know why they’re choosing a dependency and what problem it solves, and if that aligns with what they’re building properly. For example, if you choose redux, why are you choosing it? Why choose it over the context api in react with built in state management, or zustand, jotai, or etc. In any stack you should be able to answer these questions, not just JS in the browser, but my experience is that a lot of JS teams haven’t determined this properly. It’s a recipe for struggle because they end up using more dependencies and in house code to band aid the fact that their tooling doesn’t work well with their software.
The result is that the wrong dependencies and too many of them are used. This makes everything from building to testing to maintenance harder. A great goal on any team is to minimize the number of dependencies used in the first place; they’re often looked at as necessary to solve various problems, but they might not be at all.
Some degree of trouble is inevitable because the JS world is kind of crazy, but it doesn’t have to be bad.
Sorry, this came out more depressing than I originally intended.