English versionEN

Building a JavaScript Engine in Rust: Lessons From Boa

Jason Williams

Bloomberg LP

This ad is not shown to multipass and full ticket holders

React Advanced 2026

October 23 - 26, 2026

London, UK & Online

We will be diving deep

Learn More

Bookmark

Sentry

Promoted

Code breaks, fix it faster

Crashes, slowdowns, regressions in prod. Seer by Sentry unifies traces, replays, errors, profiles to find root causes fast.

Get started

JavaScript engines power the web, but what does it actually take to build one, and even contribute to the ones used by billions?

In this talk, I'll share the journey of creating Boa, a JavaScript engine written in Rust, and what it taught me about how JavaScript really works under the hood. We'll explore how code is parsed and executed, and the surprising complexity hidden inside the ECMAScript specification.

But building an engine wasn't just a technical challenge, it was also about building a community. I'll share lessons from leading an open-source project, growing contributors, and navigating the realities of maintaining a language runtime.

Finally, we'll look at how this work extended beyond Boa, culminating in contributions to V8, the engine that powers Chrome, through the implementation of Temporal in Rust. This is the story of how an open-source project can evolve from experimentation to influencing the broader JavaScript ecosystem.

This talk has been presented at JSNation 2026, check out the latest edition of this JavaScript Conference.

js runtimes

Jason Williams

24 min

15 Jun, 2026

Comments

Video Summary and Transcription

Jason Williams, a senior software engineer at Bloomberg and TC39 delegate, discusses contributing to Servo project in Rust. The process of developing Boa JavaScript Engine involved highlighting its speed, memory safety, and performance compared to Gecko. Principles of building a JavaScript engine in Rust are compared to processing plants with stages like tokenization and parsing. Tokenization involves breaking down JavaScript code into tokens following the ECMAScript specification. Boa's community contributions focused on enhancing CPU caching, inline caching, and testing for conformance. The engine successfully implemented Temporal, achieving a high test pass rate and integration into major engines.

Available in Español: Construyendo un Motor de JavaScript en Rust: Lecciones de Boa

1. Introduction to JavaScript Engine in Rust

Short description:

The speaker introduces themselves as Jason Williams, a senior software engineer at Bloomberg and a TC39 delegate. They share their experience with contributing to the Servo project using Rust to replace the Gecko engine in Firefox.

Thank you for having me here. I'm thrilled to be presenting this and being part of the event. I would love to be there in person, but digital is good too. We'll be talking about building a JavaScript engine in Rust, lessons from Boa. We'll see how we get on.

But before we do, my name is Jason Williams. I'm a senior software engineer at Bloomberg. I'm also a TC39 delegate, so that is the JavaScript Standards Committee. If you have any questions from this talk, you can post them, I believe, underneath this video. Or you can also reach out. I'm most active on Blue Sky, so you can catch me there. My domain name, JasonWilliams.co.uk. I'm also in other places, but I'm probably most active on Blue Sky, I would say.

So, yeah, about me. I've been an open source contributor for many years. Ten years ago, I was really interested in learning more about browsers, rendering, paint, layout, that sort of thing. So, I contributed to a project called Servo, which is a parallel browser engine project that was maintained by Mozilla at the time. And it was essentially designed using a new programming language back then called Rust to replace Gecko, which was the engine in Firefox.

The language was very new. So, actually, even when you were writing in that language, it could be changing underneath you. So, some of the syntax that you wrote two weeks ago was no longer valid. And I remember we often had, like, formatters and tools that would just go around and update all the syntax every now and then. I don't think I made a significant contribution to the engine during the time. But one thing that I did, I may have been the first person or one of the first to get it working on Windows. It didn't work on Windows at all back then. So, that was I was a Windows user. So, that was my main objective at the time. I was grabbing information from people that was just in people's heads. Nothing was written down. And I essentially collated all of that together, made a guide for myself.

2. Development of Boa JavaScript Engine

Short description:

The speaker shares their experience of getting Servo to work on Windows and promoting it through a blog on Mozilla Hacks. They highlight Servo's speed, performance, concurrent CSS engine, memory safety, and speed compared to Gecko. The decision to explore building a JavaScript engine led to the creation of Boa, inspired by Mozilla's animal-themed project names and personal encounters.

