Some folks seem to believe I object to any client-side JS in principle. I don’t. You might be on the wrong track if you find yourself having to do the same stuff on the server, though. SSR and CSR should complement each other, with SSR as the first and safer choice.
Stefan Tilkov @stilkov
30 May 2018
Here’s a mind-blowing idea: Instead of adding server-side rendering by getting your client-side framework to work on the server, too, first start with server-side rendering and make it really, really fast; then as a next step, maybe don’t do that client thing.
1
7
5
20
I’m also a big fan of powerful client-side JS components, triggered by HTML that’s rendered on the server, using a fancy new approach called “progressive enhancement”. On a completely unrelated note, I occasionally use a rhetorical device called irony.
1
2
9
Also, I wouldn’t dream of attempting to write a web-based video editor using SSR only. I’d probably use an SPA approach. I fail to see how that makes SPAs a good choice for most other web apps, though.

May 31, 2018 · 5:01 PM UTC

1
2
Of course everything has its place: Mostly SSR with a little bit of JS for better UX; a mixture of SSR plus quite a heavy amount of JS for complex apps; pure JS/SPA e.g. for offline apps. I just get mad if people claim SPAs are the only reasonable, “modern” choice.
5
15