[lmm]

> What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach.

As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.

Theoretically it's conceivable that someone might have a website that needed only flat forms with zero dynamism. But I've found that everyone thinks their website is like that, and they're always wrong. Every Rails/Django/Wicket/etc. site ends up needing one little piece of unmanaged JavaScript somewhere (unless you're lucky enough for a server roundtrip to be acceptable latency-wise). And then one more piece. And then you have a state management problem.

> My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.

You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them. Apart from anything else, how do you do handle the client-side state in the Rails case?

> HTML is what React renders. You need to write something like it when you write your JSX.

Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.

> Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive

I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.

> or SEO.

Perhaps - but not everyone needs SEO.

> Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.

It really isn't these days. Even a very inclusive baseline of browser support still gives you plenty to work with - e.g. flexbox is 12 years old at this point. It's entirely practical to set a reasonable baseline and just not do progressive enhancement (particularly since often the "worst" browser you're targeting - iOS Safari - is also the one that most of your customer base by value uses, so there's little to gain from progressive enhancement).

[hmeh]

> As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.

Yep, we have all this. Server round-trip is acceptably fast. Perhaps we are lucky because most users are in the US.

The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing. They only see that, and they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.

> You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them.

It wasn't our first app. We're actually very well versed in it. I just looked it up and the first app I worked on w/ React was in 2014. I worked in it exclusively for 7 years or so before making what I thought at the time was a the very risky switch, mid-stream with my current client to server rendering. Almost the whole team knew React better. Using Rails wasn't just a little bit more productive, or a little better, it was night and day.

> Apart from anything else, how do you do handle the client-side state in the Rails case?

There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple. Event hook, write to session storage. On load, read from session storage.

For everything else, it's a server round trip.

Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible. Yet, it's not.

> Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.

It's a flippant analogy here because you can't get away from the HTML. Sure, if you never look at the dev tools, or you always use the React dev tools, you always see your HTML wrapped in React components, but uhm, it's HTML wrapped in React components. You don't write assembly and give it a C function header. Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.

> I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.

Anything is possible. We would have to define fast, however. I mentioned TTI. The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers. Furthermore, in order to get reasonable TTI, you either need a small app, or you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.

> It really isn't these days.

Ok. Keep in mind it's always changing. Container queries? Clamp? Various things over the years have been useful to be able to use and worth doing progressively. I agree though that the gap is reducing. We hardly do any progressive enhancement. We are also not targeting markets that would benefit from it. We can luckily mandate an evergreen browser because of who our users are. Not everyone is in that situation.

[lmm]

> The interesting question here is, what is unacceptably slow? Why is it slow? If you really don't need any new data from the server, i.e., you are just hiding or showing something, you can use JavaScript. But I'm just here to say that it's more than possible to be "fast enough" for a forms-over-data application. Usually when developers tell me (and yes I'm a developer) that something is not fast enough it's because it's "human perceptible". That may be the measure for certain applications, but more often than not, it's a developer that's fixated on the wrong thing.

If you're making something users don't have much choice about using - either an internal business app (the article has a box about those), or a professional tool that adds major capabilities - then you can get away with it, just as you can get away with quite bad UI in general. But if you're making something that has to appeal to users, perceptible and even imperceptible latency when they click drives them away. I'm not claiming it's rational, but developers "fixate" on it because it matters to users; I wish I could just keep writing Wicket, but I can't argue with the numbers or even just my own experience of what using these UIs feels like.

> they don't see the long-term productivity cost of using a SPA framework. You may tell me it's not there, but it is.

Why though? Like, there might be specific things React does wrong (and I know that Rails is very productive for some people, much as I hate it), but there's nothing fundamental about using an SPA framework rather than a server-side framework that should make it less productive. If I want a form with 2 dropdowns and 3 text fields, that's the same question in either context, and should take the same amount of code to answer.

> There's almost none. Some I can think of are persistent scroll (in a navigation panel or comments feed that persists through page navigation) and persistent comment drafts. Persistent scroll is about 100 line stimulus controller that stores the scroll position in session storage. Comment draft is also in about 100 line stimulus controller (only about 50 lines or so are concerned with it). It's all very simple.

