What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page.
There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.
Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.
I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.
"The page content is smaller as JSON" .. "you introduced a round-trip, game over"
"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"
"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"
This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component.
My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.
There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time.
Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space.
I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same.
"The page content is smaller as JSON" .. "you introduced a round-trip, game over"
"We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded"
"We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"