Olivier Forget

Dropserver uses Deno as its app runtime and sandbox, and Deno is done. So what does this mean for Dropserver? It’s not good. But then again things weren’t going swimmingly for DS development lately. I lost some courage for a couple of reasons. Why I built Dropserver Endlessly frustrated by siloed and predatory social media corps, I wanted to give regular people a way of controlling the web services they use.

Let’s say you wrote a little web-app for your own use, like a home cooked meal. You made it just for you and your family and maybe a few friends and you want to serve it so that they can access it from their devices. How hard could that be? It turns out there are gotchas everywhere. The Goal As the developer of Dropserver I think about how people might host tiny personal web services a lot.

In my introduction to BackflipHTML I wrote: I want to embrace Web Components. If at all possible, I want my templates to serve as the single source of truth for the component in all its states. I do not want to write HTML or CSS inside of JS strings. That means that in addition to turning templates and data into a string of HTML on the backend, it should have the ability to update the DOM after that HTML is read by the browser.

When I first wrote about BackflipHTML last week I mentioned my next challenge was to support Web Components. The first step in that journey is to support using custom elements as partials. BackflipHTML Partials In BackflipHTML partials are a unit of a template. It’s one bit of reusable HTML. Here is how you define a regular partial in Backflip: <section b-name="cat-alert"> <h1>Cat: {{ cat }}</h1> <p b-slot></p> </section> And here is how you would use it:

I wrote my first website in Notepad. There were no developer ergonomics whatsoever. No syntax highlighting, no linter, no autocomplete, nothing. It was 1996. Since then I’ve written HTML by concatenating strings in Perl, by tossing a PHP and HTML salad, more string juggling in the browser, followed closely by imperative mutations to the DOM using Prototype.js. More recently I’ve suffered the pain of Go’s HTML templates, and I’ve even reached for Mustache templates as late as 2022.

This is the progress report for Dropserver for March 2026. The previous report is here. This is going to be a short update because I got very distracted with a different project midway through the month. Continuing Work On Removing DropIDs See the previous few updates for more info on this. I continued to grind away, making progress and pretty close to having something releasable. However before mid-March I got sidetracked with a new project, so progress on Dropserver stopped for now.

This is the progress report for Dropserver for February 2026. The previous report is here. This month I kept grinding away on removing DropIDs from the hot path of authentication in appspaces. See the November-December update for an explanation of what it’s all about. Showing User Conflicts in the UI A consequence of removing dependence on DropIDs and also adding authentication via Tailscale means that each appspace user can be identified through different identifiers (their tailnet ID, their DropID, and in the future probably their email address.

This is the progress report for Dropserver for January 2026. The previous report is here. I started the year by refreshing my personal note taking app, then I got back to work making ds-host more flexible with domain names, in particular making them unnecessary. Updates to Illuminoted Dropserver App Illuminoted is an app I wrote after getting fully fed up with the state of note-taking apps. It’s a very personal app, full of quirks and inadequate user experiences which is why I haven’t yet formally published it online as an installable Dropserver app, though I probably should.

This is the progress report for Dropserver for November and December 2025. The previous report is here. In November I began work on removing the dependence on domain names in ds-host. Domain Names in Dropserver When I started writing Dropserver I thought of it as a very standard server program. The main difference was that it served apps that could be easily installed through an interface. Lately I have started peeling away the assumptions that go into making a server.

This is the progress report for Dropserver for October 2025. The previous report is here. This month I continued thinking about how to make ds-host easy to install, but I also got to work on some real improvements. In particular I found out that my MacOS build of ds-dev was broken… Fixing Releases to Support arm64 My Github Action that builds the Dropserver releases used the macos-latest image to build ds-dev.