 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
At Wasm I/O in Barcelona and KubeCon in Paris, several updates regarding WebAssembly (Wasm) were announced. From these, four big patterns emerged.
Since its inception, the biggest risk to Wasm’s success has been lack of support from programming languages. Even the best cross-platform bytecode format cannot succeed if no languages compile to that format.
I’ve been keeping track of language support in WebAssembly for a long time. In particular, I track how many of the top 20 languages, according to RedMonk, are adopting WebAssembly. Python, JavaScript/TypeScript, Ruby, Rust, C/C++ and Zig have all made the Wasm move, and other languages are on their way.
At Wasm I/O, JetBrains’ Zalim Bashorov reported on the rapid progress of Kotlin. In addition to being a popular language in its own right, Kotlin represents the most progressive elements of the Java world. With Kotlin nearing WebAssembly core support and WASI 0.2 support, I expect that the popularity of the language will gain another boost as it finds a new target developer audience. More than that, it will draw the larger Java community toward WebAssembly.
Dart now ships with a WebAssembly compile target. At Wasm I/O, Kevin Moore of Google shared the exciting developments in the Dart and Flutter world. Moore did not give the impression that Dart would extend its reach beyond its browser and mobile app roots, but the performance boon that Wasm brings to that world is fantastic. Moore showed benchmarks indicating that Wasm execution can be over 50% faster than JavaScript-based execution times.
Finally, the Go team, represented by Rajiv Singh and Achille Roussel, covered the new developments in Go’s WebAssembly support. Go has ceded some of its WebAssembly support to TinyGo (and Ron Evans, head of that project, also presented at Wasm I/O). But the core Go team now has a renewed interest in supporting Wasm both in and out of the browser.
One more major feature of programming language support, though, is debuggability. Microsoft’s Natalia Venditto and Ralph Squillace demonstrated Wasm debugging inside of Visual Studio Code. Language-neutral Wasm debugging is an absolute must for modern software development, and Microsoft is hard at work on making this a reality.
Both Wasm I/O and KubeCon were abuzz about running Wasm inside of Kubernetes. Fermyon, Microsoft, SUSE, Liquid Reply and others collectively released the open source SpinKube project for running Spin-flavored Wasm Kubernetes applications. And at KubeCon, international optics company ZEISS Group showed practical use cases on the keynote stage.
SUSE announced Rancher Desktop support for WebAssembly, using its K3s Kubernetes runtime. Fermyon announced a commercially supported, ultra-dense Fermyon Platform for Kubernetes, capable of running 5,000 Wasm apps per Kubernetes node. Cloud Native Computing Foundation’s wasmCloud project reached 1.0, and supports Kubernetes integration. And NGINX Unit announced support for running Spin apps inside of its application platform.
After the KubeCon keynote on WebAssembly, EMA analyst Torsten Volk noted that Wasm had trended to the most discussed topic of the conference.
What is it about Wasm that meshes so well with Kubernetes? Wasm’s cold start times make it an excellent platform for lambda-like serverless functions. Kubernetes users have long had an interest in running such workloads inside of the cluster, but the first wave of Kubernetes serverless solutions could not match the density, performance and startup speed of Wasm.
There were eight sessions on the WebAssembly Component Model at Wasm I/O this year. While last year’s Wasm I/O covered the component model in a largely theoretical way, this year we saw the impact one year of development has had on components.
I particularly enjoyed the three-session series with Fermyon’s Thorsten Hans showing polyglot programming with components, Ryan Levick explaining the wherefore and why of components, and Luke Wagner finishing the triad with a session on asynchronous calls between components (a yet-to-be-completed part of WASI).
There were other sessions focused on using components to accomplish specific tasks by InfinyOn’s Sejyo Chang, Design Systems’ Pierre Dureau, Dilla.io’s Jean Valverde, Cosmonic’s Taylor Thomas and others. Taken in aggregate, it is now clear that the component model is ready for use.
The most important component-related development, though, came from F5’s Oscar Spencer and JAF Labs’ Danny Macovei. Work on defining a component registry has been ongoing for the last three years, but at the end of Wasm I/O’s first day, Macovei and Spencer launched WA.dev, the first Wasm component registry. It’s fair to compare WA.dev to npm or even Docker Hub. Developers can upload their components to a central registry that makes discovery and management of components easy for us all.
Perhaps the last development is an anti-trend. Language support is falling in line. Kubernetes and Wasm are hitting stride. The Wasm Component Model specification is finding its way into practical tooling. These are all signs of maturation and stability. However, Wasm has not stagnated; there’s still an element of ongoing exploration.
Nothing illustrates this better than the Wanix project, which independent developers Jeff Lindsay and Julian Del Signore introduced on the second day of Wasm I/O. Lindsay is a visionary’s visionary whose projects frequently force software developers to rethink their assumptions about how things can be done. From inventing webhooks to his prolific early contributions in the container space, Lindsay has pushed boundaries. Wanix is no exception.
Del Signore and Lindsay showed an in-browser, Plan9-inspired operating system that powered a CMS-like system capable of syncing state to GitHub. It was a fantastic example of how Wasm’s versatility, performance and cross-platform nature can combine to build a class of tool for which there currently is no name.
In a similar vein, Daniel Lopez, former head of Wasm Labs at VMware, took the audience on a fun-filled ride when he showed a variety of demos. From running Windows 95 in the browser to demonstrating AI inferencing, Lopez pointed to a variety of interesting applications of this highly versatile technology. Among the most humorous moments, Lopez showed how Docker could be run inside of Wasm, adding multiple layers of virtualization. The guiding strand of his presentation, though, is that Wasm is not to be pigeonholed.
On the last day of Wasm I/O, Ron Evans, creator of TinyGo (among other things), introduced an open source framework for Internet of Things (IoT) embedded development. Powered by Wasm, Mechanoid supports embedded development in a wide variety of programming languages, including Rust, Go and Zig. IoT is a burgeoning area for WebAssembly. While it has already gained a foothold in entertainment devices, Evans explored using it in microcontrollers, pushing Wasm down to classes of tiny devices.
In many ways, Wasm has shown its maturation. Almost all mainstream languages now support WebAssembly. Kubernetes is proving to be a popular environment for hosting Wasm applications, and the WebAssembly Component Model is unlocking the revolutionary possibilities of WebAssembly, including true polyglot programming.
But just as Java found use cases beyond its original intent, we also see Wasm opportunities opening up in fascinating areas like IoT as well as emerging areas like Wanix. This serves as a good reminder that maturity does not entail stagnation.