It was actually for my own personal use to begin with. And I followed that guide and managed to get Servo booting up on Windows and really wanted to share this with the rest of the world. So, I was quite lucky enough to be able to do a blog on the Mozilla Hacks almost ten years ago. 2017. And I was very proud of this because it was not just showing off to the world that Servo is alive and working on Windows, but also allowing people to get more involved in front of you who couldn't before because of the operating system they were on.

Another thing that stood out to me on Servo was the speed. It was quite performance. This is running on Reddit back in 2014. I'm sure it's even faster now. But the CSS engine that was written in Rust from scratch was able to make use of multiple cores. It was very concurrent. I think it was actually one of the first concurrent CSS engines at the time. And it had also good memory safety. So, we were all very confident in it. We knew it would work well. There weren't really any crashes. But it was also very fast. It was more than twice as fast as what Gecko had at the time.

So, basically, I thought, well, can we do this with JavaScript? Why not do it in a JavaScript engine? And the Servo team at the time were quite stretched. So, building a JavaScript engine was not something they were too interested in at the time. They were quite happy to continue using Spider Monkey, which is the engine in Firefox. So, I essentially went off and toyed around with some ideas. And eventually just started working on my own. And that's where Boa came in. The naming, I guess I was trying to follow Mozilla's theme of naming projects after animals. I saw a snake in a zoo in Sydney and I thought I really want to name my next project after that. So, yeah, what I'll show you is how I got started, really. Some JavaScript engine principles. It's not exactly how Boa works today. But it's a bit of an insight, really, into where things got started.

3. JavaScript Engine Development Principles

Short description:

The speaker discusses building a JavaScript engine in Rust at a JavaScript conference, highlighting the similar principles across different languages. JavaScript engines are compared to pipelines or processing plants with distinct stages like tokenization and parsing. The concept of a tree walker in the engine's development process is explained.

There is some rust code in this as well. The irony is not lost on me that this is a JavaScript conference. But the principles are the same. Whichever language that you try to build a JavaScript engine in. I'll try to keep it as high level as I can.

So, yeah, one thing I learned quickly is that JavaScript engines are pipelines or factory assembly lines or like a processing plant. The work is split into stages. Each stage, you know, you have some input. You transform it. Pass it along until, you know, eventually you end up with the final result. Which is usually executing your code.

I mean, execution doesn't even need to be the final outcome. The final outcome could be another language. So, a transpiler that takes a higher level language and spits out a lower level language or assembly or something. What I have is what we call a tree walker. And the name will become apparent in a minute. And so, these are the stages that I started putting together. You have the tokenization stage. This is where the engine takes the raw JavaScript source code and breaks it down into smaller pieces. We're going to call tokens.

4. JavaScript Engine Parsing and Tokenization

Short description:

The text explores the parsing stage in JavaScript engine development, including token structuring into AST, file reading using Rust, and the subsequent tokenization process.

We have the parsing stage, which takes the tokens and structures them to reflect the grammar of the language, resulting in the abstract syntax tree (AST). The AST represents code in a way the engine can work with, leading to execution and final results. While simplified, advanced engines like V8 have additional steps. Before parsing, reading a file is essential, as demonstrated with simple Rust code for file reading.

Learning Rust's standard library while building a JS engine is highlighted. The initial commit involved reading a JS file into a string variable, emphasizing starting from basic tasks. Tokenization follows file reading, breaking down the raw JavaScript source into smaller components. The process is likened to chopping up sausage into smaller versions, with a detailed look at character-by-character processing.

5. JavaScript Engine File Reading and Tokenization

Short description:

Engines like V8 or Boa have more steps, but starting with file reading in Rust is essential. Learning two languages simultaneously enhances understanding. Tokenization involves breaking down JavaScript source code into tokens. Understanding token types is facilitated by the ECMAScript specification.

You know, engines like V8 or even Boa today have a lot more steps in between these. But when you're starting out, this is pretty much how I viewed it. But before any of that, we actually need to read a file. So, this is just some simple Rust code. I mainly show this for two reasons. One is because it's a reminder that I also was learning the Rust standard library as well as learning to build a JS engine. If you ever want to learn two languages at the same time, you can build one language with the other and you get a good understanding of both. The second reason I show this, and by the way, this is, yeah, if it's not apparent, this is a standard library to read a file into a string. So, the buffer on the left is the string variable. And with Rust, you have to handle your errors. So, the expect here is essentially printed out if something fails during the reading. And, yeah, the second reason I show this is just to show that actually this was the first commit. So, I'm not if you don't believe me, you can see here, commit one, August 8th, 2018 is me taking the JS file and just printing it out. So, start simple. You know, you can't really get more simple than that. I put that into a file, made a repo, and then started from there.

