Okay, now that I’ve read the rest, I do get the frustration and the POV. First response is that React is emphatically a great tool for building applications. Applications are not the same as sites, or enhancements to sites that are mostly static content.

Your example for a view component with three sections isn’t so different from writing a react component against a react-jss theme, I prefer the material-ui component library as a baseline.

for example:

// styling
export const styles = theme => {
myComp: {
margin: theme.unit.spacing,
backgroundColor: theme.pallette.primary[50],
}
};

export const MyComponent extends Component {
//behavior
handleClick = e => {…};

// structure
render() {
return <div className={this.props.classes.myComp}} onClick={this.handleClick}>…</div>
}
}

// wiring state/style/component together
export default compose(mapState, mapActions)(withStyles(styles)(MyComponent));

Yes, it’s a bit more complex than HTML, but across a large application with a *LOT* of interactive components it’s better managed. The theme’s configuration is common and injectable. The components themselves are isolated and work well.

As for DIV soup, you can always use the react and redux devtools extensions (assuming react/redux) the wiring leads to a bit of nesting, but easy enough to work with. I’m also pretty stringent on project structure by feature.

For I18n, I use an injected built object from separate YML files that then gets used via keys into the components, passed as part of a state component. Accessibility is pretty much correct out of the box with material-ui and, like most things still requires checking in lighthouse, wave etc.