Fair enough - you made it sound like there was a lot of client-server state that was relevant. If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users, you have state on the client in an unmanaged way and get horrible glitches when the server and client disagree (e.g. client is on one tab of the form but server thinks it's on another tab), or you have state on the client in a managed way and use an SPA framework (or something indistinguishable from one).

> Have you used hey.com? It's an email client built with server rendered rails. From what you describe, this should be impossible.

No, but I've used similar systems. Yes you can make them. Yes they feel fast enough, if you haven't used the alternative (especially if you happen to be located close to the server). But they're clunky enough that they can't succeed in the market.

> Yes, I recognize JSX isn't HTML, className made very sure of that. But... it's practically HTML in terms of what you need to know to use it. Oh, just remember to layer on the additional cognitive load that some attributes are slightly different.

The edge cases are what take the time when learning though. Like, yes, you probably do need to be able to read HTML-like syntax without getting confused. But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

> The article you are posting comments about has a whole table dedicated to how even with server rendering and React most apps fail to achieve good performance numbers.

Most apps full stop fail to achieve good performance numbers. It always takes effort. I suspect the average React app probably is slower, partly because React sites are generally newer and mostly because React lowers the bar for developer quality needed to get anything to work at all, but that doesn't mean there's a problem with the tool.

> you need bundling, code splitting, tree shaking, all additional complexity. Look -- I rode the Babel (né 6to5), webpack, to esbuild, to vite, to whatever else wave. I was the guy that built the webpack configs for my teams and handled all the upgrades. I actually KNOW the cost.

It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase. It continued to work, and be fast - I think maybe one time in a couple of years we got alerted that we'd done something that messed up the code splitting and we fixed it. Maybe it is complexity, but it's not complexity that imposes any real overhead in actual day-to-day development.

[hmeh]

> but developers "fixate" on it because it matters to users

Then it's not a fixation. If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.). Don't get me wrong, I pay for superhuman because it feels like a native app and gets many things right. I would not pay for hey.com. But hey.com is actually relatively successful out there despite its sometimes-perceptible latency. Oh, and superhuman has perceptible latency too. Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML. The delta between those two is pretty small now-a-days, and typically not perceivable.

> If you haven't got state that affects the UI, maybe you're the unicorn. I've found that websites always need that kind of thing (tabs, radios, nested dropdowns) and once you have something like that you either have the state only on the server and the latency is high enough to bother users

I mean, we do. Our forms are pretty sophisticated. Things add/remove show/hide, and they update live as others make changes. The state just doesn't need to be on the client. You say maybe we're a unicorn, I say maybe people should consider whether or not they are a unicorn too, and maybe those unicorns are just horses developers think are unicorns. They may just be a lot more common than you (and others) think. We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.

> But you don't need to know the list of tags or attributes or the escaping rules or the rules about which tags are self-closing and which aren't or ... . You just use React components and follow their documentation.

I'm not sure how to say this... but literally none of this is typically significant and certainly not any more significant than it is in React. In React you still need to know the tags and the attributes. Escaping rules? Yea, you need to know those too -- just the JavaScript ones. Self-closing tags? Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances. I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.

> I suspect the average React app probably is slower, partly because React sites are generally newer...

This isn't why. It's because it requires a significant amount of JavaScript to load and evaluate before you see anything. That amount can get larger with time.

> It's O(1) work though, or very close to it. I was the guy that used the existing build that someone else had come up with before I started working on that codebase...

Right. That stuff is O(1)-ish, and maybe it's stabilized some, but having gone through the various transitions, I can say it's not free. Nothing is though, upgrading Rails took us a couple hours this time around because of a breaking change for our 30 apps. React comes with, as a baseline, significant complexity that is O(n): Client/server separation (APIs or phantom-APIs like Next.JS has), state entangled with presentation (See the whole smart vs dumb components for an attempt to address this), massive asynchronous concerns that cannot be fully abstracted away (suspense and the like), and probably more.

Folks can't see it until they step away from it and look back. I've done that for the last 3 years. Unless a person has done it, I wouldn't expect my arguments to land. Folks see things or they don't. Again, I'm only here to say: there's something to see that you may not see yet. I'm sorry I don't have anything more convincing.

[lmm]

> If, for your application, the difference between a 1-50ms interaction and a 150-400ms interaction matters, then you have reason to for that interaction optimize the performance. If your entire app is like that, then you're probably a particular type of app (superhuman, miro, linear, etc.).

> We all like to think that latency matters to our app because we all read that article saying that Xms in latency cost $Y, but none of us stopped to ask if that article was about our app.

Disagree, I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed. I used to be similarly sceptical about a lot of design work - I felt like designers were just messing with the visuals for no reason - but once I'd seen the before-and-after with a good designer I realised how much difference it makes.

> Any time something needs to come from the server it takes that round trip time regardless whether or not that thing is JSON or HTML.

Sure. So e.g. one thing that shocked me is how important it is to have a loading state for your form submit buttons, even though it only shows for a couple of hundred milliseconds and you'd think it wouldn't matter. But it does, and that's the sort of thing that React-based UIs tend to nudge you towards doing by default, whereas with server-side rendering often it's a bit more of an extra step.

(A server-side rendering framework will probably have a nice loading state for basic happy path form submit buttons where they've put time and effort into polishing. But it will be ad-hoc rather than idiomatic, because that kind of detailed client-side state is fundamentally cutting against the grain of a server-side framework. Once you go slightly off the beaten path, into image buttons or custom button components or what have you, it becomes harder and harder).

> Escaping rules? Yea, you need to know those too -- just the JavaScript ones.

You always need to know the JavaScript ones. So the choice is between learning the JavaScript ones or learning the JavaScript ones plus some other ones as well.

> Just don't use them, or do if you know them, or use something like HAML/Slim/any other templating language to do away with those nuances.

Then you've got another language with its own syntax that you're learning. Writing everything in the same language really does help (admittedly I don't know how many other people stay away from JSX and do everything programmatically, but doing React and never writing HTML is a genuine option, easier than doing e.g. Rails and never writing JavaScript IME).

> I'm not sure that arguing that HTML is hard to learn is a very effective platform. It's the thing that grade school kids learn to make web pages. Sure, there's edge cases, and understanding semantics is hard, but you don't need any of that.

Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that, but my position is that learning just enough to get by is just fine, and putting more time into studying the intricacies of HTML does not generally have a good return these days. To the extent that React (or Rails, or anything) allows you to dodge learning those details, I consider that a point in its favour rather than against.

> it requires a significant amount of JavaScript to load and evaluate before you see anything.

It doesn't though. Like, I don't know how much effort it took to get the right build config etc. to make it work in my case, but it absolutely can be very fast. I'm happy to believe it's easy to make a React site that's slow, but it certainly doesn't require any superhuman effort to make one that's fast. I genuinely don't know what you have to do differently, because it didn't feel like I was doing anything special.

(At a guess I'd say committing full-throatedly to React and doing everything their way, rather than trying to half-ass things with useEffect etc. - just because that's the main thing we possibly did differently from "usual", and because most of the people who have a bad time with React seem to be the people who don't want to dive all the way in - but that really is just a guess)

[hmeh]

> I've found that even if the page is, like, tax forms, latency changes the feel of it and affects how the user feels about your site, even if they wouldn't consciously say anything about the speed.

I agree with this, but probably wouldn't about specific numbers or use cases. By the way, one of the forms on our app round trips in 75ms when selecting a radio button that controls which set of fields is visible below it. On the "Slow 4G" throttling setting in Chrome, the time increases to 620ms or so, which is noticeable enough for the interaction to not feel good. Our particular forms-over-data application is not typically used on mobile (there's too much data to enter), so this isn't an issue for us. It's all contextual. If it were an issue, we'd either use an SPA-like library for our forms, or we would send all the HTML to the client and use JavaScript rules to control visibility. It's one part of our app. We wouldn't let that singular use-case dictate our entire stack.

> A server-side rendering framework will probably have a nice loading state... Once you go slightly off the beaten path... it becomes harder and harder

Indeed, this is effectively built in to Turbo. There's nothing special about it, you add CSS rules (turbo adds and removes classes). That'd apply to image buttons or anything else you want to throw at it. 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.

If a person started their career doing React and is still doing React, that person would have certain beliefs about things that wouldn't be true. I get the impression that most people I'm engaging with here haven't actually done what we're doing but they are somehow convinced it cannot work or that our use case (line of business forms over data) is so special that it can't possibly apply to anyone else.

> Then you've got another language with its own syntax that you're learning

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.

> Well, we started this conversation with you complaining about React devs who "don't know the first thing about html". I don't know how literally you meant that...

Got it. It was somewhat flippant, I admit that. They probably know the first thing, but the concerns you're raising about tags and escaping and that sort of thing honestly somewhat reinforce my flippant assertion. If those are the things we are concerned about our developers having to know then I wouldn't want them anywhere near anything our users would touch. I think we may be used to working with different calibers of developers. I get that they're all over the map now, so this is just a another contextual difference most likely.

> ...studying the intricacies of HTML...

It's not sanskrit. I'm rather confounded by the FUD around HTML here.

> It doesn't though.

Ok. I've done it, so I know exactly what it takes, at least in the 4 or 5 different apps I built with various versions of React and friends. I also know that aside from the fastest machines on the fastest networks, there's not much you can do aside from server rendering to address the first paint issue/LCP issue. But yes, once you have the initial JS bundle, the rest of the site is generally faster. By the way, one of our 30 or so web apps we have composed into a single application with nginx/SSI still uses React. LCP is 1.2s on my M4 Max and on a page with slightly more data that doesn't have React, the LCP is 0.7s. Yes, the bundle is optimized. These aren't awful numbers at all, but I'm on the fastest machine there is pretty much. There's no loading shimmer stuff like AirBNB does. Speaking of user experience, that stuff is absolute garbage and I can't wait until folks realize it. Of course, they'd have to embrace server-side rendering though... :)

Just to be reiterate: I think there are plenty of good use cases for React like libraries/frameworks. I just think there are fewer than people think.

[lmm]

> 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.