macos-cross-compiler VS container2wasm

Make is excellent if you use it properly to model your dependencies. This works really well for languages like C/C++, but I think Make really struggles with languages like Go, JavaScript, and Python or when your using a large combination of technologies.

I've found Earthly [0] to be the _perfect_ tool to replace Make. It's a familiar syntax (combination of Dockerfiles + Makefiles). Every target is run in an isolated Docker container, and each target can copy files from other targets. This allows Earthly to perform caching and parallelization for free, and in addition you get lots of safety with containerization. I've been using Earthly for a couple of years now and I love it.

Some things I've built with it:

* At work [1], we use it to build Docker images for E2E testing. This includes building a Go project, our mkdocs documentation, our Vue UI, and a ton of little scripts all over the place for generating documentation, release notes, dependency information (like the licenses of our deps), etc.

* I used it to create my macOS cross compiler project [2].

* A project for playing a collaborative game of Pokemon on Discord [3]

IMO Makefiles are great if you have a few small targets. If you're looking at more than >50 lines, if your project uses many languages, or you need to run targets in a Docker container, then Earthly is a great choice.

[0]: https://earthly.dev/

[1]: https://p3m.dev/

[2]: https://github.com/shepherdjerred/macos-cross-compiler

[3]: https://github.com/shepherdjerred/discord-plays-pokemon

It will depend heavily on the docker image you're trying to ship. For example with macos-cross-compiler[0] the resulting binary is over 2GB. With python:alpine[1] it's only 25MB.

Because image isn't copied whether the image is 2GB or 25MB the startup time will be nearly instantaneous for both.

The runtime adds 6-7MB of overhead although I expect that this can be reduced to less than 3MB with some work.

[0]: https://github.com/shepherdjerred/macos-cross-compiler

The existence of vscode.dev always makes me wonder why Microsoft never released an iOS version of VSCode to get more users into its ecosystem. Sure, it's almost as locked down as the web environment, but there's a lot of space in that "almost" - you could do all sorts of things like let users run their code, or complex extensions, in containers in a web view using https://github.com/ktock/container2wasm or similar.

Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...

As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.

[0]: https://github.com/ktock/container2wasm

[1]: https://wasmer.io/

Really impressed by the depth and breadth of this project, well done!

A particularly interesting part is the socket layer inside the browser. Other people solving this problem have previously used a proxy to a server that does the real socket implementation. This means you can't have a "browser-only" solution.

The author has solved this (for HTTP/S only) by proxying HTTP requests and then re-creating them as fetch requests (details here: https://github.com/ktock/container2wasm/tree/main/examples/n...). I'm very interested in using this approach for my own project Runno (https://runno.dev).