Programming Microcontrollers with JavaScript -- Q&A with Peter Hoddie and Lizzie Prader

Since connected, embedded IoT devices are extensively used to solve real problems, software architects and developers are increasingly aware that building a proficient IoT solution involves a savvy combination of hardware, firmware, and software. In recent years, microcontrollers have become powerful enough to run JavaScript. Conversely, optimized JavaScript engines may now run on low-specs embedded devices (32 KB RAM). While natively programming a device (for instance in C) is often the most performant option, in many situations, productivity and maintainability trump speed.

As Robbert Gurdeep Singh and Christophe Scholliers from the Ghent University in Belgium explained in one paper:

"It is extremely hard and time-consuming to make correct and efficient programs for microcontrollers. […] Microcontrollers programmed in a low-level programming language such as C [may be] hard to debug and maintain."

InfoQ interviewed Peter Hoddie and Lizzie Prader from Moddable on the opportunities and challenges of JavaScript for programming microcontrollers. Moddable strives to make tools for developers to create open IoT products using standard JavaScript on low-cost microcontrollers.

InfoQ: What is Moddable? InfoQ previously reported on the XS JavaScript engine, but I understand that it includes more than that.

Peter Hoddie: We’re best known for XS, the only modern JavaScript engine designed and optimized for microcontrollers. But XS is just the start. An engine needs a runtime to be useful. In the Moddable SDK, we’ve created a runtime where every component -- from graphics, to networking, to security -- is optimized for microcontrollers. The result is a really great way to create software for IoT products.

InfoQ: What is Moddable’s vision? Moddable’s website mentions open IoT products from low-cost microcontrollers. What drove your choice to focus on the low end of microcontrollers? What do you mean by openness and why does that matter?

Hoddie: Everything we do starts with the owner of the IoT product. That may sound strange given all the work we put into tools for developers.

Our focus on low-end microcontrollers is one example of that focus on the product owner. We want to see great software -- secure, reliable, easy-to-use software -- on every device. That isn’t going to happen if the product requires a hundred dollars worth of hardware to run the software.

"Open" is an overused term in our industry. Let me explain. We believe in the fundamentals of openness. We publish the Moddable SDK under FOSS (Free and open-source software) licenses. We implement open standards wherever possible. Through Ecma TC39 and TC53 we also contribute to new open standards. All of that is good for the product owner -- products built on standards are more reliable, secure, and interoperate better.

But, the vision of Moddable goes beyond that. We believe that IoT products can be open to third-party software -- to apps -- just like computers, phones, and servers. If that were possible, users could easily change the features and behaviors of the products they own. They could change the cloud service it connects to, or choose to operate it off the internet entirely. There are many technical challenges to making this happen. JavaScript solves many of them -- it is an open, standard language that millions of developers can work in. And, because of its history on the web, it is also extremely portable so it can run on a lightbulb, refrigerator, lock, or watch. Giving users more options and more control over their IoT products through installable apps will be a game changer for IoT.

InfoQ: What are some examples of products built with Moddable?

Lizzie Prader: If you’ve walked through the home appliance section of a Best Buy or Home Depot recently, you’ve likely seen some Moddable products without realizing it. There are washing machines, dryers, refrigerators, ovens, and more built with our software powering the user interface on the display, the logic to configure and control cycles, and the cloud communication.

Another product we’ve worked on recently is a sterilization system for ambulances. It uses half a dozen sensors to determine when the inside of the ambulance needs to be sterilized, and when the ambulance is empty it automatically activates UV lights to sterilize it. Our software controls the entire system, including sensors and cloud communication.

We’re also working on a control panel of a monitor for manufacturing equipment. It’s our first project that involves an industrial IoT product, so it’s new and interesting to us. We’re building a color touchscreen user interface that replaces 7-segment displays and various buttons and dials. This type of interface feels very familiar and makes it much easier to set up the system and operate it.

InfoQ: C or C++ are common choices for embedded systems programming, partly for performance reasons. Why did you build Moddable around JavaScript?

Hoddie: From experience, we know that building complex projects -- and IoT products -- go more smoothly using a scripting language. The language takes care of so many details for the programmer. We had to pick one language to focus on because an efficient runtime tends to be tightly connected to the programming language. We chose JavaScript because so many developers know it and because the standard is so precise and well supported by test suites. When we build a project, we use JavaScript as much as possible.

