Rendering Patterns- A cheat sheet
Rendering patterns in the JAMstack and modern web development is a lot to take in. Not only are all the acronyms confusing if you are not familiar with them but each individual pattern has its own use case.
Each pattern also has its pros and cons(like anything in life). In the list on this blog, I will define them in my own words to simplify them and give you the quick and dirty on each pattern and all that encompasses them.
Pattern 1: Server Side Rendering or SSR
Q: What is Server Side Rendering?
A: Rendering a client-side or universal app to HTML on the server. This happens at runtime per request. Essentially, a user sends a request via web-server. The web-server routes this to the app server. The app server then does whatever database calls we need to get to fetch the data and render the page as HTML. The web-server would show the user the final request.
Use-Case: When content can't be statically rendered. This is content that changes constantly. (E.g. Commenting forums, Product Checkout on an e-commerce site, user-login page)
Pros: Up to date HTML/Data request/ Content
Cons: Resource intensive
Pattern 2: Client Side Rendering or CSR
Q: What is Client Side Rendering?
Use-Case: When content can be statically generated at build time. Sites and apps who's content that does not change often
Pros: CSR generates the HTML required to be displayed. This means DOM only contains enough code which is expected to be displayed by the HTML content. So DOM can easily handle a chunk of elements with the hide and show events. Although DOM has to handle more code, it doesn't take much time to render. Due to lazy loading, CSR becomes much faster than server-side rendering.
SEO stands for search engine optimization. CSR requires a two-wave process for JS rendering and indexing in a browser, generally by Google.