Static sites are a simpler kind of web site because they don’t have a traditional server. The only server that is involved is a static asset server which you don’t have to monitor or maintain.
That functionality is usually created with complex tools like Webpack, Babel, and npm. Using these tools effectively is far from simple.
Before you dive into any of these complex tools, you’ll probably want to know:
How do they all fit together? What’s the bird’s-eye view?
So, to get you started on your path to static site mastery, I’ve prepared a few diagrams that show you how static sites work at a high level.
We’ll look at static sites from four viewpoints:
- End Users: How do users get your site?
- Deployment: How do you upload your content onto the interwebs?
- Bundling: How does your code get converted into files that you upload?
- Development: What does my workflow look like?
Let’s start at end. When you are all done and your static site is pushed live, your users’ browsers will download your assets from your static asset server.
Pretty simple right?
Your assets have to get onto the internet somehow right?
The way you get your assets onto your static server / storage service varies based on the service.
That last diagram is pretty simple because I intentionally left out all the bundling details.
Bundling is the process of converting the code you write (usually many files) into the code your browser uses. Some common bundling steps are:
- process CSS
Bundling configuration varies a lot from project to project. One thing that is always the same is the package manager, npm.
Here's the bundling overview:
This particular diagram depicts a Webpack React project with PostCSS and autoprefixer:
- Webpack: Manages the entire bundling process. Could be replaced by another bundler like Rollup.
- React: View library. Could be replaced with another view library like Vue.js.
- PostCSS: Plugin-based CSS processor. Could be replaced with another CSS processor like Sass.
- Autoprefixer: PostCSS plugin that adds CSS prefixes like
-webkitso you don’t have to.
Any of the above components could be swapped out for other tools, but these are common choices.
As you can see the bundler plays a huge role. We are using Webpack as our bundler, and in the diagram there are 4 Webpack loaders and 3 Webpack plugins.
Loaders are basically plugins, but they are a specific type of plugin. They are responsible for processing particular types of files.
I’ve only used four loaders on this occasion, but there are many more loaders.
- babel-loader: Loads
- css-loader: Loads
.cssfiles to be used by other loaders.
- postcss-loader: Processes
.cssfiles with a series of plugins, in this case the only plugin is autoprefixer.
- style-loader: Includes your CSS files as a string within your
.jsbundle. This way a single file can include both code and styles.
In this case the plugins are only used for production. But there are many other useful webpack plugins.
- ExtractTextPlugin: Remove CSS from the
.jsand output as a separate
.cssfile. It is awkward that the CSS is injected and then removed, but this is the way it is done.
- SourceMapDevToolPlugin: Creates a source map.
Of course we cannot forget development. In development further tools are useful for a speedy workflow.
I hope this helped to give you a high-level overview of one way that modern static sites are built. If you are a visual learner like myself, join the mailing list for more articles with diagrams like those above.