Behind Microvium

Behind Microvium

Updated: June 2020

Microvium is a tiny JavaScript engine for microcontrollers, designed to bring small pockets of scripting capability to an otherwise-C firmware.

I’ve created this page to informally explain some behind-the-scenes points about the development of Microvium — things that probably don’t belong in the repository or formal documentation, but which nevertheless may be interesting to some people.

I’ll treat my normal blog posts as essentially an immutable history of things I’ve been doing (Microvium or otherwise), while I’ll try to instead keep this page updated with the latest information1.

How old is Microvium?

Started in February 2020. Still a baby.

Why Microvium?

In short, I have a client2 who’s using EmbedVM to introduce small, hot-swappable units of behavior to an existing C firmware. EmbedVM is indeed a very compact and portable VM for embedding many kinds of small scripts into a program, but it has an incredibly limited and non-standard scripting language. When using it to describe more complex behaviors, the resulting scripts are almost unmaintainable. A language like JavaScript would enable the scripts to be much more modular maintainable.

I would have loved to have recommended that they incorporate a full JavaScript engine like that of XS, but the resource restrictions on the device were simply too constrained.

Microvium is what I believe to be the exact solution for the problem at hand — a JavaScript-ish engine that makes trade-offs in favor of compactness rather than language-completeness, speed, or performance. And if it works for this client, it will likely work for other people who face a similar problem.

Microvium also brings its own unique flavor and tradeoffs to the table of options to choose from.

Is it really JavaScript?

Yes and no. Average JavaScript code in the wild will not run on Microvium because the language subset is significantly restricted, especially at this early stage of release. There are also some edge cases where a supported feature is implemented with slightly different semantics for performance reasons. For the intended use cases at this stage, this will rarely be a problem: the majority of working Microvium scripts will run on a full JavaScript engine with exactly the same behavior as they have on Microvium.

What about MetalScript?

MetalScript is a JavaScript compiler I’ve been working on, and is a much more ambitious project. Microvium does not replace the need for MetalScript, nor I have stopped working on MetalScript, but my focus is on Microvium for the time being.

How Small? (ROM/RAM)

Expect these numbers to change a bit over time.

Compiled for a 16-bit architecture:

  • The engine currently uses 8 kB of ROM in its most-compact configuration.
  • A bytecode image has a fixed overhead of 44 B of ROM.
  • Each instance of a VM has a fixed overhead of about 24 B of RAM while idle.
  • Beyond that, the usage depends on how big your script is and what it does.

Why is it open-source?

The reasons are mostly personal. I think Microvium would be almost exactly as useful if it were closed-source, but by making it open-source, I don’t need to develop the project on my own in silence and isolation like I was with MetalScript. I much prefer being able to openly share ideas and collaborate.

Not only have I open-sourced it, but I’ve also used a very permissive license (MIT) for both the compiler and bytecode interpreter, making it easy for anyone to incorporate Microvium into other projects, without needing to worry much about legal issues, security issues, or what happens if Microvium stops being maintained.

(I might change this at some point to a dual-licensing model, where you can use it for free for non-commercial use but contribute financially to its development if you use it for commercial use)

What’s planned for the future?

I’m intentionally trying to avoid committing formally or informally to any particular development path or schedule. It just adds unnecessary stress to my life. Just on a personal level, I’m starting to realize that always having my head in the future, on what-could-be-but-isn’t-yet, is detracting from the great things that already exist right now and putting me in a kind of psychological “debt” — a deep and unsatisfying sense that the current reality is always less than I want it to be.

Having said that, no doubt there will be many cool things coming to Microvium in the future — the list of possibilities of directions I could go with this seems endless. Subscribe to my blog to get updates on new developments.

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.


  1. But I’m not committing to actually remember to do so — just check the date at top of this post to know long it’s been since I’ve looked at this post 

  2. I won’t disclose particular details about this client publicly