Weekly Tech Report:
26 Mar 2026

The stabilisation of WASI (WebAssembly System Interface) Preview 3, combined with the widening industry adoption of the Component Model, has resolved what was arguably the most stubborn friction point in the WebAssembly ecosystem: seamless polyglot composition without fragile FFI layers. In practical terms, a Rust-compiled data-processing kernel and a Python business-logic module can now be packaged as composable Wasm components that communicate through typed, versioned WebAssembly Interface Type (WIT) definitions rather than through raw 32-bit linear-memory pointers. The result is a degree of language-agnostic interop that the container world spent years trying to fake with protobufs and REST shims.

The architectural shift is consequential. Prior to the Component Model's maturity, every Wasm module operated as an island of linear memory: crossing the boundary between a host JavaScript engine and a Wasm module required explicit marshalling — copying bytes, serialising to JSON, and deserialising back. That round-trip dominated wall-clock time for anything more granular than large batch work. WIT definitions introduce a proper interface description layer sitting above raw memory, allowing runtimes to automatically generate optimised glue code. At the tooling level, wit-bindgen handles the code-gen step for Rust, C, and Go; Python and JavaScript targets are trailing by roughly one release cycle.

That the OpenUI team's Rust→TypeScript rewrite produced a 3× speedup deserves careful unpacking, because it risks being misread as evidence that WASM is simply slow. The six-stage pipeline (autocloser → lexer → splitter → parser → resolver → mapper) was invoked per token of LLM-streamed output. Each invocation crossed the JS/WASM boundary, triggering heap allocation on both sides plus a serialisation cycle. The WASM overhead was not in Rust's execution of the parser logic — that part was genuinely fast — but in the membrane cost of transitioning between the two memory worlds up to hundreds of times per frame. The lesson is not anti-WASM; it is a precise statement about granularity. WASM wins on CPU-bound batch workloads. It loses on chatty, pointer-heavy, streaming pipelines unless the module boundary is designed to batch across many tokens per call. The Component Model's WIT interfaces improve the ergonomics of this design constraint but do not eliminate the membrane cost entirely; they merely make it easier to engineer around.

On the serverless side, cold-start latency — the nemesis of container-based functions — has reached a structural disadvantage versus Wasm runtimes. AWS Lambda's Wasm runtime, now generally available, reports cold starts in the low-microsecond range, compared to the 100–500 ms typical of container-based serverless. The WasmEdge runtime's 2 MB minimum footprint makes it viable even for edge-constrained deployments. Fermyon's Spin framework is emerging as the opinionated orchestration layer of choice here, providing HTTP handlers, queue bindings, and timer primitives over a Wasm-native substrate. The parallels to the early Kubernetes era are striking: a raw runtime layer gaining an opinionated operator framework that abstracts its rough edges.

The WASM Component Model also provides a practical answer to the "known-good module" problem that plagues plugin architectures in game engines. A dark-fantasy RPG engine exposing a scripting API can now publish a versioned WIT interface; modders compile against that interface in Rust, Zig, or even C#, and the runtime validates component signatures before loading — replacing the fragile dlopen/GetProcAddress pattern that has been the source of catastrophic mod-induced crashes since the Quake modding era.

Two research results this month advance the intersection of physical characterisation and computational architecture in ways that will take several years to reach production but are worth tracking now. Cornell researchers published work on an advanced electron ptychography technique that, for the first time, resolves atomic-scale crystalline defects inside a completed commercial chip — not a specially prepared test coupon but an extracted sample from a production device. The method exploits the phase-contrast sensitivity of a convergent electron beam to reconstruct the 3D potential field of a sample with sub-Ångstrom precision, mapping dopant atom positions and vacancy clusters that conventional STEM imaging cannot resolve due to depth ambiguity.

