DEV Community: DRS Software

Announcing Logisim.app: Run the classic logic simulator in your browser

Martin Nyaga — Wed, 16 Apr 2025 15:34:31 +0000

TL;DR: We’ve built Logisim.app — a fully-featured, web-based port of Logisim, the beloved digital logic simulator used by students, educators and electronics hobbyists around the world. It runs entirely in your browser, powered by WebAssembly. It’s open source and completely free to use; no download or sign up required.

Introduction
What is Logisim?
How does it work?
Who is this for?
What about Logisim-evolution?
Why are we doing this?
What's next?
Who are we?

Introduction

We’re excited to announce the release of Logisim.app: a complete, browser-based port of classic Logisim — the digital logic simulator that has introduced generations of learners to logic gates, CPUs, and computer architecture.

For a large audience of students and enthusiasts — many of us at DRS included — Logisim was the gateway to understanding how computers really work. Building electronic circuits one logic gate at a time, then watching them tick and perform computation is a kind of magic that leaves a lasting impression. It's no surprise then, that over two decades since its first release, Logisim is still widely used by students, educators, and hobbyists around the world.

And now, for the first time, Logisim runs anywhere, on any platform and device, including Chromebooks, tablets, and even mobile! No sign up, no download, no installation, no Java runtime and no permissions are required. Just visit logisim.app and start building!

Logisim.app runs directly in your browser thanks to WebAssembly, a powerful browser technology that makes it possible to run complete desktop-class applications entirely client-side.

The power of the modern web makes Logisim.app especially effective for learners and educators — Logisim's largest user base today. Students can just visit the link and get to work, without worrying about device support, installation, configuration, or permissions. It "just works", which is especially impactful on centrally managed devices and in restricted IT environments.

Even better, Logisim.app is fully open source and will always be free to use. It’s also entirely client-side and completely private — none of your data or files ever touches our servers.

What is Logisim?

Logisim has long been a staple in the world of electronics and computer science education. The tool allows you to design digital logic circuits from fundamental components, with a simple interface and intuitive drag-and-drop system that makes it easy to design and simulate anything from a basic latch to a complete CPU.

The real charm of Logisim lies in how it lets you build meaningful components of computation one layer at a time from basic building blocks: adders, multiplexers, arithmetic and logic units (ALUs), and ultimately, a full processor. It’s endlessly fascinating to work upwards through the layers, demystifying what so often feels like a black box.

We wanted to bring this hands-on experience to students, educators and tinkerers everywhere, no matter what device or OS they are using, and without needing to download, install or run anything locally, which is often not possible due to challenges managing local software in a tightly controlled IT environment, or an unsupported device.

How does it work?

We’ll be publishing a technical deep dive soon, but here’s a quick overview of how it all works.

Logisim.app is a complete 1:1 port of the classic Logisim application by Carl Burch. It’s based on version 2.7.2, the final release of the original Logisim. The original Logisim is a Java Swing application based on Java 5, and we run the full compiled JAR file directly in the browser using CheerpJ, a complete browser runtime for Java apps powered by WebAssembly. CheerpJ has full support for Swing applications, allowing us to run the compiled Logisim application without rewriting the user interface, or modifying any of the application’s core logic. This allows us to deliver true feature parity with the original version.

However, there are a few adaptations required to run the application in the browser. These arise from the browser’s secure execution sandbox, which restricts access to the host system for functionality like opening and saving files to your local disk.

To address this, we’ve introduced a JavaScript layer that provides full support for all system functionality required by Logisim through browser APIs. This allows Logisim.app to seamlessly open and save files to both your local file system and the virtual file system provided by CheerpJ.

Who is this for?

Logisim.app is built for students, educators, and hobbyists who want a simple, accessible way to teach, learn or explore digital logic.

Students & Hobbyists: You can now run Logisim anywhere — on a Chromebook, tablet, or even a phone — without needing to download or install anything, or run an executable locally. Just open a link and start building.

Institution-friendly: Because Logisim.app runs entirely in the browser, it works well in environments with locked-down machines or limited IT support. There’s no installation, no permissions, and no Java runtime needed. It’s ideal for classrooms, computer labs, or remote learning setups where managing local software is often a headache.

Educators: We encourage you to evaluate Logisim.app for use in your classes. It simplifies your student’s lives by giving them a frictionless, cross-platform way to run the tool. If you have any feedback, questions or ideas, we’d love to hear from you. You can open an issue on GitHub or reach out to us directly at info@logisim.app.

What about Logisim-evolution?

Active development of classic Logisim was sadly suspended in 2014. Logisim-evolution is a community-driven fork that modernises the original tool and adds several new features. It’s been actively maintained and improved ever since. While Logisim.app is currently a direct port of the classic version, we’re already working on bringing Logisim-evolution to the web as well.

The original Logisim is an older, simpler codebase based on Java 5, which made it an ideal starting point to assess feasibility, explore potential roadblocks and quickly achieve a technical demo.

Porting Logisim-evolution is more complex, in part due to it being based on the newer Java 21. Running a modern JVM in the browser is an ongoing technical frontier; newer versions of Java introduce significant changes to the language and runtime, and WebAssembly tooling in this space is still evolving. CheerpJ is paving the way, with support for Java 21 LTS estimated to arrive in early 2026 .

