- 开发者引导
- 理解 JS API
- 高级工具
- JavaScript API
- FAQ 常见问题
- 最小可行性版本
- Features to add after the MVP
- Modules
- 语义
- Binary Encoding
- Web Embedding
- Text Format
- Design Rationale
- Security
- Nondeterminism in WebAssembly
- Guide for C/C++ developers
- Feature Test
- Tooling support
- GC / DOM / Web API Integration :unicorn:
- JIT and Optimization Library
- Dynamic linking
- WebAssembly 的长久目标
- 非网络嵌入
- 可移植性
- 使用场景
Tooling support
Tooling for in-browser execution is often of uneven quality. WebAssembly aims at making it possible to support truly great tooling by exposing low-level capabilities instead of prescribing which tooling should be built. This enables:
- Porting of existing and familiar tooling to WebAssembly;
Building new tooling that’s particularly well suited to WebAssembly.
WebAssembly development should be self-hosting, and not just as a cute hack but as enjoyable platform that developers actively seek out because the tools they want and need just work. Developers have high expectations, and meeting these expectations on tooling means WebAssembly has the features required to build rich applications for non-developers.
The tooling we expect to support includes:
- Editors:
- Editors such as vim and emacs should just work.
- Compilers and language virtual machines:
- Compilers for languages which can target WebAssembly (C/C++, Rust, Go, C#) should be able to run in WebAssembly themselves, emit a WebAssembly module that can then be executed.
- Virtual machines for languages such as bash, Python, Ruby should work.
- Virtual machines which use a just-in-time compiler (JavaScript VMs, luajit, pypy) should be able to support a new just-in-time backend for WebAssembly.
- Debuggers:
- Basic browser integration can be done through source map support.
- Full integration for languages like C++ require more standardization effort on debugging information format as well as permissions for interrupting programs, inspecting their state, modifying their state.
- Debug information is better delivered on-demand instead of built-in to a WebAssembly module.
- Sanitizers for non-memory-safe languages: asan, tsan, msan, ubsan. Efficient support of sanitizers may require improving:
- Trapping support;
- Shadow stack techniques (often implemented through
mmap
’sMAP_FIXED
).
- Opt-in security enhancements for developers’ own code: developers targeting WebAssembly may want their own code to be sandboxed further than what WebAssembly implementations require to protect users.
- Profilers:
- Sample-based;
- Instrumentation-based.
- Process dump: local variables, call stack, heap, global variables, list of threads.
- JavaScript+WebAssembly size optimization tool: huge WebAssembly+JavaScript mixed applications, WebAssembly calling to JavaScript libraries which communicate with the rest of the Web platform, need tooling to perform dead code stripping and global optimization across the API boundary.
In many cases, the tooling will be pure WebAssembly without any tool-specific support from WebAssembly. This won’t be possible for debugging, but should be entirely possible for sanitizers.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论