The main difference is that smallweb use deno instead of docker for sandboxing apps, and leverages url imports (which can be used to distribute complex apps like VS Code):
```
import { VSCode } from "jsr:@smallweb/[email protected]"
const vscode = new VSCode({ rootDir: Deno.env.get("SMALLWEB_DIR") });
export default vscode;
```
You can play with a live instance of smallweb at https://demo.smallweb.live
Yeah, a single-runtime (smallweb) instead of any language (dokku) + I'd probably say the avoidance of using git for the delivery would be the two biggest differences I can glance.
I want to "develop in prod", not rely on successives git pushes to see changes.
If I need semantic releases, I publish the dev version as a package on jsr, and I then import it from the "prod" app.
I still uses github as way to store my apps though, you can find them at https://github.smallweb.run
[0]: https://github.com/pomdtr/smallweb-vscode/blob/main/extensio...
[1]: https://github.com/gitpod-io/openvscode-server https://github.com/coder/code-server etc
You can play with it at https://vscode.demo.smallweb.live (the code is located in the `vscode` folder)
What is old is new again :) Back when I started development, we did this via git remotes, and some projects even did what you created and created environments mapped from git remotes to apps running with subdomains (like Dokku is probably the first/most memorable FOSS service for this back in the day).
And before that, I'm sure people were doing the same thing with Java WARs or similar, and before that, something else but similar.