Types of Rendering, Using GitHub Pages as the Core Example

GitHub Pages is a free static hosting service that GitHub provides. It’s designed to serve static files (like HTML, CSS, and JavaScript) directly from one of your repositories.

While it works perfectly with Jekyll for static site generation (SSG) right out of the box, you aren’t limited to just using Jekyll. Any set of pre-built static files can be deployed and served.

Core Purposes

• Hosting project documentation (often by converting Markdown with Jekyll).
• Showcasing developer portfolios and project demos.
• Encouraging developers to use Git-based workflows for web development.
• Keeping users within the GitHub ecosystem.
• Offering a free alternative to other hosting providers like Netlify, Vercel, and Cloudflare Pages.
• Beneficiaries: This is great for open-source maintainers, developers, students, small teams, and educators.

Hosting Model

GitHub Pages uses a static hosting model, which means dynamic sites are not supported.

It also only supports Pre-rendered files (which are prepared before being sent to the user’s browser) or Client-Side Rendering (CSR). Server-Side Rendering (SSR) is not supported.

For some context on those terms:

• Static Files (Pre-rendered files): These are pre-built HTML, CSS, and JS files served without any server build process. This uses minimal compute power and is very fast. A plain HTML site on GitHub Pages is a perfect example.
• SSG (Static Site Generation) (Pre-rendered files): With this method, pages are pre-rendered at build time (using tools like Jekyll, Hugo, or Astro). It’s fast at runtime because the CDN just serves files that are already generated.
• CSR (Client-Side Rendering): This shifts the rendering work to the user’s browser (think of React Single Page Applications). This can be slower on low-end devices because it involves heavy JavaScript workloads.
• SSR (Server-Side Rendering): This is where HTML is generated dynamically on the server for each request (for example, Next.js SSR apps or Flask apps). This requires higher compute power and is suited for dynamic content.

This static-first approach ensures that the compute requirements are kept to a minimum.