So, we have our string, it's stored in a variable, and we need to tokenize it. And this is where the engine takes, yeah, the raw JavaScript source code and breaks it down. It's a bit like the sausage coming out of the factory and you're chopping it up into smaller versions of itself, if that's an analogy to use. But we, yeah, have our let foo equals hello world. And we have our scanner or cursor which moves along letter by letter until we hit a space, and then that is our first token. So, you can see here we're sort of looking at this on a sort of character by character basis. Hitting a space and then creating tokens from it. So, here we've got a keyword. We have our identifier. We have a punctuation or a punctuator. And then we have a string literal. And you might be wondering, well, how do we know these are token types? How do we know what token types to make? How do we know which one is which? Well, luckily for us, we have the ECMAScript specification. I mentioned earlier I'm a TC39 delegate, so I'm very lucky to have helped also contribute to the spec. But this document is open for anybody.

6. JavaScript Engine Tokenization and Parsing

Short description:

Access ECMAScript spec for token information. Token struct resembles JavaScript object. Parser creates abstract syntax tree from tokens.

It's not behind, you know, closed doors or payments or anything like that. Anybody can visit the ECMAScript spec. Most engine authors do. You can get a lot of information you need from here. For instance, token names or token types. So, you can see here we have various tokens, identifier names, punctuators, string literals. And if you scroll down a bit on this page, you can see we also have a list of keywords as well. So, you could take these keywords, codify them into your own engine, and then check against them to see if a token is a keyword. If it is, you know what token types give it.

Back to our example. We have a token struct, which is a bit like an object in JavaScript. It has two properties. We have token data, and you can see we have all the different token types there. It doesn't fully match up with what we had in the spec, but that's okay. And then we have a position where it is or where we found it in the source code. Useful for debugging later. And then once we've created our token, it goes into our array. So, here we have four tokens, keyword, identifier, punctuation, and string literal. And you can see just above I've put what each token is holding currently. So, you can see let foo equals hello world. Once you have that, you're done, and that can be sent off to the parser.

So, the parser will go through these tokens, as we have here, from left to right. And for each one, we're not only asking what comes next, but we're taking them and we're building a tree, an abstract syntax tree that represents the structure of what the program is. We're going to go from this, what we have here, to something that looks like this. And this is a lexical declaration. So, we can see the letter at the top. And we say okay, a lexical declaration must have a variable. So, the variable is directly underneath. And even the variable and sorry, it's an array of variables, even though we only have one. That's why we've got the square brackets and variable, because you can define and declare multiple variables in one statement.

7. JavaScript Engine Variable Declaration

Short description:

Each variable has a binding name and an initiator. Lexical declarations in the AST node. Enum on line two contains let and const with variables.

And each variable has a binding name and an initiator. The initiator is actually optional. You can just do let foo and move on. But essentially, you get a tree that looks like this on the right. And when I was putting this together in Rust, it was actually something a bit like this.

Our lexical declaration is an AST node. So, what's on line two is an enum. And that's because let and const are lexical declarators. Var is a little bit different. It has different semantics with function scopes. So, it has its own node. And, yeah, you can see that it's just an enum with let and const and each one has a list of variables.

And to see what a variable looks like, you can see line seven, we have a binding and an initiator. This enum on line two, you can actually give it methods. So, we can create a pass method. And because our first token was the let, we know that we're dealing with a lexical declaration, so we call pars on that and that should deal with the rest of it for us. So, we can see here on line four, for instance, we expect that the next token is an identifier.

8. JavaScript Engine Variable Processing

Short description:

Propagating errors, syntax checking, variable bindings, and initiators in lexical declarations. Execution simplicity and method implementation within the enum.

And the question mark on the end of line four is essentially saying, well, propagate the error all the way up if it's not. So, essentially, we're ending the program there. It's a syntax error. I don't need to carry on any further. For here, line seven, we're essentially checking to see if the next token after the identifier is an equal sign. If it's not, then we just say, okay, it's a binding with nothing defined on it. And we just return non. So, we have enough information here to return a variable type that has a binding name and an initiator or an optional initiator.

