What if we could transcend JavaScript and TypeScript in our web browsers?
JavaScript emerged as a straightforward scripting language, reminiscent of the then-nascent Java. Over time, we developed numerous tools to enhance efficiency and performance, including linters, package managers, frameworks, and libraries, ensuring our code functioned across all browsers, even the notoriously difficult Internet Explorer 6. We embraced new programming paradigms, adopted functional programming, and began implementing class-based structures, ultimately creating entire applications directly within the browser environment. This evolution has allowed us to leverage the capabilities of V8 engines beyond traditional boundaries.
We often found ourselves constrained by the limitations of our scripting language, frequently voicing our concerns about its design shortcomings, and more often than not, we wished for alternatives. In response, the ByteCode Alliance introduced ASM.js, followed by WASM: a unified target for binaries and modules to operate seamlessly within our browsers, representing machine code for the contemporary web.
Astute developers recognized the compactness and portability of these binaries, attributed to the highly abstract WASM runtime. They subsequently created WASI, which enhances WASM in the browser by incorporating essential system calls that enable developers to interact with the web, I/O interfaces, sockets, and more, regardless of the operating system, platform, or architecture.
This innovation effectively allows us to execute a wide range of applications wherever WASI is supported. WASI transforms our WASM runtime into fully functional virtual machines without the overhead of a traditional operating system.
As we enter 2024, edge computing and composability stand out as significant trends within the industry. The importance of safety has reached such a level that the White House has issued a statement endorsing memory-safe programming languages. We are increasingly challenged to achieve more with fewer resources, aiming to minimize costs, time, and emissions. In this context, a fast, hardware-adjacent solution emerges, free from any specific vendor constraints and agnostic regarding coding languages and methodologies.
WASM is truly ubiquitous
During the recent Codemotion Conference in Milan, I attended a talk by Gridspertise regarding their implementation of WASM and DAPR.
What surprised me was realizing that I had already been utilizing WASM daily, simply by charging my laptop. Gridspertise is a company focused on smart grid solutions and the digital transformation of power distribution networks. They offer technologies and services designed to assist utilities in modernizing their infrastructure, enhancing efficiency, and incorporating renewable energy sources. Their expertise lies in developing advanced metering systems, grid automation solutions, and digital platforms for energy management.
Their operations depend on devices and sensors at the edge, with their cloud infrastructure communicating through consistent interfaces, interpreting the same metrics, and collecting logs uniformly to create cohesive metrics. Typically, this would require separate teams for IoT, microservices, and user devices. However, by leveraging WASM, they can address all these areas with a single team.
WASM operates within a sandbox environment, making it inherently suitable for encapsulation and deployment across various platforms. It has been integrated with DAPR, a library designed for distributed applications that utilizes the sidecar pattern. As implied by its name, it creates a supportive structure around the service, facilitating resource access and communication with other containers without requiring knowledge of the underlying implementation or platform specifics. This abstraction of complexity allows the development team to concentrate on maintaining a consistent codebase, independent of platform-related issues.
This approach aligns seamlessly with existing technologies: their containers can function as pods within Kubernetes, communicate with Kafka via MQTT and gRPC protocols, and offer APIs in a similar manner. Additionally, it eliminates the necessity of executing code within a JVM or Linux containers, resulting in minimal memory usage. WASM does not require a “cold boot,” which is often necessary for initializing functions on various cloud platforms; it can operate directly from the WASM runtime in a sandboxed setting, negating the need to start containers repeatedly.
What insights can we gain as web developers?
As previously noted, WebAssembly (WASM) enables us to create applications using various programming languages and deploy them on the web. There are numerous frameworks available, such as Yew for Rust and Blazor for C#, which facilitate the operation of our applications in the background via WASM while interacting with JavaScript. Additionally, we can leverage technologies like TensorFlow and large language models (LLMs) in our browsers, achieving performance levels that are closer to native execution.
However, I find the application of these concepts to front-end development particularly fascinating.
We can easily relate to our peers in this field, as we aim to deploy universal applications across different platforms, including smartphones and web browsers. The concept of “micro-frontends” parallels that of “micro-services,” where individual modules operate independently, share resources and permissions, and communicate through events to maintain coherence. Users expect seamless experiences, such as real-time updates to their shopping carts and product pages as they add items.
While this may not be as critical as ensuring the accuracy of sensor data, every detail is significant in competitive sectors like e-commerce and other services like online banking; reliable software that offers engaging user experiences fosters customer satisfaction and loyalty.
Is it possible for us, as web developers, to transcend the traditional divide between front-end and back-end development? I can envision a future where our web applications consist of numerous modules from various teams, seamlessly integrating in the browser similar to an event-driven architecture. This would create resilient user experiences, even in the event of module failures, without relying on complex stateful solutions. Instead, we could implement granular, stateless reactivity, eliminating the need to duplicate logic for user input validation, regardless of whether our backend colleagues prefer Scala while we favor TypeScript.
Main Author: Federico Muzzo, Front-end Developer @ Bitrock
