简体中文
EnglishWhat WebAssembly Is and What webassembly.org Provides
Updated
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine, designed as a portable compilation target for programming languages so that code can be deployed on the web for client and server applications. The site webassembly.org is the project's overview hub: it explains the format at a high level and links out to getting started material, specifications, documentation, feature status, community channels, and news. It is not itself the developer reference — for API-level documentation the site points to MDN's WebAssembly pages.
What the format is designed to do
The site describes four design goals that together explain why Wasm exists:
- Efficient and fast. The stack machine is encoded in a size- and load-time-efficient binary format, and the aim is to execute at native speed by using common hardware capabilities available across a wide range of platforms.
- Safe. Wasm defines a memory-safe, sandboxed execution environment that can even be implemented inside existing JavaScript virtual machines. When embedded in the web, it enforces the browser's same-origin and permissions security policies.
- Open and debuggable. Modules are designed to be pretty-printed in a textual format, used for debugging, testing, experimenting, optimizing, learning, teaching, and even writing programs by hand. That textual format is what you see when viewing the source of a Wasm module on the web.
- Part of the open web platform. Wasm keeps the versionless, feature-tested, backwards-compatible nature of the web. Modules can call into and out of the JavaScript context and reach browser functionality through the same Web APIs available from JavaScript. The format also supports non-web embeddings.
The standards are developed in a W3C Community Group that includes representatives from all major browsers, alongside a W3C Working Group — relevant if you need to cite the governance of the format rather than just its behavior.
What the site gives you, section by section
The navigation reflects the site's role as an entry point rather than a manual:
| Section | What it is for |
|---|---|
| Overview | The high-level description of Wasm quoted above |
| Getting Started | Orientation material for newcomers before they write code |
| Specs | The open standards documents |
| Docs | Documentation pointers, including the MDN developer reference |
| Feature Status | Which features are at what stage — useful before relying on a capability |
| Community | Where the standards work and discussion happen |
| News | Announcements about the project |
A practical consequence: if you are looking for a function signature or a JavaScript API detail, go to MDN's WebAssembly pages directly; use webassembly.org to understand the design, check whether a feature is ready, and find the right spec or community venue.
How to use it for a concrete task
Suppose you maintain a C or Rust library and want to ship it to run in a browser and on a server. A workable path using the site:
- Read the Overview to confirm the deployment model (web client and server, plus non-web embeddings) matches your target.
- Check Feature Status for any capability your build depends on before committing to it.
- Consult Specs when you need the normative behavior — for example, how the sandbox and memory model constrain what your code may do.
- Use Docs, and specifically the linked MDN pages, while writing the JavaScript glue that loads the module and calls into it.
- Watch News and Community for changes, since the format is versionless and feature-tested rather than released in numbered versions.
The expected result at the end is a module that runs in the browser sandbox under the page's origin and permission rules, callable from JavaScript and able to call back out to it.
Common sticking points
- Expecting tutorials on the site itself. The site is an overview hub; hands-on reference material lives at MDN and in the specs.
- Assuming a version number. Wasm is deliberately versionless and backwards-compatible, so "which version" is the wrong question — check feature status instead.
- Assuming it only runs in browsers. The site explicitly notes support for non-web embeddings, so the same compilation target can serve server-side and embedded use.
- Assuming it bypasses web security. The sandbox enforces the browser's same-origin and permissions policies when embedded in the web; it does not grant escape from them.
The site does not publish pricing or account requirements in the material available here, so treat access to the specifications and documentation as a separate question to verify rather than assuming terms.