Webpack with WebAssembly: GSoC 2018 — First Step (1)
After a month of GSoC work, we release our first WebAssembly version of
The project repository and npm package:
Early adopter: webpack-sources in WebAssembly
The APIs of our package are 100% compatible with currently used
weback-sources , means that you can plug and play our npm package without changing any piece of code in Webpack!
webpack-sources with our package, you can get it via yarn using:
yarn add webpack-sources@npm:wasm-webpack-sources
Important notice: This package is still under development and do not use it in production.
As a module bundler, Webpack manipulates your codes from different files in an efficient way. When processing your codes, Webpack stores them as strings in different “sources”. The source in Webpack can represent a code snippet, content and associated file name from a file, or even a manipulation on codes, like concatenation of codes or replacement in certain positions.
The sources are implemented as classes according to different purposes, you can find sources like
ConcatSource , and
ReplaceSource in the package. Moreover,
webpack-sources creates source maps for your files with its two major dependencies:
source-list-map . When you specify
devtool in your Webpack configuration,
webpack-sources creates useful mapping information for enhancing the debugging process.
If you forget about source map, here is a small reminder.
There are several reasons we choose
webpack-sources as our first step:
- Performance-sensitive: Just as what aforementioned, many string manipulations in Webpack are done with
webpack-sources. Also, when generating source maps, we need to encode the codes’ position information by Base64 VLQ, which is computationally expensive.
webpack-sourcestakes your codes as input, and output the processed code with corresponding source map. The input and output are straightforward: String in and String(s) out, and that is exactly what we want.
- Simple project structure:
webpack-sourcesis now released as an npm package and depends on two inner packages:
source-mapby Mozilla and
WebAssembly with Rust
We choose Rust to rewrite the package and its dependencies and compile to WebAssembly binaries. You may ask why we prefer Rust instead of C++? There are some reasons for us to come to the decision:
- Memory safety: As you may know, Rust guarantees memory safety by introducing some strict compiler rules. This feature is so important for low-level programming language without garbage collection and will save us a lot of trouble in future works.
- Package management: As a developer spoiled by npm, cargo, the default package manager of Rust, is entirely sufficient to let you choose Rust instead of C++.
- WebAssembly Toolchain: There is no doubt that many mature tools are there to help us develop WebAssembly in C++, like
emscripten. However, more and more tools are now published for Rust with fantastic features! For example,
There is a speech by Lin in JSConf EU 2018 talking about Rust with WebAssembly. You can refer to his post “Baby’s First Rust+WebAssembly module: Say hi to JSConf EU!”.
In this series of posts, we will introduce our conversion work with Rust and