In the meantime, we plan to back-port the application to an older version of Java currently supported by CheerpJ. Having successfully ported classic Logisim, we anticipate that much of the platform-sensitive Java code (i.e. file I/O, and other system behaviour not available in the browser) will be very similar between both versions. That will allow us to reuse much of the work on the classic version.

Why are we doing this?

First off, because it’s cool. We’re nerds, and we love this stuff.

But also, we’ve spent a lot of time working deep in the WebAssembly space, and it’s clear that it’s still widely misunderstood. Most people don’t yet have a clear picture of what WebAssembly enables. A lot of the projects we work on are closed source, so it’s hard to point to concrete examples. Logisim.app is one way of changing that — a fun, practical, open-source showcase of what’s possible with modern WebAssembly tooling.

Wasm enables us to run the full Logisim application entirely in the browser, with zero backend infrastructure. It came together quickly thanks to mature tooling. All the computation happens client-side, which means we can offer a totally free, fully-featured tool that’s fast, private, and costs basically nothing to host.

That’s a win-win for us.

What's next?

We don’t expect to make further major changes to this version of Logisim — after all, this is a faithful port of the original Logisim application. But we’re looking forward to feedback and will be responsive to any issues that come up. If you run into any bugs or have suggestions, let us know by opening an issue on GitHub or reach out to us directly at info@logisim.app. We’ll do our best to address them
quickly.

We’re especially keen to hear from educators at all levels. If you’re interested in using Logisim.app in your teaching, we’d love to support you. Whether that’s helping with setup, answering questions, or adapting the tool to fit your needs, we’re more than happy to work with you. Let us know at info@logisim.app.

We’re also working on bringing Logisim-evolution to the browser. It’s a more modern and feature-rich version of the tool, and we’re excited to share more about that soon. Stay tuned.

Who are we?

We're DRS Software, a UK based team of engineers who specialise in WebAssembly and advanced web applications. We work with companies to turn their desktop apps into fast, accessible web applications that run anywhere, without the significant cost, risk and complexity that comes with rebuilding them from scratch for the web.

If you're looking to bring a desktop app to the web, we can help!

What does 'porting' to Wasm mean?

Martin Nyaga — Tue, 25 Mar 2025 12:03:23 +0000

Welcome to part 3 of our series, Porting Native Apps to the Web with WebAssembly: A Complete Guide, by DRS Software.

Introduction
Why Applications Need Porting
Porting: Adapting System Interactions
Beyond Syscalls: Porting Libraries and Runtimes
- Language Runtimes
- Frameworks and Libraries
Practical Example: Drawing a Pixel on the Screen
- On Windows
- Porting to Wasm
- Key Differences
Tooling Automated Transformations
Conclusion

Introduction

In previous articles, we explored how native applications can be compiled to WebAssembly (Wasm) and run in the browser. We also discussed the advantages of this approach compared to rewriting applications from scratch.

In nearly all cases, however, the process isn’t as simple as compiling the source code. Most applications require porting to WebAssembly before they can function properly in a browser environment. This article explains what porting means, why it’s necessary, and what it involves.

Why Applications Need Porting

A key concept to understand is that typical applications don’t operate in isolation. While source code defines an application’s logic, it relies on various system services to perform meaningful work. For example, an application may need to:

Allocate memory from the operating system.
Draw graphics to the screen or output text to a terminal.
Read and write files.
Communicate over a network.
Access hardware devices such as a microphone, speaker, or camera.
Use system-level timing, randomness, or process management features.
Load dynamic libraries (.dll, .so) as new executable code at runtime.

All of these tasks are fulfilled by the operating system, which provides essential services through system calls (syscalls). These are low-level functions that allow programs to request resources, interact with hardware, and communicate with other processes.

Typically, programming languages and libraries provide abstractions over these low level APIs that you call from your program. The OS is then responsible for executing the requested actions and returning a result that is safe to handle within the application.

However, when compiling an application to WebAssembly, there is a major missing link: Wasm runs in a strictly sandboxed environment that lacks direct access to system calls or operating system services. Instead, it can only interact with the outside world through functions explicitly imported from the host environment — in the case of the browser, this means calling JavaScript APIs.

Porting: Adapting System Interactions

Since WebAssembly does not support traditional system calls, porting an application means replacing these system interactions with equivalents that work in a browser environment. This is conceptually similar to porting software from one operating system to another — such as adapting a Linux application to run on Windows — but with additional constraints due to different "building blocks" (primitives and APIs) in the browser environment.

So at a high level, porting an application to the browser involves adapting code that interacts with the underlying system to instead use JavaScript-based alternatives. For example:

Using fetch for networking instead of native sockets.
Using the Web Audio API instead of direct sound hardware access.
Using LocalStorage, IndexedDB, or the FileSystem API instead of direct file system access.
Using the DOM and WebGL instead of native graphics APIs.

For certain features, there is a good matching browser API. For example, playing simple audio or drawing basic 2D graphics can be implemented in a conceptually similar way on the browser as in a native application (even though the details of the APIs themselves are different).

However, some features have no conceptual parallel on the browser, and must be emulated or re-implemented. One such example is the fork syscall, which duplicates a process into two identical copies; this is a syscall available on native systems that cannot have a faithful implementation on the browser.¹

Beyond Syscalls: Porting Libraries and Runtimes

While system calls are a major part of the challenge, porting is often further complicated by dependencies on libraries, frameworks, or language runtimes.