The immediate implication for the semiconductor industry is metrology feedback. As GAA (Gate-All-Around) nanosheet transistors scale below 2 nm, the active channel volumes are so small that a single misplaced dopant atom can shift a transistor's threshold voltage by tens of millivolts — well outside the design window for SRAM bitcells and analog circuits. Current yield-learning loops rely on electrical characterisation after failure and destructive cross-sectional TEM. Ptychographic in-line inspection could enable non-destructive, spatially resolved defect maps at wafer scale, feeding directly into process-control loops. The bottleneck is throughput: current data acquisition and phase reconstruction pipelines require hours of GPU compute per sample. Parallelising the iterative phase retrieval — a problem analogous to phase unwrapping in synthetic-aperture radar — to near-real-time speeds on dedicated silicon is an open research challenge.

Separately, UW-Madison's electrical engineering group demonstrated a photonic content-addressable memory (CAM) array performing large-scale parallel associative lookup operations at the speed of light, consuming orders of magnitude less energy per search than an equivalent SRAM-based TCAM. Traditional ternary CAMs dominate packet classification in network ASICs and L1/L2 TLB lookup in microprocessors, but their power density is punishing — a 1 Mbit TCAM can draw 1–2 W in active search mode. The photonic CAM uses resonant microring modulators as storage elements; the match operation is a phase-coherent interference measurement rather than a voltage comparison. The absence of charge movement in the match path eliminates the dominant power dissipation mechanism. Whether this translates to tape-out silicon remains to be demonstrated, but the architecture suggests a path toward in-memory search engines for graph databases and transformer attention pattern matching at sub-picojoule-per-bit energy costs.

GitHub shipped its late-March 2026 Actions update this week, resolving two features that had accumulated thousands of community upvotes over several years. The changes are individually modest but their compound effect on production workflow design is worth examining at the architectural level.

The first change: IANA timezone support for schedule triggers. Previously, every cron schedule in GitHub Actions was evaluated against UTC, forcing teams to mentally offset their maintenance windows, nightly build jobs, and database rotation tasks. The problem is trivial to state but consistently dangerous in practice, particularly across DST boundaries: a team scheduling a 2:30 AM local-time deploy would, twice a year, see their pipeline fire an hour early or skip entirely due to DST spring-forward folding the skipped hour. The fix is a new optional timezone: key on the schedule block, accepting any IANA zone identifier:

# A deploy that respects Amsterdam business hours
on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "Europe/Amsterdam"

The GitHub documentation specifies DST handling explicitly: for schedules in zones that observe DST spring-forward, a skipped-hour schedule advances to the next valid time. This behaviour is consistent with how cron on GNU/Linux systems handles the transition when TZ is set — but the consistency is not free. The runner infrastructure must now maintain a per-workflow IANA zone database and compute next-fire times against zone-aware calendar arithmetic rather than raw Unix epoch arithmetic. The correctness of this becomes non-trivial when combined with the existing constraint that scheduled workflows in GitHub Actions evaluate against the HEAD of the default branch — meaning a timezone misconfiguration in a recent commit could silently shift all downstream deploys without triggering any diff-visible alarm.

The second change is architecturally more interesting from a secrets-management perspective. GitHub Environments previously created a deployment record every time they were referenced in a workflow — a side-effect that polluted the deployment history and triggered unwanted webhook events for every CI run that merely needed access to environment-scoped secrets. The new deployment: false key decouples secret access from deployment lifecycle:

jobs:
  integration-test:
    runs-on: ubuntu-latest
    environment:
      name: staging
      deployment: false   # access secrets, skip deploy record
    steps:
      - run: echo ${{ secrets.STAGING_DB_URL }}

