WasmGC and the future of front-end Java development

JavaScript is the clear choice for front-end development today, but there is a longstanding push to be able to use Java on the front end. Among other things, Java brings a vast ecosystem of libraries, frameworks, and application code, which can be exposed via its APIs. Java and languages like it also offer performance optimizations that JavaScript can’t match.

Historically, Java’s sophisticated garbage collection algorithm was an obstacle, but Google’s recent push to implement Java’s garbage collection support in Chrome suggests a path forward. The key to it all is WebAssembly’s garbage collection extension, WasmGC.

Google Sheets and WasmGC

One of the great advancements in software development is automatic memory management, otherwise known as garbage collection. In some programming scenarios, it makes sense for a developer to tinker directly with memory, but for safer applications and optimal performance, automating those processes is usually the way to go.

Java’s garbage collection algorithm is one of the more sophisticated options available, which is why Google implemented Googe Sheets in Java. Now, Google wants to take things a step further, by embedding Java’s garbage collection support directly in Chrome, as detailed here.

The evolution of Google Sheets is an interesting tale of web development history. It started as an online spreadsheet application competing with the likes of Excel, which was an ambitious undertaking. The application was built using a Java back end that did most of the heavy lifting. But after a time, Google modified that work to happen mainly in the browser, using JavaScript.

The switch to JavaScript incurred significant performance losses, however, which led to the decision to re-implement Google Sheets in Java. But this time, the implementation is on the front end, using Wasm for native assembly.

Garbage collection in the browser

Wasm is a binary instruction format, a kind of generalized way to describe what a program does at the assembler-instruction level. Once a program is transformed into a Wasm binary, it can be run in a variety of host runtime environments.

There are three basic types of host environments (described by the Wasm project as concrete embeddings): JavaScript, web, and WASI (WebAssembly System Interface), the standard system interface for WebAssembly programs. These embeddings map generally to running Wasm inside a JavaScript engine, inside the browser (not necessarily using JavaScript), and in other environments like servers.

This is an oversimplification, but what matters for our purposes is that JavaScript already has a garbage collection engine. Implementing a garbage collector inside a platform that has one running raises all kinds of problems and eliminates the performance benefits.

What we need is a specification for implementing garbage collection support directly in the browser, where it has access to as much native architecture as possible. This allows us to make optimizations while avoiding conflicts with JavaScript. And that’s where WasmGC comes in.

The state of browser support for WasmGC

The Google Sheets project is working with the Chrome browser, which is implementing the GC extension to Wasm. This is obviously a complex nexus of programming requirements. Garbage collection, although fairly well understood, remains inherently complex. Wasm’s universal binary format is also very complex. Joining the two is tricky, and the work is ongoing.

Even with those caveats, it is exciting that Google Sheets is moving to implement major functionality into Chrome’s WasmGC extension. It suggests that developers may be able to use a language like Java, with its full-featured garbage collector, outside of JavaScript sometimes sooner rather than later.

WasmGC and the emerging GC layer

The Googe V8 team published a good deep dive on the effort to implement garbage collection in Wasm. The article shows that there are two approaches to incorporating garbage collection in Wasm. The first—the one we’ve usually done in the past—is to port the entire architecture over. In essence, this means you bring your garbage collection infrastructure with you when you implement your application.

The approach being offered by the WasmGC extension is newer. The extension provides a generic garbage collection layer that your software can refer to; a kind of garbage collection layer built into WebAssembly.

Wasm by itself doesn’t track references to variables and data structures, so the addition of garbage collection also implies introducing new “typed references” into the specification. This effort is happening gradually: recent implementations support garbage collection on “linear” reference types like integers, but complex types like objects and structs have also been added.

I spoke with Thomas Steiner, developer advocate at Google Web, about the status of complex types in WasmGC. Steiner said the initial Wasm MVP implementation was only capable of dealing with numbers (meaning integers and floats) in linear memory. But with the reference types proposal being shipped, and the added struct and array heap types, Wasm can now hold on to external references. Steiner noted that now, each WasmGC object has a fixed type and structure, “which makes it easy for virtual machines to generate efficient code to access their fields without the risk of deoptimizations in dynamic languages like JavaScript.”