Language Runtimes

Many programming languages include a runtime or virtual machine that manages execution of your code, including memory management and system interactions. Examples include:

The Java Runtime Environment (JRE), which provides garbage collection, threading, and platform-independent APIs.
The .NET Common Language Runtime (CLR), which handles memory management, Just-In-Time (JIT) compilation, and interoperability.
The Python interpreter, which provides an execution environment for Python code.

These runtime components assume access to system services that are not available in a Wasm sandbox. Porting an application written in such a language may require adapting or porting the runtime itself, or replacing it with a Wasm-compatible alternative. Fortunately, a lot of tooling and wasm-compatible runtimes² exist, and this burden is rarely borne directly by application developers.

Frameworks and Libraries

Applications often rely on frameworks and libraries that provide essential functionality but are deeply integrated with native platforms. Porting such applications requires addressing these dependencies. For example:

GUI frameworks like MFC, WinForms, GTK or AppKit provide abstraction layers for rendering interfaces but depend on system-specific implementations.
Multimedia libraries for audio/video processing often use platform-native APIs that are not directly portable.
Other third-party libraries (e.g., for cryptography, compression, or networking) may assume access to system-specific features.

In these cases, porting requires one or more of the following approaches:

Rewriting parts of the application to use browser-native alternatives (e.g., using WebGL instead of a native graphics library).
Finding Wasm-compatible replacements for key libraries or frameworks.
Compiling the required libraries to WebAssembly, if they are open-source and can be appropriately adapted.

Practical Example: Drawing a Pixel on the Screen

We'll use rendering a single pixel as an example; the code is simple, but it demonstrates the key differences between how native applications and WebAssembly interact with their respective environments.

Let's consider the simple C++ function below that uses the Win32 SetPixel function to draw to a global window:

void drawPixel(int x, int y, int color) {
    SetPixel(globalWindowHandle, x, y, color);
}

On Windows

When this function is compiled and run natively on Windows:

The SetPixel function is part of the Win32 API, which interacts with the operating system.
The OS communicates with the graphics driver to modify the framebuffer.
The GPU processes the change, and the display updates with the red pixel.

Porting to Wasm

If the same C++ function were compiled to WebAssembly, it would not work as-is, because WebAssembly cannot directly access the Win32 API or the OS graphics subsystem. Instead, it must be ported to the web, i.e., rewritten to call JavaScript, which interacts with the browser's rendering engine.

We can introduce a JavaScript function, in this case drawing to a HTML canvas element:

const canvas = document.getElementById("myCanvas");
const ctx = canvas.getContext("2d");

function SetPixel(x, y, color) {
    ctx.fillStyle = intToRgb(color); // Set the color of the pixel
    ctx.fillRect(x, y, 1, 1); // Draws it at (x, y)
}

Note: the implementation of intToRgb is omitted here for brevity.

This function can then be imported into the Wasm module and used as the low-level API for rendering the pixel.

The modified C++ code might look as follows:

// The code within the block below is only compiled for Wasm
#ifdef __WASM__
namespace [[cheerp::genericjs]] client {
    // Declare that there’s an imported JS function for drawing a pixel
    void SetPixel(int x, int y, int color);
}
#endif

void drawPixel(int x, int y, int color) {
    #ifdef __WASM__
    // In Wasm build: Use the JavaScript function
    client::SetPixel(x, y, color);
    #else
    // In native build: Use the normal Win32 function
    SetPixel(globalWindowHandle, x, y, color);
    #endif
}

Note: the example above uses the semantics of the Cheerp C++ to Wasm compiler, but similar code is possible using Emscripten.

In this WebAssembly-friendly approach:

The generated Wasm module imports a JS function to supply the functionality that was previously supplied by a native system API (Win32)
When Wasm calls the JavaScript function, it updates a HTML Canvas element using the JS API.
The browser’s rendering engine processes the update and sends it to the GPU.

Key Differences

This example illustrates why porting is necessary — code that interacts with the operating system must be adapted to work within the browser’s execution model.

In Windows, the application makes direct system calls via Win32.
In WebAssembly, all interactions go through JavaScript and browser APIs.
The browser enforces sandboxing, preventing direct hardware or OS access.

Tooling Automated Transformations

In practice, compilers and tools can automatically transform many common patterns (e.g. memory allocation, some standard library functions) into browser-compatible equivalents. This means that porting efforts are typically required only for application specific functionality where such transformations do not apply.

For example, in standard C++ to Wasm compilers (e.g. Cheerp, Emscripten), writing to stdout is automatically redirected to print in the browser console, requiring no manual code changes. Similarly, memory allocation, and growing the size of the WebAssembly memory is handled automatically by the compiler. While these transformations happen behind the scenes, they follow the same conceptual process as illustrated above; that is, they automatically replace calls to native APIs with calls to JavaScript APIs.

Conclusion

Porting an application to WebAssembly is often more than just recompilation — it involves adapting system interactions, dependencies, and runtime expectations to function in a browser sandbox. This can mean:

Replacing system calls with JavaScript/browser-native equivalents.
Porting, adapting or replacing runtime components.
Porting dependencies, or finding/developing alternative libraries.

This process can be partially automated by modern tooling and compilers, which greatly simplifies the process of porting.

In future articles, we will explore the differences between the browser and native platforms in more detail, discussing common challenges and practical techniques for overcoming them.

