I got nerd-sniped by the very Andreas Rossberg into creating a `<wasm-compat>` custom element that shows the various #Wasm features and the many #WebAssembly engines' compatibility with those features.
```html
<wasm-compat wasm-feature="bigInt"></wasm-compat>
```
Learn how to use it and see it in action in this article: https://webassembly.org/news/2025-09-17-wasm-compat/.
In #WebAssembly spec news, #Wasm 3.0 is complete 
! Read all about it in Andreas Rossberg's article: https://webassembly.org/news/2025-09-17-wasm-3.0/.
#Wasm 3.0 is out. Garbage collected memory, tail calls (finally!), exceptions… And still no support for web browser APIs such as DOM, so you still cannot write a web application without having to deal with #Javascript.
So much work, so little real world usability.
With 
Swift 6.2 , you can now target WebAssembly, including WASI support. Get started here: https://www.swift.org/documentation/articles/wasm-getting-started.html #Wasm @maxd
#WASM 3.0 is complete, bundling up features that have been baking for years like GC, exceptions, and multiple memories. Doesn't mean compiling from C/C++ is any less of a PITA (except now maybe C++ exceptions will work) but should make it easier for other languages to target WASM.
A major (and interesting) release for #swift.
Notably, it now has (very similar to #rust) checks at compile time to eliminate use-after-free bugs, lots of async and actor things built-in.
Plus - #wasm (web assembly) support.
If you're wondering - you can make servers for Linux with this - it is not just the iOS / macOS language of choice.
#Rust Maps more directly to #wasm, (less indirection) has strong, ergonomic interop via wasm-bindgen, JS value conversion, and tooling that auto-generates bindings. Good support for passing typed arrays, closures, and returning JS Promises.
#GHC: interop exists but is more awkward because Haskell values are boxed and require marshaling through the RTS. Tooling and auto-binding generators are less developed
Also due to its ownership model for memory it generates smaller binaries, besides nearly no runtime
#PSA Since I've just been asked again if I could use more topic-specific accounts and not mix my photography with other topics — Unfortunately, nope! I'm on a single user managed instance and cannot create new accounts on this server nor do I want to create an account for every single topic I'm interested in or posting about. However, you can filter my posts by hashtags, which I'm trying to use consistently (also for my own purposes)...
Hashtags can be browsed individually, subscribed to (via Mastodon) or even syndicated via RSS, e.g.
Browse:
http://mastodon.thi.ng/@toxi/tagged/LandscapePhotography
RSS:
http://mastodon.thi.ng/@toxi/tagged/LandscapePhotography.rss
My most commonly used tags are:
Photography:
#LandscapePhotography #NaturePhotography #NoirCountry (my B&W photos) #POV #Hiking
Open source projects:
#ThingUmbrella #ZigThing #GenArtAPI #TypeScript #Ziglang #WASM #WebAssembly #Forth #OpenSource #ProgLang
Art:
#Art #GenerativeArt #AlgorithmicArt #ProceduralArt #KineticArt #Exhibition
Music:
#Music4Coding
Education/research:
#Edu #Research
Hope that helps!
Btw. It's amazing that this swizzle function gets compiled into single WASM `i8x16.shuffle` ops (per 4 vector components, i.e. swizzling into an 8-dimensional vector would require 2 shuffles):
Lots of exciting progress with Wasm on Swift, thanks to contributions from a wide variety of sources: https://forums.swift.org/t/swift-for-wasm-q3-2025-updates/81956 #Wasm
Hey #Energy nerds, we've retired our @datasette deployment (which was falling over with the volume of data we publish) and are re-using the domain for our new @duckdb + #Parquet + #WASM based data preview interface. Check it out and let us know if anything is broken:
Where No #PHP Has Gone Before by David Flanagan. A nice talk about running PHP with WebAssembly's WASI https://youtu.be/gJ7vEACAYmE?si=K2JVw7yLSuKtDJ9R #wasm
Nice broker you have there, it would be a shame if someone put #wasm in it
In-broker #Wasm transforms in @apachekafka with #Chicory and some light low-level patching 
I hope you enjoyed part 1, because this is part 2 
https://blog.evacchi.dev/posts/2025/09/03/extending-kafka-the-hard-way-part-2/
Yesterday I released new versions of https://thi.ng/wasm-api (and its add-on packages), a modular and extensible bridge API & toolchain for hybrid JS/TS/Zig/WebAssembly apps, now updated to be compatible with the latest Zig version 0.15.1...
The update addresses some of Zig's breaking syntax & build system changes only, nothing on the JS/TS side has changed. As a result https://thi.ng/wasm-api-dom has a slightly revised internal structure (also a breaking change, but nothing major & unavoidable). All bundled Zig examples[1] in the repo have been updated too, take a look for reference (if needed).
FYI More details about the Zig language changes here:
https://ziglang.org/download/0.15.1/release-notes.html#Language-Changes
Specifically, the removal of `usingnamespace` has had a major impact on the existing handling of generated types in these wasm-api support packages (or your own) and now forces an additional level of hierarchy in terms of namespacing. This is because `usingnamespace` enabled a form of namespace merging, which allowed the generated WASM⭤TS interop types (written to their own sourcefile) to be merged/hoisted into the main library module.
For example, previously after importing `const dom = @import("wasm-api-dom");` we could refer to a type via `dom.WindowInfo`. Now with namespace merging removed, we have to use `dom.types.WindowInfo`. As I said, it's not a major departure, but a breaking change nonetheless[2]...
The `build.zig` file bundled with https://thi.ng/wasm-api is now also only compatible with Zig 0.15.1 (for now). Build files for older Zig versions are still included too (in the same directory)[3].
Lastly, once more for the record: The wasm-api bridge itself is NOT tied to Zig (or a particular version), however it's the main use case/language for my own WebAssembly use cases...
[1] https://github.com/thi-ng/umbrella/tree/develop/examples (all examples starting with `zig-*`)
[2] The existing design of these modules helped to keep these breaking changes to a minimum in userland code and these updates are all following the same uniform pattern (i.e. exposing interop types via `modulename.types.TypeName`...)
[3] https://github.com/thi-ng/umbrella/tree/develop/packages/wasm-api#using-the-zig-build-system
Building a WASM compiler in Roc (series) https://lobste.rs/s/aqp3jc #compilers #plt #wasm
https://dusty.phillips.codes/roc/
The slides from my lightning talk "Small Update About TinyGo - GopherCon 2025 Edition" are now available online at https://deadprogram.github.io/gophercon-2025
#gopherCon #golang #tinygo #embedded #wasm
️ 
