# wasm Published articles for wasm. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Advancing Embedded Go: Recoverable Panics, UEFI, Radio and Hardware Dev Kit DevFeed: [Advancing Embedded Go: Recoverable Panics, UEFI, Radio and Hardware Dev Kit]() Original publisher: [Read original article]() Author: Olimpiu Pop Published: 2026-09-11T05:05:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Go Language](), [Embedded Software Dev](), [networking]() Tags: [development](), [embedded](), [embedded-software-dev](), [errors](), [go](), [hardware](), [llvm](), [networking](), [news](), [release](), [tiny-go](), [tinygo-devkit](), [wasm](), [webassembly]() ### AI overview TinyGo 0.42 adds recoverable runtime panics, Go 1.27 and LLVM 22 support, and a UEFI target. The article also covers prior wireless and board support, WebAssembly and WASI compilation, and the TinyGo Starter Kit with Seeed Studio XIAO. ### Source excerpt TinyGo version 0.42 introduces significant updates, including recoverable panics and support for Go 1.27 and LLVM 22, improving error handling and enabling Go code to run as UEFI applications. The TinyGo Starter Kit with Seeed Studio XIAO facilitates hardware use for developers, featuring an ESP32-C3 board and modular sensors. These features enhance its functionality for embedded systems and Wasm. By Olimpiu Pop ## Kotlin 2.4.20 Released DevFeed: [Kotlin 2.4.20 Released]() Original publisher: [Read original article]() Author: Daniel Csorba Published: 2026-09-07T11:30:57Z Content type: release Language: en Sources: [Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog](), [The JetBrains Blog]() Topics: [releases](), [Command-line interface](), [Android Studio](), [IntelliJ IDEA]() Tags: [android-studio](), [command-line](), [features](), [github](), [gradle](), [intellij](), [issue-tracker](), [kotlin](), [release](), [releases](), [swift](), [testing](), [wasm](), [youtrack]() ### AI overview Kotlin 2.4.20 adds standard-library, compiler, build-tool, Kotlin/Native, Kotlin/Wasm, and Kotlin/JS updates. The article also explains how to update Kotlin in supported IDEs or obtain the command-line compiler. ### Source excerpt The Kotlin 2.4.20 release is out! Here are the main highlights: For the complete list of changes, see What's new in Kotlin 2.4.20 or the release notes on GitHub. How to install Kotlin 2.4.20 The latest version of Kotlin is included in the latest versions of IntelliJ IDEA and Android Studio. To update to the [...] ## Building a Real-Time 3D Face Mask with MediaPipe, Threlte and Three.js DevFeed: [Building a Real-Time 3D Face Mask with MediaPipe, Threlte and Three.js]() Original publisher: [Read original article]() Author: Marek Jóźwiak Published: 2026-09-06T13:09:52Z Content type: tutorial Language: en Sources: [Codrops]() Topics: [Three.js webcam]() Tags: [3d](), [3d-face-mask](), [canonical-face-model](), [creative-coding](), [face-landmarks](), [face-mesh](), [face-tracking](), [facial-landmarks](), [generative-graphics](), [gpu](), [inference](), [interactive-3d](), [javascript-3d](), [mediapipe](), [mediapipe-face-landmarker](), [mesh](), [real-time](), [real-time-3d](), [real-time-face-tracking](), [svelte](), [three-js](), [three-js-face-mask](), [three-js-webcam](), [threlte](), [threlte-three-js](), [tutorial](), [tutorials](), [video](), [vision](), [wasm](), [webcam](), [webcam-effects](), [webcam-face-tracking](), [webgl](), [webgl-face-tracking]() ### AI overview Tutorial on building a real-time textured 3D face mask by mapping MediaPipe face landmarks onto a Three.js mesh with Threlte. ### Source excerpt Learn how MediaPipe's face landmarks, Google's canonical face model, and Three.js come together to create a real-time textured 3D face mask. ## What's new in Swift: August 2026 Edition DevFeed: [What's new in Swift: August 2026 Edition]() Original publisher: [Read original article]() Author: Dave Lester Published: 2026-09-04T16:30:00Z Content type: news Language: en Sources: [Swift.org]() Topics: [modern web development](), [Vapor](), [Back end]() Tags: [backend](), [cloudflare](), [demo](), [frontend](), [swift](), [wasm](), [webassembly]() ### AI overview A Swift community update highlights Elementary and ElementaryUI, projects for server-rendered and browser-based web UIs. It also describes Swift-to-WebAssembly progress and a Cloudflare full-stack demo using shared message types. ### Source excerpt Welcome to "What's new in Swift," a curated digest of releases, videos, and discussions in the Swift project and community. Here's an update from guest contributor Simon Leeb on Swift's progress as a language for web scenarios: Hi, Simon here! I am the creator of the elementary-swift project, a collection of packages born from a simple wish: I want to build web UIs in Swift and ultimately help Swift become a first-class choice for the web. This journey began after I started using Swift for backend services. The web frontend, however, still lived in a separate ecosystem, and I really wanted it to feel as ergonomic, safe, and efficient as the Swift I was writing everywhere else. That led to the creation of Elementary: a modern and efficient HTML rendering library with a familiar declarative API, built for the web. It integrates easily with frameworks like Vapor and Hummingbird, and has become a practical option for server-rendered web UIs. Around that same time, years of community work in the swift-wasm project made compiling Swift to WebAssembly increasingly viable, while Embedded Swift was taking its first experimental steps. This made me wonder: "How hard can it be to use Embedded Swift and build a state-driven web UI framework that produces tiny WebAssembly binaries?" Turns out: quite hard, actually! But it was too late. Despite my better judgment, I was in the middle of creating what is now known as ElementaryUI. Where Elementary renders HTML on the server, ElementaryUI runs in the browser itself. You can watch my talk at Swift@FOSDEM 2026 if you want to know more about the why, what, and how. To showcase where the project is heading, I recently posted a small Full-Stack Swift on Cloudflare demo. It features Swift in the browser communicating with a Swift backend on an edge worker through shared message types. I hope it gives people a concrete sense of how much the core technologies and the surrounding tooling have advanced. ElementaryUI is still young, with plen ## Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More DevFeed: [Kotlin Toolchain 0.12: Multiplatform Library Publishing, Wasm Apps, and More]() Original publisher: [Read original article]() Author: Joffrey Bion Published: 2026-09-03T10:40:05Z Content type: release Language: en Sources: [Kotlin : A concise multiplatform language developed by JetBrains | The JetBrains Blog]() Topics: [toolchain](), [multiplatform](), [compose-hot-reload](), [web applications](), [Spring Boot 4]() Tags: [compose-hot-reload](), [gradle](), [intellij-idea](), [kotlin](), [multiplatform](), [news](), [publication](), [releases](), [toolchain](), [toolchains](), [wasm]() ### AI overview Kotlin Toolchain 0.12.0 adds multiplatform library publishing and previews support for building Wasm modules as web applications. It also includes command-line Compose Hot Reload and changes intended to reduce Maven Central publication files. ### Source excerpt Kotlin Toolchain 0.12.0 is out. This release brings some long-awaited features: multiplatform libraries publication, a preview of Wasm application support, Compose Hot Reload from the command line, and more. Read on for the details, and check the release notes for the full list of changes and bug fixes. Additionally, klibs.io now uses the Kotlin Toolchain [...] ## Node.js 24.20.0 (LTS) DevFeed: [Node.js 24.20.0 (LTS)]() Original publisher: [Read original article]() Published: 2026-08-26T14:29:42Z Content type: release Language: en Sources: [Node.js Blog]() Topics: [Node.js](), [ci]() Tags: [benchmark](), [bugs](), [ci](), [cli](), [javascript](), [node-js](), [wasm]() ### AI overview Node.js 24.20.0 LTS release notes list semver-minor additions, fixes, benchmarks, build and CI updates, and a WebAssembly JSPI change. ### Source excerpt Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts. ## An insider argues that Google remains committed to Flutter and Dart DevFeed: [An insider argues that Google remains committed to Flutter and Dart]() Original publisher: [Read original article]() Author: Randal L. Schwartz Published: 2026-08-19T16:02:19Z Content type: opinion Language: en Sources: [Flutter Community - Medium]() Topics: [Flutter](), [Dart](), [Google](), [multiplatform](), [WebAssembly]() Tags: [cross-platform](), [dart](), [devrel](), [flutter](), [google](), [mobile-app-development](), [programming](), [software-development](), [wasm](), [webassembly]() ### AI overview This commentary argues, from the author's stated experience as a Flutter Google Developer Expert, that Google remains committed to Flutter and Dart despite restructuring-related concerns and reduced public communication. It cites renewed advocacy and investment in rendering, Dart ergonomics, WebAssembly compilation, and multiplatform performance. ### Source excerpt Every few months, like clockwork, the tech blogosphere gets flooded with the same recycled headline: "Is Flutter Dying?", "Why CTOs Are Quietly Leaving Flutter", or "Why Google is Killing Its Cross-Platform Bet." As someone who has been a Flutter Google Developer Expert for eight years now -- literally from day one of the GDE program -- and a five-decade software industry veteran, I usually just chuckle at the clickbait. "Flutter is dead." -- Said every six months since 2018. Meanwhile: Flutter is kicking tail on every single measurable scale. The alarmist articles point to standard corporate reorganizations, shifting tech job boards, and "state management fatigue" as evidence of Flutter's demise. But having watched this ecosystem evolve from an experimental alpha into an enterprise powerhouse, the reality on the ground is the exact opposite. Here is the real insider story on what's actually happening with Dart and Flutter. 1. The Inside Story: What Happened at Google? When tech companies restructured engineering teams recently, the internet spun a wild narrative that "Google put Flutter on life support." Having direct access to internal teams, I watched the commitment to Dart and Flutter remain steadfast within the organization. However, there was a temporary disconnect: internal engineering activity was roaring, but external communications and public advocacy had slowed down, leaving an information vacuum that clickbait writers eagerly filled. I personally called out to team leaders and senior VPs that this perception gap needed immediate correction. And the leadership responded strongly: Revitalized DevRel & Advocacy: A renewed surge in active community engagement, tutorials, and public roadmaps. Enterprise Adoption Transparency: Showcasing massive internal and external production milestones. Aggressive Core Investment: Deep work on the Impeller rendering engine, Dart 3.x ergonomics, WebAssembly (Wasm) compilation, and native multiplatform performance. Flutter is no ## Electric is joining team Neon at Databricks DevFeed: [Electric is joining team Neon at Databricks]() Original publisher: [Read original article]() Author: Nikita Shamgunov Published: 2026-08-11T13:00:00Z Content type: news Language: en Sources: [Blog -- Neon Docs]() Topics: [databricks](), [Database](), [real-time](), [wasm](), [AI-assisted coding]() Tags: [agentic](), [company](), [postgres](), [real-time](), [sync](), [wasm]() ### AI overview Electric is joining Neon within Databricks, bringing PGlite and its real-time Postgres synchronization technology. The article presents these as primitives for lightweight applications and agent workloads. ### Source excerpt Today Databricks announced that Electric, the team behind PGlite and the Electric sync engine, is joining Databricks. We have our own reason to celebrate: Electric is joining the Neon team within Databricks, bringing lightweight WASM Postgres + real-time sync to Neon. ## The challenge of adding a Web target to DroidconKotlin - Kevin Schildhorn DevFeed: [The challenge of adding a Web target to DroidconKotlin - Kevin Schildhorn]() Original publisher: [Read original article]() Published: 2026-07-22T18:00:00Z Content type: tutorial Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Web](), [multiplatform](), [Kotlin](), [compose-multiplatform](), [wasm](), [browser](), [Firebase]() Tags: [browser](), [browsers](), [compose-multiplatform](), [crashlytics](), [dependencies](), [droidcon](), [firebase](), [kotlin](), [kotlin-multiplatform](), [project](), [wasm](), [web]() ### AI overview This post explains how Touchlab added browser Web support to the DroidconKotlin multiplatform app. It covers dependency limitations, the decision to use Web instead of Kotlin WASM, SQLDelight support, Coil and Okio filesystem issues, the lack of Firebase Crashlytics Web support, and localization and resource handling with Compose Multiplatform. ### Source excerpt We recently added support for Web to our DroidconKotlin app. In this post we'll go over our process and the difficulties of adding a Web target to an existing project. ## GC and Exceptions in Wasmtime DevFeed: [GC and Exceptions in Wasmtime]() Original publisher: [Read original article]() Author: Nick Fitzgerald Published: 2026-07-20T00:00:00Z Content type: release Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [wasm](), [Exception](), [toolchains]() Tags: [compilation](), [exceptions](), [release](), [toolchains](), [wasm](), [webassembly]() ### AI overview Wasmtime 47 enables the Wasm GC and exceptions proposals by default. The article explains how Wasm GC supports languages with object-and-reference data models by letting the runtime manage types and lifetimes, while the exceptions proposal provides more efficient exception handling for WebAssembly compilation targets. ### Source excerpt The Wasm GC and exceptions proposals are both enabled by default in today's Wasmtime 47 release! We are excited to help bring more languages to WebAssembly and everywhere that Wasmtime runs. Getting to this point involved large Wasmtime changes and represents the culmination of years of engineering effort. ## We compiled our TypeScript parser to WASM DevFeed: [We compiled our TypeScript parser to WASM]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-07-15T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [Parser](), [Rust](), [wasm](), [browser](), [TypeScript]() Tags: [browser](), [parsing](), [rust](), [typescript](), [wasm]() ### AI overview Encore describes compiling its Rust parser for TypeScript infrastructure declarations to WebAssembly so it can run in the browser. The browser-based parser supports reproducing parser errors from code snippets and shared links, and powers the tsparser.encore.dev playground. ### Source excerpt How we compiled the Rust parser that reads infrastructure out of Encore code so it runs in the browser, and how we use it to reproduce the parser errors people report. ## wasmCloud 2.5.0: Wasmtime 46, WASI 0.3, and multiplexed WebAssembly host plugins DevFeed: [wasmCloud 2.5.0: Wasmtime 46, WASI 0.3, and multiplexed WebAssembly host plugins]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-06-30T00:00:00Z Content type: release Language: en Sources: [wasmCloud Blog]() Topics: [WebAssembly](), [wasm](), [Streaming]() Tags: [helm](), [release](), [streaming](), [wasi](), [wasm](), [webassembly]() ### AI overview wasmCloud 2.5.0 is released with Wasmtime 46 and WASI 0.3 enabled by default. It adds configurable top-level WebAssembly proposals, multiplexed host-plugin interfaces, async-shaped and WIT improvements, Helm chart hardening, a host-controller refactor, and quality-of-life fixes. ### Source excerpt wasmCloud 2.5.0 ships with Wasmtime 46, WASI 0.3 on by default, configurable WebAssembly proposals, and `(implements ..)` multiplexing for host plugins. ## Experimenting with the proposed Cross-Origin Storage API in Transformers.js DevFeed: [Experimenting with the proposed Cross-Origin Storage API in Transformers.js]() Original publisher: [Read original article]() Author: Thomas Steiner Published: 2026-06-23T00:00:00Z Content type: tutorial Language: en Sources: [Hugging Face - Blog]() Topics: [AI, ML & Data Engineering]() Tags: [ai-models](), [announcement](), [api](), [artificial-intelligence](), [asr](), [browser](), [cache](), [chrome](), [chrome-extension](), [cos](), [cross-origin-storage](), [inference](), [javascript](), [on-device](), [open-source](), [storage](), [transformers](), [transformers-js](), [wasm](), [web](), [web-apps](), [web-developers](), [web-standards](), [webassembly]() ### AI overview A tutorial that uses Transformers.js browser inference examples to examine duplicate model and WebAssembly downloads across origins and the proposed Cross-Origin Storage API. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## June 2026 newsletter DevFeed: [June 2026 newsletter]() Original publisher: [Read original article]() Author: Mark Needham Published: 2026-06-18T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [clickhouse](), [data](), [Open Source](), [real-time](), [wasm](), [WebAssembly](), [Apache Iceberg](), [Parser]() Tags: [analytics](), [clickhouse](), [data](), [database](), [engineering](), [open-source](), [performance](), [real-time](), [release](), [systems](), [wasm](), [webassembly]() ### AI overview The June 2026 ClickHouse newsletter marks the project's tenth anniversary, highlights its open-source community, and covers contributions to WebAssembly user-defined functions, geospatial and Iceberg functionality, and performance improvements in ClickHouse 26.5. ### Source excerpt Welcome to the June 2026 ClickHouse newsletter, which will round up what's happened in real-time data warehouses over the last month. ## The Road to Component Model 1.0 DevFeed: [The Road to Component Model 1.0]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-06-08T00:00:00Z Content type: article Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [wasm](), [browser]() Tags: [apis](), [architecture](), [async](), [binaries](), [browser](), [compatibility](), [interfaces](), [polyfill](), [production](), [wasi](), [wasm](), [webassembly]() ### AI overview This article explains the path toward a stable, formally specified WebAssembly Component Model 1.0. It reviews how the Component Model and WASI relate, describes the Component Model as a foundational layer with WASI providing system-resource interfaces, and notes that both are already used in production while their specifications continue to evolve. ### Source excerpt WASI P3 is almost here, bringing native async support to the WebAssembly System Interface (WASI) and Component Model. In this post, we're looking to the next big milestone: a stable, formally specified Component Model 1.0. At February's Bytecode Alliance Plumbers Summit, Luke Wagner and Alex Crichton gave a preview of what the path to a stable 1.0 actually looks like. At Wasm I/O 2026 in Barcelona in March, Luke expanded on that vision. So let's take a look at where the Component Model is heading. ## What's new in Swift: May 2026 Edition DevFeed: [What's new in Swift: May 2026 Edition]() Original publisher: [Read original article]() Author: Dave Lester Published: 2026-06-03T21:45:00Z Content type: article Language: en Sources: [Swift.org]() Topics: [Swift](), [SDKs](), [Back end](), [iOS](), [MLX](), [wasm](), [WebAssembly](), [AWS Lambda]() Tags: [aws](), [aws-lambda](), [backend](), [community](), [conferences](), [ios](), [local](), [mlx](), [news](), [releases](), [serverless](), [swift](), [wasm](), [webassembly]() ### AI overview A curated May 2026 digest of Swift community activity, including meetup videos, backend development resources, the Temporal Swift SDK, AWS Lambda, MLX for iOS, and Swift for WebAssembly updates. ### Source excerpt Welcome to "What's new in Swift," a curated digest of releases, videos, and discussions in the Swift project and community. To start, we're focusing on some of the many local meetup groups sharing Swift content: Around the world, local meetup groups and conferences bring Swift developers together, and some even predate Swift itself! Many have YouTube channels where they share videos from their events, so you can tune in remotely. Let's highlight a few. In May the SF Swift meetup hosted a talk by Dan Federman, Agentify Your Swift Repo, which covers building an agent for CI and review feedback. Swift Barcelona has a dedicated YouTube presence, while some groups, like the new MLX India meetup, post event playlists, including a recent talk about using MLX Swift in iOS apps that's worth checking out. And there's even a community-organized Swift Community Meetups YouTube channel, which hosts meetups online and is home to a series of cross-platform Swift talks. These groups support developers in a few ways worth calling out: Local community: they're building local connections among Swift developers and organizations. Room for experimentation: by being less formal and sometimes featuring works in progress, meetups create space to share ideas, get feedback, and learn from one another. I encourage more folks to get involved in their local Swift meetup. And if your group starts publishing content and videos, please share on the Swift Forums in the Community Showcase category. -- Dave Lester Now on to other news about Swift: Videos to watch Interested in using Swift for backend server development? Mohammad Azam posted a livestream recording of Introduction to Hummingbird, a walkthrough of the web framework covering installation and development basics. Meet the Temporal Swift SDK, from Replay 2026, introduces the SDK that brings Temporal's durable workflows (long-running processes that survive crashes, retries, and restarts without losing state) to Swift. The SDK recently reached ## How Wasm components enable pluggable tooling through interposition DevFeed: [How Wasm components enable pluggable tooling through interposition]() Original publisher: [Read original article]() Author: Elizabeth Gilbert Published: 2026-05-14T00:00:00Z Content type: article Language: en Sources: [Bytecode Alliance]() Topics: [wasm](), [Architecture & Design](), [Tooling]() Tags: [architecture](), [modularity](), [services](), [tooling](), [wasm](), [wasm-components]() ### AI overview The article explains how WebAssembly components can support pluggable HTTP middleware through component composition, service chaining, and interposition. It describes in-process communication between components whose imports and exports agree, including fan-in service topologies and chains of handlers for cross-cutting request and response processing. ### Source excerpt And how the splicer framework makes it tractable at any interface edge. ## wastrel milestone: full hoot support, with generational gc as a treat DevFeed: [wastrel milestone: full hoot support, with generational gc as a treat]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-09T13:48:04Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [scheme](), [toolchain](), [gcc]() Tags: [binaries](), [garbage-collection](), [gc](), [gcc](), [hoot](), [optimization](), [repl](), [scheme](), [spidermonkey](), [toolchain](), [treats](), [v8](), [wasm](), [wastrel](), [web](), [webassembly]() ### AI overview The article describes a Wastrel milestone: compiling WebAssembly files produced by the Hoot Scheme toolchain into native binaries, including a console-based read-eval-print loop. It covers the build process, runtime modules, binary size, dependencies, and initial performance observations. ### Source excerpt Hear ye, hear ye: Wastrel and Hoot means REPL! Which is to say, Wastrel can now make native binaries out of WebAssembly files as produced by the Hoot Scheme toolchain, up to and including a full read-eval-print loop. Like the REPL on the Hoot web page, but instead of requiring a browser, you can just run it on your console. Amazing stuff! try it at home First, we need the latest Hoot. Build it from source, then compile a simple REPL: echo '(import (hoot repl)) (spawn-repl)' > repl.scm ./pre-inst-env hoot compile -fruntime-modules -o repl.wasm repl.scm This takes about a minute. The resulting wasm file has a pretty full standard library including a full macro expander and evaluator. Normally Hoot would do some aggressive tree-shaking to discard any definitions not used by the program, but with a REPL we don't know what we might need. So, we pass -fruntime-modules to instruct Hoot to record all modules and their bindings in a central registry, so they can be looked up at run-time. This results in a 6.6 MB Wasm file; with tree-shaking we would have been at 1.2 MB. Next, build Wastrel from source, and compile our new repl.wasm: wastrel compile -o repl repl.wasm This takes about 5 minutes on my machine: about 3 minutes to generate all the C, about 6.6MLOC all in all, split into a couple hundred files of about 30KLOC each, and then 2 minutes to compile with GCC and link-time optimization (parallelised over 32 cores in my case). I have some ideas to golf the first part down a bit, but the the GCC side will resist improvements. Finally, the moment of truth: $ ./repl Hoot 0.8.0 Enter `,help' for help. (hoot user)> "hello, world!" => "hello, world!" (hoot user)> statics When I first got the REPL working last week, I gasped out loud: it's alive, it's alive!!! Now that some days have passed, I am finally able to look a bit more dispassionately at where we're at. Firstly, let's look at the compiled binary itself. By default, Wastrel passes the -g flag to GCC, which results in bi ## WebAssembly interpreter performance depends on the runtime, not just the code pattern DevFeed: [WebAssembly interpreter performance depends on the runtime, not just the code pattern]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-07T12:49:39Z Content type: article Language: en Sources: [wingolog]() Topics: [Rust](), [WebAssembly](), [Assembly](), [toolchain](), [V8](), [Chrome](), [Firefox]() Tags: [assembler](), [assembly](), [chrome](), [firefox](), [oracles](), [performance](), [performance-oracles](), [raven](), [rust](), [tail-calls](), [toolchain](), [wasm](), [wasmtime](), [wastrel](), [webassembly]() ### AI overview The article revisits a comparison of switch-based and tail-calling bytecode interpreters. Its measurements confirm earlier native and Wasmtime results but report that Wastrel substantially reduces the apparent WebAssembly penalty, suggesting that the poor performance is runtime-specific rather than inherent to WebAssembly. ### Source excerpt Over on his excellent blog, Matt Keeter posts some results from having ported a bytecode virtual machine to tail-calling style. He finds that his tail-calling interpreter written in Rust beats his switch-based interpreter, and even beats hand-coded assembly on some platforms. He also compares tail-calling versus switch-based interpreters on WebAssembly, and concludes that performance of tail-calling interpreters in Wasm is terrible: 1.2x slower on Firefox, 3.7x slower on Chrome, and 4.6x slower in wasmtime. I guess patterns which generate good assembly don't map well to the WASM stack machine, and the JITs aren't smart enough to lower it to optimal machine code. In this article, I would like to argue the opposite: patterns that generate good assembly map just fine to the Wasm stack machine, and the underperformance of V8, SpiderMonkey, and Wasmtime is an accident. some numbers I re-ran Matt's experiment locally on my x86-64 machine (AMD Ryzen Threadripper PRO 5955WX). I tested three toolchains: Compiled natively via cargo / rustc Compiled to WebAssembly, then run with Wasmtime Compiled to WebAssembly, then run with Wastrel For each of these toolchains, I tested Raven as implemented in Rust in both "switch-based" and "tail-calling" modes. Additionally, Matt has a Raven implementation written directly in assembly; I test this as well, for the native toolchain. All results use nightly/git toolchains from 7 April 2026. My results confirm Matt's for the native and wasmtime toolchains, but wastrel puts them in context: We can read this chart from left to right: a switch-based interpreter written in Rust is 1.5x slower than a tail-calling interpreter, and the tail-calling interpreter just about reaches the speed of hand-written assembler. (Testing on AArch64, Matt even sees the tail-calling interpreter beating his hand-written assembler.) Then moving to WebAssembly run using Wasmtime, we see that Wasmtime takes 4.3x as much time to run the switch-based interpreter, compare ## Wastrel Compiles Hoot Scheme-to-WebAssembly Output DevFeed: [Wastrel Compiles Hoot Scheme-to-WebAssembly Output]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-31T20:34:23Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [Compiler](), [scheme]() Tags: [accidentally-quadratic](), [aot](), [bigint](), [bignums](), [compiler](), [compilers](), [exception-handling](), [exceptions](), [gc](), [gcc](), [gmp](), [hoot](), [igalia](), [library](), [maps](), [precision](), [scheme](), [standard](), [tail-calls](), [wasm](), [wastrel](), [webassembly](), [whippet]() ### AI overview The article describes recent work on Wastrel, an ahead-of-time WebAssembly compiler, including compiling output from the Hoot Scheme-to-Wasm compiler. It covers implementing bignum operations with mini-gmp and updating Hoot to use standardized WebAssembly exception handling. ### Source excerpt Good day! Today (tonight), some notes on the last couple months of Wastrel, my ahead-of-time WebAssembly compiler. Back in the beginning of February, I showed Wastrel running programs that use garbage collection, using an embedded copy of the Whippet collector, specialized to the types present in the Wasm program. But, the two synthetic GC-using programs I tested on were just ported microbenchmarks, and didn't reflect the output of any real toolchain. In this cycle I worked on compiling the output from the Hoot Scheme-to-Wasm compiler. There were some interesting challenges! bignums When I originally wrote the Hoot compiler, it targetted the browser, which already has a bignum implementation in the form of BigInt, which I worked on back in the day. Hoot-generated Wasm files use host bigints via externref (though wrapped in structs to allow for hashing and identity). In Wastrel, then, I implemented the imports that implement bignum operations: addition, multiplication, and so on. I did so using mini-gmp, a stripped-down implementation of the workhorse GNU multi-precision library. At some point if bignums become important, this gives me the option to link to the full GMP instead. Bignums were the first managed data type in Wastrel that wasn't defined as part of the Wasm module itself, instead hiding behind externref, so I had to add a facility to allocate type codes to these "host" data types. More types will come in time: weak maps, ephemerons, and so on. I think bignums would be a great proposal for the Wasm standard, similar to stringref ideally (sniff!), possibly in an attenuated form. exception handling Hoot used to emit a pre-standardization form of exception handling, and hadn't gotten around to updating to the newer version that was standardized last July. I updated Hoot to emit the newer kind of exceptions, as it was easier to implement them in Wastrel that way. Some of the problems Chris Fallin contended with in Wasmtime don't apply in the Wastrel case: sinc ## wasmCloud v2.0 is here DevFeed: [wasmCloud v2.0 is here]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-03-23T00:00:00Z Content type: release Language: en Sources: [wasmCloud Blog]() Topics: [wasm](), [WebAssembly](), [Cloud Native Ecosystem](), [Kubernetes](), [Command-line interface](), [Containers](), [Development]() Tags: [cli](), [cloud-native](), [containers](), [go](), [kubernetes](), [native](), [operator](), [rust](), [typescript](), [vendor-lock-in](), [wasi](), [wasm](), [wasm-components](), [wasmcloud](), [webassembly]() ### AI overview wasmCloud v2.0 is a redesigned platform for deploying WebAssembly workloads across clouds, Kubernetes clusters, datacenters, and edge locations. The release introduces a simplified runtime architecture, Kubernetes-native scheduling, Wasm Shell, a workload API, and a Kubernetes Operator. ### Source excerpt wasmCloud v2.0 is a reimagining of the wasmCloud platform: Kubernetes-native, radically simplified, and more powerful than ever. ## Hiring at Zed: Building in Real Time DevFeed: [Hiring at Zed: Building in Real Time]() Original publisher: [Read original article]() Author: Mary Luna Published: 2026-03-20T00:00:00Z Content type: article Language: en Sources: [Zed Industries - Blog]() Topics: [Rust](), [Open Source](), [Code](), [real-time](), [Cloud](), [wasm](), [ui](), [Framework](), [Pull Request](), [GPU]() Tags: [building](), [cloud](), [code](), [collaboration](), [demo](), [framework](), [gpu](), [hiring](), [how-we-work](), [real-time](), [rust](), [ui](), [wasm](), [work]() ### AI overview Zed describes how it hires engineers and how new hires work during their first 90 days. The company says fewer than half of its hires submitted applications, with others discovered through open-source contributions, conferences, Hacker News, or existing relationships. New engineers land an early pull request, demonstrate their work, pair with colleagues, and contribute across Zed's vertically integrated Rust stack. ### Source excerpt How we work at Zed and how we hire. ## Five ways of looking at Jco, Part 1 DevFeed: [Five ways of looking at Jco, Part 1]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-03-19T00:00:00Z Content type: article Language: en Sources: [Bytecode Alliance]() Topics: [JavaScript](), [wasm](), [WebAssembly](), [Rust]() Tags: [blog](), [javascript](), [js](), [presentation](), [technical](), [wasm](), [webassembly]() ### AI overview This first article in a series explains Jco as a layered architecture for the JavaScript and WebAssembly ecosystem. It introduces the projects involved in building JavaScript WebAssembly components, including StarlingMonkey, componentize-js, Wizer, and Jco's CLI and transpilation capabilities. ### Source excerpt Jco (@bytecodealliance/jco on NPM)is a "multi-tool for the JS WebAssembly ecosystem." At the 2026 Bytecode Alliance Plumbers Summit, Technical Steering Committee member Bailey Hayes put it another way: Jco is "like five projects in one." It's certainly a project with many facets--five big ones, arguably! Recognizing what those facets are, and how they fit together, is the key to understanding why Jco matters beyond the JavaScript ecosystem. In this blog series, we'll draw on Victor Adossi's Plumbers Summit presentation to take an in-depth look at Jco from five different perspectives, in order to better grasp how you can use (and contribute to!) Jco today. There's a lot to unpack here, so in this first post, we'll try to get to grips with Jco as a layered architecture that brings together many pieces of the Wasm and JS ecosystem. ## Turbopack: What's New in Next.js 16.2 DevFeed: [Turbopack: What's New in Next.js 16.2]() Original publisher: [Read original article]() Author: Tim Neutkens Published: 2026-03-18T20:00:00Z Content type: release Language: en Sources: [Next.js Blog]() Topics: [releases](), [modern web development]() Tags: [bugs](), [css](), [javascript](), [next-js](), [performance](), [release](), [typescript](), [wasm](), [workers]() ### AI overview Next.js 16.2 updates Turbopack with Server Fast Refresh, Web Worker origin support, SRI for JavaScript files, dynamic-import tree shaking, loader and Lightning CSS configuration, TypeScript PostCSS configuration, log filtering, and performance and bug-fix work. ### Source excerpt Turbopack in Next.js 16.2 brings faster builds, SRI support, postcss.config.ts, tree shaking of dynamic imports, Server Fast Refresh, inline loader configuration, and over 200 bug fixes. [Next page]()