Steve, Dan and A.J talk with Nick Hehr and Peter Hoddie about using JavScript with IoT devices. They cover a wide range of topics, including the XS JavaScript Engine, the only complete ECMAScript 2018 engine optimized for embedded devices (created by Moddable), and even get into the nitty gritty of how it is built and how it works. They also cover TC53 - the standards committee for JS in embedded systems, a committee that Nick and Peter are part of. In picks, they get into a great discussion on home security systems and their various security issue, and of course, Steve brings the great dad jokes.

Hello everybody and welcome to yet another thrilling adventure that is an episode of JavaScript Java. My name is Steve Edwards. I am the host with the face for radio and the voice for being a mime, but you're stuck with me. I'm still your host. Mostly because Dan and AJ didn't want to do it. Anyway,

 

Hahaha

 

our panelists today are first Dan Shapiro. How you doing, Dan?

 

Hey, coming from warm and sunny Tel Aviv.

 

Yes, it's actually been warm and sunny here. I mean, I was camping over the weekend with a church thing with my son, 110 degrees every day. We spend a lot of time in the water, let's put

 

Well,

 

it that way.

 

at least unlike Europe, we have air conditioning, so we can live with the heat.

 

Oh yes, and when you're outside, the air conditioning doesn't really work that well. But anyway, also is he of the more recently gray hair as we were discussing, AJ O'Neil, how you doing AJ?

 

Yo yo yo, I'm coming at you live from the backs of my hands are

 

from

 

red.

 

the backs of my hands are red. How's things in the backs of your hands are red?

 

Um, well, it's not, I just kind of mashed

 

Oh,

 

that

 

okay.

 

up in a weird way, but

 

I was just going

 

I was,

 

with it.

 

I was riding and I had long sleeves to protect myself from the bugs and inadvertently, or no, wait, that's not the right word. Anyway, protecting myself from the sun with long sleeves, but my hands, I wasn't wearing gloves. And so I have a sunburn on the backs of my hands.

 

And that's the only place I have a sunburn other than a little behind my neck, but really

 

Yeah,

 

not

 

you're

 

much.

 

The

 

more of a pink neck and not a red

 

Kind

 

neck,

 

of weird.

 

it looks like.

 

The worst by the way is when you're wearing sandals and accidentally get sunburned

 

Oh,

 

on the top of your feet.

 

yes, I got that this weekend. And then the bug bites around the ankles too. It was a great combination for feet yesterday. And before we get to our guests, I'd also like to say hello to the studio audience. Yes, yes, yes, thank you.

 

you

 

It's always, oops, sorry.

Okay, you guys can stop now, thank you. So I always like to throw in the studio audience. It adds more ambiance to the podcast. And after all that, let's get to our guests. Today we're talking about IoT, otherwise known as the Internet of Things, things being a very specific term. I always love that as a suggestion on Wheel of Fortune thing. Okay, that narrows it down. First of all, we have Nick Hare. How you doing, Nick?

 

I'm doing pretty well. How are y'all doing? I'm doing pretty well. How are y'all doing? I'm doing pretty well. How are y'all doing?

 

Good, and Peter Hattie.

 

Hello.

 

Hello, so before we get going, why don't each of you give us a quick intro about yourselves, who you are, why you're famous, what you do, where you do it, et cetera, et cetera.

 

Sure. Again, my name is Nick, and I am a staff software engineer at a company called Betterment in New York City. We do have a lot of remote employees, including myself now. I just live just right outside the city these days. And I work on the front end platform team there as a staff engineer and do a lot of stuff with JavaScript and CSS and accessibility and overall UX. But in my free time, I like to tinker with JavaScript including internet connected things and met Dan at recently at the JSCOM Budapest talking about offline first IoT, which I'm sure we'll maybe bring up a little bit today.

 

Yeah, it was a cool talk. I enjoyed listening to it and meeting you there. So it's also worth mentioning that people can catch you at conferences and recognize you by your mustache.

 

Yes, the mustache that's

 

Which

 

been around for

 

we determined

 

almost a decade

 

that

 

now.

 

it, yeah, which we determined is not a zoom, you know, effect or something like that, it's real.

 

Yep.

 

Yes. For those of you that can't see, as most people can't on an audio podcast, he's got these impressive mustaches that with the curls on the very ends, I mean, a complete loop. It's awesome. It's awesome.

 

If you ever see

 

I'm also

 

my,

 

jealous

 

uh.

 

because he has a ton of hair, but that's another story.

 

If you've ever seen my avatar on GitHub or around places for my handle being hipster brown, charlie brown with a mustache glasses and a little bit of curly hair.

 

Oh, okay, that's shown up worthy for sure right there. All right, Peter, your turn.

 

Hey, so I usually describe myself as an engineer and an entrepreneur. I'm one of the co-founders of Modable. We do a lot with JavaScript and IoT. It's kind of our business. I also am very involved with ECMA, which is the standards body that defines the JavaScript programming language and is now, together with Nick and some other folks, defining JavaScript APIs for IoT. Way, way back in the dark recesses of time, I started my career at Apple doing digital video back when computers had less power than a light bulb has processing power these days, which is kind of strange. And that also got me started on standards. I worked on the ISO and PEG-4 standard way back when, which is how everybody ships around their video today. And then somewhere in between there, I worked at Marvell, which was a semiconductor company, which for me in working in IoT here at Modable.

 

So that's Mar-a-Vell is different than Marvel comics, right?

 

Yes,

 

Yes,

 

and

 

very different.

 

apparently there was some kerfuffle about that at some point, which resulted in the founders of Marvel Semiconductor getting to meet Stan Lee. So that was kind of cool for them.

 

Hopefully he wasn't yelling at them for taking their same name, right?

 

Yeah.

 

You

 

Excelsior!

 

know, I think

 

Where?

 

I'm sorry. I'm sorry.

 

the yelling was left to the lawyers so that they could

 

Yeah,

 

have

 

there

 

some

 

you go.

 

happy

 

There

 

pictures at the end.

 

you

 

Yeah.

 

go. And then also

 

I mean,

 

I'd

 

that

 

like

 

extra

 

to clarify

 

L, right?

 

it. Right. And I'd also like to classify that he said ECMA script, not eczema. Those are two very different things, but, uh,

 

Yes.

 

just for clarification

 

easily

 

purposes,

 

confused.

 

easily confused.

 

Yeah,

 

Alrighty.

 

it's worth noting by the way mentioning ECMA that most people, well I guess we'll get to that in more detail soon, but you know, most people when they think about JavaScript and ECMA, they think about the TC39. You're actually a different TC.

 

Right. So before we get going, I guess we'll sort of get organized here a little bit. Dan, since you brought them on, we want to start out and what interested you and how we want to get started talking about JavaScript and IOT.

 

Well, I don't have that much to add, to be honest. Like you, I'm actually a bit of a novice when it comes to the technical implications of IoT. I think we kind of mentioned in the pre-recording conversation that everybody uses IoT, but somehow I never got into the technicalities of it. It's just that I met Nick at the JSConf conference, and it seemed like a super interesting topic to discuss, the fact that JavaScript really and it can run on devices that you wouldn't imagine can actually run JavaScript. I think that JavaScript even runs in space right now on the James Webb telescope. So they wanted something robust, so they put JavaScript there. I'm looking at AJ's face. And so again, I basically invited Nick to come on our show, and he was kind enough to bring Peter along. And I think this can be an awesome conversation. I certainly plan on learning a lot. Let's put it this way.

 

All right, so I guess let's start out. I'm always big on background and instead of just jumping into something. So Nick or Peter, if you want to talk about what IoT is, maybe it starts, you know, my, my first memories are listening to Leo Laporte on Floss talking about things like Arduinos and I know Raspberry Pi is probably one of the more commonly discussed pieces of hardware used with IoT. I always started thinking about PIE, not PI, and it made me hungry. But anyway, just a little background of maybe where IoT started and where it's headed and how JavaScript fits in with that.

 

Steve, what you just said actually reminded me of the first time I told that I went to some conference and won a Raspberry Pi single board computer at that conference. I texted my wife, or I called her and told her, I was like, hey, I won a Raspberry Pi at this conference. She's like, that's interesting, cool, neat. And I come home and show her the little single board computer. She's like, I thought you were actually bringing me a Raspberry Pi just from this random conference. That was a weird prize, but hey, we're going to enjoy it. And so I think that's a common point of confusion. I'm hurt.

 

Thank you to our studio audience there.

 

Yeah.

 

Anyway.

 

But yeah, I agree. The starting point for a lot of people when they think about IoT, it is a lot of like the maybe the maker side of it in terms of like Arduino, Raspberry Pi, the ESP, the expressive boards these days, which are the ESP8266, ESP32, and the various ranges that come from that. And a lot of those ladder boards are being integrated into a lot more of these common off the shelf internet connected things. what I consider an IoT device was actually the Pebble smartwatch. When I'm going to date myself a little bit, when I was in college, when it first came out on Kickstarter, and I backed the original Kickstarter for the Pebble, like e-paper, e-ink. I don't remember what the official brand that they used. I don't feel which one's the copyright, which one's the technology.

 

Was it

 

Peter

 

Flintstones?

 

probably.

 

No.

 

Flint says, yeah. And yeah, that was like you could program this internet-connected device that was on my wrist and it got me super into wearables. I wasn't studying programming at all in college. I was actually studying psychology and ended up doing programming as a hobby and finding out that I can make a career out of it. And ever since then, I've been finding ways to kind of put JavaScript on things and make really interesting experiences out of it. Because the Pebble at one point actually ran JavaScript on it or a form of it called JerryScript, which came out of Samsung. bit more history around his experience with it, coming from semiconductors and other embedded areas.

 

