> Specifically, what problem does it solve, and do I have that problem? The problem most teams tend to face, and I believe part of the authors argument is that people reach for React out of an almost superstitious or orthodoxy-based belief.
The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.
> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along
Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.
The problem is building a front-end UI with compositional components (essentially the only way to build anything substantial), with sane handling of state, and with acceptable performance for interactive use (which means not round-tripping to the server every time, sadly, otherwise I'd keep using Wicket). Almost everyone doing front-end work has that problem, which is why React is a good "best practice". It's rightly the orthodoxy.
> They don’t know the first thing about html, server-side rendering, progressive enhancement or any of the things we used to use to build forms over data applications before React came along
Which is smart of them. That stuff is an overcomplicated waste of time. I mean, occasionally you need to debug some HTML, just as occasionally you need to read the disassembly of a binary, but most of the time there are more valuable things to learn.