For I desired mercy, and not sacrifice; and the knowledge of God more than burnt offerings.
Hosea 6:6, The Bible
Building websites today has become easier than it's ever been. All you need is a text editor and a browser, two programs that almost every home computer possesses today (and most times, right out the box).
To make your first webpage, you can create an index.html file anywhere on your computer, stuff it with the following content, and open the file in a browser:
<h1>Hello, world</h1>
And voila! You've made your first webpage. Slap on a domain name and throw it on a hosting service and you are good to go.
So why do we need build steps on the web?
That question reminds me of a story in the Bible.
Starving on the Sabbath
Jesus was walking through a field of corn with his disciples one Sabbath day. His disciples were hungry, so they plucked ears of corn from the field and ate them. The Pharisees saw them and told Jesus that his disciples are doing what is unlawful on the Sabbath.
What was Jesus' response?
And he said unto them, The sabbath was made for man, and not man for the sabbath:
Mark 2:27, The Bible
Huh? What was Jesus saying?
Jesus was telling the Pharisees that God created the Sabbath to serve man (by giving him rest) and not so that man serves the Sabbath. In other words, instead of focusing on the work others are doing, rest (like God did on the seventh day of creation).
In this analogy, sabbath can be replaced with web. The web was made for man, and not man for the web.
But today, with so many tools on the web, web developers tend to focus on work (i.e. build steps) and tend to do more work than necessary.
Why are build steps bad?
When I say build step, I mean any step that needs to be performed before deploying your website.
As innocuous as it sounds, choosing the wrong build steps can affect 3 areas every web developer should care about:
- 👤 User experience (UX): The overall experience of a site visitor when using your website.
- ♿ Accessibility (a11y): The degree to which your website is usable by as many people as possible, including disabled people.
- 👨💻 Developer experience (DX): The overall experience of the developer when building the website.
Let's explore some popular build steps on the web and measure how each listed area is affected.
The transpilation build step
This involves converting JSX, TSX, TypeScript, SCSS, SASS, Svelte templating language etc. into HTML that browsers can render.
Advantages
- You get to write lots and lots of JavaScript/TypeScript or whatever language and no HTML. Every developer's dream I suppose 😒.
- You get to place your code in separable components that can never be effectively reused outside of the project.
- You don't repeat yourself.
- You write shorter code.
Disadvantages
- 👤 The browser has to execute JavaScript first, which could fail and cause the screen to remain blank.
- 👤 You are going from HTML to JavaScript, back to HTML. This slows down the rendering.
- ♿ The code that is converted to HTML is often not accessible, as the transpiler lacks context of the content on the page.
- 👨💻 You have to write lots of JavaScript/TypeScript or whatever language you are using. Whatever language that is chosen will not be safer than HTML, meaning you should expect more issues than usual.
- 👨💻 Iterations are slower because you have to build every time .
- 👨💻 JSX sucks! It is not as pleasant to write as plain JavaScript. Or plain HTML. (The developer suffers.)
- 👨💻 If I have to build HTML, what is the point?
The minification build step
This step involves removing all the unneeded white space and sometimes obfuscating the data in a CSS or JS file to reduce the size of the data that is sent to the browser.
This sounds like a wonderful idea.
Advantages
- You get to remove the white spaces and save 0.001 KB of wasted data. Hooray 😒.
- You get to obfuscate your code, save space and contributing to the 0.001 KB saved 😒.
- You get to obfuscate your code, making it harder for people that have capable browsers to study it 😒.
- You get a false sense of achievement that you have saved a lot of bytes sent for the user 😒.
Disadvantages
- 👨💻 Contrary to popular belief, 0.001 KB of data is not a lot saved. You get the best savings when you use
gzipto transfer your website (supported on the web as of HTTP 1.1). - 👨💻 If it breaks someday (maybe due to updates in HTML or CSS syntax), you can't deploy.
- 👨💻 A different set of code sent to the browser makes debugging a Herculean task (though web developers love this pain).
- 👨💻 If your build step has to modify your CSS or JS and can't send it as is, what's the point?
Could be wrong on this one; it seems like the advantages are more here. 😒
The Webpack build step
Webpack is a powerful tool used to bundle modules together. A module is any file that processed by Webpack. In the case of Webpack, we're talking HTML files, CSS files, JavaScript files, images etc.
NOTE: This also includes running npm run build.
Advantages
- Module bundling for easier optimization
- Code splitting
- Dependency management
- Development tools and enhancements like hot module reload and source maps
- Asset optimization like image compression, tree shaking (i.e. removing unused code), CSS and JS minification
- Loaders and plugins for processing different files
- Environment-specific builds
- Easy framework integration
- Long term caching
- Community and ecosystem
Disadvantages
- 👨💻 Modules. (I want my HTML, CSS and JavaScript files to be considered unique and separate, thank you 😒.)
- 👨💻 Code splitting is unnecessary for plain HTML because the browser needs the whole HTML to render a webpage properly.
- 👨💻 Dependency management is unnecessary for plain HTML because if you only use HTML and CSS (and build from scratch), you would have very few dependencies.
- 👨💻 Hot module reload is unnecessary for plain HTML because you could just refresh the webpage.
- 👨💻 Source maps are unnecessary for plain HTML because the code sent from the server is the same code seen in the browser.
- 👨💻 Tree shaking is unnecessary for plain HTML because all the code in HTML is used. The CSS code can be cleaned up manually.
- 👨💻 Minification is useless, as I highlighted in the previous section.
- 👨💻 Loaders and plugins are unnecessary for plain HTML because the browser handles everything for us. We just need to provide the HTML and CSS.
- 👨💻 Webpack has to be aware of the type of build. Unlike Webpack, HTML and CSS have no control over your environment. They are just languages. (Thank God.)
- 👨💻 Framework integration is unnecessary for plain HTML if you are not using any frameworks.😜
- 👨💻 Who needs long term caching when you have
Cache-Controland cache-busting techniques? - 👨💻 Sadly, you have a lot of people using HTML and CSS but not a lot of people writing it. However, you can navigate the web world if you are willing to read documentation and answers online.
Am I the only one that notices that half of the advantages are solutions to the problems caused by Webpack itself? Maybe it's just me. 😒
The SSG build step
According to ChatGPT:
An SSG stands for Static Site Generator. It is a tool that generates static HTML pages from source files, usually using templates and content written in a markup language like Markdown. SSGs are widely used in web development for creating fast, secure, and SEO-friendly websites.
Advantages
- Faster load times
- CDN compatibility
- Reduced attack surface
- No server-side processing
- Simple to scale
- Efficient resource use
- Lower hosting costs
- Content management
- Template based design
- Community support
- Plugins and extensions
- Environmental and deployment flexibility
Disadvantages
- 👨💻 No real-time content. You can't easily make changes once an update to older content has been made.
- 👨💻 Workarounds for interactivity. Because it's HTML-focused, it makes it easier to extend your code. This makes it less scalable.
- 👨💻 Slow build times for large sites.
- 👨💻 Incremental builds, complex to configure.
- 👨💻 Steep learning curve; Contrary to popular belief, I don't think it's easier than just learning things properly
- 👨💻 Dependency on build tools. And you need to keep updating them.
- 👨💻 Updating your build pipeline. This could break things.
- 👨💻 Third-party dependence for advance features. Limited by what is available.
- 👨💻 Inflexibility for certain projects. For e-commerce or similar, forget about it.
- 👤 Third-party libraries used may have a different look-and-feel than the main theme library.
The SSR build step
Once again, educate us ChatGPT:
Server-Side Rendering (SSR) is a web development technique where the server generates the full HTML for a web page and sends it to the client (usually a browser) in response to a request.
Did you catch the fallacy? Rendering only happens at the browser, not on the server. Server-side rendering is really a myth.
The server's job is to serve HTML, not to render it. But I digress 😒.
Advantages
- Improved SEO
- Faster initial page load
- Better performance on low-powered devices
- Consistent content, the server sends the same pre-rendered HTML
- Increased server load. Though this is usually a disadvantage, load on the server is generally better than load on the client. The website becomes more accessible.
Disadvantages
- 👤 Slower interaction time, because at least all of the HTML must be rendered before interaction can take place. In comparison to the alternative, this is not as bad as it sounds.
- 👨💻 Complexity. Using frameworks where you have to switch between server-side rendering and client-side rendering already sounds like a headache.
- 👨💻 Caching challenges, because static sites are easier to cache than dynamic sites. That's not too bad if you know how to use
Cache-Controland cache busting.
Maybe we should stick to servers serving HTML and not rendering it. 🤔
So what is the ideal process?
The ideal process is no build steps! That's it! You just need to run your code in the browser.
To host your code online, just copy it from your computer to the server. It should be that simple.
Why is rest important?
Jesus wanted to do all the work for us and wanted us to rest. The same is true for the web.
Tim Burners-Lee (TBL) made the web simple so that everybody can contribute. When you make things harder for people to do, you are working against the principles of the web.
It is only in rest that you can fully appreciate what TBL and contributors to the web have done. It allows you to focus on real problems on the web, and not the many build steps that don't improve the quality of what is delivered.
The bottom line
Ditch the build steps. 🛠️❌ Become familiar and well-acquainted with HTML, CSS and JS. Unlike all the web frameworks and fanciful build steps, those languages are not going anywhere.