There are places -- performance is one, as you mentioned -- where C is needed. We have an API called "XS in C" that efficiently bridges JavaScript and C. The apps the user installs are pure JavaScript for portability and security, but the objects provided by the device manufacturer can use C as they like to provide high-performance services to those apps. That’s just like the web browser which has lots of built-in native services that are used by the scripts in a web page.

InfoQ: Safety is a key feature for IoT product users. Safety means that using the product will not have harmful results for the user or his immediate environment. How does Moddable help developers handle the risks derived from addressing low-specs devices? I am thinking about a running program outgrowing the constraints of the devices (memory, battery life, and more). I am also thinking about programs interrupting their behavior because of the famous undefined is not a function error message.

Hoddie: Though it might seem counter-intuitive, constrained systems may be inherently safer than large ones. That’s because smaller systems are generally simpler systems that tend to be more robust. There’s less to go wrong and the developers are aware of everything that is going on.

JavaScript helps too. Many common programming mistakes in C -- like forgetting to free memory or writing past the end of a buffer -- don’t happen in JavaScript. The single-threaded execution model of JavaScript also helps by eliminating error-prone, difficult to debug multi-threaded code (and yes, the Moddable SDK can still take advantage of multicore SoCs like the ESP32 using Web Workers).

We also take a very conservative view towards handling exceptions -- like the undefined is not a function error you mentioned. Those can leave the machine in an inconsistent, kind of zombie-like state. The Moddable SDK is configured to restart the device when an unexpected error occurs: out of memory, stack overflow, etc. This puts the device back into a safe state in a few milliseconds (the Moddable SDK is optimized to begin executing JavaScript almost immediately after boot). The device can then recover as appropriate.

To help detect resource depletion issues -- such as out of memory and stack overflow -- our xsbug debugger shows real-time graphs of resource use so developers can visualize the behavior of their product during development to catch problematic trends before they fail.

InfoQ: Security is another crucial non-functional requirement of some IoT products. Insecure products may for instance be taken over, altered, or incapacitated by malicious actors. How does Moddable support developers in developing secure IoT products?

Hoddie: Everyone knows security is important. But there are so many aspects to security that it is often unclear what they mean.

The Moddable SDK supports Transport Layer Security (TLS) for secure communication. Pretty much everyone does. What’s unusual is that our TLS is implemented in JavaScript.

Another aspect of security is preventing third parties from tampering with the firmware. That goes by various names like secure boot. It’s really a feature of the microcontroller. There’s not much for us to do there. If the hardware supports it, products can use it.

Features like secure boot are designed to keep third party code out. But recall that our vision is about letting third party code in. We want users to have the freedom to install the apps they want in their IoT products. We need a way to let in untrusted code while keeping the overall system secure.

To do that, we are bringing secure execution to the JavaScript language standard through the Secure ECMAScript (SES) proposal to TC39. SES allows the execution of JavaScript to be sandboxed into extremely lightweight compartments. This limits an installed app to access only certain features of the system. Part of what is great about SES is that the product defines the security policy; SES is just a tool to implement the policy. XS is the first JavaScript engine to implement SES and we’ve demonstrated that SES is light enough to run comfortably inside a Wi-Fi-connected lightbulb.

InfoQ: Tell us about the TC53 committee. What is it and why another committee? What has it produced so far? What is in the works?

Hoddie: When Ecma International first approached us about TC53, I had a similar reaction. The last thing the world needs is one more IoT standard.

But most IoT standards are about communication protocols. They begin and end at the physical edge of the product. We took a different approach with TC53. We are absolutely not inventing another protocol. We’re developing standard APIs that run inside the product. Those APIs can be used by the product manufacturer to implement their software and by apps the user installs. Those APIs need to be standard so that apps can work on light bulbs (or garage door openers or washing machines) from multiple manufacturers, just as web pages work on browsers from multiple manufacturers.

The great thing about the TC53 approach is that we don’t have to worry about what communication protocols come to dominate IoT. Because we can write portable code that runs inside the product, we can pretty much implement whatever protocol happens to be needed.

The committee is formally known as ECMAScript Modules for Embedded Systems. We’ve got a draft specification that covers IO, sensors, and displays. IO includes network sockets, which is the foundation for implementing network protocols. We also have a prototype implementation for the ESP8266 microcontroller built on XS which allows us to build experiments. The J5e project, Johnny Five for Embedded Systems, is a really cool example of what’s possible -- it is a reimagining of the popular Johnny Five robotics JavaScript framework that is implemented entirely in JavaScript using the TC53 IO APIs.

