Running Java in Node.js with WebAssembly

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Many organisations have a lot of Java code. As they adopt newer technologies such as Node.js or Cloudflare Workers, maintaining interoperability with this existing code is important. WebAssembly is an instruction set for a stack-based virtual machine. This is the same type of abstract machine the Java Virtual Machine (JVM) uses making it possible to convert existing Java code to WebAssembly. This would allow Java code to be "imported" directly without rewrites, meaning it could be executed anywhere WebAssembly was supported. In this talk, I'll describe a research project that does just that. I’ll speak about the history of WebAssembly, what Java bytecode looks like, how to interpret it, decompilation techniques and implementing polymorphic objects.

This talk has been presented at Node Congress 2025, check out the latest edition of this JavaScript Conference.

FAQ

The main topic is running Java in Node.js with WebAssembly.

Running Java in Node.js is significant for maintaining interoperability with existing Java code as organizations adopt newer technologies such as Node.js or CloudFloat workers.

WebAssembly is important because it allows Java or any other JVM targeting languages to run in Node.js or the browser by compiling JVM bytecode to WebAssembly, which is highly optimizable and supported in various environments.

WebAssembly addresses the limitations of Asm.js by providing a new binary format, supporting streaming compilation, and modern CPU features like SIMD and 64-bit integers.

WebAssembly improves performance by allowing direct compilation to optimized machine code, thanks to its typed nature, without needing to observe execution first.

WebAssembly allows other languages to run in JavaScript engines by acting as a compilation target, thanks to its stack machine-based nature and optimizable binary format.

Java class files are parsed to extract method descriptors and bytecode, which are then transformed into WebAssembly types and instructions for compilation.

Virtual method tables are used to manage method calls in object-oriented programming by storing method offsets for each class, allowing for dynamic method dispatch and inheritance handling.

The two types of loops discussed are pre-tested loops (while loops) and post-tested loops (do-while loops).

The source code for the project is available on Brendan's GitHub.

Brendan Coll
Brendan Coll
19 min
17 Apr, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hello, everyone. Welcome to my talk on running Java in Node.js with WebAssembly. Many organisations have a lot of Java code, and as they adopt newer technologies such as Node.js or CloudFloat workers, maintaining interoperability with this existing code becomes important. WebAssembly is a stack machine-based thing, like the JVM, but with a different instruction set. It improves over Asm.js with a new binary format and supports streaming compilation, SIMD, and 64-bit integers. Compiling Java code to WebAssembly involves converting JVM instructions, handling local slots, recovering if statements, and understanding control flow. Short circuit conditionals and loops are important to consider in the conversion process. Additionally, memory allocation, object creation, and program memory are key concepts. Overall, this talk explores the challenges and techniques involved in running Java in Node.js with WebAssembly.

1. Introduction to Java in Node.js with WebAssembly

Short description:

Hello, everyone. Welcome to my talk on running Java in Node.js with WebAssembly. Many organisations have a lot of Java code, and as they adopt newer technologies such as Node.js or CloudFloat workers, maintaining interoperability with this existing code becomes important. Let's start from the basics. This is a simple Java program that prints to the console. The JVM is a stack machine. The JVM provided a very portable runtime. So, there was this thing called Asm.js, which was designed as a compilation target for other languages. This is where WebAssembly comes in.

Hello, everyone. Welcome to my talk on running Java in Node.js with WebAssembly. I'm Brendan. I'm currently a research engineer at Expo, but before that, I worked on developer tools for CloudFloat workers.

So, before we begin, why would you want to do this? Many organisations have a lot of Java code, and as they adopt newer technologies such as Node.js or CloudFloat workers, maintaining interoperability with this existing code becomes important. Additionally, lots of interactive web experiences used to be powered by Java, but modern browsers block Java applets, so lots of sites no longer work. It would be nice if we didn't have to rewrite everything.

