WebAssembly Memory64 Proposal Lands in Major Browsers

Chrome 119 and Firefox 118 now support 64-bit memory in WebAssembly. About damn time.

Why This Matters If You Process Real Data

We've been hitting the 4GB limit constantly. Our video transcoding service would choke on anything over ~3.8GB because WASM's linear memory was stuck with 32-bit addressing. Had to split everything into chunks and reassemble after processing - total pain in the ass.

Now you can use i64 addresses instead of being stuck with i32. Browsers cap it around 2GB per tab still (memory protection reasons), but Node.js and server-side runtimes can actually allocate what you need instead of this artificial limit.

Still Waiting on GC Though

Memory64 is great but we're still stuck with manual memory management for most languages. The GC proposal is still in Phase 3 - almost there but not quite shipping yet.

Tried compiling our Kotlin code to WASM last month and it's still a nightmare. You either implement your own allocator or stick to languages that compile down to linear memory nicely (C, Rust, AssemblyScript).

The moment GC lands in browsers, half our stack becomes viable for client-side WASM. Until then, we're limited to specific use cases where manual memory management makes sense.

What's Actually Coming Next

Multiple memories proposal is still in development but Memory64 is a solid step forward. Means you can actually think about running real workloads in WASM instead of toy demos.

The reference types improvements landed in most browsers already - better function references and some performance wins for indirect calls. Not earth-shattering but noticeable if you're doing a lot of function pointer stuff.

Still feels like we're 2-3 years away from WASM being a serious alternative to native apps, but Memory64 removes one of the biggest blockers for data-heavy applications.

WebAssembly 3.0 isn't just about 64-bit memory and garbage collection. They also fixed a bunch of other annoying problems that made compiling real languages a nightmare.

Exception Handling That Doesn't Suck

Native exception handling fixes the JS callback nightmare. Before, every exception meant bouncing back to JavaScript, which was slow as hell. Our Kotlin code had more JS callbacks than actual Kotlin.

Now you can define exception tags and catch them without leaving WASM. Still figuring out the details but it's way cleaner than the ridiculous hacks we were doing.

Tail calls are supposedly huge for functional languages. They don't eat stack space or whatever. Haven't touched that yet but anything that prevents stack overflows sounds good to me.

SIMD That Actually Performs

Relaxed vector instructions fix the SIMD performance nightmare from 2.0. Some vector instructions were doing extra work on certain hardware just to match the spec exactly, which was fucking slow.

Now the relaxed variants can pick the fastest implementation instead of forcing compatibility bullshit. Seems way faster on ARM and x86 from the limited testing I've done.

For blockchain stuff that needs deterministic execution, there's a separate profile that guarantees identical results everywhere. You pick deterministic or fast, not both. Fair enough I guess.

Languages That Actually Work Now

Garbage collection opened the floodgates. Java, OCaml, Scala, Kotlin, Scheme, and Dart all compile to WebAssembly now without the memory management nightmares we had before.

This is a big deal. WebAssembly isn't just for C/C++/Rust anymore. High-level languages can compile to WASM and actually perform well instead of fighting the runtime constantly.

String Handling Finally Works

The JS string builtins let you manipulate JavaScript strings directly instead of treating them as useless black boxes. No more copying strings around just to check their fucking length.

This fixes a huge performance bottleneck for text processing. Our document editor was slow as shit before, now it's actually usable. Still not great but at least it doesn't freeze on large documents.

WebAssembly 3.0 finally feels like something you'd actually use in production instead of a research project.

Everyone's acting like WebAssembly 3.0 is some huge game-changer. Let me tell you who's actually using this stuff and why it matters outside the hype cycle.

Big Companies Are Actually Using This Now

The banks are pissed they can't run their massive data processing on the web because of that stupid 4GB limit. Now they can actually deploy their Java risk calculation engines without rewriting everything in JavaScript. Goldman Sachs and JPMorgan developer portal have been asking for this shit for years.

Our client has a 10GB dataset processing pipeline written in Java. Before WASM 3.0, they had to either split it into tiny chunks or run it server-side only. Now it runs in the browser and doesn't crash every 30 minutes when they hit the memory wall.

The GC support means no more "let's rewrite our entire Java app in JavaScript" conversations in meetings. You can take your existing pile of Java code, compile it to WASM, and actually use it. Not perfectly, but way better than the old garbage where you needed a PhD in memory management to get anything working.

Cloudflare and AWS Actually Give a Damn

Cloudflare Workers finally stopped being a toy for tiny functions. With 64-bit memory, you can run actual applications instead of "hello world" demos. Their edge deployment went from "cute proof of concept" to "we can actually run our image processing pipeline here."

AWS Lambda is betting hard on WASM for the new serverless runtime. They're tired of dealing with container cold starts and want something that boots faster than JavaScript but doesn't suck like their previous attempts. The security isolation means they can pack more workloads per machine without customers' code stepping on each other.

We moved our ML inference to Fastly Compute@Edge last month. The old Python deployment took 800ms to cold start; WASM boots in 5ms and runs the same model inference. It's not rocket science, just finally having the memory to load a decent model without hitting limits.

Finally, Languages That Don't Suck

Before this, if you wanted to use WASM, you had to either learn Rust (which is fine but takes forever) or deal with C++ (which is hell on earth for web stuff). Now you can just take your Kotlin Android app and compile it for the web without rewriting the entire thing.

NPM packages with WASM have exploded because people can finally ship their existing code. The GitHub trending page went from "interesting experiment" repos to actual useful libraries you'd want to use in production.

My team spent 6 months trying to port our Java library to JavaScript before giving up. Now the same code compiles to WASM and runs faster than our hand-optimized JS version. This should have been possible years ago, but hey, better late than never.

The Numbers Don't Lie

Our image processing app went from 8 seconds to 3 seconds for the same operation. That's not a 40% improvement, that's "holy shit this actually works now" territory. WebAssembly benchmarks show 3x faster than equivalent JavaScript, but in practice it's way better than that because you're not fighting with JavaScript's garbage collector.

The 64-bit memory thing is huge for anything that processes real data. Scientific computing that used to require chunking files into tiny pieces can now just load the whole dataset. Financial modeling that crashed browsers can run for hours without issues. Performance research backs this up - memory-intensive apps are 5-10x faster when they're not constantly swapping.

Tools That Don't Make You Want to Quit

Chrome DevTools finally supports proper WASM debugging. You can actually set breakpoints in your Kotlin code and see what's happening instead of staring at cryptic hex dumps. This alone makes WASM development bearable for normal humans.

The SpecTec tool means browser implementations actually agree on what the spec means. Before this, your WASM code might work in Chrome but fail mysteriously in Firefox. Now it's much more predictable.

What's Next (Spoiler: More Good Stuff)

WebAssembly 4.0 proposals include interface types, which should finally fix the "passing complex data structures is a nightmare" problem. Threading improvements are also coming, which means your multi-core processing apps won't be stuck running on one core like it's 1995.

The working group learned from 3.0 that having proper tools and formal specs prevents the "it works on my machine" problems that plagued earlier versions. 4.0 should actually work everywhere from day one instead of requiring 6 months of browser compatibility fixes.

WASM 3.0 isn't just another incremental update. It's the difference between WebAssembly being a cool tech demo and being something you'd actually bet your startup on. Finally.