DevContainers vs Nix Flakes: Native Addon Compilation Speed vs Cross-Platform Onboarding

Context

A team spanning Linux, macOS (Apple Silicon), and Windows needs a repeatable development environment for a Node.js project that compiles native addons (e.g., sharp, better-sqlite3, canvas) while preserving sub-second hot-reload during development.

Constraint

DevContainers standardize on a Linux container via Docker, giving zero-config onboarding (Docker Desktop, GitHub Codespaces, Gitpod) but introduce 10–100× filesystem latency on macOS/Windows bind mounts, slowing node_modules access and incremental builds. Nix flakes provide hermetic, reproducible environments with native-speed hot-reload on Linux by avoiding container overhead, yet require every developer and CI runner to adopt Nix (still experimental CLI flags) and lack a blessed pattern for sharing prebuilt native-addon caches across heterogeneous architectures without a binary cache server. Cross-compilation from macOS aarch64 to Linux x86_64 for native addons remains fragile (toolchain mismatches, node-gyp Python version drift).

Open Questions

1. For a team that cannot mandate Nix adoption today, what DevContainer configuration (mounts, features, postCreateCommand) mitigates bind-mount latency enough to keep hot-reload under 500 ms on macOS/Windows?
2. If the team adopts Nix flakes, what is the minimal viable binary-cache setup (e.g., Cachix, GitHub Actions artifacts) that lets macOS and Windows developers pull prebuilt Linux x86_64 native addons without maintaining a dedicated cache server?
3. Are there documented patterns for a hybrid approach—using DevContainers for onboarding and CI, while offering an opt-in Nix flake for Linux developers who need native-speed iteration?