DEV Community

Discussion on: Understanding Server Side Rendering

Collapse
 
zanehannanau profile image
ZaneHannanAU

There is quite a lot that I want to disagree with here...

Server side rendering does not mean more network requests. If anything it means less requests.

Server side rendering can be done through various means. It's one of the fundamentals of the web.

There are issues with how it's often done, though...

In many cases, we wait for a DOMContentLoaded/load event listener (jQuery .ready hook) or throw our application at the end of the page. This sort of thing does not lend itself well to pages needing interaction.

An example might be using a click global event listener and filtering by class (or closest) to work it.

I see the idea of server-side rendering as counter-intuitive in most applications. Service workers might make more sense if you think of them as the go-between for a client and a server.

For instance, Jake Archibald is basically the guy who napkined service workers, and uses them... for everything.

SSR is almost always faster than client rendered to have working content, given that you aren't killing the thread.

Serviceworker rendered... is similar. It's midway.

If you're building for it, it's more or less one of three. You attach global listeners and wait until you have some confirmation. I've done it myself, though on a really small scale.

It's everything that you do that makes it work. It may not necessarily work well, but it works.