It actually looks like this when it's all put together. So, you can see our lexical declaration. It's holding an array of one variable which has an identifier foo and hello world. Execution is actually pretty simple because we've done most of the work up front. As I said earlier with this type, coming back to this, as I mentioned earlier that we gave this type a method called pass. We can also give it another method called execute.

So, you can see the impl on line one. If I didn't describe it earlier, I apologize. It's essentially allowing us to add a method to that enum. And now we can execute it. We've put the values in there. And now the values are in there, we can actually run it. So, what's going on here is we do a pattern match first on the value itself. Is it a let? Is it a const? In this case, the same happens regardless. We pull out the variables and we store them on VARS on line three. And then on line eight, we recurse, we loop through the variables.

9. JavaScript Engine Lexical Declaration Evolution

Short description:

Single iteration execution and recursive tree walking for lexical declarations. Scope and context explanation with a focus on a straightforward variable binding creation. Evolution from an initial implementation to a virtual machine with byte code generation and inline caching.

In this case, there's only one. This only runs, we only have one iteration of this. If there is an initiator on line 10, we call execute on the expression. So, this is where the sort of the name, the tree walking comes from. Because if the lexical declaration has an execute, that will call execute on nodes underneath that. Which will then call execute on nodes underneath that. Until eventually we get back a value, which is what we have on line 10. So, it's quite recursive.

We then declare our variable name into our context with our value. I haven't talked too much about scope and context on this. I think that's a bit, a bit, well, out of scope for this. But essentially the scope is a hash map representing the current scope. And then those hash maps have parents. So, if a variable is not in there, it will then recurse above and so on. But you can see here, it's quite straightforward. What we're left with is a binding foo that's been created with a JavaScript value, which is a string of hello world.

So, that was a quick run-through of the sort of things that I got set up in the early stages. It was quite naïve as an implementation. I'd never built a JavaScript engine before. But luckily, it's had a few years to grow. And so, today, I'm pleased to say that we have moved on quite a bit from that. But it was definitely a good start. We have a virtual machine. So, instead of executing as we go down, we now have byte code generation. That is a lot more compact, making reusability of certain routines faster. Inline caching is also implemented, reducing back and forth to main memory, resulting in faster general execution.

10. Boa JavaScript Engine Community Contribution

Short description:

Enhanced CPU caching and inline caching for faster property lookup. Growth from a solo developer to a strong contributor community. Emphasis on community involvement, code readability, and comprehensive documentation.

More things are cached on the CPU. We're doing less back and forth to main memory. So, it means that general execution is a lot faster. We have inline caching as well. Property lookup on various objects is much faster now than it was a couple of years ago.

We've built a maintainer team over the years. Initially, it was mainly just me working on Boa. Gradually, more contributors joined the project, forming a strong community. This community has helped us create a stable open API with a significant user base, including support for extensions like Biome.

From the start, fostering a community of contributors was a priority. Making it easy for others to contribute to Boa was crucial, given the complexity of building a JavaScript engine. Ensuring code readability, providing comments, and maintaining good documentation were fundamental aspects of this effort.

11. Boa JavaScript Engine Contribution Focus

Short description:

Stable open API with Biome extensions support and async functions. Emphasis on community involvement, code readability, and comprehensive documentation. Categorization of issues for easy contribution and transition to an organizational structure for maintenance.

I'll come back on to that. But yeah, it's helped us put together an open API that's quite stable. So, we do have quite a few users. If you know of Biome, they use Boa for their extensions. And we have support for various other things as well.

I've put async support here, promises, and any asynchronous run times that want to use Boa, it works fairly well. I just want to highlight community. One thing that's really worked quite well for us is from day one when working on Boa, I wanted to make sure that it was something that other people could contribute to and work on. I struggled to contribute to other JavaScript engines before I started Boa.

I wanted to make it as easy as possible. I knew that I would never be able to build a complete JavaScript engine on my own. And it was definitely something that you would need help with. So, making it easy for people to contribute to, for me, was quite important. So, with that said, I always made sure that, you know, code was quite easy to follow, you know, commenting on various things. If something worked, but I wasn't quite happy with it, I'd often try to comment and say, maybe we can try this in the future or, you know, to-dos and things like that.

