lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

61
active users

#wasm

1 post1 participant0 posts today
openSUSE Linux<p>How hard can it be? That question led to a <a href="https://fosstodon.org/tags/WebAssembly" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WebAssembly</span></a> adventure at <a href="https://fosstodon.org/tags/oSC25" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>oSC25</span></a>, featuring music tech, retro vibes, and real-world lessons on porting apps like <a href="https://fosstodon.org/tags/LGPT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LGPT</span></a> across devices! From handhelds to the browser, this one’s for the tinkerers. <a href="https://fosstodon.org/tags/openSUSE" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>openSUSE</span></a> <a href="https://fosstodon.org/tags/WASM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WASM</span></a> <a href="https://youtu.be/pq-04MlLAnM?si=m4y_MdO-dkh7wV11" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">youtu.be/pq-04MlLAnM?si=m4y_Md</span><span class="invisible">O-dkh7wV11</span></a></p>

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?

Replied in thread

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

Replied in thread

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

Replied in thread

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

Continued thread

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

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.

atomvm.net

github.com/atomvm/AtomVM

AtomVMAtomVMWelcome to AtomVM, the Erlang virtual machine for IoT devices!
#atomvm#IoT#wasm

🌀 Introducing **Chakra** - a blazing fast in-browser WebAssembly runtime for builders.

```sh
chakra myfile.wasm
```

– Runs WASM in-browser with logs
– Supports Rust, TinyGo, C, Asc and Python
– One-line introspection & verify commands

Chakra is an open source project and we're building it *with the community*.

🌟 github.com/anistark/chakra
📖 Read more: blog.anirudha.dev/chakra

Give us a shout-out or star the repo on github if you like the idea. 🙌

GitHubGitHub - anistark/chakra: Run WebAssembly instantly in your browser with a single command.Run WebAssembly instantly in your browser with a single command. - anistark/chakra

📢 New #WasmAssembly podcast 🎙️ episode is up: Enabling in-browser scientific computing with #Wasm: David Kircos of Quadratic.

🍿 youtube.com/watch?v=TTUaZXl0X4
🎧 wasmassembly.libsyn.com/enabli

We discussed how Quadratic's spreadsheet uses #WebAssembly to enable scientific computing directly in the browser with tools like Pyodide, pandas, and numpy. The conversation also covers practical challenges such as bundling large-scale Wasm applications, exploring browser limitations, and Quadratic's integration of AI.