-
I've experienced a 2x speedup when porting tight loops from JS to WASM. In my case, my tasks are decompression and texture decoding. I initially ported to C, and then ported to AssemblyScript, being careful to manually manage the memory along the way.
The old code was also very "tight-loop" code that just math, and no GC allocation, so it's not applicable to many people here yet, and it's possible that JS interpreters have improved since when I ported (GC behavior has gotten quite noticeably better in V8 in the last two years), but I'll take the speedups I can get.
For comparison:
Old TypeScript: https://github.com/magcius/noclip.website/blob/master/src/Wi...
New AssemblyScript: https://github.com/magcius/noclip.website/blob/master/src/as...
Wrapper for WebAssembly execution: https://github.com/magcius/noclip.website/blob/master/src/Co...
-
Nutrient
Nutrient - The #1 PDF SDK Library. Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.
-
I absolutely love the new MDN where every article is just a file on Git. For example, the source for this article is here: https://github.com/mdn/content/blob/main/files/en-us/webasse...
You can find the link to the source of any article at the bottom of the page.
-
I'm switching a browser game side project from Typescript to WebAssembly because determinism enables a simpler style of multiplayer. Instead of relying on a server to manage state, I can just send inputs p2p like a modern fighting game (with rollback [1]). Then the game acts just like singleplayer! For a hobbyist like me, WebAssembly makes the minefield of multiplayer so much easier to navigate.
[0]: https://github.com/WebAssembly/design/blob/master/Nondetermi...
-
A few wasm projects I've worked on:
- An in-browser crossword puzzle generator: https://crossword.paulbutler.org/ (source: https://github.com/paulgb/crossword-composer)
- A multi-player word game: https://redwords.paulbutler.org/
- A library for synchronizing state between clients, used for that word game: https://aper.dev/ (source: https://github.com/aper-dev/aper very WIP right now)
In my experience, the single biggest perk of using WebAssembly is that I can use a language I'm very productive in (Rust) compared to JavaScript. Everything else is secondary. That said, I think these projects have specific advantages by virtue of being WebAssembly:
- The backtracking search used for the crossword puzzle generator is carefully implemented to not allocate extra memory. This would be tough to do in JavaScript, and I believe it's partly responsible for its performance.
- The word game uses a compression algorithm that benefits very noticeably from wasm-opt, to the point that I can't run it without it. Given that wasm-opt takes a non-trivial amount of time at compile time, I suspect the JavaScript JIT would be slow at doing something similar at runtime. This is just conjecture, I haven't checked.
- What Aper does just wouldn't be possible without Rust features like Serde and macros.
-
Static site generators have been around for ages. Jekyll was one of the first, as far as I know, but there are dozens of others now.
https://jekyllrb.com/
https://jamstack.org/
-
-
Here's one: https://amp.dev/documentation/examples/components/amp-analyt..., backed by https://github.com/ampproject/amp.dev/blob/future/examples/s...
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
Do you have an example of getting bazel to work with emscripten?
I’ll share mine if you share yours:
https://github.com/sorbet/sorbet/tree/master/tools/toolchain...
When we set this up to compile Sorbet (C++ codebase) for https://sorbet.run, it involved what I considered an inordinate amount of boilerplate and arcana.
To be fair since we set it up it’s hardly ever needed to be touched, and I could probably cargo cult this into future projects where I wanted to use it, but I wouldn’t exactly say that bazel magically makes the pain of emscripten go away.
Curious to hear otherwise.
-
The trick is that to provide Bazel with a custom toolchain involves way more than just setting an environment variable, because Bazel wants to control installing and making available the compiler reliably (e.g., what if `emcc` is not present on the system where Bazel was invoked? Bazel solves that problem by fetching it and building it for that system)
There are projects that provide drop-in support for custom toolchains (e.g., we use this project[0] in Sorbet to fetch and build a custom LLVM/Clang toolchain for every host we build on (rather than relying on the system toolchain). But I'm not aware of a project that has done that for Emscripten. Maybe it would be as easy as plucking out what we've done in our project into a project that others could depend on, but to quote a colleague:
> Setting up a cc toolchain in Bazel is a unique sort of pain.
[0] https://github.com/grailbio/bazel-toolchain/
