[eawgewag]

I really appreciate this comment. You've very eloquently put into words how I feel about React and the ecosystem, and also my exhaustion towards these "anti-React" posts, which stoke an angry mob without offering obvious alternatives.

And I think the crux of the problem is that there is no obvious alternative. That isn't to say it can't, or shouldn't exist. I'm not a React loyalist. I was a working frontend developer when React came out and I remember how it took the web community by storm, because it was an obvious step forward.

When the alternative exists, it will be as purely obvious.

[hmeh]

To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back.

I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience doing the exact thing you are doing say there’s another way.

The really tricky part here is that that “other way” in this case looks similar to the “old way” and thus is easy to dismiss. It also doesn’t come with any of the dopamine inducing things like hot reloading and really cool tech like virtual dom diffing, etc. in other words, it doesn’t speak to the parts of us that are drawn to the “cool” factor. It’s simple, it’s basic, it’s sometimes tedious, but it’s productive — in the long run.

[eawgewag]

I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React answered my three basic concerns very clearly, in an obvious way:

1. Component based architecture

2. The ability to express view as a pure function of state

3. The ability to express HTML and code together in a neat and ergonomic way

This is what I mean by obvious -- all experienced frontend engineers I knew at the time immediately got it, they got that React nailed these three things, and why they were important. Surprisingly, even new frameworks don't always lead with these three principles, which makes me less likely to believe that they resolve the particular concerns that I find of most importance.

[hmeh]

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.

[eawgewag]

I'm definitely a fan of LiveView and Turbo. I think they present reasonable choices for applications that are more complicated than a static site and less complicated than a full application. I would like to see their interop story with React improve, however, since I think a lot of impetus towards React comes from the fact that the core business product, which has high application/interactivity requirements, is (understandably) in React, so the cost of build is significantly lower staying within the ecosystem.

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.

[hmeh]

Indeed. I think an important concern is what constitutes a "full application". I think that's where the community (I've even seen this at my own agency) has lost the plot a bit.

> I am the TL of all the setting pages

Ok, now I'm intrigued. If you're interested, I'd love to hear more about this. As someone who has (aside from a 2 year stint at Microsoft) only worked on relatively small teams (15 max) I'd love to hear more about what it's like to work on a team that's responsible for the settings pages. If you're interested, I'd be happy to connect for a chat. I just added my contact info to my profile here. If not, no worries! Cheers.