 Hi, I'm Peter and I'm Lizzie and we're some of the co-founders of Mottable, a company that works on JavaScript for embedded. I've been working on JavaScript for embedded for my entire career. When I shipped my first embedded JavaScript project in 2005, before that I was working at Apple on digital video. As part of that, I helped create the impact for file format with ISO. I'm also currently a delegate to ECMATC 39. Both of us are also delegates to ECMATC 53, a new standards committee that is focused on JavaScript for IoT. Before we get into what we do there, we want to talk a little bit about IoT itself. To put it simply, IoT sucks. We all kind of know this. If you go on Twitter, you can find many, many tweets about IoT product failures. This person's thermometer can't be used for cooking because it needs a software update. This person's sprinklers won't work because they aren't currently connected to their Wi-Fi network. And my personal favorite is a barbecue offering to be this person's default browser. You can spend all day looking at these. They're very entertaining, but they do reflect some of the very real problems that IoT products have. And those are worth listing briefly. Privacy isn't respected. Companies orphan products. We have to beg manufacturers for features rather than just writing the code ourselves. Manufacturers make choices about interoperability based on their strategic relationships rather than our needs for the product. The SNIOT stands for security. Products are unreliable because companies underinvest in testing, especially their software. We won't go into details. This is already well established. We aren't here to point fingers or complain about IoT. We're here to invite you to help fix it. We believe that web developers are in a unique position to help resuscitate IoT. That's because they already have experience solving many of these problems on the web. And it's also because some of the key technologies of the web, we'll focus on JavaScript in this talk, are now ready to use in the embedded software that powers IoT products. So who do we mean when we say web developers? It's not us. We're certainly not web developers. But into that broad category, we include both front-end and back-end developers. So developers working in JavaScript in the browser and developers working in JavaScript with Node.js. We should also define what we mean by embedded software. There are lots of definitions around. Code that works with hardware. Code that runs in devices including IoT products. Code that runs on constrained or resource-limited hardware. Often all of those are true, but it isn't what we mean by embedded. Embedded software is software written for a set of known constraints. You know the constraints before you start coding. They can include hardware constraints like memory, storage space, CPU power, and energy, or battery power. They can also include other software constraints like knowing which JavaScript engine you are using, which JavaScript features it supports, and which modules are available. A key part of embedded development is tailoring the implementation to deliver great results within the constraints. Fundamentally, these are optimization problems. Of course, there are many differences between programming in JavaScript for the web and programming in JavaScript for embedded systems. Let's look at one seemingly simple question to see how. And that question is, what happens when your JavaScript code runs out of memory? No one really knows. The JavaScript language specification has almost no text about that. There isn't a memory full-error object or anything. The one place that out of memory behavior comes up is in allocating array buffers. Some call this JavaScript's infinite memory model, that memory can be allocated forever. And of course, it isn't true, but on the web platform, it's close enough to true that web developers take it for granted. On embedded devices, memory is far from infinite. One of our favorite trips has about 45 kilobytes of free memory for scripts. Not 45 megabytes, not 4 gigabytes, 45 kilobytes. The JavaScript engines and web browsers can't even launch with 45 kilobytes of memory. Embedded JavaScript developers ship products without memory. Maybe you're thinking, why not just add more memory? It isn't that expensive. It is that expensive. IoT products tend to be cost sensitive because their profit margins are thin and their markets are competitive. That chip with 45 kilobytes of memory costs about a dollar. Adding memory can easily cost 50 cents or a dollar more and make the board bigger, make it use more energy, add more high-frequency traces to its board, which makes our certification more difficult and more. All of that increases cost. Software that delivers within the constraints saves people money. Finally, remember that IoT features are only part of a product. The product exists to do something else. Be it a door lock, a washing machine, or a thermostat, IoT just helps. Here's a sticker on an IoT dryer that we found at Home Depot. Notice that Wi-Fi is just another feature. One that the manufacturer appears to see as less important than Steam. We mentioned that JavaScript engines that are used on the web won't run on the hardware and IoT products. Fortunately, there are JavaScript engines dedicated to embedded devices. You may have heard of some of them. There's Esparino, Ducktape, JerryScript, V7, and several others. All of these exist because the detailed work to standardize JavaScript has made it practical to create engines optimized for specialized needs. All of these engines have in common is that they implement ES5, the fifth edition of JavaScript from 2009. And while some implement a handful of more modern language features, the fundamental programming experience is somewhat dated. You may not have heard of the XS JavaScript engine. That's Modable's engine. For most of its 15-year history, XS has kept a pretty low profile. But XS is the only modern JavaScript engine for embedded devices. How modern? Look at the results from Test262 Report, the definitive test suite for JavaScript language conformance. No other engine targeting resource constrained devices is included. Not only is XS here, it has better language conformance than the JavaScript engines in many browsers. Why doesn't everyone switch to XS if it has such amazing language support? The answer is in its name. XS stands for Extra Small. XS focuses on being small, small memory size, small code size, to run on inexpensive hardware. The engines used on the web platform are optimized for speed. Still, XS is more than fast enough for consumer and industrial IoT products. Let's take a quick look at examples of consumer and industrial IoT products built on XS. This is a control panel of a monitor for manufacturing equipment. Unlike the user interface of most industrial IoT, this one has a color screen with a familiar touch user interface, which makes it easier to set up and operate. Here you can see how it's configured with a type and search field similar to a smartphone. What's really surprising is that this product is completely controlled by a chip that costs $2.35. This is a sterilization system under development for ambulances. It uses half a dozen sensors to determine when the inside of the ambulance needs to be sterilized. And then when it detects that the ambulance is empty, it activates UV lights to sterilize the inside for the next patient. The system is entirely controlled by JavaScript, including secure cloud communication to report the system status. These are home laundry appliances. The entire user experience is coded in modern JavaScript using the pure user interface framework. But that's not all. The logic to configure and control cycles is too. So is all the communication code to talk with the cloud for remote control. The performance is great and the cost is low, which allows the manufacturer to include these features in dozens of different models, not just the premium ones. If you as a web developer were to sit down and read the code of these products, much of it would be familiar because you already know the programming language. Some APIs would be familiar to web workers, for example. But many would be unfamiliar. Instead of DOM for the user interface, they use Pew. Instead of Fetch, they use a custom HTTP client class. These classes are different from the web because they're designed to work with far fewer resources. But they're also different between different embedded JavaScript engines because those embedded JavaScript engines evolved independently. Kind of like how JavaScript engines on the early web evolved before ECMA TC39 began the work of standardization. Embedded JavaScript would be a lot easier with standard APIs. So Mottable and Boku worked with ECMA International to create a new technical committee, TC53, to try to solve this problem. Boku is the driving force behind Johnny 5, the JavaScript robotics toolkit, and has extensive experience in web standards. The TC53 contributors have a wide variety of interests and expertise. Representatives like us from Mottable are interested in efficient scripting and touchscreen support. There is a delegate from Michigan State University who focuses on data precision for big data analysis. Members from McGorick who are interested in provably secure script execution. Boku brings their expertise in sensors and robotics applications. Lighten who focuses on portable drivers for sensors, displays and energy harvesting. Monotype brings expertise in text handling, fonts and text rendering. And Whirlpool for embedded system requirements and focus on safe operation. The formal name of TC53 is ECMA script modules for embedded systems. So the name sort of explains the focus. It's defining standard modules for JavaScript. There's no intention to extend JavaScript or to define a subset specifically for embedded. The modules that TC53 defines are intended for use in embedded systems and IoT products. These APIs are not destined for the web anymore than DOM is destined for a light bulb. TC53 takes inspiration from the extensible web manifesto. The idea that standards should focus on low level APIs for developers to build on. TC53 is following that idea by starting at the lowest practical level. A JavaScript hardware abstraction layer. This allows a device to boot almost immediately to JavaScript. The dryer you just saw does that. This gives scripts near complete control of the hardware. Developers build up from there with modules and frameworks to create products. To give you an idea of what working with the hardware abstraction layer looks like, let's look at a simple example. If you've experimented with Arduino, this will look familiar. Blink uses a button to turn an LED on and off. And here's how it looks in C. In JavaScript, using the TC53 digital IO, it looks like this. Where practical TC53 APIs use familiar API styles. So notice that the digital class API uses a callback. This is a very common way to deliver asynchronous events in JavaScript. We recognize that many newer APIs on the web use promises. However, for performance and simplicity, TC53 uses callbacks. The callbacks can be used to implement promise-based APIs by libraries building up from the TC53 specified modules. Also notice that the constructors are configured with an options object. This is familiar and extensible. Extensibility is important. The low-level TC53 APIs are a hardware abstraction layer, not a least common denominator API. So where hardware is the same, TC53 wants it to support the same APIs. But TC53 also wants it to be possible to benefit from hardware differences. Extensibility provides script access to those unique features. One of the coolest features of TC53's work is inspired by the Firmata communication protocol used by the Johnny V robotics library. A typical embedded system consists of a microcontroller and several peripheral chips. Some of those external chips add more IO capabilities. TC53 has an IO class called an expander to support these. A common type of expander provides additional digital pins. A script creates an expander using an options object-based constructor. You can access the digital pins of the expander exactly like the built-in pins in the Blink example. Here's the Blink example modified to use the expander pins. All that has changed is the name of the constructor from digital to expander.digital. Expanders are a powerful new concept for working with hardware in JavaScript, and they aren't limited to hardware physically connected to the microcontroller. We've built expanders that connect to wearables using Bluetooth and to cloud services using Wi-Fi. This makes controlling hardware with scripts simple and consistent, no matter where in the world the hardware is located. TC53 is also working on security. I know, everyone in IoT says that, but we're taking a different approach. Actually, at our first meeting, like everyone, we agreed on the importance of security, but we had no idea how to solve it, so we set it aside. Later, we learned about Secure ECMAScript, CES, a proposal to add Secure Execution to JavaScript. CES is based on work by Mark Miller of Agorek to bring the proven object capability security model to JavaScript. CES is great because it allows trusted and untrusted scripts to coexist, even communicate directly, while guaranteeing security boundaries are enforced. It does this using lightweight sandboxes called compartments, which allow code from different authors to be safely combined in a single system. The CES approach elegantly meets the security needs of TC53, and importantly, it can be efficiently implemented on embedded systems with limited resources. We know this because we already implemented CES in excess. Last year, we showed CES running on an $18 IoT light bulb. TC53 has decided to adopt CES as its execution security model. We are working with Agorek to advance this work in TC39 and hope it will one day be part of the JavaScript standard. All of this is just some of the work that TC53 is doing to standardize embedded JavaScript. But you don't have to wait for the standards work to be finished to get started learning and developing. Some adventurous web developers are already starting to explore embedded JavaScript. Some, like Shinya Ishikawa-san, are simultaneously learning and teaching others. Others, like William Hilton, with his isomorphic Git project, are pushing at the boundaries of what's possible on embedded systems and developing models for sharing code between web and embedded projects. Others are building the IoT products they wish already existed. When the COVID-19 shelter in place began, Mike Hedman, a web developer working from home, had a difficult time balancing work meetings with family communication, so he used his JavaScript skills to create a solution. JavaScript in the browser gave access to his Outlook calendar to JavaScript on a Model 2 development board. The result allowed his family to know when he had a work meeting, and even better, he added buttons for each family member so they could signal for his attention. This is the kind of useful project that large manufacturers aren't creating, but they help real people solve real problems. Mike published his code so anyone can replicate his setup, improve it, and adapt it to their needs. That's the kind of people-centric project that is possible when web developers bring their skills to IoT. That's all we have for today. Thank you for joining us. We hope we've inspired you to think about how you can help make IoT stuff less. If you want to learn more about TC53, we're having our next meeting this Thursday and Friday. You're welcome to sit in. Our first day agenda is an introduction to TC53, so you'll hear from various contributors about our roadmap. Please join us. We'd love to see more JavaScript developers getting excited about this and getting involved. If you want to learn more about Model, check out our website and blog at Model.com. If you want to get started developing with XS, the Model SDK is available on GitHub. You can also follow us on Twitter to get frequent updates about what we're doing and see what other developers are working on. We also just finished writing a book called IoT Development for ESP32 and ESP8266 with JavaScript. If you want a hands-on guide to building IoT products that combine networking, sensors, actuators, sound, graphical user interfaces, and more, this will be a great resource for you. It's expected to be published later this summer, but you can pre-order it now. If you have questions about TC53, Model, or JavaScript for Embedded in general, we'll be around for a Q&A session right now. Thanks for listening.