You can buy one on Amazon, actually. I'm looking at it right now.

 

The Pebbles. Yeah,

 

Pebble smartwatch.

 

they were bought by Fitbit at one point when they just couldn't make the independent business work. And then now Fitbit's owned by getting bought by Google or has officially been bought by Google. And so a lot of the, you can see the design and some of the kind of characteristics of Pebble in some of the newer Fitbit devices and some of the developer runtimes, which were some of the best parts about working with it, in my opinion.

 

Yeah, I mean, Pebble had a, Pebble actually came out of, was just up the street here where they started that effort. And the folks who created that had a really beautiful kind of idea that this was an open device that people could make their own. And I'm actually, I'm thrilled to kind of learn that Nick, Nick got started on something like that. Cause I think that's what's really interesting about IoT. IoT, I mean, every device in our world a computer in it. I mean, I always come back to light bulbs as the classic example, but you know, door locks and refrigerators and I mean, you name it, anything that has electricity going to it kind of is getting a microcontroller in it. And what's annoying about that, frustrating maybe from my perspective, is that those are all kind of black box devices that we can't program. So you know, when you're when you're a software engineer and you look at a door lock that you know computer in it, all you think is, I could make this better. And you're kind of stopped because the device is completely sealed and you can't tweak the software. And that limits so much. And I think all of us have ideas about how IoT should be, but we're kind of stopped from exploring that. And I think JavaScript is really kind of the key to unlocking that. really kind of creating more malleable IoT, if you will.

 

Yeah, I

 

So.

 

mean, JavaScript does have a long history on devices, controlling devices even, back to like when Node.js became a thing in itself. And if folks are familiar with Node Serial Port and that project from Chris Williams, which was eventually like what became or was used to build on to become Johnny 5 and that project to control things like Arduinos, Raspberry Pis, all these embedded devices with a host computer usually over using Fermata as the protocol to communicate with those devices over USB or even Bluetooth and expanded and expanded. And Jotty 5 is still a great place to start today. And often, I generally call it, and I think a lot of people call it, jQuery for hardware because it gives you a single API to work with all sorts of peripherals and sensors and all sorts of things, and even running on some devices itself depending on the hardware that's available to it and operating systems that's available too.

 

Thank you.

 

So it's amazing it's gone back even that far to allow you to control things.

 

you

 

And then we've made leaps and bounds since then to allow you to actually embed full JavaScript engines onto really, really resource-constrained devices that can be run off of batteries and I'm not sure coin cell just yet for a long time. But it's getting there, and you can do really interesting things with it.

 

So I wanted to ask about that actually specifically. So obviously using JavaScript as the programming language has this huge advantage of so many people just knowing that programming language. I think probably more people know JavaScript programming than any other programming language out there. Thanks to the web and thanks to the openness of the web and the ubiquitousness of the web. the web. But I'm also thinking that JavaScript is kind of a problematic choice, I guess, because as you mentioned, one of the defining aspects of all these microcontrollers in all these devices is that they are fairly constrained. They have not a lot of memory. They need to lots of memory, they're usually fairly constrained in terms of their processing power, and various other restrictions. And JavaScript kind of was designed for, not for that, let's put it this way. It's an interpreted programming language rather than being compiled, which means that you need to have an engine installed on that device. the output of a compiler. It's really dynamic, which means that a lot of the optimizations that are associated with static programming languages are not really possible. It uses GC, and it's really, really, let's put it like that, fast and loose with how it uses memory. It tends to create, you know, to add I locate a lot of objects all the time and stuff like that. And the list goes on and on. So I'm just wondering, how do you effectively get JavaScript on all of these devices and why you wouldn't choose some other programming language, which certainly won't be as popular, but would be a lot more appropriate maybe for such constrained environments? I don't know. Obviously, C is everywhere. languages like Rust or something like that. That was kind of a long-winded

 

Nick,

 

question, so feel...

 

you...

 

I'll let Peter take that one. Peter's got,

 

Yeah,

 

yeah.

 

could you clarify that,

 

There

 

Dan?

 

was a lot there, Nick, do you want me to try this?

 

Yeah, go for it. I think you have the best sort of history around that too. And especially being

 

Sure.

 

an implementer.

 

Sure. So, Dan, you've got a lot there. I'm going to back up and try to cover some of it, and you feel free to jump in and tell me what I missed. So, you know, you've got to start with the engine, and, you know, modern web JavaScript engines like V8 and JavaScript Core are designed to be ridiculously fast, and they're frighteningly good at it. that they've developed to achieve that, I mean literally have pushed computer science forward in the last decade, it's incredible. And so that gives JavaScript the reputation of being big and heavy. But scripting languages have been used on small devices forever. Smalltalk being kind of the classic example, ran on devices that make a lot of, on much less powerful devices than IoT products today. And JavaScript isn't that different from those kind of classic scripting languages. So we made our own here at Modable, we made our own JavaScript engine. It's called XS. And XS stands for extra small. And rather than optimizing for performance, our first order bit, our high order optimization, is for size to run on microcontrollers. That refers to the size of the engine itself. That refers to the memory footprint. That really changes how you build an engine. And so our engine doesn't look anything like V8, for example, although it can run basically the same scripts. Go ahead.

 

I apologize

 

No,

 

for interrupting you, Peter, because it's just so interesting.

 

please.

 

So just to clarify, you build your own JavaScript engine from scratch, from the bottom up.

 

Yeah, I should, when you say you, it's in the broad sense. The main force behind XS is one of my colleagues and long time friend named Patrick Soquet, who works out in the Belgian countryside very quietly, creating brilliant optimizations to JavaScript engines.

 

So when you say JavaScript, do you mean literal JavaScript or do you mean ES 20 XD X?

 

We mean well, so we mean the same JavaScript programming language that you find in your web browsers and so currently that is formally defined as ECMAScript 2022 the standard that comes from TC39 and

 

How can you fit a language that large on anything?

 

Yeah, it's really super doable. You just have to approach it from a different perspective. Our full engine will fit in less than a megabyte of space in flash ROM, which is very practical on most microcontrollers today. And we do some really cool tricks. We've actually run it on chips that have as little as 256K of storage for code. We do that with this really slick optimization we developed where you're familiar with tree shaking, where you can basically have a web package or take out the parts of libraries you don't use. So what you deliver is smaller. We basically do tree shaking for the JavaScript engine. So when you write your code as an option, we'll analyze your code to see which features of the language you use. And then we'll take out the parts of the JavaScript engine you don't use. get an engine that's custom tailored to exactly what your code uses. And so that can be much, much smaller.

 

So

 

But

 

basically,

 

if you want all of JavaScript, go ahead, Dan. Sorry.

 

no, what you're describing is just so cool. Can't help really thinking about the implications. So basically, I could take one of the tools out there, like Babel or whatever, that can transform modern JavaScript into quote unquote older JavaScript, or even ES5, and then leverage that in order to make Smaller?

 

Yeah, you could do that. That would absolutely work. It's an interesting idea. I think at some point, you may generate more bytecode than you save in engine size.

 

Oh,

 

But yeah,

 

yeah.

 

I mean, it's a trade-off. You'd have to measure it. But yeah, no, you could totally do it. But it's been really neat for us because it means as the JavaScript language gets bigger, right? Like, if you don't use atomics in your code, and honestly, most people don't use atomics in their code, a price for having that on the device. Right, and if you use it, and

 

Wait,

 

if you use

 

what

 

it,

 

are atomics?

 

yeah, see, it's

 

Okay.

 

been in the standard

 

Hahaha!

 

for like five years.

 

I thought the whole point of JavaScript was it runs on a single thread,

 

Now, Atomics

 

so you don't

 

let

 

need

 

you

 

Atomics.

 

synchronize between web workers, as it were.

 

Oh, OK. So you're not just implementing JavaScript. You're implementing what wig

 

No,

 

and.

 

we don't do what wig.

 

Not really,

 

We pull

 

yeah.

 

in, because the browser is huge and everybody who's tried to do browser-like things on an embedded device has just flailed out. And so, we'll pull bits and pieces from what wig where it makes sense, where we can do that well, but it's really straight up JavaScript.

 

And there are workers in the modable engine as well. So you can have background processes as workers, which is why things like Atomics are useful when needed, but not necessarily out of the boxes, Peter was saying. I think one of the interesting things too is some parts of language become a bit more important to know when to use on modable or XSS, excuse me, versus when we usually do in the browser. So I know a lot of people default to let in a lot of ways. variable declaration. Whereas a const actually has a key benefit in excess versus maybe what would be in the browser. Peter can correct me on that if I'm speaking.

 

No, it's perfectly correct. And so that kind of segues into answering another one of Dan's questions, which is about memory. And so one of the techniques we use a lot is to basically put objects in ROM rather than RAM. So in a typical microcontroller, you might have an order of magnitude more flash storage space, ROM space we call it, than you have RAM. hostages and basically flash memory is really inexpensive. And so we have some techniques that basically let you take JavaScript objects that don't change and store them in Flash and keep them in Flash for their entire lifetime so that they never come through RAM. And that saves

 

Thanks for watching!

 

a ton of memory. Go ahead.

 

So are you changing the way that const works so that it actually makes objects into constants

 

you

 

rather than variables?

 

No, we don't change the semantics of the language at all. But if you assign a string to a const, a string is immutable. Strings in JavaScript never change. And it's assigned to a const.

 

Well, they're, they're immutable, whether you mark them as var, let or const, strings are always immutable

 

Right, but

 

anyway.

 

if they're assigned to a const, both the string and the variable that it's assigned to can never change, and then that allows you to make some optimizations.

 

This is super cool what you're describing, but if I'm...

 

Hmm.

 

Again, I can't help it. The tech in

 

Ha ha.

 

