| Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention. And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption wasn't worth it. Instead, we opted for helpers and view partials. The limited behavior we needed on the client would be in a separate Stimulus controller. The helper would typically reference it. Then, the declaration in the view would look more or less like a React component invocation, albeit with a totally different syntax. There may very well be room for improvement here, but it certainly works "well enough". As I've mentioned, the main thing that is different now is that we can render updates to views on the server. This allows us to have "The ability to express view as a pure function of state" on the server and not have to be concerned about everything else that comes with owning and operating a React implementation. I think React really helped move things forward and I don't regret my time using it. I may even use it again if I worked on an application where it was warranted. I wish I could spend time with every commenter on here showing them our code, working with them on it, and helping them see the way that we do it so that my words don't just sound crazy or anathema. Unfortunately, that just doesn't work out in practice. I appreciate the discussion all the same. |
This is actually something I think a lot about, because in my company I am the TL of all the setting pages. We don't have high interactivity requirements, and it's reasonable to explore a different path. But the core product is in React, and there's basically no justification to rebuild it in something else just to build out settings pages.