[timr]

"It's not an ugly hack at all. It works well"

URLs are addresses of resources on the internet. They're parsed by your browser to request resources on another server.

If you've rewritten this functionality in JavaScript to support storing application state in your single-page application, it may "work well" but it is, in fact, a hack. If you've done this to support storing application state in your web application that sometimes has to actually talk to servers on the web, it's an abomination, and a complete violation of the way web browsers are supposed to work. The fact it is a currently popular hack does not change the nature of the thing. Lots of bad ideas were once popular (remember when everyone wanted to build SPAs in Flash?)

"for at least REST, you no longer really need things like an ORM on the server-side as all of the endpoints are simple and basically fetching a single data type"

If your problem is that you don't want to use an ORM, then don't use an ORM. Likewise, there's nothing stopping you from writing a server-rendered webapp with single-datatype endpoints. You can use HTTP2 with server-side rendering. None of these things are enabled by React.

If these are truly the arguments in favor of a particular client-side stack, it's clearer to me than before why so much of this thick-client stuff is terrible.

[mottomotto]

I haven't written this functionality in, it's a browser API:

https://developer.mozilla.org/en-US/docs/Web/API/History_API

https://html.spec.whatwg.org/multipage/history.html#history

None of these arguments are for a specific stack. React has little to do with any of this. We're talking about underlying technologies that enable the web to be used as a platform for application development.

My point about an ORM is that your API becomes so simple you don't require a lot of complexity that is required with server-side joins of data in order to render a view. That is gone. No need. I'm giving you examples assuming you can extrapolate them to a bigger picture.

[timr]

The history API is a standard. The various "routing" JS toolkits are hacks built upon that feature.

"My point about an ORM is that your API becomes so simple you don't require a lot of complexity that is required with server-side joins of data in order to render a view. That is gone. No need."

Yeah, I understood your argument the first time you said it, just couldn't believe you were making the argument. If you don't like joins (related: why do you think you need an ORM to join?), don't write your server-rendered endpoints to use them. The one technology has nothing to do with the other.

That said, as soon as you want to achieve reasonable performance and scale, you will rather quickly find it essential to return multiple pieces of data in a single API call.