me is, you know, I just want to ask ever more questions about it. So if we're thinking about V8 for comparison for a minute, so V8 actually, the engine actually has in it like an interpreter and a compiler and a smarter compiler. Again, having to do with that whole emphasis on performance. in order to make the startup time as fast as possible. It starts by interpreting, but then it does a little bit of compiling in the background. And then if I identify certain pieces of code as being really hot, it actually uses an optimizing compiler for that. Are you doing anything sort of similar with the purpose of just reducing the size of the code stored? Or is it just an interpreter? code form or do you just interpret the actual raw source code all the time? Like how do you do? What do you do? How do

 

Yeah,

 

you do it?

 

great questions. It's completely different from V8, that's for sure. We do a couple things. One is that we compile to bytecode for sure. So we can run eval, we can parse JavaScript on the device, but we prefer not to. So we precompile the JavaScript typically on your computer into bytecode. We have this option we call preload, which actually can begin to execute your JavaScript on the computer before it deploys to the device. And this is a little tricky and bizarre, but actually in practice turns out to be pretty easy to use. So if you think about it in JavaScript, when you declare a class, that's not static. That's dynamic. It actually executes bytecode to define the class. And that's because you can say class extends some variable name, and that variable name can change. And so we can execute that with some constraints, but we can execute that at build time, basically, before we deploy to the device and create the class object on the computer and burn it into ROM. That does a few things. One, it means that the bytecode to build the class never gets deployed to the device. So it just evaporates into space. What you're left with is the result, class. It means that class can live 100% in Flash. So it's never copied into RAM, so super lightweight. And third, because it's already executed, there's no time, literally zero overhead to create that class when you boot up on the device. So you start up much faster. And so all of this gives us near instant on, where we can be from the time a microcontroller gets powered up to the time we're executing your scripts, like single digit milliseconds on a lot of microcontrollers, which is crazy. We don't do, we don't have a JIT, we don't try on the device to compile your bytecode to native code. But we have another escape hatch, which is if you in the course of development see that your JavaScript code, some particular function's really hot and it doesn't make sense for that to stay in JavaScript, you can recode that and see. and embedded projects. It's a tiny fraction of functions, maybe, I mean, certainly well under 1%. But there's a handful of places that are critical. And so because it's embedded, we can fall back to native code when we need to for a function. And the XS engine kind of makes switching between C and JavaScript really clean and easy to do.

 

That should be pretty easy. I mean, C is one of those languages that's real easy to pick up and learn, you know,

 

Very

 

on a

 

forgiving,

 

whim, right?

 

right?

 

Very forgiving.

 

Ha

 

Yeah.

 

ha ha!

 

Not very forgiving, but very small.

 

and

 

The dry humor is

 

Yeah.

 

very

 

Ha

 

dry for

 

ha

 

those

 

ha.

 

listening in to the mime voice.

 

Yeah, I do have to ask then, so this sounds amazing, it is amazing. Where, you know, on which devices can I find it? Is it excess something that I can put on a device? Does it need to come built into the device? How do I get to use this magic?

 

Yeah, so

 

So

 

it's,

 

yeah, go ahead, Peter.

 

I'll start that and then Nick, I'll hand it off to you, because you've made it so much better. So, XS is open source, and the whole moddable SDK is open source. You can just grab it off of GitHub, and we've got ports for a bunch of different microcontrollers, the Espressif ones, Raspberry Pi's, Raspberry Pico, excuse me, their little microcontroller, and a bunch of ARM-based devices. And we even have people in our ecosystem who are doing their own ports of it to other silicon. So pretty straightforward to grab. The initial setup for anything with embedded is always like just the biggest headache in the world. And that's something that's not been as easy as it could be. And Nick has actually recently done some really fantastic work to kind of simplify that getting started experience. I'll turn it over to you, Nick.

 

Yeah, so I was working with Modable. I met Peter at TC53 from getting invited as an invited expert from experience working on the TESOL open source project many years ago. And for those that remember that as an embedded open source hardware device that you could run Node.js and hardware code on. And I met Peter, learned about Modable, started playing with it, and realizing web dev experience and kind of like the NPM ecosystem, a bunch of that type of stuff, how kind of tedious it is to get set up. And for someone who also does a lot of workshops and wants to teach other people how to do this, most of the workshop would be setting stuff up and making sure everything was running before they got to go and run any code anywhere. So I put a little effort into automating the stuff because documentation is there. And for like the model documentation is in part of the repo and you can read through it And step by step, it answers pretty much everything you need to do. So I went and said, all right, well, let me see if I can program something around it. And so I created a CLI called XSDev. And that allows you to not only set up the model SDK and all the tooling on your computer, but also pulls down the adjacent tooling needed to build your projects for the various devices you're using, either the Pico, the ESP32, ESP8266, adjacent tools, like there's a font tool, which is pretty actually a really interesting part of the Model SDK where you can have custom fonts to use on device screens and touch screens and all that type of stuff. And so there's these workflows built into it as well as being able to bootstrap or initialize new projects and then use like a template from the Model SDK to say, okay, I want a project that has Wi Fi integration so I can just get everything set up with like template, and then working on pulling in more things like third-party scripts, because that's not something that's necessarily built into the way moddable projects work today. And so something Peter and I have been discussing, I've also been discussing with Donovan Buck, who is another member of TC53 and has another project called J5E, which is Johnny-5 embedded, and is also a maintainer of Johnny-5. And so we've been working on seeing how do we make this a really good experience for as well as adventurous embedded developers who want to get more into that ecosystem and maybe open up the world of NPM and some of those other things into embedded devices and allow you to share code and still have the really nice optimized experience

 

Thanks for watching!

 

that you can do today.

 

So with this name of XS that you're using,

 

you

 

you're talking about XS dev, have you

 

Mm-hmm.

 

ever thought of naming something like existential?

 

Hehehehe

 

Hehehe

 

And every time we wonder is JavaScript the right answer for this? And it's like, yeah, yeah, we're doing pretty good there.

 

You mentioned TC53. Most people who know about JavaScript and ECMAScript and ECMA know, kind of heard about TC39, which is the committee that's in charge of the evolution or according to AJ, the regression of the JavaScript programming language. Or the inflation, whatever, AJ, you decide. But what is TC53?

 

it.

 

So TC53 is the standards group, the ECMA standards group for defining how JavaScript APIs on embedded devices. So not just IoT, but embedded environments in general. And so Peter is the chair of TC53. And it's been going on for three or four years now, Peter.

 

Yeah, it sounds about right.

 

Yeah.

 

Yeah,

 

And so

 

we, go ahead.

 

we're not trying to add new features to the language. We're just trying to define, again, a standard for other people to implement on their various environments. And moddable or XS, really, being one of the first environments to meet that standard. And there's one published version of ECMA 419, which is the actual specification.

 

So this confuses me a little bit because before Peter you said that you were able to effectively implement the entire ES 2021 standard into your excess engine But now so so if you're just able to implement the entirety of ECMAScript as defined by TC 39 Why do we need another standards body?

 

Mm-hmm.

 

sit in on the TC39 maybe and tell them, hey, you are looking to add this feature or that feature into the language, but that really doesn't play nice with embedded environments. Maybe you should reconsider.

 

Yep, great question. So maybe a little bit of the evolution of TC53 or how it kind of came to be is helpful here. So, god, it was a while ago now. A few years back, Patrick Sokay and I were asked by Brendan Icke, the guy who created JavaScript, to come and present what we were doing at TC39. Because he was like, this is really cool. It's insane that you have JavaScript running on these little devices, and the committee should understand that. So Patrick and I went, we were thrilled and terrified to be invited, but we went and did the talk. And the committee was very nice, despite our fears. It was really fun in retrospect. But at the end, we sort of closed by saying, look, the reason we're here is we think JavaScript is awesome. It's really good on embedded devices. And we just kind of want to encourage you guys to keep it that way. stony silence in the room, and then one guy, who has since become a friend, leaned back in his chair, and he said, well, we don't know anything about that. And then he paused, and he goes, but you guys seem to know something about that. Why don't you join us and help with that? And so we did, which, so we consider Modable's presence at TC39 just to be, to kind of make sure that the language stays viable But the second part of that is JavaScript, ECMAScript, does not define anything other than kind of compute stuff. You know, all the, AJ, like to your question, all the stuff about how do you make a web page, for example, or how do you talk to a WebSocket server. That all comes out of whathg, for example, right? So totally different standards body. And if you look at all these different domains where JavaScript is used, groups of people who are defining the APIs for that. So the language committee sticks to the core of a language, which I think is great. And then there's domain expertise making different standards for APIs that build on the language. And so TC53 was set up to do just that for IoT. And kind of based on some interesting provocative questions by, or observations by Rick Waldron, who was one of the people behind J5, we focused the initial work on I.O. So how do you talk to IOT hardware? How do you read a button? How do you turn on an LED? How do you talk to a sensor? This is all the stuff that's kind of roughly analogous to what you do in Arduino, but instead of doing it in C, we want to do it in JavaScript, we want to do it in a standard way, a vendor neutral way. And so TC53 kind of complements and builds on what TC39 does. And occasionally we do kind of come back and say, hey, we're working on this, or we see a challenge here, we see a need here. And so, being part of ECMA, that's a really easy conversation to have. So that's kind of how TC53 separates itself from TC39.

 

Can you give a concrete example of one of the things that you've worked on specifically in that committee?

 

in TC 53.

 

Yes, yes, please.

 

Yeah, Nick, you want to take that?

 