The caveat is intentional: custom deployment protection rules — those using the GitHub Deployments API to gate pipelines through external approval systems — are incompatible with deployment: false. Any environment configured with a protection rule will continue to require an auto-deploy, preserving the audit trail that makes those rules meaningful. The design correctly separates two independent capabilities that were accidentally coupled: secret namespacing (which environments provide) and deployment lifecycle management (which environments also provide, but don't always need to).

For teams building event-driven Belgian-market booking platforms with multi-region staging environments, the combination of these two changes enables a cleaner pattern: a nightly regression suite that fires at 22:00 Europe/Brussels, reads staging secrets without polluting the deployment history, and gates production promotion through a separate, protection-rule-gated environment job — all in a single workflow file without any custom offset arithmetic or dummy deployment workarounds.

Deno's 2.7 release this week includes a cluster of meaningful performance and ergonomics improvements, among them: auto-detection of CJS versus ESM in deno eval, a --cpu-prof-flamegraph flag that generates interactive SVG flamegraphs directly from the runtime profiler, OTEL attribute array support in telemetry, and a runtime source map application for CPU profiler output. The flamegraph generation deserves attention: it wires v8::CpuProfiler output through an SVG renderer inside the Deno binary itself, meaning teams running Deno on CI can emit a self-contained, browser-openable flame chart as a workflow artefact without any post-processing step. The profiler output is also now source-map aware, so TypeScript symbols appear in the flame chart rather than transpiled JavaScript identifiers — a material improvement for profiling TypeScript-first backends where the compiled output is sufficiently transformed to make raw V8 profiles nearly unreadable.

The broader runtime ecosystem is stratifying along two fault lines: raw startup performance versus ecosystem depth. Bun, built on Apple's JavaScriptCore (JSC) engine, prioritises the former. JSC's design philosophy — shared with Safari's JavaScript pipeline — favours fast startup over peak JIT throughput. V8's TurboFan JIT is a more aggressive optimiser that pays a longer warm-up cost in exchange for higher steady-state throughput on long-lived server processes. For serverless functions where each invocation may be cold, the JSC trade-off wins decisively: teams report AWS Lambda execution-duration reductions of ~35% after migrating from Node to Bun, with the savings originating primarily in reduced JIT warm-up overhead rather than in algorithmic changes. For persistent, high-throughput API servers — the kind that handle thousands of concurrent connections across a long process lifetime — V8's JIT typically closes the gap and often inverts it.

Deno's differentiation is architectural correctness rather than raw throughput. Its Rust-based CLI provides a permission-first security model, native first-class TypeScript compilation (no ts-node interception layer), and a standard library that follows Web API specifications rather than Node's historical conventions. The consequence is that Deno is meaningfully easier to reason about in security-sensitive contexts — a scheduled job that has no network permission cannot accidentally call out to a third-party endpoint through a transitive dependency, because the capability simply isn't granted. For backend services processing medical or financial data, this model has genuine audit trail value.

The Hono framework continues to emerge as the TypeScript backend framework for the edge and multi-runtime tier. Its zero-dependency core, explicit Context-typed handlers, and native support for Cloudflare Workers, Deno, Bun, and Node runtimes make it structurally well-suited for polyglot CI/CD pipelines where the same business logic is deployed to a Lambda function, an edge worker, and a Docker container from the same source. The framework's cold-start characteristics are excellent precisely because it makes no assumptions about the runtime environment and carries no singleton state in module scope.

One architectural signal worth watching: Deno Deploy Classic's announced shutdown (July 20, 2026) is forcing teams to migrate to the new Deno Deploy platform. The new platform uses a Wasm-based workload isolation model rather than V8 isolates, aligning Deno's production deployment story with the broader WASI ecosystem. Whether this proves to be an advantage or a footgun depends on how effectively the WasmEdge runtime underneath it handles the concurrency patterns that Node.js isolate-per-request handles with well-understood semantics.

The three major browser rendering engines — Blink/V8, Gecko/SpiderMonkey, and WebKit/JavaScriptCore — have converged on full WebAssembly 2.0 compliance and achieve identical scores on Acid2/Acid3, but they diverge sharply at the JIT architecture and GPU utilisation layers in ways that matter for engineering decisions about where to deploy performance-critical WebAssembly modules.

V8's WebAssembly execution pipeline operates in two tiers. The first is Liftoff, a single-pass baseline compiler that produces x86-64 or ARM64 machine code with near-O(n) compile time relative to bytecode size. Liftoff trades quality of generated code for compilation speed: it performs no register allocation beyond a simple stack discipline and emits no loop invariant code motion. The second tier, TurboFan (shared with JavaScript optimisation), is an SSA-based optimising compiler that performs full dataflow analysis, escape analysis, and instruction scheduling. V8 hot-tiers Wasm functions into TurboFan asynchronously on background threads, meaning the main thread never stalls on optimisation. The critical detail for engine authors and game developers targeting WASM: TurboFan WASM now supports speculative inlining across Wasm→JS and JS→Wasm call boundaries, using deopt points to fall back to unoptimised code when speculation fails. This is the mechanism that makes Wasm-integrated game scripting viable — calling a JS callback from a tight Wasm render loop no longer necessarily exits the JIT context.

Gecko's SpiderMonkey uses the Warp compiler (successor to IonMonkey) for its optimising tier. The key architectural difference from V8 is Warp's extensive use of CacheIR — a bytecode-level intermediate representation for polymorphic inline cache stubs. CacheIR allows SpiderMonkey to inline the "fast path" of property accesses and type checks directly into the JIT output without the full overhead of type feedback oracle that V8 uses. The practical consequence is that Gecko's JIT performs better on highly polymorphic TypeScript code patterns — the kind generated by framework boundary code — while V8 wins on monomorphic hot paths where TurboFan's aggressive type specialisation can run deeper. For WebAssembly specifically, SpiderMonkey integrates RLBox sandboxing for third-party Wasm modules, which wraps memory accesses in a Software-Fault-Isolation boundary. This is a meaningful security trade-off for browser plugin ecosystems but introduces ~5–10% overhead on memory-intensive Wasm workloads.

The more structurally important CSS story is in Gecko. The Stylo CSS engine, written in Rust as part of the Quantum project, performs style recalculation across independent DOM subtrees in parallel — spawning work across all available CPU cores using a work-stealing scheduler. A single Chromium process, by contrast, runs style computation on a single thread. For rendering-heavy pages — a map canvas, a live scheduling grid, a large fantasy RPG inventory UI — Firefox's parallel style computation can provide a meaningful frame-time advantage. The engineering cost is complexity: the work-stealing scheduler introduces non-determinism in the order of style resolution for subtrees with shared cascade context, which is why Blink has not adopted the same model. Chrome's GPU-accelerated compositor (CC) and WebRender (now default in Firefox) both render via GPU, but their rasterisation models differ: Blink rasterises to textures on the CPU and uploads to the GPU, while WebRender tessellates and rasterises directly on the GPU. For scenes with many independently animated layers — a common pattern in game HUDs — WebRender's approach reduces the number of texture uploads and eliminates redundant CPU rasterisation work.

Belgian chip research institute imec confirmed delivery of ASML's EXE:5200 High-NA EUV lithography system this month — a machine that costs roughly $400 million and is one of fewer than a dozen units in existence globally. The acquisition is part of imec's five-year strategic partnership with ASML, backed by EU Chips Act funding (IPCEI and NanoIC pilot line programs) and the Flemish and Dutch governments. Full system qualification is targeted for Q4 2026, after which imec's global partner ecosystem — comprising essentially every major fabless design house and memory manufacturer — will have access to sub-2nm and advanced DRAM process development on European territory for the first time.

The physics of High-NA EUV requires some unpacking to appreciate why this system is categorically different from the 0.33 NA EUV tools that enabled 7nm through 2nm production. Numerical aperture in an optical system governs the finest resolvable feature through the Rayleigh criterion: R = k₁ · λ / NA, where λ for EUV is 13.5 nm and k₁ is a process-dependent constant typically around 0.28 for dense line/space patterns. At 0.33 NA, this resolves to approximately 11.5 nm half-pitch per exposure — which is why 3nm and 2nm nodes required multi-patterning to achieve tighter pitches. At 0.55 NA (the EXE:5200), the resolution improves to approximately 8 nm half-pitch in single exposure, eliminating two to three multi-patterning steps per critical layer. Each eliminated patterning step reduces overlay error accumulation, simplifies process flow, and improves yield by removing one opportunity for misalignment-induced shorts or opens.

The engineering challenges introduced by the higher NA are non-trivial. The larger optical cone angle means the anamorphic projection optics must use a 4:1 reduction ratio in one axis and 8:1 in the other — requiring new reticle stitching infrastructure and resizing the maximum printable field from 26×33 mm² (standard) to 26×16.5 mm². The smaller field requires more die exposures per wafer, partially offsetting the throughput gains from eliminated multi-patterning steps. Additionally, mask-induced shift (MIS) and aberration uniformity across the anamorphic field demand mask fabrication tolerances an order of magnitude tighter than current EUVL masks — a supply chain bottleneck that ASML CEO Christophe Fouquet has acknowledged as the primary gating factor for high-volume manufacturing entry in 2027–2028.

Intel's 14A node is the first commercial high-volume target for High-NA, building on the EXE:5200B acceptance testing completed at the D1X Oregon fab in December 2025. Samsung is deploying its second High-NA unit in the first half of 2026 for 2nm (SF2) and advanced HBM4 DRAM patterning. TSMC, notably, has chosen to defer High-NA adoption, opting instead to push 0.33 NA EUV to its limits through enhanced multi-patterning for the A14 (1.4nm) node. The economic rationale is clear: TSMC's 2nm wafer pricing is already at $30,000 — a 10–20% premium over 3nm — and adding High-NA capital expenditure (at $380M+ per system, requiring multiple units per production bay) would compress margins or force further customer price increases. Intel and Samsung, both seeking to close the foundry gap with TSMC, are making a different calculation: that process density leadership justifies the equipment cost premium.

For GAA nanosheet transistors — the device architecture that replaces FinFET at 2nm and below — High-NA EUV's tighter patterning tolerances are not merely a density benefit. GAA gate formation requires patterning the internal surfaces of nanosheet stacks where overlay error compounds multiplicatively across each sheet layer. A 1 nm overlay improvement at the lithography step translates to a threshold voltage distribution tightening of roughly 15–20 mV at the device level, which cascades into reduced leakage variance and improved energy efficiency at the circuit level. The thermal design power (TDP) consequences are material: chips manufactured on a well-yielding GAA process enabled by High-NA EUV are expected to deliver a 30–40% improvement in performance-per-watt relative to FinFET 3nm — not through faster clocks, but through leakage current reduction and the ability to drive supply voltages lower while maintaining timing margin.

Three interconnect and memory standards are maturing in parallel this year, and their convergence is defining the memory hierarchy for the next five years of AI and HPC infrastructure. Understanding the role each plays — and where they interface — requires separating three distinct problems: on-package bandwidth (HBM4), die-to-die integration (UCIe 3.0), and rack-scale memory disaggregation (CXL 4.0).

SK hynix's 16-layer HBM4 with 48 GB, debuted at CES 2026, extends the architecture first specified in JEDEC's JESD238 standard. The 16-layer stack achieves bandwidth exceeding 2 TB/s per stack by widening the through-silicon via (TSV) interface bus to 2048 bits and increasing signalling rate to approximately 7.2 Gbps per pin. The move from 12 to 16 layers is not purely a capacity scaling story: the additional DRAM dies provide more independent banks, allowing finer-grained burst scheduling that reduces effective access latency at the controller level by approximately 12% in random access patterns. The base die in HBM4 supports customer-specific logic integration — termed cHBM — enabling compute-in-memory operations, PIM (Processing-In-Memory) acceleration, and direct on-die attention score computation for transformer inference. Samsung is pursuing a parallel cHBM path for its Exynos 2600 and Tesla AI chip designs.

UCIe 3.0, specified in mid-2025 and now in its production IP integration phase, doubles the data rate from UCIe 2.0's 32 GT/s to 64 GT/s. The protocol adds runtime recalibration — a mechanism allowing the physical layer to dynamically adjust equalisers and timing margins while the system is live, compensating for thermal drift in 3D-stacked packages where the TSV pitch is shrinking to 6 µm (hybrid bonding territory). The most strategically important feature is the UCIe DFx Architecture (UDA), a vendor-agnostic management fabric enabling real-time link telemetry across chiplets from different foundries and vendors. The "known good die" (KGD) problem — the yield risk of assembling untested chiplets into a multi-die package — is addressed through UDA's early-stage testability hooks that allow individual dies to be burned-in and characterised before bonding. AMD's MI400 GPU, using 2nm compute chiplets alongside HBM4, is the first production silicon expected to leverage UCIe 3.0's full feature set.

CXL 4.0, released by the CXL Consortium in November 2025, rides the PCIe 7.0 physical layer at 128 GT/s and introduces bundled ports that aggregate multiple physical connections into a single logical attachment delivering 1.5 TB/s. The key capability enabled by CXL 3.x/4.0 is multi-host memory pooling with cache coherency: a pool of CXL-attached DRAM in a 2-socket server can be addressed by both CPUs and by PCIe-attached accelerators as part of a coherent address space, with the CXL controller maintaining MESI-style coherence across the fabric. The production deployment timeline for multi-rack CXL memory pooling (100+ TB per rack) is late 2026–2027. Near-term deployments are focused on single-rack KV cache offloading for LLM inference, where storing KV cache in CXL-attached memory (at 4–5× lower cost than GPU VRAM) while keeping hot activations in HBM achieves 3.8–6.5× inference throughput improvements over RDMA-based approaches. PNM-KV, a processing-near-memory architecture for KV cache token page selection, demonstrates up to 21.9× throughput by co-locating selection logic with CXL memory — eliminating the CPU round-trip for cache eviction decisions.

The architectural geometry emerging from UCIe 3.0 + HBM4 + CXL 4.0 can be described as three concentric memory tiers. The innermost tier is HBM4 on-package: 2 TB/s bandwidth, ~10 ns latency, attached to the compute die through hybrid bonding at sub-6 µm pitch — essentially L4 cache semantics for AI workloads. The middle tier is CXL-attached DRAM in the same server (CXL 2.0/3.x): ~70 ns latency, ~200–400 GB/s bandwidth, providing memory expansion without cache coherency complexity for capacity-constrained inference. The outermost tier is multi-rack CXL 4.0 pooled memory: latency in the 200–500 ns range but coherent across the fabric, enabling the "memory-as-a-service" model where AI workloads' KV caches can grow to 150+ GB without GPU VRAM constraints. The research proposal to use UCIe-S instead of LPDDR6 as an on-package memory interface reports bandwidth density up to 10× higher than HBM4 alternatives at equivalent energy per bit — a result that suggests HBM's packaging model, which requires heterogeneous DRAM+logic stacking, may eventually yield to a UCIe-native memory chiplet model as hybrid bonding matures.

One implementation signal worth watching: SK hynix's CMM-Ax product integrates computing capabilities directly into CXL memory modules — effectively embedding an FPGA-class processing element inside the memory expander. This positions CXL-attached memory not merely as a capacity tier but as an active processing resource, analogous to near-data processing (NDP) architectures explored in academic literature for the past decade. For graph neural network inference, where memory access patterns are deeply irregular and data reuse is low, co-locating selection logic with the data eliminates the bandwidth cost of moving candidate data to the GPU for evaluation — a pattern that AMD's FPGA-in-package research confirmed delivers 2–4× throughput improvement for sparse workloads.