Let's start from the basics. This is a simple Java program that prints to the console. You compile it with the Java compiler that produces a class file and you can run it with the Java command. Java here is a runtime, which is slightly different from C and Go programs, where you're compiling for a specific architecture. As I mentioned, this runtime is the Java virtual machine, which takes these class files, which are portable and platform-independent, containing JVM instructions as opposed to architecture-specific instructions, and then runs them. The important thing here is that it doesn't have to be just Java. You can compile other languages like Scala and Kotlin to the same JVM bytecode as well.

The JVM is a stack machine, so let's have a quick look at what that looks like for this simple add program. So, the parameters to the function are stored as locals, and we start the first instruction, which pushes a local onto the stack, we move on to the next instruction, and then this add instruction pops two values off the stack, adds them together, and then pushes the result back onto the stack.

As I mentioned, the JVM provided a very portable runtime. You used to be able to run applets in browser via a plugin. Browsers started to disable applets, they introduced this thing called Java Web Start instead, but we've still got lots of, like, not very nice security warnings here. You still have to install the Java runtime, and it wasn't built into browsers. Nowadays, of course, we do all of this interactive stuff with JavaScript instead, and JavaScript engines are becoming very powerful. So, modern JavaScript engines will use just-in-time compilation. This is a simplified pipeline of Chrome's V8 engine. So, what happens is you first interpret the JavaScript and then you observe what types functions are called with on a frequent basis, and then you generate optimized code as a result of that. With all of these, sort of, efficient JavaScript engines, it becomes possible to potentially run other languages in the browser as well using the same engine.

So, there was this thing called Asm.js, which was designed as a compilation target for other languages. It was an extremely optimizable subset of JavaScript, and browsers that didn't support this Asm.js thing could still treat it as regular JavaScript and run it without, like, additional runtime. And what people found is when, like, you compiled C programs to this optimizable subset, you could usually, sort of, get near native performance with still, sort of, integrating with JavaScript. But there was more that could be done here. So, this is where WebAssembly comes in.

2. WebAssembly: Introduction and Compatibility

Short description:

WebAssembly is a stack machine-based thing, like the JVM, but with a different instruction set. It improves over Asm.js with a new binary format and supports streaming compilation, SIMD, and 64-bit integers. WebAssembly has two interchangeable formats: binary and human-readable text. It can run everywhere, including browsers, Node.js, and other JavaScript runtimes.

WebAssembly is a stack machine-based thing, like the JVM, but with a different instruction set. So, it's typed, so it's highly optimizable, but it improves over Asm.js with this new binary format, and it also supports streaming compilation as well, and modern CPU features like SIMD and 64-bit integers.

WebAssembly has two interchangeable formats. You've got the binary format on the left and this human-readable text format on the right. And in all future examples, we're just gonna use the text format because it's much easier to read.

So, if we go back to the pipeline, because we now know these types ahead of time, we can go straight to the optimized machine code. So, we don't have to, like, watch the executions and see what's going on first. WebAssembly runs everywhere these days. So, browsers, of course, Node.js, other JavaScript runtimes on the server, like CloudFlow Workers and all that, and embedded runtimes as well, so you can sort of run it within your Rust or Go programs or whatever. Yeah. So, that's what this project is going to be about. We're going to be compiling JVM bytecode to WebAssembly so that Java or any other JVM targeting languages can run Node.js or the browser or anywhere else that supports WebAssembly.

3. Compiling and Calling Functions with Class Files

Short description:

Class files contain constant pool, metadata, fields, and code. Method descriptors describe input/output types. Convert JVM instructions to WebAssembly. Wrap with WebAssembly module, export, and convert to binary format for Node.js. Method overloads in Java can be implemented in WebAssembly by using separate function names. WebAssembly expects single typed values for locals, causing complications when reusing local slots.

So, now that we've had a quick look at the history, let's look at what these class files actually look like. So, if we go back to the simple compilation example, what does this hello.class file contain? A binary mess. We can see the names of some other class names, but, yeah, that's not very useful. So, class files themselves are packaged into jar files, and each class file looks something a bit like this, where you've got this constant pool, you've got some metadata, you've got some fields, and you've got the actual code itself.

