You want to deploy a website. Where should you start?

In the last two months, I redeployed this personal website and deployed FluidFramework.com for the first time. I made some mistakes along the way, but I ultimately chose to create a static website for both. It’s been a good choice for both.

In this post, you will learn when and why a static website is a good choice and which tools I used for this website. Next time we’ll talk about why I chose those tools over others and how you can deploy your website using the same tools I used.

Should your website be a static website?

A static website is a website that is delivered to your user’s web browser as it is stored. A static website does not rely on a web server to dynamically change the appearance or functionality.

For instance, this blog post is stored as azure-static-webapps-1.html in Azure Blob Storage. The sidebar to the left and footer on the bottom are added into the .html file before they are uploaded to Azure Blob Storage.

Let’s talk about the actual delivery of files for a second.

My personal website delivers four types of files to your browser: .css, .html, .js, and various media files. The .html file is first. In the HTML, there are references (tags) to the .css, .js, and media files necessary to make this page look how it does.

Many people choose to “bundle” these assets directly into the .html file. If I bundled the assets, the .css, .js, and (although less likely) the media would be included in the .html file and there would be no need to fetch those files later.

This is just how Hugo, the static site generator I'm using, works and I wasn’t too picky about it.

All else being equal, static websites are often more cost-effective to host, easier to develop, and quicker to render. For a blog like this one, these are the core attributes I was considering. I want a cheap, easy, performant personal blog.

There are a few other reasons you may choose to build a static website, but they were less important to me.

• Security - With no JS & no servers there’s less to manage
• Tooling - Static website generators are mature and customizable with large communities.
• Hosting - Static website hosting has also become very simple.
• Few dependencies - no React, Vue, _.js to import

Prior to the Second Age of JavaScript, many websites were static websites. The internet is more powerful and you have more choices.

When shouldn’t your website be a static website?

If your website will have data that changes dynamically, like Facebook.com or Office.com, your website probably should not be a static web app. In both of those cases, every user receives a slightly different HTML file from the server.

A lot of the modern web is not delivered as static web apps and there are good reasons for that!

Here are some application types that are typically harder to implement as static web apps

• Storefronts
• Social Media
• Login Pages
• Productivity Tools
• Games

There’s a theme to this list: it would be impossible to list every HTML page. That is, if Facebook had to statically generate the HTML pages necessary for every user who visits the site, they couldn’t do it! There are an infinite number of ways to view the data on Facebook. Facebook must generate a new HTML page whenever a specific user visits a specific page.

Next Time

In the next post, we’ll talk about the tooling I used and how you can get started. If this post was a why and a what, next time we’ll do “which and how.”

• Hugo - Static Site Generator
• Github Actions - Build & Deploys the Hugo Site to Azure Static Website
• Azure Static Web Apps - Hosts the website
• Azure Frontdoor - Additional caching & domain management