Sure. So as Peter was saying, the original specification of the original draft that was published last year was focused on how do you talk to sensors, how do you talk to different sockets. So the hello world of a lot of hardware projects is usually like Hello Blinky or Hello Blink. And just like, how do I make a light turn on? Because it's a great bit of feedback in the same way that you have console feedback when you initially start with some sort of programming language. So with the specification for ECMA 419, you can, there's a class that you can use, and it's all class-based, and there's the specification talks about like why classes, why some of the ways that we talked with events and event registration and emitting. And you can tell like, here's my class, here's the port I wanna talk to, which is usually some type of pin that you're talking to on a device and that pin, or even could be like, embedded LED on the device itself that is hooked up to some pin number. And then you can tell it, here I want you to have this value, if it's analog or if it's digital. You can say, all right, one or zero, one or zero. And then I'm blinking now. And it's the very bare metal as much as possible, so people can build greater abstractions on top of it. So like I was saying before, J5E or Johnny-5-embedded is building on top of ECMO419 to provide a little bit more, I'll say, intuitive to people who like jQuery or Johnny-Five, the full version. You can just have built-in blink methods, and you can have ways of adding animations to LEDs and all that type of stuff. So that's just one example of how you can take the originations and specification for ECMO 4.9 and build on top of it yourself. And some of the more recent conversations that are near and dear to the work I like to do, and especially with IoT, is how do you hook up to Wi-Fi? internet and all these different protocols that are available to IoT devices like MQTT, Peter brought up web sockets. There are all these sort of ways you can talk over UDP or TCP directly, and those aren't necessarily built into JavaScript the language. We need to find some way for people to implement that on their various environments because ESP8266 has a different way of doing it than the ESP32 versus the new Pico W just came out, which might have its own different way to the radios that it has for starting to talk to sockets for Wi-Fi and Bluetooth and all those sort of things.

 

So it seems to me that you're dealing with lots and lots of APIs and means to interface with various external devices and communication protocols and whatnot. It kind

 

Exactly.

 

of brings to mind, I don't know if there's any potential overlap between the two, but it kind of reminds me of a conversation that we had with Thomas Steiner from Google about their project Fugu, which I guess the constraints are very, very different. It seems like there's a certain amount of similarity in the objectives of getting JavaScript to talk to stuff.

 

Yeah, it's an interesting point. So for folks who don't know, and to make sure that I'm talking about the same thing as you are, Dan, Project Fugu is kind of like Google's initiative to add JavaScript APIs to the browser that can talk to different capabilities on the computer. And so they, for example, they have a Bluetooth API in JavaScript. They have a web USB. They have a serial API. There is some overlap. And the part of what TC53 has been thinking long and hard about is, how do we kind of coexist with those things in a nice way? And so the serial one is a good example. First, you have to remember that a computer has, if you say, like 1,000 times more memory and horsepower than a typical embedded device, you're And so the design point is so different between these two things that you can't just say, hey, we'll do what Google's doing. That'll work perfectly. We can't emulate the web and run well on these devices. So of course we have, as part of the work we did, we have in ECMA 4.19, we have a serial port, or a serial class. And conceptually, it's functionally equivalent to what Google's doing, but it's much lower level, offering much lighter weight in terms of the way that you use it. But we did things like where to ease developers' mental burden, where there were similar functions or similar properties, we chose the same name. So we just followed Google and used their names so that you didn't have the same concept go by different strings and be unnecessarily confusing. And then we also have done, I don't published, but I know we wrote it. We actually did a wrapper of the ECMA 4.19 implementation that emulates a big chunk of the Google implementation from Project Fugu so that if you have the memory and the CPU and you want compatibility at the API level, you can have that. But if you want to work closer to the metal, you can do that. And that's a pattern we've been following with work in second edition. So Nick and I both mentioned network calls like WebSockets. And so the second edition will include a WebSocket class, which is ridiculously efficient and low level. I'm very happy with how it's coming together. But of course, it's a new API for doing WebSockets. And web developers know the WhatHG HTML5 WebSocket interface. And so we did an implementation of the WhatHG WebSocket using the ECMA 4.19 WebSocket. And it uses a bit more memory. It uses a bit more horsepower. But that's a trade-off you can make if you want the API compatibility. And so we're really trying to build things in a way that is aware of the web, that creates a path to the web, but that doesn't burden people who are concerned with making the most efficient possible embedded device that they can. And as consumers, as users and purchasers of those products, because when those devices are lighter, they're also less expensive. And so when you get to mass market stuff, these things really matter. And so when people say, oh, let's just add like, a ton of RAM and a ton of storage, you add five bucks to the cost of goods, which adds 20 bucks to the cost at retail, and all of a sudden people are like, this product is ridiculously expensive, who's the fool who made it? And so you really have to kind of look at both sides of this. And I'm really happy with the balance with input from people like Nick and Donovan who have very real world experience on the web.

 

So if I can take it, sorry go for it.

 

One of my favorite implementations

 

you

 

that has happened in recent discussions at TC53 has been the application of the Fetch API on top of this draft that is being put together for all the networking protocols. So the underlying Wi-Fi, or not Wi-Fi connection, but the network requests and TCP and then HTTP requests. So built on top of those bases, I think it was Patrick and Peter have put together the actual Fetch So now when we have fetch on these embedded devices, we have fetch on all these server environments. We have fetch in the browser. It's full stack fetch everywhere now if you choose to opt into that API and have some sort of solid API documentation. If you're just like, all right, use fetch to opt to my remote service, you can kind of do that in all these different environments now, which I think is pretty great.

 

So if I can take it in a practical direction for a minute. So I can think of two really practical scenarios. Well, I'll call them practical. One is I have this idea. I'm going to do a Kickstarter. I'm thinking, hey, it'll be great if I can implement this. I have this great idea for an IoT device. It would be awesome if I can develop it in JavaScript instead of having to learn and use some other programming language. So how do I go about it? my use case. The other one is, hey, I'm a hobbyist. I know JavaScript. I have lots of smart devices at home. I have various ideas about how some of them could work better. How can I start using my JavaScript knowledge to be dangerous? So, you know, pick which one you want to answer first, but, you know.

 

Nick, why don't you take the second part?

 

Yeah.

 

That seems like something you do, and then maybe I can follow that up with kind of the more product-specific parts.

 

Yeah, I think you definitely have more experience on the product side of things. Um, yeah, I mean, again, I come from the hobbyist side for sure. I've been tinkering with JavaScript on devices. And one thing I talked about at the JSConf Budapest talk, which is now online, uh, is I built like, uh, my own clapper, if people remember that product. So like clap on, clap off. Um, except it was, you know, IOT rather than just being plugged straight into the wall. So I had, uh, had it hooked up to HomeKit, various other integrations. but it also just talks on my local network. And that felt really good to be able to take that. And I have since implemented it with Excess versus on the TESOL, which was the original environment. And I also have an on-air light and things. So, you know, there are places you can get these boards moddable themselves have these dev kits you can use as well. But, you know, you can buy an ESP8266 that has wifi connections or wifi capabilities on it for a couple bucks. And they've developed them boards SparkFun, Adafruit, Micro Center, all sorts of places, Amazon even. And you can, again, we talked about XS dev earlier, plug it into your computer, start running XS dev, even prototype on your computer without running on a device through some of the simulators that Modable provides. So you can just kind of get some quicker feedback before even shipping to the device and starting to get the full peripheral and finally deploying it out to the real world. So.

 

Well, talking about the clapper, that brings back some memories. Clap

 

Oh yeah.

 

on, clap off.

 

It delighted my wife when she first got to do that.

 

Hmm

 

And then we moved, and we had all different situations to set that up again. But yeah, it's nice how accessible it can be. I think the hardest part with a lot of hobbyist stuff with hardware is ordering the stuff and waiting for it to arrive. And I think being able to prototype out of the box on your local machine. And there's even a web simulator as well, which is pretty awesome. compiling the excess and all that stuff towards Wasm and having it execute in the browser. And so there's all these sort of places to just get your feet wet before even you have hardware locally and sort of experiment with some of these APIs and then deploy to an actual device and get into that. You don't even have to know how to solder or anything. I don't solder really any of my projects. We just put them on breadboards and then stick them to a wall or wherever I'm putting them. And that's pretty much how I get started. Peter, you can talk a bit more about the product side of things.

 

Yeah, thanks. The hobbyist side kind of leads directly into the product side. I mean, so many products start out as an idea, they start out as an experiment. And one of the great things about especially the ESP32 ecosystem, which is one of the microcontrollers that we really like, is, as Nick mentioned, you can get a board for as little as a couple bucks, but you also can spend, one with a really nice e-paper screen, or 60 bucks and get one with a really nice screen and an accelerometer and a speaker. And so there's literally hundreds of different ESP32 boards these days. And so you can often just find one that's a good starting point for your product and kind of just start programming those things in JavaScript. And we've even had designers at companies go out and order our dev kit and use it to prototype a UI interaction in JavaScript directly on the device, just to kind of get a feel for how that would be. And so people can grab a DevBoard, start building, and prove out a concept, get a demo working. The cool thing is that when you're doing that in the Modable SDK, you're doing that with JavaScript, that kind of experimental code just migrates directly into production code. And so you don't hand that off to somebody code in C, who then tells you that they can't possibly do what you did in JavaScript because it's C, don't you understand? But there's some other really neat things. We have a customer who's delivering a battery-powered product on an ARM processor. And it took them six months to get the first boards back. But we built the entire product on an ESP32 for them. And it worked, and we could test it. to tweak the UI, we could do everything they needed. Then we got the boards back, we were able to bring up the same software in a matter of days. And that was thanks to standards. That's because the JavaScript language was the same, that's because the APIs to talk to the hardware were the same. And that may not seem like a big deal coming from the web where interoperability is the norm, but in embedded, each manufacturer for how to talk to everything. And so just because you can turn on a light, or read a button, or write to serial, or talk to a sensor on one part, doesn't mean you can do it on another. You basically have to rewrite all that code. And so one of the really cool things that people are going to get from the standards work that we're doing in TC53 is that they're going to get portability out of their embedded code that they've never had before, that they can literally move their JavaScript code across processor and get the same results. And that's game changing, where people can get locked into a given silicon provider for years or decades, or can have to halt production because of supply chain issues and they can't get a part for 18 months. And so portability really changes things from a development perspective for firmware, and the standardization work that we're doing is really what makes that possible.

 