Documentation. So, in Rust, in the Rust ecosystem, you know, we have docs.rs, which will host documentation for you if you publish your crates to crates.io. I always tried to make sure the documentation was good. Even though it was just me working on it on my own and there was no one else collaborating, I still tried to make sure the docs were good. Good first issues. I always find these quite welcoming and useful. I personally like them and I see them on other projects.

12. Boa JavaScript Engine Testing and Conformance

Short description:

Categorized issues for contributors, formed a maintenance team, and transitioned Boa to an organization. Emphasis on community building through Discord and Matrix. Testing intensified with an incremental approach, achieving 18% conformance in 2020. Test progress showed significant improvement from 2019 to 2024.

So, I try to make sure that issues were categorized into easy, medium, and hard. And some good first ones to pick up as well. And when people did pick those up that weren't sure about the repo or the project, I tried to help out on pull requests. I'm very happy to say we had a few maintainers. There's about five or six of us now. So, we moved Boa into an organization I think in 2020. Before then, it was just under my own name. And then I also made sure that maintainers had access to, you know, review and merge pull requests as well.

So, it removed that bus factor of everything having to go through me, which wouldn't be very easy today. And then of course, we had Discord and the Matrix. So, for me, yeah, building up a community was quite important and has really helped us a lot.

With that said, testing. The reason why I mentioned testing after the community aspect of this is because testing massively ramped up once we had people working on Boa. Nicholas P. Pierron from SpiderMonkey said to me, you know, make it correct first, you can always speed it up later. The order I've always done this in is a naive implementation that follows the spec and we can worry about performance later on. We had someone called Iban join Boa. He's been with Boa since I think 2019 to 2020. And he helped build a little test harness that ran against the ECMAScript specifications test suite called Test 262.

In 2020, we had 18% conformance. You probably can't see it too well. But Iban also had these little dots, the red dots, you could see fail and I think it was one you could just about see for pass. But over the years, people sort of treated this like a challenge and we had all sorts of contributors come to us and massively try to fix any tests they came across. I really like this. This is our test progress over the year. So, I think the left is around 2019, 8,000 tests passed. And you can see the, yeah, you can sort of see the, I guess the burn up chart of the green going up by the time you get to, I think it goes to 2024, we're at around 75 pass tests. So, that's really good. If you get into the website today, it looks a bit like this. So, it's a bit more boring.

13. Boa JavaScript Engine Temporal Implementation

Short description:

Boa's impressive conformance at 95.5%, ranking fourth in test results. Successful implementation of Temporal with collaboration producing Temporal RS library. Achieving 100% test pass rate for Temporal suite in test262, leading to integration into major engines like Chrome and Node.js.

We don't have that chart anymore. We need to bring it back. We revamped the website. And so, now we're looking at around 51,000 tests passed out of a total 53. So, actually, the number of total tests has come down since this. And that's because Test 262 removed a few tests. But we're pretty good actually on conformance. There's a website called test262.fyi. And that runs engines nightly and gathers the results of how they're doing on tests. And we're fourth at the moment. We're actually above JavaScript Core, which is a Safari JavaScript engine. So, we're currently 95.5% passing on the entire suite.

Just before I go, I do want to quickly mention Temporal. So, the Boa team decided that we wanted to implement Temporal. This was around 2024 when we got to work on this. It's the most anticipated feature in JavaScript right now. And for us, things really started to pick up around this time. But what was exciting is we collaborated with V8 and Intel, the Google Intel team, behind Chrome. And we decided to work together on a standalone library in Rust called Temporal RS.

Over the 2024 and 2025, I put together a team. It's been a few of the Boa maintainers, myself, Manish from Google, and we've had students from Bergen University, six students from Bergen University join us as well. But Temporal RS has been actually not just running and complete, but it now passes 100% of tests for the Temporal suite in test262. So, that's roughly around 5,000 tests that Temporal passes. And so, because of that, it's arrived in V8, and it's actually shipped in what you can see here, shipped in Chrome, 144, Jan 6th. Node.js, which only came out recently, May 5th release, it's been in Deno for a while. And of course, Boa has had it for a while behind the flag too. So, I'm really, really proud of this work that we've managed to do.