The methods each have a sort of method descriptor which describes the types of the inputs and the outputs. So, we've got this sort of the types of parameters in the brackets and then the return type afterwards. And the primitive Java types map to these little letters, so, like, byte is B, char is C, long is J, of course, and so on.

So, now that we can parse these class files, let's talk about compiling and calling functions with them. So, we've got the method descriptors, we've got the byte code. So, we can start transforming it to WebAssembly. To do this, we can just pattern match on the descriptors that we've parsed earlier and convert them to WebAssembly types, and similarly for instructions, we can just take the JVM instructions and convert them to WebAssembly. This is going to be really easy. And that's kind of all we need for basic compilation. When you've got this, to run it, you can just wrap it with a WebAssembly module, and then you can export it, and then we've got this text format which we can't actually run, so we convert it to the binary format, and we get this Node.js code, which is super nice, because we just have to read the file, we can compile that into a WebAssembly module, instantiate it, and call its exports.

So, we can also call the function from within WebAssembly, which is nice, but hang on a minute, we've got a first problem. Java lets you do method overloads, where you can have the same method, the same name, but just, like, different parameters instead. And we can kind of implement this in WebAssembly. We can just stick the method descriptors on the function names and treat them as separate functions. That works, that's fine. But there's a little subtlety here. In, even though we're adding two of the same things, in the integer example, the second integer is loading from index one, and in the double example, the second double is loading from index two. This is kind of a quirk of how Java's storing these locals. So, Java treats locals as four byte word slots, and ints are one word each, doubles are two words, and the problem is that WebAssembly expects single typed values for locals. So, when you create a local in WebAssembly, you have to define its type ahead of time, and it can only ever be that type. This gets even more complicated, because if we take this, like, example here, the local slots get reused if the variables go out of scope. So, a single word is referenced as an int, and the first half of a double in the same function. This is definitely not allowed in WebAssembly.

4. Handling Local Slots and Recovering if Statements

Short description:

WebAssembly locals can be remapped to handle reuse of local slots. Understanding conditional logic and executing if statements. Converting JVM byte code to structured control flow in WebAssembly. Analyzing control flow graphs and recovering if statements.

This gets even more complicated, because if we take this, like, example here, the local slots get reused if the variables go out of scope. So, a single word is referenced as an int, and the first half of a double in the same function. This is definitely not allowed in WebAssembly.

So, the solution here is that we can remap WebAssembly locals. What we can do is for each unique JVM index and type pair, we can create that pair as its own local instead.

Compiling functions is great, but almost all programs will have some conditional logic to you. This is an example program with an if statement. What we're doing here is returning true if the value is greater than two. Probably wouldn't write something like this, but we can see the corresponding Java byte code on the right-hand side.

So, let's walk through an example execution of this function where the value is three. So, we've got the parameter in local zero, and we've got the result value in local one. So, we've reached this point in the execution where we've hit this if integer compare less than or equal to instruction, and we have to evaluate whether three is less than or equal to two. So, that's not the case, so we're not going to take this jump. Instead, we just continue on to the next instruction, and we store true in the result. If we go back, and instead the value that we pass to the function is one, then we do want to take this branch, so we move forward five instructions and we jump past the if statement.

The problem is that WebAssembly has no gotis, so we can't implement this kind of jumping base branching. Instead, WebAssembly needs structured control flow. So, this basically means just like regular if statements that you'd see in JavaScript. So, in order to take this JVM byte code and convert it to this, we need to recover the if statement somehow.

Let's look at a more interesting example. So, this has some nested if statements and some pretty interesting control flow. So, for analysis, a control flow graph is very useful. A control flow graph is basically each node is an instruction, and you have an edge if one instruction leads to another. We can group instructions with no intermediate control flow into basic blocks. This doesn't affect the results of the analysis, it just makes it more efficient and it's also much easier to see what is going on as well.

