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