The entire idea behind Remix going the SSR route is that SSG and ISR have a major flaw, which is when dealing with websites with lots of pages and dynamic data. At this point you might be wondering “Why would Remix limit itself to only SSR? SSG is awesome and ISR is like SSG on steroids”. Remix on the other hand takes a different approach by placing all bets on only SSR as the solution. The focus with Next.js is being able to switch between any of these options within the bounds of the framework. This approach is somewhat like a hybrid of SSR and SSG and is suitable for static websites with some dynamic content. Incremental Static Regeneration (ISR) - which is exactly like SSG, but you can instead set a time interval for your pages to be regenerated at these intervals.This approach is suitable for static websites that have very little to no dynamic data, else all of the web pages would have to be regenerated whenever there is a change in data.

Static Site Generation (SSG) - where you can generate all your pages ahead of time during the build time and send only the requested page to the client when prompted.This approach is suitable for websites with a lot of dynamic data and content that change often. Server-Side Rendering (SSR) - where when requested, your pages are always fully rendered on the server on-demand before getting sent to the client.Next.js comes with three different page rendering strategies: As you might have guessed, this automatically solves most of the problems plaguing client-side rendering.īut Next.js and Remix go about server rendering pages differently. These come with the primary purpose to have the requested web pages built and rendered on the server before sending the fully constructed page to the client. In a bid to solve the drawbacks of client-side rendering came the need to have dedicated frameworks such as Next.js and Remix. Hence the birth of dedicated React frameworks for creating websites that are rendered on the server before being sent to the client - Next.js and now Remix. Issue with caching - Since the actual HTML content is not available in the initial render, the HTML structure of the page cannot be cached.Slow Initial Render - It takes a while to load up the first contentful page when a user first lands, the webpage remains blank until Javascript is loaded and the content is rendered.SEO Problems - The content is not reliably indexed by search engines and social media bots as when a bot first hits the webpage, it’s the initial HTML shell that is met.But there are a few major drawbacks associated with client-side rendering: This is the general idea behind Client-Side Rendering (CSR) frameworks such as React, Vue.JS, Svelte, etc. So, the HTML file that is initially sent stays the same, but the components and contents are replaced by JavaScript with those of the requested route - these types of websites are known as Single Page Applications (SPA) as it has client-side routing and only a single HTML file is used to render all of the web pages. From there, the browser fetches the JavaScript file responsible for rendering the actual page in the HTML - which is then used to render the appropriate components and content of the requested page - hence the term “Client-Side Rendering (CSR)”.īut user navigation will trigger the client to re-render the HTML file to match the route the user requested. In a traditional React app, the web page is rendered on the client-side where when an initial request is made for that webpage, the browser is sent a shell of an HTML page lacking any pre-rendered content. If you’re new to the world of server-rendered applications, you might probably be wondering, why exactly do we need these frameworks? Remix vs Next.js: Why Do We Need These Frameworks? In this post, we will compare these frameworks by highlighting what makes each unique and where they shine the most. It’s actually quite exciting to see Next.js having a new competitor as it has only ever had Gatsby as its main competitor.

Twinkle lights repix app