@nikelborm Thanks for jumping in and for the great feedback! You raise some very valid points regarding WASM performance versus native targets.

I completely agree that for the primary use cases of ts-morph (linters, formatters, and CLIs running on developers' machines or in CI), we shouldn't be leaving native performance on the table by forcing a WASM backend. And I also agree that the underlying implementation details (FFI vs. WASM) shouldn't leak into the public API surface (e.g., forcing an async Project.create()). A unified backend interface that uses native FFI/IPC by default in Node/Deno, while falling back to WASM for web environments, is absolutely the right architectural direction.

However, I want to give some specific context on why I'm pushing for this and why the audience for a WASM-backed ts-morph is broader than just simple playgrounds or a couple of specific lambda runtimes. For my work, it's actually the foundational enabler.

I am the author of cdd-ts and cdd-web-ui, part of a suite for "Compiler Driven Development" (CDD). CDD provides bidirectional synchronization between API specifications (like OpenAPI) and code implementations (SDKs, Servers, CLIs). Unlike traditional string-templating code generators that overwrite files, cdd-ts uses deep AST/CST-aware parsing to perform "surgical patching". This means developers can hand-edit generated code, and the tool updates only the necessary AST nodes without destroying manual edits, or conversely, it can reverse-engineer structural changes from the source code back into a 100% accurate specification.

This is where WASM becomes mission-critical. cdd-web-ui is a central graphical dashboard that brings these polyglot compilers entirely into the browser. We need WASM for several crucial reasons:

1. Privacy & Offline-First Execution: Our users are processing proprietary, highly sensitive internal API specs and source code. We cannot send their code over the wire to a cloud backend for compilation or AST diffing. Everything must run securely and entirely within the client's browser.
2. Interactive Split-View Editing: As a user edits an OpenAPI spec, the WASM-powered compilers instantly parse, diff, and synthesize the updated SDK code in the adjacent pane in real time.
3. Zero-Install Toolchain: Users can instantly interact with multi-language ASTs and code generators without needing to install heavy local toolchains (Node, Rust, JVM, etc.) on their machine.

By switching my tooling to a typescript-go WASM backend, I've already dropped the TS parser footprint from 138MB down to 106MB. Crucially, it slashes V8 memory overhead because the massive AST structures stay inside the Wasm linear memory, exposing only lightweight JS proxies.

So while I wholeheartedly agree that ts-morph's primary Node/Deno environments should prioritize a native FFI/IPC bridge for maximum throughput, having a robust WASM build isn't just an edge case for us—it's what enables next-generation, heavy-duty AST tooling to run natively and securely in the browser.

As mentioned in the PR description, this was mostly to get the conversation started. My next steps will focus on abstracting the bridge to allow for native FFI/IPC on the desktop/server side while preserving the WASM fallback for browser clients. I'd love to hear your thoughts on preferred IPC/FFI approaches for Go <-> Node.js bridging!

PS: Live hosted WASM demo in case you're interested https://offscale.io/cdd-web-ui - everything open-source of course

This part:

Privacy & Offline-First Execution: Our users are processing proprietary, highly sensitive internal API specs and source code. We cannot send their code over the wire to a cloud backend for compilation or AST diffing.

Doesn't necessarily dictate this part:

Everything must run securely and entirely within the client's browser

Web browsers are not limited to only interacting with file systems, be it interacting with the host's native OS file system, or interacting with origin-scoped OPFS.

There are approaches like the one taken by https://npmx.dev/, which lets the user interact with a running local daemon of npmx, and NPMX's cloud never can reach any credential file stored on the device, as well as process it, while still making the user able to do all the nice interactions with private APIs and files, that are coming from the user's own machine, and not proxied through npmx's cloud, through the web interface, that's not shipped as part of any binary to the client, and is loaded as a plain https page from the cloud.

Interactive Split-View Editing: As a user edits an OpenAPI spec, the WASM-powered compilers instantly parse, diff, and synthesize the updated SDK code in the adjacent pane in real time

This part is not an achievement of WASM; any TSGO communication option in a sufficiently local context will let the dev "instantly parse, diff, and synthesize the updated SDK code in the adjacent pane in real time". And the instant part is actually achieved not by selecting any specific communication options, but by making the compiler stateful -- by enabling incremental typechecking and correctly managing the hierarchy of dependencies in a project and cross-package importing.

Lastly. Could you explain why you need the tsgo compiler packaged into WASM? Did you put all the C89, C++, C#, Ruby, Swift, etc compilers listed on cdd-web-ui into WASM as well? This is an insane amount of work, and I don't understand why you would do it when things like StackBlitz, peerd, Oh My Git, Effect.ts playground and countless others use the same approach implemented by things like webcontainers.io, CheerpX, v86, webvm which would essentially need you to do nothing on your side like maintaining unofficial tsgo-wasm connector, and make it possible to use the official tsgo:ffi/tsgo:ipc integration in this virtualized environment.

If avoiding installing any new tooling on the user's machine is one of the core values for your project, then virtualized environments are a universally accepted answer

@nikelborm "Did you put all the C89, C++, C#, Ruby, Swift, etc compilers listed on cdd-web-ui into WASM as well? This is an insane amount of work"

Thank you! - It took f-o-r-e-v-e-r to engineer and get working in the browser. - Each compiler is written in the language it targets and is completely standalone. - Then my cdd-web-ui brings together all 13 language compilers into one fully client-side bidirectional (OpenAPI ⇄ language) browser-based code editor.

They are all whitespace and comment sensitive, and for the TypeScript target ts-morph is used extensively.

Without exception: every single component is open-source under (Apache-2.0 OR MIT) or even more permissive licenses.

(and purely client-side; as in you can host just the static files on any CDN, python3 -m http.server, etc. and it'll just work)

Also, what would be a reason for ts-morph to own the build part and add GO to their dependencies, instead of using a prepackaged and built solution like https://www.npmx.dev/package/tsgo-wasm