That's amazing. And, and keeping up with my practical questions, how do you debug?

 

I mean, debugging is pretty great, actually, compared to some of my past experience trying to debug embedded devices, given that the Modable SDK comes with a GUI debugger out of the box. So when you deploy or push code out to a device using the Modable tooling or XSDED built on top of the Modable tooling in the debug mode, it'll actually just pop up the debugger right away and allow you to start tracing memory profiles and network usage and all sorts of statistics and have a console to work against as well. It's not necessarily like you're going to, I think, put instructions back to it. You're not communicating with the device. It's just communicating with you. And so you can start looking at like put your debugger in if you want to do it that way or just start putting out traces as the API in the moddable environment or on access versus console.log. Same thing, sort of. You just set out some logging and start monitoring the feedback there and seeing, all right, what's going on? I will sometimes log before I've connected to a Wi-Fi device, after I've connected to a Wi-Fi device, during various states of the connection periods or of the application that's running. And although I haven't done too much debugging to a screen yet, necessarily, as Peter was saying, buy some devices that have touchscreens or just regular, e-paper or LCD screens. And so there's probably some logging and debugging you can probably do there, too.

 

So that gets me to another practical question that I have never understood or seen, is we're talking about running JavaScript on a little Raspberry Pi or Arduino or whatever. How do you do that practically? What are you doing? Are you connecting the device to a computer, and there's a UI that comes up, or some sort of IDE that you can code in? Or where are you actually writing this code, and how is it so that it's on your IoT device? Because I'm assuming you're not connecting a monitor Raspberry Pi in a keyboard and encoding directly on it or something like that, right?

 

No, thank goodness. Yeah, or you can use your own development environment. I use Vim. So I just write my programs in Vim and then run one of the commands for if you're using moddable directly, you can use it's mcconfig. Or if you're using my CLI, it's just xsdev run. And then it'll run the local project that you have onto the device. And you can specify which either on the debugger the local simulator or you can specify a device target. And I connect over USB. So it's connected over USB to my computer. And then I can list out the various devices connected to my computer using Exist Dev List, which just kind of abstracts over all of the individual tools that will display all the connected devices you have that will be a target for either the Espressif drivers or the Raspberry Pi Pico. In the past, for Tesla, that was kind a big thing, you can actually deploy wirelessly after you've connected it once and given the device your SSH key, like your public key, then you could deploy wirelessly on your local network. And that would allow you to just have devices out in the field and then push new code out to it as long as it was connected to your same wifi and was discoverable. There are ways to do over the air stuff with the moddable SDK. I've seen some examples, I've never tried it myself and I'm not sure how much Peter suggests folks doing that right now at least.

 

So you're copying the code from a base level standpoint. Are you copying the code to your computer, writing it, and then pushing it back, sort of like the old school FTP, to a web server type of thing? Or you're actually accessing the code directly on your device?

 

So as Peter was saying earlier, the tooling that modelable drives, at least for XS, is that it will compile your code locally and then turn it into bytecode and then deploy it over USB, usually serial, to the device and then start running that program. So it'll flash it over is usually kind of the term for a lot of the hardware programming. Am I missing anything there, Peter?

 

So then you're programming

 

you

 

against a simulator on your computer to see how it would run on

 

Yep,

 

there?

 

you can.

 

OK.

 

Depending on what you're using, there are certain simulator environments for having a screen or having buttons. And I think they're slowly adding more and more simulators to alight it, kind of prototype more peripherals available to it, or even some of the networking APIs hooking into the native operating system APIs for certain HTTP requests and things like that.

 

This really reminds me of some of the experiences that we discussed with people talking about developing using JavaScript for various cloud-based platforms, like various types of workers and edge computing and stuff like that, where you run things in a local environment which simulates the target environment, and then when you think you're ready, you kind of push the code, out to production for you just in the case that you're describing instead of sending it over the the internet to some cloud-based server or whatever you're sending it across a physical wire to an actual IoT device but the end result is kind of similar and it seems that even the debugging experience is kind of similar.

 

Yeah, it can be. I remember just remembering back to the days of working on Pebble, they had a cloud IDE that

 

Thanks for watching!

 

you would use to prototype, and it had a simulator embedded there. And then you could ship it over online to your local. It would ship it to your phone, which would then deploy it over to your watch while you were working in that environment. And that was very interesting to me. I always wished I could do it locally, set up, they're using Cloud9 at the

 

you

 

time as the base layer and then built on top of that to provide their

 

Hmm.

 

programming environment with feedback for their SDK and all that sort of stuff. Right now, so one thing that's interesting that's been happening is the inclusion of TypeScript to deploy to XS as well. And so it can give you a bit more of that feedback. Some folks look, and one thing I enjoy about using TypeScript in my day-to-day work is that rather than having a full blog an ID like you might have for something like Xcode or Android Studio and things like that, you can still choose whatever editor you want, but then having TypeScript feedback and typings for all the different APIs and it being open source, people have contributed typings for the ECMA 419 standard and all the other sort of SDKs provided by Modable and give you that feedback and help you feel a bit more confident before pushing code over to the device and longer feedback loop than most JavaScript developers are used to.

 

Isn't TypeScript support just basically having the DTS files for the relevant APIs? I mean, at the end of the day, TypeScript gets compiled into JavaScript. And if you have full support for JavaScript, it would seem fairly straightforward then.

 

Yeah, I mean theoretically, yes, the devil is in the details. There's

 

Always

 

a couple

 

is. Ha

 

of

 

ha

 

things.

 

ha.

 

I mean, there's a couple of things we do that make it easier for developers. One is that somebody has to convert the TypeScript to JavaScript. And we've integrated TypeScript support into our build system. So whether you use MC Configure, you use Nix, dev, you can just throw TypeScript files into your project, and they'll run on embedded because they'll be automatically converted. And before we added that to the Modable SDK, we had a few hardy souls who were using TypeScript with the Modable SDK. But everybody else just considered it an exercise left to the reader that they weren't going to tackle. At this point, based on just kind of the questions and the things that we see going on in the community, developers are using TypeScript right now. It's crazy popular. It really has taken root. The other thing we do, which is a big deal, is debugging. So transformed TypeScript to JavaScript is similar, but not the same. And in the excess JavaScript engine and through the full tool chain, we implement support for source maps. And that means that when you're debugging your TypeScript, you see your TypeScript source code and not script. And that's one of those things that's completely magical, but behind the scenes is just a total headache. And so we're thrilled that developers are using it and like it, but it really is one of those tooling things that is a real commitment to maintain and create, but that adds really great value for people because being able to debug stuff in real time versus just console log all your life is kind of a game changer.

 

Yeah.

 

We're really committed to TypeScript at this point because it's provided a lot

 

you

 

of benefits, both for our kind of open source community users, but also for our enterprise customers who are working on just huge code bases and really benefit from the static type checking that you see, that you get from TypeScript.

 

One thing that occurred to me when I mentioned the similarity that I saw with some of the cloud-based platforms and serverless and stuff like that, is that it seems to me that you have something of an overlap potentially with a relatively new Winter CG working group. That's the working, that's a community group that's kind of trying to implement a web interoperable runtime for JavaScript, work in edge computing and devices that are constrained in other ways. So since you're focusing on constrained devices and they're focusing on constrained devices, it seems to me that there's a lot of similarity or potential for similarity there. Is that something that you're also looking at?

 

Yeah, Donovan Buck, who is another member of TC53, brought this up to the committee. And actually at the, I think it's at the OpenJS Foundation, I'm really bad with conference names, but at a conference recently in Austin,

 

OpenJS world.

 

Donovan and I, OpenJS World, thank you, Nick. Donovan and I attended a talk by James Snell, who's the driving force behind Winter CG, or one of the driving forces, and talked with him afterwards about, whether there was an openness to us getting involved. We got a really positive response. And so we're starting to kind of look at what that might mean. Actually put together a lengthy issue at James Request on the WinterCG GitHub, kind of outlining all the different APIs that were relevant to us from the web universe. Things they're working on as fundamental as like, standardizing that across environments. Things like fetch that Nick mentioned. And there's other things which actually are interesting for standardization that are a little bit in the future for them but that matter to us, things like W3C sensors. We work with sensors a lot. There's actually a standard API for sensors in the browser. Why not extend that as part of the Winter CG effort over time? So I think what they're doing is great. when they can apply their knowledge in more places, where they can reuse that. And so we're really interested in kind of seeing how that evolves. We definitely are bringing, just like we bring a perspective to TC53 about the language, a different perspective because our high order bit is severe resource constraints. I think that's sort of what's novel about us because they are generally looking at more kind of server and computer environments. And even when they talk about Edge, it's more like a Node.js or a Dino powered Edge device, not a little microcontroller. But I think it's great what they're doing and happy that they're open to having us get involved because I think it will just make JavaScript programmers in general more powerful by being able to apply their knowledge in more places.

 

That's awesome. I know that we are kind of starting to near the end of our show, but there's another thing that I wanted to ask about, at least briefly. One of the things that simultaneously the boon and the bane of the JavaScript community is NPM. On one hand, you've got functionality readily available to do essentially anything. On the other hand, entire JavaScript ecosystem downloaded onto your device. So I guess that it's even more delicate in your scenario. Do you even support NPM or some sort of a subset? And if so, how do you bring some sort of sanity and control into it?

 

