Why?

In the last 10 years, the web has come a long way. Browsers have standardized on HTML5 features, and they do things that we only dreamed of (or built with plugins) in the 2000s. CSS and Javascript have become rich languages and for better or worse, pretty much everyone uses one of 2 browsers, both of which have excellent spec support.

And yet, building a website is in many ways harder than it ever has been. We have complex toolchains for cross-compiling js and css from non-standard languages like JSX and Sass, and even simple blogs require rich knowledge of webpack or other build tools just to push to a simple static host.

Sadly, these "omakase" tools also homogenize the web. We normalize on tools that limit the creativity of the person building a website by standardizing on information architecture that isn't always the right solution for the problem. The web of the 90s and 2000s was a vibrant, if ugly at times, mash-up of creativity and exploration. We've improved in many areas like accessibility and usability, but could stand to bring creativity back to the web now that we have a solid foundation.

The world of hosting and infrastructure is also fraught. Despite the capabilities of these rich build tools, we often use servers and databases instead of generating static content. If a blog only ever changes when you change the posts, why do you need a server that has a connection to a relational store, that runs a query when a user requests it, and that has a money and energy cost similar to a social network?

Finally, despite the fact that versioning tools like git are common for code, websites are becoming more and more ephemeral and it's not yet common to store historical versions of content. We write directly to DBs, and the prior content is lost forever. We're also pushing tons of content into walled gardens like Facebook or Medium, platforms that don't have an incentive to keep your content durable and visible, and who use your content for surveilance and profit.

Archival: easier to build

The primary purpose of archival is to make it really easy to build websites that are really cheap and easy to maintain. This is in part so that folks who build websites for a living can spend less labor on maintenance, but it's also intended to make it so more people can participate in building the web.

Archival attempts to solve this problem by using plain HTML as the primary tool for building websites. However, hardcoding HTML has some limitations in terms of maintainability, and Archival attempts to resolve them as minimally as possible. In addition to providing a live-reloaded HTML editing environment, Archival supports a very simple templating language called Liquid, originally developed at Shopify, which should be familiar to many people coming from an e-commerce maintenance background.

This allows for some scalable patterns around layouts and control flow that lowers the barrier of entry to building maintainable and interesting websites.

Archival: easier to update

Archival has no database, instead using version control to manage "objects", which are just simple files written in the TOML language.

These objects are organized directly inside a folder, and are loaded at build time so that they're available directly inside your HTML code via Liquid variables.

The objects can contain values of scalar types, which Archival automatically parses. This means that to update an Archival website, all you have to do is add an object file. Archival provides a web interface and mobile apps for updating these files in the same way that you might update a social media post.

This approach also has an intentional side-effect of versioning the content with the website, meaning that you can see any version of the website from all of its history by checking out a given git sha and building it with Archival. Your version control system then also provides the permissioning and history layer that is a large part of many platforms, making Archival stay simple and single-purpose.

Archival: easier to maintain

Archival generates fully static websites. This means that you can deploy them pretty much anywhere with very minimal serving infrastructure.

When you run archival build, the dist folder it generates can be uploaded to an S3 bucket or another static host to make a very simple website. To make things even simpler, services like Netlify, Github Pages and Cloudflare Pages make it easy to rebuild when the content of a git repository is changed. Archival is intended to work with these systems exceptionally well, and in most cases, can be configured with a single line of code in these systems to allow you to auto-deploy your website whenever the content changes.

Because content is versioned with the site, this also means that if you're using Archival's editing apps, the content will automatically update on your production website whenever you add or modify objects via the app.

One of the biggest advantages to this approach is that it's exceptionally inexpesive. Netlify and Vercel cost ~$10/mo for as many websites as you can possibly build, Github Pages is free forever, and S3 costs pennies per month for most websites.