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