The bottom line is that language compilers targeting Wasm can integrate with a garbage collector in the host VM, said Steiner. Developers porting a programming language to Wasm no longer need to include the language’s garbage collector as part of the port. Instead, they can just use the existing garbage collector provided by the WasmGC extension.

While it is work in progress, the Wasm binary format could eventually include a generalized garbage collection framework that all the garbage collected languages (like Java, Python, Kotlin, C#, etc.) could rely on without bringing along their own garbage collection implementation.

JavaScript, Wasm, and Java

There are also practical considerations in adopting WebAssembly in general and garbage collection in particular. Wasm is loaded differently from JavaScript and requires different tooling. Everything points to Wasm expanding language support in web browsers. But it will only happen incrementally and with much care.

The Java to Closure compiler
For a hands-on look at using WasmGC, this hello world example from the J2CL (Java to Closure compiler) project is an interesting place to start. The J2CL project is geared toward making Java and JavaScript interoperate, and it’s keeping pace with the WamsGC developments in improving the ability to run Java directly.

It’s also worth noting that Wasm code runs alongside JavaScript, and exposes modules to it, so it’s not an either-or choice. In fact, the future of front-end development is likely to be JavaScript and, meaning that JavaScript remains the entrypoint for apps, even if much of the work is handed off to another language running on WebAssembly.

Although the pioneering work is happening in the Google’s Sheets application and Chrome web browser (where WasmGC is now on by default), Mozilla Firefox and Microsoft Edge also support the extension, as do the Deno and Node runtimes. You can check for WasmGC support on Wasm’s support page. In general, it looks like WasmGC is coming of age and becoming a reliable feature for standard web platforms.

Is WasmGC ready for production use?

I asked Steiner about using the WasmGC extension in production apps and he noted that “WasmGC is a standardized proposal (Phase 5 in the process), with implementations in three browsers and the feature shipping in Chrome and in Firefox.” For Safari, he said, the extension has also been merged into WebKit, but “we don’t know yet in what version of Safari it will ultimately ship.” Furthermore, “support for WasmGC is feature-detectable, which means sites and apps like Google Sheets can use a progressive enhancement approach: On browsers that support WasmGC, the new version is loaded, and on other browsers without support, the existing legacy version will do.”

The performance potential of languages like Java over JavaScript is a key motivation for WasmGC, but obviously there’s also the enormous range of available functionality and styles among garbage-collected platforms. The possibility for moving custom code into Wasm, and thereby making it universally deployable, including to the browser, is there.

More broadly, one can’t help but wonder about the possibility of opening up the browser to other languages beyond JavaScript, which could spark a real sea-change to the software industry. It’s possible that loosening JavaScript’s monopoly on the browser will instigate a renaissance of creativity in programming languages.

When I asked Steiner if we’d ever see pure-Java (no JavaScript) browser apps, he said, “That day, effectively, is already today. Solutions like CheerpJ allow developers to run entire Java apps in the browser, for example, this Swing demo (give it a bit of time to load). It’s thought more for porting legacy Java apps to the web, but, in theory, if someone wrote a Java program targeting CheerpJ today, they could run it in the browser. In the Google Sheets case, they used J2Wasm to port the calc worker from Java to WasmGC.“

Steiner mentioned further that other languages like Kotlin can use Kotlin/Wasm, and that “Likewise, the Flutter team at Google now makes use of WasmGC by compiling Dart to WasmGC, and similar solutions exist for SwiftWasm (which doesn’t yet target WasmGC, but regular Wasm).”

Conclusion

I am personally a huge fan of JavaScript. It’s a marvel of expressiveness and I don’t have many gripes about it. On the other hand, I’m always interested in how competition and cross-pollination spur innovation.

Looking back some years from now, it could be that Wasm as a universal deployment layer creates a new phase in enterprise and web development. Quietly, with little fanfare, work is proceeding on making that universal layer more powerful and useful. WasmGC’s progress is a tantalizing milestone in the story.

Of course, there is an enormous amount of work remaining and the path is not straightforward. Security, performance, tooling, and just simple inertia all present real obstacles. Still, the vision of the Wasm-empowered browser as a truly universal compute platform is here.