

Damn... Rust devs going crazy with these libraries.
⚒️ sledgehammer_bindgen 🦀
💥 Breaking the performance barrier of WASM/JS communication.
⚡ Faster Rust batched bindings for JS code.
⭐ GitHub: https://github.com/ealmloff/sledgehammer_bindgen
#rustlang #webassembly #wasm #javascript #performance #bindings #frontend #bindgen
Covered:
🦀 Build an HTTP handler in Rust
🦀 Deploy it with modern Wasm runtimes
🦀 Debug, profile, and monitor your Wasm backend
🦀 Wrap it up with a working calculator API
All the details are here ➡️ https://eurorust.eu/workshops/long-live-webassembly/?utm_source=mastodon&utm_medium=social&utm_campaign=2025-07-17-workshop-jonas-kruckenberg
#RustLang#WebAssembly#Wasm#RustWorkshop#EuroRust25#Mainmatter
🧵2/3
Damn... Rust devs going crazy with these libraries.
⚒️ sledgehammer_bindgen 🦀
💥 Breaking the performance barrier of WASM/JS communication.
⚡ Faster Rust batched bindings for JS code.
⭐ GitHub: https://github.com/ealmloff/sledgehammer_bindgen
#rustlang #webassembly #wasm #javascript #performance #bindings #frontend #bindgen
Covered:
🦀 Build an HTTP handler in Rust
🦀 Deploy it with modern Wasm runtimes
🦀 Debug, profile, and monitor your Wasm backend
🦀 Wrap it up with a working calculator API
All the details are here ➡️ https://eurorust.eu/workshops/long-live-webassembly/?utm_source=mastodon&utm_medium=social&utm_campaign=2025-07-17-workshop-jonas-kruckenberg
#RustLang#WebAssembly#Wasm#RustWorkshop#EuroRust25#Mainmatter
🧵2/3
How hard can it be? That question led to a #WebAssembly adventure at #oSC25, featuring music tech, retro vibes, and real-world lessons on porting apps like #LGPT across devices! From handhelds to the browser, this one’s for the tinkerers. #openSUSE#WASMhttps://youtu.be/pq-04MlLAnM?si=m4y_MdO-dkh7wV11
How hard can it be? That question led to a #WebAssembly adventure at #oSC25, featuring music tech, retro vibes, and real-world lessons on porting apps like #LGPT across devices! From handhelds to the browser, this one’s for the tinkerers. #openSUSE#WASMhttps://youtu.be/pq-04MlLAnM?si=m4y_MdO-dkh7wV11
New #WasmAssembly podcast 🎙️ episode! Dart, Flutter, and WasmGC:
🍿 https://www.youtube.com/watch?v=vgOABOvtBT8
🎧 https://wasmassembly.libsyn.com/dart-flutter-and-wasmgc-with-mer-aacan-and-martin-kustermann
🚀 In this episode of WasmAssembly, I chat with Ömer Ağacan & Martin Kustermann from the Dart team at Google about #Dart, #Flutter, #WasmGC, dart2wasm vs dart2js, Jaspr, and the future of #WebAssembly—both in and beyond the browser. A must-listen for #Wasm nerds!
New #WasmAssembly podcast 🎙️ episode! Dart, Flutter, and WasmGC:
🍿 https://www.youtube.com/watch?v=vgOABOvtBT8
🎧 https://wasmassembly.libsyn.com/dart-flutter-and-wasmgc-with-mer-aacan-and-martin-kustermann
🚀 In this episode of WasmAssembly, I chat with Ömer Ağacan & Martin Kustermann from the Dart team at Google about #Dart, #Flutter, #WasmGC, dart2wasm vs dart2js, Jaspr, and the future of #WebAssembly—both in and beyond the browser. A must-listen for #Wasm nerds!
I have implemented an API for WASM modules for a game engine. I want to create tests for it to make sure that the API that the WASM scripts use are correctly implemented.
How could I build a test suite for this? Since I would have to compile the modules as well, I doubt just "cargo test" would be enough. Is there another testing tool that could be better for this?
I have implemented an API for WASM modules for a game engine. I want to create tests for it to make sure that the API that the WASM scripts use are correctly implemented.
How could I build a test suite for this? Since I would have to compile the modules as well, I doubt just "cargo test" would be enough. Is there another testing tool that could be better for this?
Web's superpower is its openness. Native JS templating makes JS more ergonomic. Direct WASM→DOM makes the web more OPEN. Which better serves the platform's future? The web shouldn't privilege one language. True platform evolution means equal access to core capabilities for all languages. That's how we get the next generation of web innovation. #compsci#webdev #webstandards#opensource
Direct WASM→DOM access doesn't leave JavaScript behind - JS could use the same fast path! We could even build Fagnani's exact templating API as a reference implementation on top of it. But unlike a JS-only solution, the platform stays open for potentially superior approaches in ANY language. Rust might build something faster. Zig might build something smaller. That's the kind of competition through collaboration that drives innovation. Everybody wins wins wins. #compsci#webdev #wasm#javascript
Frameworks already solved templating. They're good at it! What they CAN'T solve is the JS monopoly on DOM access. Open that up and watch innovation explode across the entire ecosystem. React, Vue, Svelte - they all work great. But imagine what could be built if any language had direct DOM access. New paradigms, new approaches, new frameworks we can't even conceive of yet. #compsci#webdev#javascript
Instead of standardizing one templating syntax (that'll be bikeshedded to death), give us the primitive: fast DOM access from any language. Let a thousand templating libraries bloom - in any language. Lower-level primitives enable more innovation than high-level APIs. That's the Unix philosophy. Simple, composable, powerful. Build the foundation right. #compsci#webdev #wasm #frontend#unix
Native JS templating: helps JavaScript developers. Direct WASM→DOM: helps EVERY language. Rust, Go, C#, Zig, Swift, Kotlin... all get first-class web UI performance. That's real platform evolution. We shouldn't be adding more JS-specific APIs when we could be opening the web to all languages equally. The web platform should be language-agnostic at its core. #compsci#webdev #webassembly#programming
The performance argument for native templating is weak - we're talking 2% gains, max. But remove the JS bridge for WASM? That's where real performance wins live. Fix the actual bottleneck. Every DOM call through JS is overhead we don't need. Direct access would unlock true native speeds for web UIs. Imagine game engines manipulating DOM at 60fps without JS overhead. #compsci#webdev #performance #wasm
Why add yet another JS templating API when WASM + direct DOM access solves the root problem? Every language could build efficient UIs without the JS bottleneck. More universal than blessing one syntax. Think beyond JavaScript - imagine Rust components with zero overhead, Go templates that actually perform, or C# Blazor without the bridge tax. That's true platform evolution. #compsci#webdev #wasm #webstandards
Obelisk is a workflow engine that uses WebAssembly components for the workflows themselves. Separates deterministic computations (workflows) from i/o and network side-effects (activities). Interesting 👀
Obelisk is a workflow engine that uses WebAssembly components for the workflows themselves. Separates deterministic computations (workflows) from i/o and network side-effects (activities). Interesting 👀
So happy to see the project that I have been in love with and contributing to for the last several years getting so much attention.
If you work with ESP32 or RPi Pico devices and want a development platform built with fault tolerance and concurrency at it’s heart that allows you to write sophisticated applications with very little code AtomVM might be just what you are looking for.
A space for Bonfire maintainers and contributors to communicate