Loom Web Server

Introduction

Normally if you want to host a website, you prepare the website and then upload it to a server. This could be a nginx, something like github pages or even a fancy next.js app. This process often includes a separate compilation step that turns your content into the HTML you can then give your visitors. Getting the files on a server can be as simple as a single scp but often this is much more complicated and has a lot of drawbacks. For example I can't easily use scp on my phone.

I don't like this.

I don't want to copy files around, run build pipelines, execute deployments and so on just to get a bit of HTML online. I don't want to have steps between me writing something and the thing appearing on my website. I want to write a page, hit save and then forget about it.

So for a while I had this idea of a Web server that I could update and patch while it is running. Loom is the realization of that idea.

What is loom?

In short: a server that can be updated while it's running and provides tools to edit its own content.

Loom has a couple of pieces but the most important piece is the folder that contains all the content for the website. This folder is watched by the server for changes so visitors will always get the newest version of a file. Make a change and it's live. Need a backup? Just download the folder.

An admin UI allows you to edit files on the fly. No more ssh, scp or deployment pipelines. Loom provides you with everything you need to manage your website.

One server for everything. Not only can loom serve static files, you can write templates and fill those with data or script routes that will do whatever you want. You even get a built-in database for all the dynamic data. All of this with no deployments. Add a new API and its instantly available.

HTML over Markdown. All the stuff you can easily do in Markdown you can also do very easily in HTML. Headings, tables, lists, fat or cursive text and so on. Markdown is nice for notes but for websites I rather write real HTML.

Why not use a CMS instead? Those can be dynamically updated too.

True. I do have a couple of arguments against CMS:

• Vendor lock-in If you write your website in a CMS you are forced to use it forever. If you host on a big CMS provider and later decide you want to move you often can't simply download your stuff and move it somewhere else. They might use a propriatery data format or wont offer a way to easily download your content.
• Single use-case A CMS based blog or website can only serve mostly static content. This is fine for most applications but sometimes you want to have something a bit more specialized, a bit more dynamic. A couple of JSON API endpoints, a page showing the last bluesky posts you have liked, a comment section under a blogpost. Normally you would need a full backend for stuff like that. A CMS can't dynamically serve you a custom API or store comments.
• Focus on multi-user Content management systems are often built to be used by multiple users. This is not bad per-se but it is a feature I simply don't need for a website managed by me. Assuming you have multiple users working on a website makes many things much more difficult. Who is allowed to do what? What happens when two users edit the same file?