I mean, that's, that's a big point of discussion right now that Peter and I have been having and, and, um, mostly through the kind of how XS dev can facilitate that, um, cause yeah, moddable and the SDK don't have any sort of opinion necessarily around it. Um, in terms of like supporting it, you'd, there's a manifest file that, um, moddable projects have, uh, that defines like, here's all the files that will be part of my project. And you kind of almost think of it as import maps in ways as well for defining like almost bare module specifiers for saying like, all If I import from RGB, then it's pointing at this file. And you can do that as well for things in your node modules if you wanted to, or a get sub module, or however you want to pull stuff in. Nothing's stopping you from doing that, except that the third party module itself would also need to have a manifest to define all the files that it wants to bring in for all that or all of its imports as well. from Donovan again, has shows a couple ways of pulling in his project to use for your projects in terms of either downloading source code directly and put it into your project and then pointing at his manifest and having the build incantations for all that type of stuff, as well as using npm to download it in the point at the node module folder for his manifest. And so that's something we've been thinking about because, like you said, Dan, npm is so ubiquitous. And so I was depending on it for saying this is the way to pull in third party modules for the excess dev workflow in a way, because it can grow and grow and grow and becomes harder to say, all right, why won't this build now? Because someone else added a new dependency, now my product's too big. And so I think there's going to be a lot of parts of education to say, how do we tag certain packages to say they're ready for working in this environment or that they're ECMO 4.1 standards and all that type of stuff? But I think it's just a lot of prototyping in that case. I think NPM is still big enough and ubiquitous enough and still so in standard to a lot of ways people work in the JavaScript ecosystem, even outside of JavaScript ecosystem. I know there's a WASM packages that go through NPM as well. It's just a general registry that I think using it in that way with certain conventions can be really useful and helpful for folks. constantly repeating the same code or having to use things like get sub modules or bringing down and vendoring the code themselves, which is always an option, but then makes it hard to stay up to date and have the latest updates and testing and features that they may want and are used to working with. Yeah, it's a tough call for sure. I mean, Peter's work in more production environments and I don't know how they manage all that stuff or if it's all just invented in-house and they just have common patterns that they over to various projects. I don't know, Peter.

 

And I mean, NPM is a tricky beast. I mean, I think the way that Donovan's using NPM and Nick described is basically a way to distribute libraries that work on embedded is great. But there is a huge kind of potential surprise because, of course, a lot of stuff in NPM will not work on embedded because it has dependencies that aren't there or because of its resource requirements. there's room for developers to kind of run into an unpleasant surprise when they try to use NPM in general. So we haven't kind of made it easy to use NPM as part of the moddable SDK because we don't feel like we have a way yet to make it safe. And so people are kind of doing it ad hoc. We'd like to solve it. Nick's got some good ideas there, and other folks have as well. We do have in our commercial work Clients who use modules from MPM as part of their products, and in some cases, from my perspective, a shockingly large amount of code, but it completely works for them, and so great. And again, that's a real testament to the work of TC39, that that JavaScript language that was written for Node without even a thought about embedded actually just runs, because test 262, which is the test suite for language conformance, we run on embedded the exact same tests that they run for the web. And so we really know that the language is the same at that level. And so to even be talking about NPM interoperability, it takes, it's a huge leap because we've gotten, it says a lot about how standard we are and what we're able to do in embedded that creates an on-ramp for web developers to become embedded developers too.

 

All right, so as Dan mentioned, we're going a bit along here. But before we head to PICS, Peter, I wanted to give you real quick a chance to talk about Modable. I know we've talked about Modable and the Modable SDK and so on. But I would just give you a chance to call it a shameless plug here early, talk

 

I'm

 

about

 

sorry. I'm sorry.

 

Modable, who you are, what you do, that kind of stuff.

 

Yeah, totally appreciate it. I will try to keep that short. You know, we're basically a startup in the Silicon Valley. We are nobly self-funded, so we exist because we have clients that pay us, not because we have giant investors, and that keeps us incredibly responsive to our client base.

 

It's amazing

 

Yeah,

 

how that works, isn't it?

 

you know, it comes with its own challenges, but it really keeps you focused. are incredibly committed to openness. So all the work that we do, we publish as open source. A lot of the work that we do for our clients, we publish as open source because they will say, oh, we need this new feature or this optimization or report to this silicon. And we invariably structure the deal so that we can then publish that out to the community. We consider the open source community just like another client. We get great ideas there. We interact with, we have feedback and we love that. And so, you know, we're happy to engage with people, both kind of on the public front and as a business, where sometimes we'll do projects as small as, hey, wouldn't it be great if you had this optimization in your engine, and we'll do that. Other times, people will show up with, you know, a piece of paper with a sketch of a product, and we say, will you build the software for us to do this? And by the way, do you have a hardware reference design? And we'll do that too. problems on embedded. We love where performance is key. We love where screens are involved, because we think users interact better when they can see a screen that shows what the device is thinking. Security is really fun. And low cost is really probably the greatest challenge of all, which is kind of a balance of all those different factors. So yeah, that's the shameless plug. If you're building embedded stuff, take a look at what we're doing. And if you need a hand doing it, we're here to help.

 

Yeah, the blog is also really, really great too, for various project ideas and ways that you can start putting stuff onto embedded devices. And I think one of the big things that every time Peter mentioned light bulbs that just maybe chuckle is the actual blog post about them programming a light bulb with XS and making it controlled through their own code, which is really fascinating. We can see some of the constraints that they ran into as well.

 

There

 

Excellent.

 

was definitely some soldering

 

I have

 

there.

 

to say that the concept of running JavaScript in a light bulb brings me lots of joy for some inexplicable

 

Yeah.

 

reason.

 

Thanks for watching!

 

Yeah, it gives new meaning to the term and a light went on, doesn't

 

Yeah,

 

it?

 

Mm-hmm.

 

yes it does.

 

So, all right. So thank you gentlemen for that. No, actually pun intended that very enlightening conversation on

 

Ha

 

JavaScript

 

ha.

 

and IOT. So with that, we'll move to picks and let's start with AJ.

 

Uh, let's see.

 

AJ was obviously prepared.

 

I've got. Yeah. Well, first of all, I talking anytime we're going to bring up TypeScript, I want to bring up the fact that you do not need TypeScript at all to get all the benefits of having strictly type JavaScript. JavaScript already had types before jobs before TypeScript came along. TypeScript gives us tooling to take advantage of those types. You don't have to reinvent the wheel or create a new language to get good tooling around the thing that already existed. I'm linking to the JS doc typescript starter that I created because it's not, the problem is not intuitive how to do this, right? It's not intuitive that if you want to have the simplicity that JavaScript affords you, that you can get all the benefits that you want from strict typing. Just, it's already,

 

I'm

 

it's

 

going

 

there,

 

to

 

you

 

interrupt

 

just need the

 

you

 

tools

 

for

 

for

 

a

 

it.

 

second AJ and remind

 

So,

 

you that we actually had

 

yeah.

 

Gil Tayar on episode four eight nine to talk about the beauty of JS stock and how you can use JS stock to get typing in, in JavaScript without TypeScript.

 

And I still need to actually listen to that one because I wasn't on that one.

 

Yeah, you weren't.

 

But I would love to hear his tips and tricks as well, because there are a couple of things that I, because TypeScript is designed around the concept of C-sharp, there's a few things that don't quite map well to JavaScript. And so things that are really intuitive and obvious in JavaScript aren't necessarily

 

Yeah.

 

carried over, like returning an object

 

Thanks for watching!

 

with functions from a function that requires kind of a non-intuitive syntax with this at type def function, in just about any examples you look at, some stuff like that. But

 

No,

 

were you going

 

I'm

 

to

 

just

 

say something

 

saying

 

else, Dan?

 

that that episode is definitely worth a listen. And I won't kidnap the conversation. I'll just say that there is a certain difference between how TypeScript started, which is very much influenced by C Sharp, and where TypeScript is today, because the JavaScript community bought into certain patterns and didn't buy into certain other patterns. So it's not necessarily as close to C Sharp to be. But that's a whole different discussion and not one we have time for right now.

 

Yeah, so I will, let me see if I can find a link to that real quick, what number did you say that was? 416

 

489

 

did you

 

it's

 

say

 

better

 

416?

 

when I speak when I'm not muted

 

4 4 8 9 oh Yeah

 

Well, that's a matter for debate sometimes,

 

Hahaha!

 

but we won't go down that road.

 

Yeah, okay. So I will link to that one as well. And then also for it. I wear glasses and I finally got a four wheeler. And so I needed some goggles that would fit.

 

you

 

And There is the Oakley L frame. Has little slits in the side of the goggle. That will fit glasses not large glasses, but medium or small glasses not not necessarily hipster glasses, but just kind of glasses that the average person would wear will fit them pretty decently

 

Ooh, you just piqued

 

well

 

Nick's interest

 

and

 

there,

 

so.

 

Mr. Hipster

 

What's

 

Brown.

 

wrong with hipster glasses, man?

 

I was going to say, Hipster Brown is all,

 

Well,

 

it's his thing.

 

because if they're if they're really big, you know, and they they come up against the foam of the goggles and they're not going to fit in right. So or if you've got a really big head and you got glasses that are extra wide. So these are the glasses that I normally wear and these are actually meant for a head that's just slightly wider than mine by about half a centimeter. But you probably can't tell when they're on me because my head is only at least smaller than what they're intended for. Um, but these that no one listening

 

Thanks for watching!

 

