| It's not an ugly hack at all. It works well, the browser history works properly and the interaction is just as if the pages were being fetched from the server. At any point in time, the user can do a hard reload and the page will rerender as it did before. The URLs are the same as if I was doing server-side rendering. So I would ask you at this point to turn this all around. Look at it from my perspective. I've been doing fullstack for more than a decade (professionally, hobbyist for twice as long) so I've done plenty of server-side rendering in frameworks like Ruby on Rails, ASP.net MVC, etc. I've contributed (as lead) to open source gems that have over 800k downloads. So I have invested a lot of time into the server-side. But today, with client-side, there is a huge simplicity factor. You can only get to it after wading through the turbulent waters of "flavor of the week" client-side projects and noise. But when you do get through that and identify your pillars to build on, this is what you have: * all of your complexity is on the client-side for web * you can make a simple fairly clean REST or GraphQL backend that will work with multiple clients (web, mobile, etc) * 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 (I use SQL with PostgreSQL so I would say a table here but it depends on implementation) * HTTP/2 reduces the cost of small requests so complex things like GraphQL aren't really necessary -- you can stay with REST without a penalty Is there complexity? Is it different? Does it challenge the conceptions of those used to fullstack? Yes. But there is real value and simplicity here too that you might find if you're willing to put aside your hard and fast rules and try something new. |
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.