Hacker News new | ask | show | jobs
by pomdtr 494 days ago
This looks fantastic, I'll make sure to try it!

I've been working on a similar platform (https://smallweb.run), which allows me to host all my side projects from a single root folder. Each subfolder automatically becomes a subdomain, and I can just use vscode remote ssh or mutagen to live edit my websites.

3 comments

> and I can just use vscode remote ssh or mutagen to live edit my websites

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.

Yeah dokku is an inspiration!

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/vscode@0.1.7"

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

By "VSCode" here you mean something like a HTTP API for file read/write[0] that can be used from VSCode, I think? VSCode also can be made into a web app[1], but I don't see that happening here.

[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

By vscode I mean vscode-web + an fsprovider extension.

You can play with it at https://vscode.demo.smallweb.live (the code is located in the `vscode` folder)

> The main difference is that smallweb use deno instead of docker for sandboxing apps

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.

Yeah, I see smallweb as a playground.

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

Very cool, very similar to SSHFS support on https://pico.sh/pgs and https://pico.sh/tuns
I love pico.sh! Some of their service can be reimplemented as smallweb apps.

Ex: prose.sh is similar to https://jsr.io/@tayzendev/smallblog, an app created by a member of the smallweb community (we have a server at https://discord.smallweb.run). You can see it running from smallweb at https://blog.tayzen.dev

I even use the underlying lib ssh implementation of pico.sh in smallweb (https://github.com/picosh/pobj), and I plan to introduce a cloud service similar to their (you can subscribe to the waitlist at https://cloud.smallweb.run)

`live edit my websites`

This will only work if your websites are in vanilla javascript / html right ?

Smallweb also allows you to run server-side code using deno. The main process watch for changes in the app directories, and automatically restart the corresponding deno processes when a change is detected.

If you ever interacted with cloudflare workers or https://val.town, it is a similar experience.

Feel free to join our discord at https://discord.smallweb.run if you're curious !

Interesting, thanks for sharing. Will explore
If you want to get notified on future updates, you should join the community discord at https://discord.smallweb.run