> It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.
Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.
And if you flip the question, I just haven't seen the compelling case for server side rendering. If you have a specific case where something else does something you can't do with React, or does something a lot better than React, then of course do that something else, and if that something else happens to use server-side rendering then maybe it will be a tolerable tradeoff. But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them (which is not to say that we wouldn't have e.g. a Ruby based convention-over-configuration framework - but I think it would have a state model closer to React's).
> You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.
It's personal experience, but perhaps outdated, and I never was hugely into Rails specifically. The last time I checked in was several years into wailing and gnashing teeth about people fleeing to React, but only really offering a smattering of ad-hoc fixes to specific pain points. Maybe they've found themselves a good unified state abstraction now, but I think it would be a real struggle especially for a framework that isn't really component-oriented in the way I see it (and indeed prides itself on embracing HTTP and having routes corresponding to pages).
> Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.
I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless. Learning new things that expand the way you think is worthwhile. Learning new tools that you can apply generally is too. Learning yet another slightly different templating syntax or curly brace programming language usually isn't. And some tools have enough depth to them that you can spend years and still learn new, useful things. I don't know that React is one of them - I don't know it as well as I'd like - but these days I generally find it more rewarding to learn a deeper corner of something that I can use a lot, than a new standalone thing that doesn't have any general lessons to impart.
> Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.
Yes, in that case, i.e., if it were a problem we had. It's NOT a problem we have though. That's my point. Not currently. Not in our context.
> But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them
Not exactly React, but there was ActiveX, Flash, and Java Applets. Thick clients came first. It wasn't until IE6 where there some AJAX was viable. React came later to address additional shortcomings: procedurally updating the state of the document via jquery got complicated, and large organizations with poor development practices (e.g., facebook) struggled to maintain control of their application. They came up with React to help with this, and it did, but it brought its own host of problems. Declarative UI was what we always had with server rendering. They just allowed it to update. Btw, this isn't a new idea. We had something like this with ASP.NET as well, but that included the server.
Meanwhile, people like Chris McCord had already built a syncing library for Rails to solve these problems and, being fed up with the performance at that point, went to Elixir where he eventually built Phoenix LiveView. By then, React already had significant market share. Turbo's previous incarnation came out before then and its current one came out around that time or slightly after. Combined with Ruby's performance improvements over time, it was quite viable for many apps.
Also, note what's happening in React -- it's moving towards more server rendering. People realized they lost something by doing client only and they're trying to get back to it. Remix is an ode to the simplicity of old (which is really the simplicity of now, but they don't want to give up their React Components). I can't blame them in a way, React is a lot of fun to write a lot of the times.
> Maybe they've found themselves a good unified state abstraction now...
We've always had the database. That's insufficient for highly interactive applications where you need client-side state, which is likely what you mean by "unified". So yes, if you need "unified" state, and specifically the ability to change your UI based on changes to that state, React is great, or any of the other libs. The author was specifically concerned about React's current state (e.g. legacy IE6 support) and I'm specifically concerned about people reaching for React when they don't need it. That's because I've done it, I've seen people do it, and I see people continuing to preach the React orthodoxy which will lead to more people doing it. This thread is full of it.
Whether or not a person recognizes it, HTMX, Turbo, LiveView and its kind have greatly narrowed that gap. They've made server rendering just as capable at highly-interactive UIs in many more cases than many people think.
> I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless.
Sure, I can relate to this. But this is different than spreading FUD about having to learn a new language. That's easy. That's the easiest thing we have to do. I'm not suggesting to do it flippantly. I'm suggesting that sometimes it's worth it. When it's worth it, you do it and it's not a big deal.
Well sure, but in that case it's no longer "it's solving a problem we don't have". It's solving a problem that may be low on your priority list, that you maybe choose to tolerate, or solve in a more cumbersome way, but it's still an undeniable pain point.
And if you flip the question, I just haven't seen the compelling case for server side rendering. If you have a specific case where something else does something you can't do with React, or does something a lot better than React, then of course do that something else, and if that something else happens to use server-side rendering then maybe it will be a tolerable tradeoff. But I honestly think that if React or similar had come first, we'd never have invented server-side frameworks as we know them (which is not to say that we wouldn't have e.g. a Ruby based convention-over-configuration framework - but I think it would have a state model closer to React's).
> You're making assertions here about it getting more challenging, but I can't tell if that's from personal experience or if it's hypothesis.
It's personal experience, but perhaps outdated, and I never was hugely into Rails specifically. The last time I checked in was several years into wailing and gnashing teeth about people fleeing to React, but only really offering a smattering of ad-hoc fixes to specific pain points. Maybe they've found themselves a good unified state abstraction now, but I think it would be a real struggle especially for a framework that isn't really component-oriented in the way I see it (and indeed prides itself on embracing HTTP and having routes corresponding to pages).
> Yes, HAML is a new language. Our designers can work with it. It's not much more complicated than, say, markdown. Learning new things is what we do, every day. There are certain developers that prefer to hone their skills in the one thing they know how to do. They're the ones that put "React Developer" in their twitter or LinkedIn profile. That's fine. That's a career path. I don't work with those people by choice.
I used to pride myself on knowing dozens of languages, but I've come to see much of that as superficial and pointless. Learning new things that expand the way you think is worthwhile. Learning new tools that you can apply generally is too. Learning yet another slightly different templating syntax or curly brace programming language usually isn't. And some tools have enough depth to them that you can spend years and still learn new, useful things. I don't know that React is one of them - I don't know it as well as I'd like - but these days I generally find it more rewarding to learn a deeper corner of something that I can use a lot, than a new standalone thing that doesn't have any general lessons to impart.