The future (and the past) of the web is server side rendering

Thanks. Speed and quality content is what I've been focused on. I was tired of Google search spam and Amazon review rot so built this to try expose good/trusted/authentic content.

> What I have for native applications that I don't for the web is the ability to firewall off the native applications.

There you're placing trust on the firewall's sandbox. Are you sure the application can't communicate with the outside at all? DNS exfliltration for example?

I love the concept, but for my case, I'd need more granular filters. In particular, I only buy TVs that have analog audio outputs so I can hook them up to any speakers. That's a minority of TVs these days, but there are still a few around. Finding the good ones would be useful to me.

> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded.

If you can reasonably cache the response, SSR wins on first page load, no question. On the first page dynamic render "it depends", can be SPA or SSR. 2nd page render a well built SPA just wins.

"it depends....." Server CPU cores are slower than consumer cores of similar eras. They run in energy efficient bands because of data center power concerns. They are long lived and therefore are often old. They are often segmented and on shared infrastructure. And if the server is experiencing load, seldom an issue on the client's system, you have that to deal with also. Your latency for generating said page can easily be multi-second. As I've experienced on many a dynamic site.

Using the client's system as a rendering system can reduce your overall cloud compute requirements allowing you to scale more easily and cheaply. The user's system can be made more responsive by not shipping any additional full page markup for a navigation and minimizing latency by avoiding network calls where reasonable.

On dynamic pages, do you compress on the fly? This can increase latency for the response. If not, page weight suffers compared to static compressed assets such as a JS ball that can be highly compressed well ahead of time at brotli -11. I never brotli -11 in flight compression. Brotli -0 and gzip -1.

This is for well built systems. Crap SPAs will be crap, just as crap SSR will similarly be crap. I think crap SPAs smell worse to most - so there's that.

> Compatibility is higher with server-side rendering because, again, the HTML is generated on the server, so it is not dependent on the end browser.

If you use features the end client doesn't support, regardless of where you generate the markup, then it won't work. Both servers and clients can be very feature aware. caniuse is your friend. This is not a rule you can generalize.

> Complexity is lower because the server does most of the work of generating the HTML so can often be implemented with a simpler and smaller codebase.

Meh. Debatable. What's hard is mixing the two. Where is your state and how do you manage it?

If you're primarily a backend engineer the backend will feel more natural. If you're primarily a front end engineer the SPA will feel more natural.

There are 2 things that are orthogonal in current trend. This SSR buzz is not actually selling Server Side Rendering, they are selling 'one language to rule them all' (they call this dumb name "isomorphic").

Therefore, they are not solving all the problems of client-server + best UX constraints. Basically the problems we have all this time comes from:

  1) There's a long physical distance between client and server 
  2) Resource and its authorization have to be on server.
  2) There's the need for fast interaction so some copy of data and optimistic logic need to be on client.

The "isomorphic" reusable code doesn't solve [latency + chatty + consistent data] VS [fast interaction + bloat client + inconsistent data] trade-off. At this point I don't know why they think that is innovation.