can see these do not fit in those, but I got a few pairs from, I guess I might as well just mention. I can't even remember their name. There's an online glasses company that you can, you can literally get glasses for the whole thing for, for 10 or 15 bucks. dollars of shipping so you might you know just buy three or four different pairs and different styles what is any Zenny that's what it's called Zenny so you can get I mean good-looking prescription glasses from from Zenny and what I did was I got the nicest looking pair that I wanted and then I also got just some super cheap ones to have as backups and that's what I I use for my writing glasses is one of the super cheap pairs that's a little bit So I'll pick I'll pick Zinni as well anyway, so the Oakley L frames and Zinni and JS types those are my picks

 

Excellent. Dan, what do you got for us?

 

Okay, so I've got a few as well. So my first pick is the fact that I've got accepted to speak at the Web Directions Summit Conference in December. And what's really cool about it is that it's in Sydney, Australia, and I've never been to Australia. So if you happen to be in Australia in the beginning of December, then I would recommend me and meet me there and we can chat about JavaScript and web development and stuff. So that would be my first pick. My second pick is we're watching the unfortunately the final episodes of Better Call Saul, what is a strong candidate to be the best show on TV that I've ever watched. It's amazing. really sad that it's drawing to a close. On the other hand, it just keeps on getting better with each episode, so it's kind of great. And I can't recommend it highly enough. Obviously, if you haven't, you need to watch Breaking Bad before you watch Better Call Saul. So if you've watched neither of them, you've got something like 12 seasons ahead of you, but it's just amazing television, in my opinion.

 

Now isn't Better Call Sol a prequel to Breaking Bad?

 

It's effectively a prequel, although we are at the point where it's kind of, it's both a prequel and a sequel in a kind of strange

 

Hmm.

 

sort of a way, and now we're getting to the point where it's finally also concurrent. So

 

Oh.

 

it's kind of building in from both directions at the same time. It's really kind of interesting the way that they did that. Breaking Bad before watching Better Call Saul to get the full benefit and My final pick is going to be that same pick that I pick every time which is the ongoing war in Ukraine which is just keeps getting worse and worse and and unfortunately, we're all kind of getting used to it and and that's really unfortunate in this context because it needs to be on our minds so that you know anything that we can do to help the situation we should and those would be my picks for today.

 

Excellent, I will go next and leave our our guests I won't say the best for last because that's the dad jokes, but I'll leave them for last. Let them have the last word. Interestingly enough, we're talking about IoT and I mentioned Arduino. I saw a article on Hacker News and knowing nothing about Arduino or IoT I'll throw it out there anyway. It's from the Arduino blog and it talks about introducing multitasking to Arduino. So they're looking to do some work to handle multiple tasks simultaneously because it's needed more now than before apparently. Either of you guys have any comments on that? Just out of curiosity.

 

You know, a lot of the, I mean, it's great they're doing it. A lot of the microcontrollers have multiple cores. As Nick mentioned, we support web workers. And so a lot of our projects actually is in our commercial work are using both cores in parallel by using web workers. And it's awesome. Let's you do a whole lot more, especially when you're building like UIs, it stops, you know, just like the web, it stops you from blocking the UI when you've got stuff, other work to do. So good to see

 

Excellent,

 

they're doing that.

 

good. All right, so on to the dad jokes of the week. Let's see, first one here. Now, question, if Wonder Woman and Spider-Man started a business together, what would they name it?

 

What?

 

Amazon Web Services.

 

Hehehehe

 

That's good.

 

you

 

I like that one.

 

Crush franchise,

 

Yeah,

 

that's

 

actually

 

pretty good. Yeah.

 

pretty good. Yeah, I mentioned AWS, but I didn't get your love on it. So I don't know if they liked it or not. So the other day I was talking to my wife and I said, you know how you talk about someone seeing the cup as half full or half empty? So I said, do you think the cup is half full or half empty? And she said, please, could you stop wearing my bras?

 

Oh man,

 

Get it?

 

but

 

Cup.

 

I have to give you one in return. They say that an optimist sees the cup as half full and the pessimist sees the cup as half empty and the developer says, well, you just could have used a smaller cup.

 

There you go. and give you a rim shot for that. And then finally, so we all talk about as developers, we always talk about side hustles or things like say, moddable, where people start up your own business. So I decided I'm gonna go down that route and I'm trying to start up a business that recycles discarded chewing gum, but the problem is I just need help getting it off the ground. Yeah, that's one to chew on there for a while. So,

 

Oh.

 

okay. Moving on, Nick, do you have any picks for us?

 

Sure. Something I mentioned earlier and the place I was actually at this past weekend is a place called Micro Center, which is still a physical store but also has online ordering for all sorts of maker projects, electronics. It's kind of one of the places I go to to explore and see what they have and maybe inspire some ideas for various projects. And I still like being able to go into a physical store and see some stuff. And they often have some really good deals on boards that might be kind of a shortage shortage, chip shortage affected also Singapore computers, especially Raspberry Pi, you might find some in the store that aren't seen online and without paying scalper prices. So still enjoy going to do that. So it's just finding your local micro center or just checking them out online. And then,

 

Interestingly enough, MicroCenter.com. Brilliant

 

yes.

 

naming.

 

And we're talking about IoT stuff and something I just moved into my house a couple of months of the things that was on my list was setting up a security system. Um, and so I've been really happy so far with the abode security system, um, which has a pretty good balance of professional and do it yourself sort of set up and monitoring. So it has an optional, um, subscription service for professional monitoring, but you don't need it in order for everything to

 

Thanks

 

work

 

for watching!

 

together, which is really kind of big for me. Um, and it has a lot of local first integrations, and also integrates really well with HomeKit, which I use for my smart ecosystem. and also integrates with other devices over Z-Wave.

 

ماشنه او بایش از از سنوشه کن

 

So I've been really happy with it so far, just getting

 

درموشه کن

 

started with it, but it's been really helpful.

 

اومد

 

And so that was been a good one for me. And along those lines, I kind of want to pick the matter standard

 

Bye.

 

for connected devices, also formerly known as CHIP, something I've been keeping an eye on and should be coming

 

you

 

out and being published. We're talking about standards today. And this is hopefully an actual standard home and trying to be local and encrypted first with the option to speak to the wider internet through what they call border routers. So if you

 

can invest in thread devices these days, I would go for that and you might just have matter support when that comes out. And I'm very excited and I hope it doesn't become that XKCD comic about yet another standard.

 

 Nick_Hehr:

And days.

 

Uh-uh.

 

Oh yeah, I was thinking about that cartoon earlier

 

So.

 

when we were talking about adding something

 

I

 

to

 

was

 

that.

 

expecting you to say, my new home security system is powered by JavaScript. This is my home address. Bring it on.

 

Yeah, no, not that daring

 

I

 

yet.

 

was gonna say, I think that really matters too.

 

Yeah Hey

 

So how do you get see that I'm very interested in having a home security. I don't want it connected to the internet because I don't want anybody to just be able to hack Amazon sidewalk or whatever

 

Mm-hmm.

 

they call it and then get into my house, which inevitably is going to happen and actually already has happened didn't Amazon had their ring devices were hacked and then people could open doors that way and then didn't they have another hack?

 

That's one reason I don't use those devices.

 

Yeah, so so I I'm more interested in cameras than in the motion sensors or stuff like that because you you want to get something to give to the police if somebody's already in your home, you kind of you know, it's game over

 

Right.

 

at that point. But so what are devices that you would recommend? Are there any brands that are implementing this or because I mean basically the only thing that seems even close is Ubiquiti Unified.

 

So this is one of the big topics in what I was discussing for my talk at JSConf. Budapest was offline for a tie of teeth. It's something I look for in everything. And something that Matter actually covers is Matter over Wi-Fi to cover things like cameras because the bandwidth for thread. So Matter is the... 

Well,

 

is

 

what

 

the...

 

is

 

Matter is the...

 

what

 

Matter

 

is

 

is the... Matter

 

matter

 

is the... Matter is the... Matter is

 

and

 

the... Matter is the... Matter is the...

 

what

 

Matter

 

is

 

is the...

 

the threat are these companies or these

 

Yeah,

 

standards?

 

Matter is a standard for built on top of the Thread network protocol, which uses the same radio as it's a low power radio frequency used for talking to various other devices that use Thread as well. And then can operate, Matter also operates over Wi-Fi for higher bandwidth devices like cameras, as you specified. And then the default behavior for Thread devices, that they only talk to each other can talk to each other on the Thread Network. You don't need a special hub or anything like that. And then the only way to talk to outside of that network is through what they call border routers. And those border routers can be things like a router node, actual wifi router node, like Eero is doing this with their, they have Thread enabled Eero routers. Apple TV can be one. And I, the, whatever the speakers that they have, the HomePod mini is also, can be a border router because it operates over a Thread system is. And then any device within, because this is Google, this is Samsung, this is Apple, this is Home Assistant, this is a bunch of different companies talking to each other and saying, OK, we agree on this. And now all devices that use this standard can talk to each other no matter what ecosystem you bought them from. And then if that company were to go away, then they should still keep working, because they all talk to the same standard. And there's even, yeah.

 

So where would I find

 

So.

 

one? I mean, I get that there's a standard, but where can I get something at Walmart or how would I find

 

So

 

one

 

the unfortunate

 

of these things?

 

part, and why I say I'm looking forward to it, is because it hasn't been published yet. It's been in the works for several years.

 

Oh, okay.

 

But they've published some details and some implementations as well online and on GitHub for, like, here's what a thread or matter device will look like and how to start using it. And then that will help actual device makers and manufacturers to start building that into their devices. Hopefully, this fall, when matter is actually published, we'll have official support for all various devices. why I say invest in thread devices for low power efficient things because they will have most likely have MatterSport out of the box. Some Zigbee devices may also get upgraded later depending on how much memory they need to

 

Thanks for watching!

 