Stay tuned for part 4, or review part 2: When should you use WebAssembly?

See this issue for some discussion about why fork cannot faithfully be implemented in the browser. ↩
Several examples of wasm-compatible language runtimes have been touched on in previous articles. ↩

When Should I Use WebAssembly?

Martin Nyaga — Wed, 12 Mar 2025 10:51:39 +0000

Welcome to part 2 of our series, Porting Native Apps to the Web with WebAssembly: A Complete Guide, by DRS Software.

Introduction
Practical Use Cases for WebAssembly
- Using Native Libraries in the Browser
- Performance-Critical Client-Side Code
- Expanding Language Options for Front-end Web Development
Porting Native or Desktop Software into Web Applications
- The Pitfalls of Software Rewrites
- A Better Approach with Wasm
Real World Success Stories
- Adobe Photoshop
- SketchUp
- AutoCAD
Aside - WebAssembly beyond the Browser
- WebAssembly’s Flexibility and Portability
- Build Once, Run Anywhere
Summary
Related Reading

Introduction

In this series, we’re exploring how WebAssembly (Wasm) can help transform desktop or native apps into fast, capable web applications.

This second post focuses on practical use cases of Wasm and provides guidelines to help determine whether Wasm is the right choice for your project.

Practical Use Cases for WebAssembly

Wasm is a powerful and flexible technology with wide applicability. That being said, it fits especially naturally into some primary use-cases that were envisioned in its original design.

Rather than discuss specific applications or industries, here we focus on the categories of problems that WebAssembly is especially good at solving, with several concrete examples for each.

Let’s explore some of its most well suited use cases for the web.

Using Native Libraries in the Browser

Wasm enables you to reach for well tested and highly optimized native libraries from a wide range of programming languages. No longer limited to JavaScript, you can compile existing open-source and commercial libraries to Wasm and use them directly in the browser.

In addition to massively expanding the available libraries, WebAssembly also delivers superior performance, often outperforming equivalent JavaScript implementations.

Many popular libraries across a variety of languages already offer a Wasm build. For example:

PDF Manipulation: Render and edit PDF documents using a mature library like iText, running in Wasm.
Physics and Game Engines: Implement high performance physics with Wasm-compiled versions of well established engines. For instance, Ammo.js is a Wasm version of the popular bullet physics engine written in C++.
Video and Image Processing: Work with industry standard tools like ffmpeg, directly in the browser for fast multimedia processing.
Data Processing and Machine Learning: Run inference models directly on the browser using onnx.wasm or tensorflow.js.
And much more.

Performance-Critical Client-Side Code

WebAssembly is particularly useful for web applications that require intensive client-side computation. Tasks like real-time graphics rendering, data processing, and machine learning can push JavaScript to its limits, leading to performance bottlenecks. By offloading these critical workloads to Wasm, applications can achieve significantly better speed and efficiency while seamlessly integrating with existing JavaScript code.

Crucially, incorporating Wasm doesn’t require a major architectural overhaul. Thanks to its straightforward interop with JavaScript, developers can enhance performance-critical parts of an application while keeping the rest of the codebase unchanged. This makes it easy to adopt Wasm incrementally, targeting only the areas that benefit most.

Some real-world examples highlight Wasm’s impact:

Figma saw a 3x improvement in load times ¹ for large design files by switching its core file processing logic from a JavaScript (asm.js) based implementation to WebAssembly .
Google Meet leverages Wasm for their client-side machine-learning-based features, such as background blur and background replacement ² . These effects require fast execution of advanced ML models directly in the browser. Wasm provides the level of performance required to achieve real-time results in live video calls.

Expanding Language Options for Front-end Web Development

Wasm provides a first-class way to build browser applications in languages other than JavaScript. There are several reasons why teams might choose this approach, for example:

