[mottomotto]

But I have zero use for SEO-friendly pages -- all my client-side pages are behind a login-wall. It isn't one big blob of JSON -- it's multiple endpoints. With HTTP/2, multiple small requests are fast.

> build the few dynamic elements on their pages with a simpler, more robust technology

This is a horrible idea that has worked poorly for so many projects. At one potential employer, they did this and their app had a message view with a read count. They didn't care the read count didn't update -- you had to reload the whole page for it to update. Those are the kind of inconsistencies that the above approach encourages because it's not cohesive.

Can you do it? Yes. Should you? No, not in my book.

> low latency, URL routing, progressive enhancement

I've got low latency, I have client-side URL routing, I have no need for progressive enhancement -- it's just more complexity that neither I nor my customers need. These are all great ideas if you have a public website and need to cater to a wide range of visitors. I don't. I'm very happy to be able to only have to support the last couple major versions of each browse.

[timr]

"I've got low latency, I have client-side URL routing, I have no need for progressive enhancement"

Again, maybe you're in the 5% of "web application" users that are not actually web applications, but rather, "browser apps that download some data once in a while". If so, great. Most people aren't in that group.

Also, just to clear this up: client side URL routing is not URL routing. It's an ugly hack to make up for the fact that you can't use URLs for their stated purpose. It's honestly sad that we've wandered so far from the norms of the web that URLs have lost their meaning.

[mottomotto]

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.

[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.

[dasil003]

I've been a web developer since the beginning, so I understand this frustration with the current generation of web developer that reaches for React first purely because it's trendy with complete ignorance of the strengths of traditional approaches.

However, you are throwing the baby out with the bathwater. Client-side rendering saves server resources, and allows a single API to power web and mobile apps. A pure API is easier to optimize, and is generally a sensible separation of concerns. Of course this doesn't come without overhead, but you don't have to have Facebook-level complexity for this architecture to make sense.

[timr]

"However, you are throwing the baby out with the bathwater. Client-side rendering saves server resources, and allows a single API to power web and mobile apps."

I don't believe I am. There are certainly uses where I openly acknowledge that using a React is a good idea. If you're building something that needs to be a single-page application, for example, then I grant you that concerns of SEO and URLs and whatnot are superfluous. If you have a totally dynamic site, coupled with a Facebook-esque guarantee that your assets are nearly always in the user's cache, and a huge team of front-end engineers to optimize your code, great. But again, that's a tiny minority of teams.

All webpages are "client-side rendered", so that's a bad use of words. That said, JS-based rendering only "saves resources" if you don't count the bandwidth of the user, the amount of code needed to display a page, render speed, time to first render, and so on. I can't count the number of Reactionary sites I visit on a daily basis that hang for 10+ seconds before rendering or peg my CPU -- and nine times out of ten, they're rendering static content. It's an epidemic, caused by people making bad technical decisions, and even big sites like Instagram get it wrong on the regular (Instagram, in particular, pegs my CPU so often while looking at photos that I believe their secret business model is to mine bitcoin in my browser.)

A pure API may be easier to optimize, but unless you've transferred the time you're saving to front-end optimization, I guaranteed that you're punishing your users -- particularly those who are on low-bandwidth connections and/or mobile devices -- with lower performance and higher system demands.