mootoday

Wasm Components, deployed on wasmCloud.

IMHO, that's the way to go. Instead of hundreds of megabytes or even gigabytes, we're talking kilobytes, sometimes megabytes for each unit of compute.

Actually sandboxed environments per component.

Add/remove permissions of who can execute what at runtime.

But then again, I'm biased towards modern tech and while it often turns out I was right on the money, it's not always the case.

Do your own research and such, but FYI about wasmCloud.

I use ts-rs [1] in my project to generate Typescript definitions. The files are copied to the web app automatically.

[1] https://crates.io/crates/ts-rs

That was a great intro to clap, thanks for writing it up!

I've been building clap CLIs for a while and started to put together a template: https://github.com/mootoday/cli-template.

It also includes a crate I developed to reduce the boilerplate code for nested commands: https://crates.io/crates/clap-nested-commands

Why containers when you can have Wasm components on wasmCloud :-)?!

https://wasmcloud.com/

This is great, lots I learned by looking at your code and the dependencies you use!

I started a similar thing, although not as feature-rich as yours. My goal was to follow CLI best practices and add all the boilerplate one needs to build a Rust CLI.

https://github.com/mootoday/cli-template

Worth noting some are cloud-only whereas others like Jetify's Devbox work locally and in the cloud.

I wrote about that years ago and the article is as valid today as it was back then, IMHO.

https://mootoday.com/blog/dev-environments-in-the-cloud-are-...

I've used Devbox by Jetify for two years. Never looked back.

https://github.com/jetify-com/devbox

Leaving this here as it's by the creator of Insomnia: https://yaak.app/

Sounds like you're looking for https://yaak.app/.

Did anyone say debugging?

I've followed https://debugbetter.com/ for a few weeks and the content has been great!

No

Pretty sure you'd have a more lightweight experience with https://www.jetify.com/devbox.

Happy to set it up and demo if you can share (or DM) a repo URL.

I hear you, Nix has been nothing but a waste of time for me every time I tried to do anything with it.

Devbox abstracts it and the only time I had to do a nix-specific thing was when I needed a flake to install a CLI from a GitHub release.

Thank you, TIL about ubi! My brain is now compiling a list of places where this will replace either a shell script or flake for my projects :).

Tasks sounds similar process-compose which is bundled into Devbox. I'll have to read up more on tasks though to see if that's an accurate assessment.

Nix is definitely a double-edged sword... One thing I like about Devbox is that it keeps Nix mostly (!) out of sight, mostly unless I want a binary from a GitHub release :).

I've used Devbox for two years for my projects and any work I've done for my clients.

I'm curious what some of the mise features are you like.

I read the project's Readme and all I'm left with is "why?".

I use Devbox[1] and get access to the entire Nix ecosystem, done.

[1] https://github.com/jetify-com/devbox

All I can say when I see Homebrew: "I replaced Homebrew with Devbox" [1]

[1] https://mootoday.com/blog/i-replaced-homebrew-with-devbox

Meta also uses React and we know what mess that introduced to the world...

I've worked with remote dev environments for many years, including some time with one of the providers of such a service.

It became clear to me that cloud-only is not the way to go, but instead a local-first, cloud-optional approach.

https://mootoday.com/blog/dev-environments-in-the-cloud-are-...

I had done the same before I learned about Devbox.

It's very lightweight and gets very powerful combined with `git worktree` to work on multiple branches in parallel, each with its own database instance.

For me, the key push towards using it as a Homebrew replacement was the fact that I already used Devbox to create isolated dev environments for individual projects I work on.

Now I have one tool to manage all dependencies.

Other than that, it likely comes down to personal preference.

One neat thing is `devbox global push/pull <repo>` to persist my config in a repo.

There's an interesting alternative to Homebrew: Devbox

It abstracts Nix in a way you don't have to know or learn anything about the Nix language.

I wrote a few words on how I use it instead of Homebrew [1].

[1] https://mootoday.com/blog/i-replaced-homebrew-with-devbox

https://mootoday.com/blog/i-replaced-homebrew-with-devbox

If I end up building a web app to display notifications from all sorts of services, any of these three options would likely be a good fit in the architecture and save me a ton of time.

Thanks for sharing the links.