operate. And so these are all like,

 

you

 

again, we've had all these things before where we had Z-Wave, Zigbee, Wi-Fi, Bluetooth, and Matter is hopefully collecting that into a more usable thing for any typical consumer to go see like, oh, it has MatterSport. use this on my

 

you

 

network and not worry about having a separate hub and all these other sort of things. As you talk about cameras

 

See you

 

and things

 

later.

 

like that, one thing I like about the HomeKit ecosystem for myself is that they have a thing called HomeKit Secure Video. As a

 

you

 

part of their way of approving things for the HomeKit ecosystem is saying, okay, if you support secure video, then none of that video leaves your network or can be saved cloud if you want as well. And so the doorbell I got actually has support for HomeKit Secure Video. And there are also things like Home Assistant you can look into that have local first camera support for all sorts of other devices that

 

you

 

don't have to be HomeKit out of the box. And so those are generally the things I look for.

 

I recall there was this website a while back, couple of years ago, that was basically just, they were finding unsecured security cameras around the world, and basically you could watch like the current video from any one of hundreds of thousands of security cameras from everywhere, like.

 

I remember

 

Yep.

 

that. I remember checking that out. Yeah.

 

That sounds so creepy and scary and cringe and all the hip words

 

Yeah,

 

for

 

I would be careful

 

uck.

 

about all the, any sort of cheap IP camera you find online. Cause you're like Peter saying, you're never sure what's running on them and what the default behavior are,

 

Thanks for watching!

 

behavior is. So I'm willing to spend a little bit more if I know like where the origination from that

 

you

 

is, what the history of it is. But.

 

So do you have any specific brands you could recommend that if I was going to go get something today and do you actually trust that Apple is keeping it private because I

 

I haven't been told otherwise. So right now I do. And unlike some of the recent news has come out around ring and Nest cameras are automatically shared to law enforcement without necessarily getting your approval first, which is something like, I'd like to at least know if I'm going to be sharing that information outside of my home and have that choice to do so and. You know, comply with me.

 

And they're being a warrant in due

 

Exactly.

 

process.

 

Which is not part. So right now Apple and many other camera makers have said we don't do that or we end in encrypts. So we have no access to that information. So that is my current trust in that ecosystem. If I had absolutely no trust, I would probably go to the Home Assistant route and set up everything in my home and have never leave my home network and do a lot more DIY sort of work. And so if you go to Homelessness.com, they have a bunch of like the official integrations or Home Assistant IO, one of those. And then their default is local. So all the stuff that they integrate and all the sort of community around that defaults to local first. And then they have a paid company behind it to support the home assistant ecosystem, excuse me. That's like $5 a month for end-to-end encrypted sort of like outside network access. Yep.

 

So with the Apple with the Apple system, I'm going to look into Home Assistant

 

hehe

 

as well. I've heard about that before, but with the Apple system, do you do you know of any cameras that specifically support the security features you were talking about? Because I mean, I see here are

 

Mm-hmm.

 

low and Logitech and I know that those companies they have their own thing where they want you to connect in and log in and share your video with their

 

Mm-hmm.

 

system. So I guess they support HomeKit. I highly doubt that they're, you know, security first. Do you know of any brands particularly that support that Apple security first type of camera

 

Not off

 

access?

 

my head, I don't actually have a lot of cameras because I need to do more research to make sure, same thing, I don't have

 

Okay.

 

smart door locks yet because that's another thing I wanna make sure that I'm doing the right research into and make sure I can depend on it. One thing I talk about in my tenets of offline first IoT is it must have a physical fallback for anything that controls some sort of access or anything like that. So

 

video.

 

if for some reason, Wi-Fi goes out or the battery dies a lock, right? I want to be able to have a physical fallback as needed to be able to still get into somewhere and still have that control. And then from there, it is almost like progressive enhancement for having access to the wider internet or access to the connected network. And that's why I don't always like to call it IoT, just connected devices. They're connected in some way. They may not be connected to the internet or not. And I am very careful about what I expose to any sort of network, including especially things that are connected that are security-wise. So right now, I'm mostly just monitoring door access and then having sirens and things like that and being able to inform local law enforcement if needed to. And so I'm slowly adding things. And so right now, the Abode has its own camera system that doesn't actually integrate with HomeKit. And that's one of my one knock against it until they have it in the Home app, phone. So I'm still looking into a bit more of like which one I trust even if it does support like you know HomeKit out of the box. Yeah,

 

Excellent.

 

it's a scary world out there. You're never sure about what you're letting into your home.

 

Yeah, for sure. Yeah. I've got

 

Yeah.

 

a cheap little ring camera and I've been thinking about replacing that, getting some little more comprehensive and secure for a video and like outside the house and stuff too. So all right, all right, Peter, we're finally to you. Are you still awake?

 

Yes, absolutely.

 

Good,

 

Thank you.

 

good.

 

So I got a couple things to share. We've talked a lot about standards and I know to people who don't work in standards, they can be really opaque and mysterious and one question that comes up often is, you know, how do you decide what to standardize? How do you set priorities? How do you figure out where the right place to go is? web manifesto that at least for web standards that I think and I apply it to IOT standards as well I think is is a really great one it's a it's almost ten years old and it was written by a bunch of people who were leaders in the web at the time and many of them many of them still are but it talks about how you decide they they and a lot of the ideas that we kind of take for granted are really there like they really heavily promote starting from a very place because low-level APIs can then be kind of enabled the most. I think we talked a little bit about Google's project Fugu, which I see is kind of adhering in many ways to the extensible web manifesto. And then that allows a library,

 

you

 

an ecosystem of modules on top of it that provide kind of ease of use and application to different places, so like Donovan's J5e, for example. So, you know, if you're interested in standards and how I think the extensible web manifesto is a pretty quick read and pretty interesting. On a much less geeky front, I like many, many, a surprising number of programmers anyway, also play music. I am a terrible classical pianist, but I enjoy it. So it just doesn't matter if it's terrible or not. Over the pandemic, I started exploring the music a composer named Fanny Mendelson. She was long overlooked, but is getting a lot of recognition these days. Very little was published in her lifetime and she performed very seldomly. But as a result, her music is, I think, wildly experimental for romantic era stuff. And I think also much more personal. I always feel like her, when she was writing, especially for piano, was writing for herself versus like an audience. And so if you're interested in kind of a pianist, you know, piano music you've never heard from an era, you know, of other great composers that you have heard of, check out Fannie Mendelsohn. She has a suite of piano pieces called The Year, one for each month that are really fun.

 

Any relation

 

And yeah, just

 

to the well-known

 

something else.

 

composer Mendelssohn?

 

Ah, Dan, you took my question, man. I was just about

 

She,

 

to ask

 

you

 

that.

 

know, in fact, I deliberately didn't mention that because she's lived for or existed for 150 years in the shadow of her brother Felix. And I think, I mean, he was brilliant, too. But I think in her own way, she really stands alone and is just an incredible, I mean, from all I've read, just an incredible individual. And so well worth checking out. Yeah.

 

Excellent. Alrighty. We have gone so long. This is going to be a packed long episode

 

Maybe a double episode.

 

for those who have made it this far. Yes. So before we go, Nick, how can people get ahold of you or yell at you or say, what are you working on or whatever they want to communicate with you?

 

So I'm on Twitter and github in most places as hipster Brown all one word if you see Charlie Brown with the mustache and glasses that's me a hipster Brown comm and You can find excess dev on my github as well. So github.com slash has around slash XS hyphen dev And working on a lot of documentation and education sides of that So if you are interested in getting involved there or just want to help prompt me for things you want to learn more about know and I'm happy to help out.

 

Now it should be worth noticing that the amazing mustache we were talking about, according to your GitHub page, it is a figment of our imagination. So I'm not

 

It's amazing

 

sure

 

trick,

 

which

 

isn't

 

one to

 

it?

 

believe. Yes, it is. Very good. All right, Peter, how about you?

 

Yeah, I'm on Twitter at, my name is weird, so I'll just spell it out, at P-H-O-D-D-I-E. You can reach me there. And Modable is at modable.com and on Twitter at at modable, M-O-D-D-A-B-L-E, tech. So feel free to reach out either way.

 

Excellent. All right, oh, before we leave, I would like to also say thank you to the studio audience. Yes, yes. Thank you. Yes, they agreed it was a good show too. I am on Twitter, I always forget to mention this so I'm remembering it now. I am on Twitter at wonder95. If you wanna see my dad joke of the day, you can always follow me there. AJ, I forget you were cool, AJ86. Now you're, you're still cool, AJ? Okay.

 

No, I'm cool. Age 86. I switched for a year to something else. And then I realized that that was just stupid. And I was able to switch

 

Right,

 

back.

 

okay, and then Dan is, Dan Shapir.

 

Yes, I am Dan Shapir as Dan Shapir.

 

And if you're reading Dan's tweet, you almost half the time you will have to use the translate tweet function if you don't read Hebrew.

 

Oh, no, I just I just

 

So.

 

reply in Hebrew. I don't I hardly tweet in Hebrew. So

 

Okay, just the replies,

 

Hmm.

 

Yeah

 

okay. I use that function frequently when reading your replies. So I just realized, you know, I used to copy paste over to Google to translate. Then I realized,

 

Well,

 

oh, if

 

it's

 

you

 

a...

 

click on the tree, there's a translate tweet

 

Yeah,

 

function.

 

there are elections coming on in Israel yet again and sometimes I can't help myself and I respond to some people when I shouldn't.

 

All righty. All righty. So with that, we will wrap up this episode of JavaScript Jabber. Thank you to Peter and Nick for coming on and enlightening us about IoT. And we will talk at you next time.

 

Bye.

 

Thank you all so much.

 

Thank you.