So, when we're recovering if statements, what we're interested in is finding the headers of those if statements, where they start, and then the follow nodes where the branches join back together. We want to allow nested statements as well. Let's go through some definitions. Node A dominates B if control must pass through A before reaching B. Node A strictly dominates B if A dominates B and A is not equal to B.

5. Understanding Dominators and Handling Control Flow

Short description:

Understanding the immediate dominator and recovering follow nodes using an algorithm. Reconstructing if statements using the obtained information. Handling short circuit conditionals in Java and their impact on control flow graphs.

And then node A is the immediate dominator of B if A strictly dominates B, but doesn't dominate any other strict dominator of B. So, that's a bit of a word soup. But basically, immediate dominator is the closest strict dominator. So, in this example, the immediate dominator of node 5 would be 0. To actually recover the follow nodes, we have this algorithm here, which traverses the graph in reverse, depth first post order.

So, nested structures are handled first. We have this set of unresolved nodes, which is the two-way header nodes for which we haven't yet found a follow node, and we say that the follow node is the maximum node with two plus in edges that has a header as the immediate dominator. If we found it, we mark all unresolved nodes with that follow to, and if not, we add it to the unresolved set. And using this algorithm, we end up with enough information to reconstruct the original if statements. The resulting web assembly would look something like this.

As before, the branching instructions, if you hit an if statement, you take the branch if the top of the stack is non-zero. So, that works great for most conditionals, but Java also has these short circuit conditionals as well. You'll see this in JavaScript as well. And B isn't evaluated if A is false. This produces a control flow graph that looks something like this, and what we have here is something called unstructured or irreducible control flow.

6. Understanding Short Circuit Conditionals and Loops

Short description:

Looking for patterns in short circuit conditionals. Treating if statements as expressions. Understanding loops in control flow graphs. Recovering loops using derived sequences of tuples. Implementing loops with block and loop types in Wasm.

If we wanted to apply similar logic to what we just did before, we may need to duplicate block two. Instead, we can look for patterns in these, what these short circuit conditionals produce, and then we can repeatedly apply rewrites to the graph until we have no more changes. And WASM lets us treat if statements as expressions as well. So, you can sort of return values from branches, and then after evaluation, the sort of the stuff I've got on bold here will collapse to a single stack value, and then we can use that for branching on instead. And that will let us produce these short circuit conditionals.

Okay, so in addition to conditionals, most programmers will have loops as well. So, the defining characteristic of a loop in a control flow graph is a back edge. So, this is an edge to the same or an earlier point in the graph. Each back edge corresponds to a loop. We have two different types of loops. We have pre-tested loops, these are like your traditional while loops, and we have post-tested loops, which are like do-while loops.

To recover loops from our control flow graphs, we need this sort of derived sequences of tuples, of graphs and their intervals. So, we say that the nodes of graph I are the intervals of the previous graph, and we add edges to graph I if there exists an edge between intervals of the previous graph. And we keep repeating this until we've got no changes, and this produces the sequence of tuples. So, this is an example sequence that we've got here. 0 is our original graph, 1 is after one iteration, and then 2 is after the second iteration. And we've reached a trivial graph at the end. If we hadn't reached a trivial graph with just a single block, we would say that we have irreducible flow. And again, we've got this algorithm where we can, for each of these tuples in the derived sequence, we can look at each interval, look for the back edge in the same interval, and then we've got, we can work out which is the header and the latching node, and then based on some patterns, we can work out what the type of the loop is, and then we can work out the follow node, based on whether it's a pre or post-tested loop. To actually implement these types of loops, Wasm gives us two other block types. So, block behaves like break statements, loop kind of behaves like continue statements when you branch to them, and then using these two different things, we can implement pre and post-tested loops. Finally, we're missing something important.

7. Understanding Graph Iterations and Program Memory

Short description:

Example sequence of derived graphs. Determining loop characteristics and types. Implementing loops with block and loop types in Wasm. Introduction to program memory in Java and WebAssembly.

So, this is an example sequence that we've got here. 0 is our original graph, 1 is after one iteration, and then 2 is after the second iteration. And we've reached a trivial graph at the end. If we hadn't reached a trivial graph with just a single block, we would say that we have irreducible flow.

