I'm both of these developers, and I don't think either part is complex or all that difficult. I have no problem bouncing from backend to frontend in the course

I'm both of these developers, and I don't think either part is complex or all that difficult. I have no problem bouncing from backend to frontend in the course of implementing a feature and I don't find my mental stack getting smashed in the process. If your developers aren't cross-functional in exactly the way you describe, I think you probably hired insufficiently skilled developers. ;) To me, it's more that every HTML templating solution I've ever seen kinda sucks for composition beyond a very basic "insert blob here", whereas TSX--don't write plain JavaScript, kids--does a lot to address that. It's more that commingled views/controllers and the actual logic of the application causes separation-of-concerns issues (and yes, you can write better code, but people don't). And it's more that for any nontrivially successful thing I'm probably going to either need to provide an API or a mobile client--which are the same thing--and so I might as well get it out of the way to start. In a way, it's the microservices argument. You don't make microservices because of performance, you make them because it forces less skilled developers to do (more of) the right thing and allows those less skilled developers to parallelize better. So it is with tooling like React in an SPA and an API-driven backend. But, and unlike microservice-all-the-things, I find myself able to crank out more involved features, faster, using React and talking to a backend API in something like Swagger than dealing with postbacks and string-manipulating my way to HTML output. So I think there are wins on both ends.