rename_exe doesn’t do anything on the aqua backend either (and isn’t a documented option). I’m on mise 2026.5.10 right now though so if you fixed something recently I might be missing out!

Then why is the PR quality still a problem?

Going through your article on the topic [0], I think the only strong point that SFWAs have which SPAs don’t is: “you can download and run them completely offline”. This highlights the best use case for SFWAs – it is something that you might want to download and run offline. Hypervault [1] is a better example here, IMO.

SFWAs do have drawbacks, mainly the inability to cache things independently (it’s all-or-nothing), or to download things in parallel. So basically it boils down to two questions:

• Is my app something users would want to run offline?

• Will I update it frequently enough for the cache problem to matter?

And it’s up to you to find the balance here.

[0]: https://gods.art/articles/single_file_web_apps.html

[1]: https://gods.art/articles/single_file_web_apps.html#hypervau...

---

Actually I’ve just thought of something.

If it still makes sense to distribute your app as an SFWA, but you have to use a bundler, you can have the best of both worlds by making two builds: one as an SFWA, and one as a “traditional”, chunked static SPA. It should be fairly easy (just make two different configs, building from the same source).

The default docker-compose definition comes from aqua:docker/compose though, which does not support rename_exe. You have to specify github:docker/compose instead.

Neat! Got curious if you can do that without a temp file, turns out you can:

  #!/usr/bin/osascript -l JavaScript
  
  ObjC.import("AppKit");
  $.NSFileHandle.fileHandleWithStandardOutput.writeData(
    $.NSPasteboard.generalPasteboard.dataForType("public.png"),
  );

Edit:

> `docker compose` is a bit trickier

I’ve tweaked my setup a bit. This installs it as `docker-compose` without symlinking required:

  "github:docker/compose" = { version = "latest", rename_exe = "docker-compose" }

  DOCKER_CONFIG="${DOCKER_CONFIG:-$HOME/.docker}"
  mkdir -p "${DOCKER_CONFIG}/cli-plugins"
  ln -s "$(mise which docker-compose)" "${DOCKER_CONFIG}/cli-plugins/docker-compose"

Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).

I suppose it’s more of a CYA nowadays than that. (Well, at least one can hope.)

> You can still cache the HTML.

But then any time you update any part of the app, the user has to re-download the whole thing. It is also a problem with many traditional frontend builds, but if you carefully split it into chunks, you can update parts of the app while most of it stays cached.

See e.g. Linear’s approach to vendor dependencies: https://performance.dev/how-is-linear-so-fast-a-technical-br...

---

The strong point of single .html apps is, of course, that you can run them locally without setting up a web server or anything, and deploy anywhere you want by just uploading it. But it is a fairly niche thing IMO.

Doesn’t seem to have Compose support though, but it’s probably not impossible to build upon.

And of course, it also uses VMs, though unlike Docker, it’s one (micro-?) VM per container: https://github.com/apple/container/blob/main/docs/technical-...

https://www.lightspeedhq.com/ecom/

https://www.lightspeedhq.com/pos/retail/api/

Well, it does makes sense. I’d be more interested in the rejection rate for businesses that are allowed but are just starting up.

Stripe has a Get started button. You click it, fill out a form, get your site approved in maybe a day, and start making money.

Adyen has a Talk to our team button. You close the tab and never think about it again until you’re making serious money.

---

Edit: that is, of course, by design. Adyen doesn’t want small businesses. From the sibling comment:

> only able to support businesses currently transacting more than €5M per year

I am Russian and I do oppose Putin’s regime. My family is in Russia, though. If I send them money (which), and they pay for, say, groceries, which are taxed, some tiny part of my money will be used to fund the regime and the war. I am very disappointed but there is no way for me to just yank all my family and friends and relocate them to a less fucked-up jurisdiction.

Doing business with Yandex is a whole other beast. Kagi can choose to use a worse search engine API which doesn’t involve paying money to a Russian company. Are there some market forces at hand here? Maybe a lot of Russian expats pay for Kagi because it has good Russian-language results? I don’t know.

Edit:

> But is Yandex government owned?

It isn’t, but I really doubt it has no ties with it. It would be interesting to trace and see if Yandex Cloud’s international branch money gets back to its Russian counterpart, or if they are two separate things.

If there was a way to run Mailspring on the web, I’d switch in a minute! I’ve tried to port it one time, but it got a bit tricky.

Mailspring uses a native module for syncing the mail, which would have to run either on a server somewhere or in a web worker. I think the web worker makes more sense nowadays, and would make it an offline-first app, but there’s a catch: how do you connect to IMAP/SMTP from a web browser?

Running the sync engine on a server is possible, but you have to have a server. It could make sense, though, if you’re running your own email server and want a killer webmail app to go with it.

(Also... Thunderbird is not that different from an Electron app itself. It uses Gecko instead of Blink, and has a few bits of XUL here and there, but the core premise is the same. Though it doesn’t use React at least!)

Something like Sega Toys Homestar?