Familiarity: To write in a language that the team is more familiar with (e.g. C#)
Cross-platform Code Sharing: To develop functionality for multiple platforms that shares code between web and non-web targets
Scalability & Maintainability: To use a strongly typed, and memory-safe language to ensure maintainability as team grows

Several fully featured web frameworks have been developed to address various aspects of these needs, targeting WebAssembly to achieve fast, lightweight applications as a result. For example:

Blazor, allows developers to build client-side web apps using C# .NET. Bolero is a similar project based on F#.
Leptos, Yew and Dioxus are modern frameworks for building front-end web apps in Rust. These all compile to Wasm.
Qt for WebAssembly enables compiling C++ Qt GUI applications to WebAssembly, and running them in the browser.
Flutter a cross platform application development framework, compiles to Wasm for its web target.
And many more.

Altogether, Wasm expands the options available for writing robust, production-ready applications on the web, without the overhead or drawbacks of past compile-to-javascript approaches.

Porting Native or Desktop Software into Web Applications

And finally, Wasm offers a compelling, highly efficient approach for converting desktop or native applications into web applications by porting them to Wasm. This will be the focus of the rest of this series, so we will spend some time motivating it.

The Pitfalls of Software Rewrites

The traditional approach to modernise legacy native/desktop software to the web involves a full rewrite, typically targeting a client/server model for cloud deployment, or as a new web-native application.

This approach is infamously problematic, and many essays have been written about the pitfalls of the big rewrite ³ ⁴ ⁵. In some rare cases, a rewrite might make sense. But for the vast majority of commercially motivated software efforts, the verdict is out - the odds are that this will take longer or cost more than expected, and often result in outright failure.

Unclear Scope and Specifications: Long-lived software often evolves beyond documented specifications, and embeds a history of forgotten decisions in the source code. Replicating its behaviour faithfully, in a different language and platform is extremely challenging for even the most talented engineers.
New Technical Debt: Realistically, you risk introducing significant new technical debt through new bugs and design flaws in the rewrite effort, duplicating years of debugging and architectural refinements from the original application.
Re-skilling and Lost Institutional Knowledge: Rewriting software in a different language/platform also requires re-skilling the existing team, or building a new team that is unlikely to deeply understand all the nuances of a long lived software project.
Missed Opportunities: By definition, a rewrite requires you to spend a significant amount of time developing a new version of software that will not bring value for a while, while tying up significant resources that might be better invested.

For these and other reasons, rewrites have earned their infamy and should be avoided whenever possible. Fortunately, there is a better way.

A Better Approach with Wasm

Instead of undertaking a costly and risky rewrite, Wasm offers a much more pragmatic solution: compile and reuse your existing source code (in part or in full), and run your application directly in the browser. This avoids the pitfalls of rewrites, while offering several significant benefits:

Behaviour Consistency: Retain the same business logic and application behavior as the original, ensuring a 1:1 match without any additional effort.
No New Technical Debt: Porting an existing battle-tested codebase minimizes the risk of introducing new bugs or design flaws, and leverages all the debugging effort that has been invested in the existing code.
Faster Time to Market: Since you’re reusing most or all of your existing code, the development, testing and debugging effort is substantially reduced. This results in a faster, more predictable timeline for launching a modernized product.
Code Sharing: Once ported, your old and new applications can share the same code and functionality, allowing both applications to advance together with minimal duplication of effort.
Leverage Existing Expertise: Instead of needing to re-skill or build a new team, your existing developers and domain experts can continue to contribute to the new web application in the same programming language they have always used, making the transition smoother.
Performance and Security by Default: Wasm’s superior performance and security by design deliver a more efficient and secure user experience right out of the box, compared to a JavaScript rewrite, or a client/server model.
Lower Operational Costs: Since Wasm runs entirely client-side, it requires no costly server infrastructure. Compared to a client/server implementation, the savings in operational costs over time are substantial.

By adopting Wasm, you not only avoid the high costs and risks of a complete rewrite, but also achieve faster results with lower operational overhead. This approach is far more efficient and offers lower risk, making it an ideal solution for modernizing existing applications.

Real World Success Stories

This approach isn’t theoretical – it’s already transforming major applications in the real world. Here are a few standout examples where Wasm enabled companies to modernize and scale their applications, without the need for costly and risky rewrites.

Adobe Photoshop

An excellent example is Photoshop, the behemoth photo editing application developed by Adobe. Writing a new web-native version of PhotoShop is practically impossible, or at least, inconceivably expensive. But thanks to Wasm, Adobe was able to port the application to the web while reusing the vast majority of its existing C/C++ code, and compiling it to WebAssembly ⁶. To date, the web and native versions of PhotoShop are essentially different builds of the same codebase!

SketchUp

SketchUp is a popular 3D design tool known for being easy to learn and use for 3D modelling. Initially developed as a desktop application, it was a strategic goal for the team to build a web version - it would significantly broaden the market of users, and help them achieve their goal of making 3D modelling accessible to all.

Rewriting the complex application in JavaScript was not an option, given its scale. The SketchUp team instead decided to port their application to WebAssembly, an effort that provided an unprecedentedly quick turnaround - the initial port took two engineers only three months ⁷. The SketchUp web app went on to become one of the most popular apps on the GSuite for education marketplace.

AutoCAD

AutoCAD by AutoDesk - a complex and widely used computer-aided design application - followed a similar journey. After unsuccessful attempts to rewrite the existing desktop application using Flash and JavaScript, WebAssembly finally offered a solid foundation for a serious porting effort ⁸.

Early prototypes proved that Wasm could offer the performance required to run the large C++ application on a browser. They ported the full application to Wasm, delivering a consistent and familiar user experience, while sharing code between the desktop and web applications. This approach allowed them to cut their timeline drastically, without compromising on scope – they faithfully brought the full power of AutoCAD to the browser.

Aside - WebAssembly beyond the Browser

No discussion of Wasm would be complete without touching on its applications beyond the browser. While WebAssembly is often associated with the web, its design allows for far broader usage, extending its potential into a variety of environments.

WebAssembly’s Flexibility and Portability

As a bytecode and virtual machine specification, WebAssembly is not conceptually limited to the browser. Wasm modules make no assumptions about their execution environment, save for from the requirements explicitly defined through their imports and exports. This design makes it particularly well suited to use in a wide variety of environments.

Wasm runtimes can be (and have already been ⁹) implemented outside of the browser, giving rise to a new development target for server-side, cloud, and embedded environments. Anywhere you can run a Wasm runtime, you can run Wasm.

There are established initiatives formed around this idea, most notably WASI, which introduced the idea of a POSIX-like system interface for Wasm. This allows Wasm modules to interact with OS level functionality in a standardized way. Code from several languages can be built to target WASI, and then run in any WASI compatible runtime on any system.

Build Once, Run Anywhere

Despite many existing options for server-side, cloud, and embedded development, Wasm’s simplicity, speed, portability, and security make it a real compelling alternative. The vision is that Wasm modules can truly be built once and ran anywhere - code compiled to a Wasm module can execute on any runtime implementation across operating systems (or even without an operating system!). It’s an ideal similar to Java’s/JVM’s goal to “write once, run anywhere”, but for virtually any programming language, and with a modern, lightweight runtime.

This opens up new possibilities for advanced application architectures outside the browser. Some interesting examples include:

Container Workloads: Docker now supports Wasm workloads - Instead of building a docker image, you can build a Wasm module, and docker can execute that in the same way. This keeps all the benefits that containerised cloud infrastructures have brought over the years, while layering added flexibility, security and portability benefits.
Executing untrusted code: Wasm introduces a unique approach for running untrusted code. For example, Shopify’s functions allow third party code to execute server-side on Shopify's infrastructure, modifying the behaviour of the platform, with virtually no security risks, due to Wasm’s strict sandbox.
Serverless Architectures: The lightweight nature of Wasm runtimes is enabling new serverless platforms based on Wasm, focused on speed and responsiveness. Providers like Fastly and Fermyon are reporting impressive cold-start times, and realising the promise of a “scale-to-zero” architecture where compute can be matched exactly with demand.

Wasm’s applicability outside the browser is an exciting area of active development. It’s a testament to its design that it has found utility well beyond its intended browser use cases.

Summary

Wasm is a flexible tool with growing adoption in the browser and beyond. Whether for high-performance web applications, cross-platform development, or porting existing applications, Wasm offers a compelling alternative to traditional approaches, and is a useful technology to have in your toolkit.

Specifically, the concrete examples presented here show that Wasm is not just a theoretical solution, but a proven path for bringing powerful native applications to the web, without the risks and costs of a full rewrite. By reusing and building on top of existing code, companies can deliver performant, browser-based experiences in a fraction of the time.

In the next articles of the series, we’ll dive deeper into the process of porting existing desktop applications to WebAssembly. We’ll cover key strategies, best practices, and real-world techniques to help ensure a smooth transition.

Stay tuned for part 3, or review part 1: Understanding WebAssembly - The Fundamentals.

Understanding WebAssembly: The Fundamentals

Martin Nyaga — Fri, 28 Feb 2025 14:45:48 +0000

Welcome to the first entry in our series, Porting Native Apps to the Web with WebAssembly: A Complete Guide, by DRS Software!

Introduction
The Birth of WebAssembly
- Going Beyond JavaScript
- From Asm.JS to Wasm
- Wasm is Born
What is WebAssembly?
- Wasm Bytecode
- Wasm is a Compilation Target
- Language Support
Running a Wasm Module on the Browser
The Anatomy of a Wasm Module
- Passing data between Wasm and JavaScript
- Memory
Design Benefits
- Speed
- Portability
- Safety
Summary

Introduction

In this series, you'll discover how WebAssembly (Wasm) can help transform desktop or native apps into fast, capable web applications. We'll explore the fundamentals of Wasm, discuss architectural considerations, and provide practical strategies for porting native applications to the web with Wasm.

Whether you're an engineering leader, architect, or developer, this guide will help you develop the right mental models to approach a porting effort and to set you up for success.

To start, let's look at the history and design of WebAssembly, its role in modern web browsers, and why it's a game-changer for web applications.

The Birth of WebAssembly

Going Beyond JavaScript

The web's ubiquity has driven a demand for increasingly advanced applications in the browser. In response, browsers have continuously evolved, adding new capabilities to match the growing complexity of modern web apps.

However, JavaScript — the web's only built-in programming language — has historically posed challenges to this advancement. Among other limitations, it limits the ability for web apps to leverage existing software and libraries developed in languages other than JavaScript.

This led to the "compile-to-JavaScript" movement that started in the 2010s — an ecosystem of tools and techniques aimed at compiling code written in other programming languages to JavaScript, making it runnable in the browser.

From Asm.JS to Wasm

Among the compile-to-JavaScript technologies that emerged, one of the most prominent was Asm.js -- a well defined subset of JavaScript carefully designed to be an efficient compilation target for software written in languages like C/C++.

By using only specific JavaScript features, Asm.js could provide significant performance benefits over hand-written JavaScript. For the first time, C/C++ code could be compiled to Asm.js and run in the browser, and provide better performance than JavaScript code. This unlocked a new world of interesting use cases. The impact of Asm.js, driven by its novel design, was so significant, that it prompted some browsers to develop specific optimizations ¹^,² for Asm.js code.

Asm.js demonstrated the potential of compiling native code for the web, but its reliance on JavaScript ultimately limited its capabilities. Despite its clever optimizations to achieve impressive performance, it became clear that a faster, more flexible, more capable and more long-term solution could be realised by a purpose built technology -- one that could take inspiration from the design of Asm.js, but was not constrained to JavaScript as its runtime ³, and that could be standardised and widely adopted at the browser level ⁴.

Wasm is Born

In 2015, WebAssembly (Wasm) was announced as a cross browser initiative to develop and standardise a purpose-built, assembly-like language for web browsers, with the express goal of being able to run code compiled from other languages in the browser.

Today, Wasm is supported by all major browsers, has become an open standard, and has a rapidly growing ecosystem of tools and technologies built around it. Its standardisation ensures longevity, stability and a commitment to backward compatibility, making it an excellent platform on which to base architectural decisions today.

As of January 2025, WebAssembly is used on over 4.5% of websites with adoption growing exponentially. Major companies -- including Adobe, Figma, AutoCAD, Google, Microsoft, Shopify and more -- are investing heavily in WebAssembly, and using it to power some of their most widely used products.

What is WebAssembly?

Wasm is a low level, assembly-like language optimised for safe and efficient execution in modern web browsers. Its binary instruction format prioritises compact, fast, and portable code that can achieve near native performance⁵.

On the browser, Wasm is designed to run alongside and inter-operate with JavaScript, extending the possibilities for client-side applications.

We will review its design at a high level here, but you can find full design details at webassembly.org.

Wasm Bytecode

Wasm is a bytecode -- a set of instructions in a binary format that runs on a virtual machine (VM). All modern browsers today include a mature Wasm VM by default.

It is conceptually similar to other languages that have a bytecode executed in a virtual machine (e.g. Java or .NET), with the major difference being that Wasm code is not constrained to any single source language; it can be generated from a wide variety of languages.

Wasm code can be disassembled into a text representation (WebAssembly Text Format, or WAT):

;; Module start
(module
  ;; Add function
  (func $add (param i32 i32) (result i32)
    local.get 1
    local.get 0
    i32.add)
  ;; Sub function
  (func $sub (param i32 i32) (result i32)
    local.get 0
    local.get 1
    i32.sub)
  ;; Exports
  (export "add" (func $add))
  (export "sub" (func $sub))
)

An example of a simple Wasm module in its text format (WAT). This module defines and exports an add and a sub function.

Wasm is a Compilation Target

In contrast to JavaScript, Wasm is not intended to be written directly (although it can be). Wasm is a compilation target; this means that source code from other programming languages is compiled to Wasm code using a compiler. The resulting Wasm code can then be executed on a Wasm runtime, for example, the browser.

This is one of the most powerful aspects of Wasm - it provides a language agnostic way to run code written in almost any programming language in a fast, platform-independent way.

Language Support

A large number of languages today have production ready Wasm tooling.

C/C++: Can be compiled to JS/Wasm using Cheerp, Emscripten
Go: Supports the GOARCH=wasm target by default
Rust: Supports a wasm target by default (--target wasm32-unknown-unknown). Tools like wasm-bindgen and wasm-pack provide better ergonomics for Wasm development
C# .NET: Blazor is a full stack or client-only framework that compiles into a combination of Wasm and JavaScript. F# has a similar framework built on top of Blazor called Bolero
Kotlin: Has alpha support for Wasm
Swift: SwiftWasm is a mature community project to support Wasm compilation
Python: Pyodide is a complete python distribution compiled to Wasm
And several more.

Running a Wasm Module on the Browser

Wasm code is packaged and distributed as .wasm files called Wasm modules. The following example demonstrates a simple WebAssembly module that imports a console.log function, and exports a single function (exportedFunc). The module is loaded and instantiated through the JavaScript code below, which proceeds to execute the exported function.

(module
  (func $log (import "console" "log") (param i32))
  (func (export "exportedFunc")
    i32.const 42
    call $log))

A sample Wasm module with a single exported function, that logs 42 to the console when called.

const importObject = {
  console: { log: (arg) => console.log(arg) },
};

WebAssembly.instantiateStreaming(
  fetch("example.wasm"),
  importObject
).then(
  (obj) => obj.instance.exports.exportedFunc(),
);

JS code to instantiate and interact with a Wasm module.

The Anatomy of a Wasm Module

The key high level elements of a Wasm module are summarised below.

High level structure of a Wasm module.

Code: Or, functions. These are implementations of logic in the Wasm module as stateless blocks of Wasm instructions. These functions can accept arguments and can return values when called.
Imports: Wasm modules can import definitions (memory, functions etc.) from the host (browser) environment. This allows Wasm modules to use functionality provided by the host. For example, a Wasm module might import a function from JS to draw an array of pixels to a canvas, log to the console, or send a notification to the user.
Exports: Wasm modules can export definitions (memory, functions, etc.) to the host environment. This allows them to expose useful functionality to JavaScript as callable functions. For example, a Wasm module might export a function to perform a specific statistical calculation, compute the next frame in a game loop, or run an ML inference model.
Memory: Wasm modules have access to a linear, growable, untyped memory. Think of this as a large array of bytes that both JavaScript and Wasm can access.
Other internal sections (types, tables, globals, element segments, data segments, start function, custom sections), whose details are omitted here for brevity.

Memory, Code, Imports, and Exports form the essential components to understand Wasm’s anatomy from an architectural perspective.

Passing data between Wasm and JavaScript

On the browser, Wasm modules need to communicate with JavaScript code to provide receive useful input or provide output.

Generally speaking, Wasm functions can only accept and return simple numeric types (like integers and floats)⁶. To handle complex data (like strings or objects), both JavaScript and Wasm can use the shared linear memory to communicate.

For example, to pass a string from JavaScript to Wasm, you can:

Encode the string as bytes
Write those bytes into a specific location in the shared linear memory.
Call a Wasm function, giving it the location of the string and its length.

Wasm code can then interpret these bytes into a readable string.

This mechanism requires that the host environment and the Wasm module both know how to correctly interpret the bytes in memory. Handling this manually can be complex, and so the necessary “glue” code is typically generated by tooling rather than written by hand.

Memory

Wasm virtual machines are 32 bit, which has implications for porting
applications as we'll see later in the series. This also means that Wasm modules can address up to 4GB (or 2³² bytes) of linear memory. This is sufficient in most cases, but there are active proposals to support 64 bit and larger memory sizes⁷ for more demanding use-cases.

We will discuss further details about JS/Wasm interop and the Wasm memory model in a future post in the series.

Design Benefits

Wasm's design offers a few key benefits, as explicitly discussed in its design goals.

Speed

Wasm can execute at near native speed, enabling otherwise unachievable
performance on client-side web applications. Its performance often surpasses JavaScript as a result of its design:

Wasm uses a compact binary format, which can be downloaded, decoded, and executed more efficiently than JavaScript’s text format.
As a compilation target, it is often optimized ahead of time (AOT), while JavaScript primarily relies on just-in-time (JIT) compilation for optimisation.
Supports SIMD (single instruction, multiple data) instructions, enabling vector computations.

Wasm is not only fast, but also predictable:

The linear memory model in Wasm, combined with explicit memory management (in source languages like C/C++/Rust) allows strict control over memory layout and allocation.
JavaScript, on the other hand, relies on the browser’s garbage collection, which can lead to unpredictable pauses in code execution, with no control over when these occur.

Altogether, Wasm's design makes it easier to write well performing code by default. For example, Figma saw a 3x improvement in load times of heavy files by switching to WebAssembly.

Portability

A Wasm module makes no assumptions about the platform on which it executes (including the browser). By design, its dependencies are made explicit in the form of imports. This makes Wasm modules executable on any spec-compliant Wasm runtime, provided the required imports can be supplied at runtime.

This design feature of Wasm has led to the development of many use-cases for Wasm outside the browser, despite browser based use-cases being its initial motivation. Wasm can now power not just browser applications, but also server-side runtimes, IoT devices and more.

Safety

Wasm code is executed in a memory-safe sandbox, isolating the running program from all other programs on the host system. By design, Wasm programs cannot interfere with the execution of, or memory from any other running code on the system, and can only access its well defined linear memory.

Wasm code can only escape the sandbox through imports explicitly supplied by the host, providing a clear access control mechanism for Wasm code. For browser use cases, this means that access to the DOM, any web APIs and the underlying system is only through explicitly provided JavaScript functions. In this way, Wasm code is subject to a permissions model that is as strict (or stricter) than JavaScript.

Summary

Wasm has matured into a foundational platform, on top of which a new generation of tooling, frameworks and application architectures is actively being developed, with a multitude of production ready apps being shipped today. It is transforming web development with its speed, portability, and safety.

In this introduction, we’ve explored Wasm’s history, core features, and
benefits.In future articles, we will dive deeper into practical applications of Wasm, and specifically, practical ways to use Wasm to bring native applications to the web, with patterns and tips to help you succeed.

📌 Follow DRS Software for future updates to the series!

MS Edge developed a specialized pipeline for asm.js code. ↩
Optimizations were introduced in V8 specifically with asm.js in mind. ↩
A good explanation about why WebAssembly is faster than asm.js can be found here. ↩
Why create a new standard when there is already asm.js? Some commentary can be found here on the official WebAssembly website. ↩
WebAssembly's high level goals are listed here. ↩
Recent proposals extend Wasm's primitive types new opaque “reference types” to allow passing more complex objects across the Wasm <-> host boundary, but the details of this are omitted for brevity. ↩
Memory64 is an active proposal to support 64 bit pointers and larger memory in Wasm. While implemented in some browsers, this is not stable at the time of writing. ↩

DEV Community: DRS Software

Announcing Logisim.app: Run the classic logic simulator in your browser

Table of Contents

Introduction

What is Logisim?

How does it work?

Who is this for?

What about Logisim-evolution?

Why are we doing this?

What's next?

Who are we?

What does 'porting' to Wasm mean?

Table of Contents

Introduction

Why Applications Need Porting

Porting: Adapting System Interactions

Beyond Syscalls: Porting Libraries and Runtimes

Language Runtimes

Frameworks and Libraries

Practical Example: Drawing a Pixel on the Screen

On Windows

Porting to Wasm

Key Differences

Tooling Automated Transformations

Conclusion

When Should I Use WebAssembly?

Table of Contents

Introduction

Practical Use Cases for WebAssembly

Using Native Libraries in the Browser

Performance-Critical Client-Side Code

Expanding Language Options for Front-end Web Development

Porting Native or Desktop Software into Web Applications

The Pitfalls of Software Rewrites

A Better Approach with Wasm

Real World Success Stories

Adobe Photoshop

SketchUp

AutoCAD

Aside - WebAssembly beyond the Browser

WebAssembly’s Flexibility and Portability

Build Once, Run Anywhere

Summary

Related Reading

Understanding WebAssembly: The Fundamentals

Table of Contents

Introduction

The Birth of WebAssembly

Going Beyond JavaScript

From Asm.JS to Wasm

Wasm is Born

What is WebAssembly?

Wasm Bytecode

Wasm is a Compilation Target

Language Support

Running a Wasm Module on the Browser

The Anatomy of a Wasm Module

Passing data between Wasm and JavaScript

Memory

Design Benefits

Speed

Portability

Safety

Summary