InfoQ: In what measure is it possible to write portable embedded programs? That is, how do you minimize the changes in the program related to the changes in the hardware modules used?

Prader: It’s very possible. JavaScript is a platform-independent language, and the JavaScript APIs in the Moddable SDK are completely platform-independent. Our Commodetto graphics library, Piu user interface framework, networking protocols, BLE, files, and hardware APIs are all JavaScript. That means if you write an application that uses them, you can run it on multiple target platforms without changing a single line of code.

The APIs we’re defining for TC53 are also pure JavaScript. Hardware manufacturers can implement all of the device-dependent code to make the JavaScript APIs work, but application developers don’t have to worry about the low-level details. They just write JavaScript applications using a familiar, standard API. So, for example, if a developer writes an application that displays temperature sensor data on a screen, they’ll be able to swap out the temperature sensor for any other TC53 conformant temperature sensor or swap out the display for any other TC53 conformant display. And they can do that with no changes, or minimal changes, required in their code.

InfoQ: What are some pain points impeding a faster growth of IoT and more specifically the use of JavaScript in an IoT context?

Prader: IoT has a ton of issues. User privacy isn’t respected, companies orphan products, manufacturers decide which products are interoperable and which are not, the security of some products is a joke -- the list goes on and on. To put it simply, IoT is broken. Moddable and all of the TC53 contributors want to fix it and believe JavaScript and standards can help.

It is a completely different challenge convincing others that JavaScript for embedded development is a good idea. I’ve talked to hundreds of people over the past several years at trade shows, conferences, and meetups about it, and reactions range from excitement to indifference to hostility. Some JavaScript developers are thrilled that their programming skills can be applied to a new platform and others who don’t have any desire to develop applications that run outside of a browser. There are embedded developers who are excited to learn a new approach to embedded development, and others who are horrified that anyone would consider using a language like JavaScript. Our approach to embedded development is relatively new and very different from classic techniques; it’s no surprise that not everyone is immediately on board.

Hoddie: In the big picture, it is going to take a lot of people working together to get IoT right. Our work is about creating a way for lots of people to work on the software of each IoT product. The JavaScript language and emerging TC53 standard are tools to make that possible by breaking away from proprietary APIs and closed firmware.

InfoQ: What are interesting didactic resources for developers who want to understand more about IoT, start with their first embedded programs, or simply see what others have done?

Prader: You can get started writing embedded applications today. The Moddable SDK is available on GitHub and includes over 150 example apps and thorough documentation of its APIs. There are tons of examples that work with a variety of hardware platforms. But you don’t even need hardware to start -- there are hardware simulators that run on Mac, Windows, and Linux.

The Moddable team posts about recent projects made with the Moddable SDK -- not only by us -- and other updates on our company blog and Twitter.

Peter and I just finished writing a book for developers who want to learn more! It’s called IoT Development for ESP32 and ESP8266 with JavaScript and you can purchase a copy today. The book is written both for embedded developers who want to start building with JavaScript and web developers who want to bring their skills to embedded products.

And, of course, there are tons of resources from other sources. There are many professional developers and hobbyists that share their work on Twitter and blog posts. Many conferences post videos of speakers on their websites or YouTube. There are email newsletters and podcasts -- one of my personal favorites is Stacy Higginbotham’s e-mail newsletter. She talks about all things IoT, from chips to consumer products, startups to giant corporations, and more.

About the Interviewees

Peter Hoddie is an engineer and entrepreneur focused on client software. He is recognized for crafting compact and efficient code that pushes the boundaries of user experience on consumer hardware. The software he and his teams have built has powered mass-market consumer products from companies including Apple, Whirlpool, Palm, Sling, HP, and Sony. Peter recognizes that the first users of any product are the developers who created it and that those developers cannot build compelling consumer products on a foundation that’s unstable, complex, or confusing. He led QuickTime development at Apple during the 1990s and contributed to the development of the MPEG-4 file format standard. He is a co-founder of Moddable, a delegate to ECMA TC39, and chair of ECMA TC53.

Lizzie Prader is a software engineer at Moddable in the San Francisco Bay Area. She is an IoT skeptic working in the IoT space, hoping to make consumer IoT products more open and customizable for the end user. She specializes in developing touch screen user interfaces for embedded systems and creating developer resources.