Rendering Spectrum

Website rendering is mainly divided into three categories:

• Client-side Rendering:<div></div> Send to the client and rendered by the JavaScript template.
• Static Rendering: Pre-render HTML.
• Server-side Rendering: The server processes the request and generates an HTML response.

These three categories are not mutually exclusive and can be used in mixture. For example:

• A website can statically pre-render 75% of pages (such as blog posts), while the remaining 25% of pages are responded by the server (such as forums).
• A website can statically pre-render all pages, but contains some empty ones.<div> ,These<code><div> Contains the client rendered content (for example, a dynamically generated menu based on the logged-in user).<li> A website mainly uses server-side rendering, but has a cache in front of it, making it behave like static rendering.</li> <li> A website can be rendered statically and then "hydrated" into a fully client-side rendered website.</li> <li> A website can mix server-side and static rendering, but has dynamic parts similar to client-side rendering, but actually happens in edge functions, so it ends up being more like server-side rendering.</li> <p> What's unique about Next.js is that it can implement these three rendering methods at the same time. Tim Neutkens mentioned in a recent interview:</p> <blockquote> <p> Next.js allows you to pre-render the page. It uses static site generation (SSG) to create HTML on the server at build time, or to use server-side rendering (SSR). Next.js allows you to use both ways. Unlike most other frameworks, you are not limited to fully statically generated applications. You can have some pages rendered server-side while others are generated statically.</p> <p> In the new version, we can update these statically generated pages without rebuilding the entire application.</p> </blockquote> <p> This flexibility is great! For many websites, it is not practical to use a single rendering method throughout the disk.</p> <p> Client rendering is the most flexible, but the disadvantages are also obvious, such as poor performance, low reliability, heavy equipment burden, unfriendly SEO, etc. Static pre-rendering is the most robust, fast and secure, but has the most limited functionality. Edge functions based on static rendering have begun to open some doors, while server-side rendering classically takes into account both flexibility and speed, and has long dominated.</p> <p> Client rendering also brings the "Single Page Application (SPA)" experience. This feeling of pageless refresh makes the website faster and facilitates page transitions. Gatsby is known for promoting “hydration”, combining the advantages of pre-rendering static content and upgrades to SPA after JavaScript downloads.</p> <p> Ideally, we want a good user experience with the SPA without building it. This is especially worthy of attention when frameworks provide SPA feelings without managing a lot of JavaScript on their own, but there is still <em>some</em> mechanism to manage it.</p> <p> Tom MacWright also explores this issue in its article "If it's not a SPA, what is that?" Some existing alternatives include:</p> <blockquote><p> Turbolinks… <em>What is the least thing you need to do without relying on application matching in order to get a SPA experience?</em></p></blockquote> <p> Turbolinks works similarly: clicking on links, intercepting click events, making Ajax requests for new pages, and JavaScript replacing page content with new content. It's very simple to implement, but it still relies on JavaScript and is not smart enough to reduce data transfers.</p> <blockquote><p> barba.js and instant.page are other ways to solve similar problems.</p></blockquote> <p> Barba focuses on page transition effects. instant.page mainly preloads/pre-renders the page before clicking, so even if the page is refreshed, it feels less noticeable (especially when keeping the drawing). Both are cool, but not a complete replacement for SPA. (Even with keeping the pages drawn, pre-rendered, and lightweight, I think the experience is still not as smooth as the SPA. For example, you'll still see the page loading spinner.)</p> <p> So, is there any other way? There may be some. For example<code><portal></portal> . It may be oversimplified, but the basic idea is: portals are similar to iframes. They can even be visually displayed like an iframe. This means that rendering of the URL in portal has been completed. You can then "elevate" the portal to the active page, and even animate the portal itself when doing this.

  I don't think this is not impossible. I can imagine someone building a Turbolinks-like library based on portals, making it "easy to use" and making the website more like a SPA.

  However, animateing rectangles to specified positions is usually not an ideal effect for page animation transitions. Please refer to Sarah's article "Page Transitions Similar to Native Animation on the Web". That's what people want (at least that possibility). That's why Jeremy joked recently when she said " most single page apps are just huge carousels " that it 's not portals . He also mentioned the navigation transition proposal proposed by Jake a few years ago.

  I like this proposal. It focuses on the needs of users. It also asks why people choose JavaScript frameworks instead of using the features provided by the browser. People choose JavaScript frameworks because browsers do not provide certain features: components such as tabs or accordion; DOM differences; controlling the style of complex form elements; navigation transitions. The problem that the JavaScript framework is solving today should be considered as the R&D department of tomorrow's Web standards. (Instead, I firmly believe that the goal of any good JavaScript framework should be to make itself redundant.)

  So, what is the best rendering method? What suits you is the best, but the following hierarchies may have some general meaning:

  1. Use as much static HTML as possible
  2. Use static HTML-based edge functions to handle dynamic content
  3. Then use the HTML generated by the server
  4. Client rendering is only performed if absolutely necessary