JavaScript still can't ship a full-stack module
Despite advances in the ecosystem, JavaScript still lacks a native way to ship a full-stack module—combining frontend and backend code in a single, shareable package. The article highlights the ongoing fragmentation between client and server runtimes, which forces developers to rely on workarounds rather than a unified standard.
Background
- The JavaScript ecosystem (Node.js, Deno, Bun) still lacks a standard way to write and distribute a single module that works seamlessly on both the server and the client (browser).
- Unlike Python or Go, where a package can be a single import across environments, JS tooling forces developers to maintain separate entry points, build configurations, or dual-package formats (e.g., CJS vs ESM) for the same logic.
- This is a recurring pain point for full-stack frameworks (Next.js, Remix, Astro) and library authors who want to share code — like validation schemas, types, or API clients — between frontend and backend.
- The piece argues that despite years of proposals and tooling work (package.json "exports" field, bundlers, the "isomorphic" pattern), the problem remains unsolved at the runtime and registry level, limiting the "full-stack module" vision.