And again, we've got this algorithm where we can, for each of these tuples in the derived sequence, we can look at each interval, look for the back edge in the same interval, and then we've got, we can work out which is the header and the latching node, and then based on some patterns, we can work out what the type of the loop is, and then we can work out the follow node, based on whether it's a pre or post-tested loop.

To actually implement these types of loops, Wasm gives us two other block types. So, block behaves like break statements, loop kind of behaves like continue statements when you branch to them, and then using these two different things, we can implement pre and post-tested loops. Finally, we're missing something important. Java is an object-oriented language, so we need objects too. Before we can talk about objects, we need to talk about program memory. So, program memory is usually split up into two sections, the stack made of local variables living for the lifetime of a function call, and the heap, which is an unorganized pile of objects living for the lifetime of the program. The stack contains references to objects on the heap, and so WebAssembly, if we want a heap, we can use the linear memories, and this here creates a memory which is 64 KB in size.

8. Memory Allocation and Object Creation

Short description:

Understanding memory allocation and object creation. Implementing a bump allocator strategy. Adding instance methods and understanding the implicit this parameter.

Let's look at a simple class with two fields. We've got integer field and we've got a double field. The integer fields will occupy four bytes and the doubles will occupy eight bytes. The fields are stored continuously in our memory.

When we create a new instance of the object, we allocate space for it, and there are lots of different allocation strategies, but to start with, we can implement a bump allocator. So, this has a global next pointer, and when you allocate a specific size, we add that size to the global next pointer and return the original pointer. There's no garbage collection here, we just keep on allocating, keep on allocating.

We can use this with our adder class, so we know the size of the adder is going to be 12 bytes, so we just create a constant on the stack and then call our allocation. What if we want to add instance methods, though? So, we have this add method here which adds the two fields together, and it produces the following byte code, but what is this, like, a load zero thing? So, this is loading the implicit this parameter, which you might have seen in, like, other languages like Python itself. In Java, you don't actually have to write it, but it's always there.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
ESM Loaders: Enhancing Module Loading in Node.js
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Top Content
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
Towards a Standard Library for JavaScript Runtimes
Node Congress 2022Node Congress 2022
34 min
Towards a Standard Library for JavaScript Runtimes
Top Content
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
Out of the Box Node.js Diagnostics
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
The State of Node.js 2025
JSNation 2025JSNation 2025
30 min
The State of Node.js 2025
The speaker covers a wide range of topics related to Node.js, including its resilience, popularity, and significance in the tech ecosystem. They discuss Node.js version support, organization activity, development updates, enhancements, and security updates. Node.js relies heavily on volunteers for governance and contribution. The speaker introduces an application server for Node.js enabling PHP integration. Insights are shared on Node.js downloads, infrastructure challenges, software maintenance, and the importance of update schedules for security.
Node.js Compatibility in Deno
Node Congress 2022Node Congress 2022
34 min
Node.js Compatibility in Deno
Deno aims to provide Node.js compatibility to make migration smoother and easier. While Deno can run apps and libraries offered for Node.js, not all are supported yet. There are trade-offs to consider, such as incompatible APIs and a less ideal developer experience. Deno is working on improving compatibility and the transition process. Efforts include porting Node.js modules, exploring a superset approach, and transparent package installation from npm.

Workshops on related topic

Node.js Masterclass
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Top Content
Workshop
Matteo Collina
Matteo Collina
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Building a Hyper Fast Web Server with Deno
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
Workshop
Matt Landers
Will Johnston
2 authors
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
0 to Auth in an Hour Using NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
GraphQL - From Zero to Hero in 3 hours
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
Pawel Sawicki
Pawel Sawicki
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.
Mastering Node.js Test Runner
TestJS Summit 2023TestJS Summit 2023
78 min
Mastering Node.js Test Runner
Workshop
Marco Ippolito
Marco Ippolito
Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky. You will learn how to use Node.js test runner to its full potential. We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.