WasmCon 2023: A Conversation about the Future of WebAssembly

WebAssembly, often abbreviated as Wasm, is shaking up the open source development landscape. Not only does it improve security with its sandboxed execution, WebAssembly also promotes code reusability by enabling developers to create high-performing web applications in nearly every popular language (C, C++, Go, Ruby, Rust and more) while seamlessly integrating with existing technologies.

Maybe you can tell — at NGINX, we’re excited about WebAssembly. With the latest release of NGINX Unit, we added WebAssembly support to the server side. And in September, we joined the inaugural WasmCon conference.

One thing that became clear during our time at WasmCon: WebAssembly is about improving the developer experience. To explore what this means for developers, we broke for a short conversation about WebAssembly’s advantages, potential hurdles and exciting use cases in action.

What’s the Wasm Hype All About?

Jenn Gile: Why do you think people are so excited about WebAssembly?

Matthew Yacobucci: Fundamentally, people are excited about the properties you get out of WebAssembly. You get to run untrusted code in a secure way, efficiently. This came from the browser use cases of wanting to improve on JavaScript, being able to optimize better and having sandboxed/isolated memory ­that gives you a better security posture. It’s also very compacted bytecode when compared to JavaScript. Couple that with its growing maturity and how it’s easier to use on the server side, you get this confluence of properties and growing maturity that’s making everyone excited.

And not to mention the portability aspect of it. WebAssembly frees us up from being tied to computer architectures or tied to language semantics. It’s created this perfect storm of maturing usability as the other properties of security and sandboxing start to take solid form.

Now, we can start also seeing companies building developer tools and experiences that are based on WebAssembly but independent of WebAssembly itself. WebAssembly is starting to become an implementation detail for the user experience, and that’s a very exciting thing.

Challenges to WebAssembly Adoption

JG: We’ve been talking about how WebAssembly is maturing and where people are using it. There are obvious use cases out in front of it, but we’re also hearing from a lot of people that there are barriers to adoption because, in many ways, it’s not mature enough and it’s not easy enough to use. There are lots of reasons for that — and lots of solutions.

What are you seeing? What are the three challenges for you, as someone who works with WebAssembly, with picking it up and using it?

MY: Standards, standards, standards. We’re seeing a lot of great development around the component model and toolchains. There are also portability and language neutrality aspects. But it’s not always easy to get all your languages compiled down to WebAssembly.

Technically, anything that has an LLVM backend can compile into WebAssembly. But it’s not necessarily that easy, especially for dynamic languages. For Rust and Go, and up to a point for C and C++, it’s relatively easy. But it’s harder for Python and JavaScript.

Maturing toolchains and coalescing standards will certainly help. WASI [the WebAssembly System Interface] is also bringing us to a really good point. But we need to see Preview 2 [the next phase of WASI standardization] to see some of that stabilize before people can really start adopting it and committing to it. We also need other players to converge onto WASI so we can push that standard forward to make it appropriate for all these use cases. It needs to become a whole product solution.

Right now, WebAssembly is very low level. Using WebAssembly can be scary, because you are not thinking about objects — you’re thinking about integers, you’re thinking about offsets into memory and about the length of that memory. We need to start building higher-order abstractions.

That’s where a component model comes in. But, as far as a component model goes, that feeds into better toolchains and into a better developer experience. That also feeds into questions like “How do you debug?” or “Can I use a debugger?” or “Are DWARF [debugging with attributed record formats] symbols enough?”

So, as exciting as it is and with as much maturity as we have, there’s still a long way to go. But there’s a very energetic and very enthused community behind it. Which you will see in some of the videos coming out of WasmCon.

JG: Yeah! Everyone’s really in it to mature it.

MY: Yes, for sure.

A WebAssembly Case Study

JG: Okay, so we’ve been talking about all the implementation details of getting WebAssembly out there into people’s hands. But let’s take a moment and step away from that, because a lot of people this week are asking, “Where’s the opportunity here? How does this actually help people?”

We’ve talked a bit about developer experience being a huge area where WebAssembly can have impact, but let’s look at a case study for a moment. You went to a session with Bosch Research Group. What does it look like in practice? What kind of problems can you solve with WebAssembly?

MY: One of our favorite keynotes of the conference was the Bosch Research Group presentation. We can see the real-world application of WebAssembly, and even though the technology still has rough edges, it stands poised as a unifying abstraction across multiple paradigms: language neutrality, hardware and architecture neutrality, ecosystem, and environmental neutrality. Couple this flexibility with WebAssembly’s other safety, security, performance and efficiency attributes and you begin to see an exciting potential.

What I found most exciting about it was that it’s where the ones and zeros really do meet a physical use case. Bosch can definitely speak better to this than I can, but, essentially, they are constrained by ECUs [electronic control units] and these physical components that are in cars, robots and microcontrollers. And there are multiple generations of these with very strict constraints.

What they ended up having to do is build a lot of bespoke code to control these things. What WebAssembly helped them do is start building components once, create an abstraction layer, and then start to be able to share those components around throughout multiple different robotic, multiple different manufacturing and multiple different vehicular use cases.

The keynote really brought home the portability aspects of WebAssembly, with the compact size of the bytecode and the security via sandboxing of the bytecode. It was pretty enlightening to see someone use it in a real-world use case like this.

Learn More

You can watch our full conversation below and learn more about how NGINX is adding open source, server-side WebAssembly support at the NGINX Unit 1.31.0 release page. NGINX and F5 have long looked to extensibility use cases to meet our users’ varied and unpredictable needs, and we believe WebAssembly can supercharge and unify our different platforms.

All in all, WebAssembly is a game-changer for web development. As it continues to evolve and its ecosystem expand, we’re excited to be a part of the developments that lie ahead.