[dragonwriter]

> The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience

Sure, it's the >100ms between the user entering the first value that might have an error and the user submitting the form that's a much bigger problem between validate-on-server-on-submit and validate-on-client-on-entry.

> But I don't agree React _benefits_ developer productivity. On the contrary, I think it (and its competitor frameworks) are responsible for a lot of wasted developer time and frustration.

After a not-very-long familiarization period, developers seem to be more productive with React (or probably Angular.) I know I am, and I've been using SPA frameworks (mostly React) for a short time after having done web lots of other ways for a very long time.

[the_gastropod]

I've been professionally working on SPAs for the past 7 years. I'm familiar. I strongly disagree with the premise that it's in any way more productive. I'm, at a minimum, 2x more productive building something the traditional "Rails way" with server-rendered HTML, and a handful of JS enhancements where necessary vs doing a full-blown SPA. I'd love to do a showdown, and challenge anyone to a head-to-head non-trivial app build-off to put these competing notions to the test.

[nohuhu]

Everybody is different. You might be more productive at doing stuff the "Rails way", somebody else might not be. I know I won't be, simply because I don't know Ruby and/or Rails enough to be productive in it.

Not every organization can use this approach either. E.g. I work at a True Java Shop(tm), where voicing the idea of using Ruby for a back end service would get me laughed out of the room with a permanent label of That Funny Guy Who Likes Toy Languages.

Using React for a front end client application that consumes back end API built in Java is 10x more productive than doing the traditional "Java Way" application with server-rendered HTML.