 I should, I guess, full disclosure, for some reason I thought my talk was this afternoon, so I haven't even practiced this because I'm one of those last minute right-year talk people. So I make no guarantees on how short or long this goes. But hopefully it'll be interesting. So yeah, so I'm going to be talking a little bit about this over-sensationalized title of spanning the IoT developer chasm. I think that's one of those situations where it's like, how do I get my talk accepted? Let's make this title really out there. But basically what I want to talk about is kind of this idea of maybe some advantages of finding an end-to-end solution within your IoT applications using a single programming language, potentially. So with that, I guess just real quick, I'm Chris Borchers. I run the JS Foundation, which was recently launched in October out of the Linux Foundation. And I'll talk a little bit more about what we do as well once we get going. So I will go ahead and dive in here. So like I said, I think chasm is probably a little bit of an overstatement, I guess, because a lot of this stuff is blurry, right? I mean, there's a lot of crossover between some of these things. But I mean, if you take a really high, really oversimplified view and kind of divide things up into kind of your things, your microcontrollers, sensors, small devices, then you've got your edge devices, and then usually some sort of server or cloud instance or whatever displaying data that you're aggregating or whatever. And a lot of times when you look at the teams working on sort of this one single application, you have different sets or even different teams sort of writing this software for these different divisions within your application. And what I kind of want to talk about today is the opportunity for JavaScript to kind of bridge all the way across from down on the device all the way up into your web app and kind of everything in between. Like I said, I think chasm might not be the right word. Maybe it's more of like a muddy bog that you can get across if you really try to. But the hope is that JavaScript, among others, I also don't want this to come off as like JavaScript is the solution, right? Obviously, I think it's the solution. But I don't want to get into that debate, because there are completely viable solutions outside of JavaScript. So yeah, so what I was kind of getting at there is, so with these, with JavaScript, so client-side developers have already been kind of moving into other areas thanks to things like Node. So I mean, we have JavaScript developers that started out just playing around in the browser, are now writing pretty complex applications on the server-side in Node, and a lot of those opportunities are starting to present themselves within the IoT space as well. And different projects sort of starting to pop up where JavaScript developers can translate their skills into those areas as well. And so what we're hoping to see is that JavaScript is starting to become this kind of unifying language across that entire software platform for IoT. And gives you that opportunity to have all of your teams, or even one team, all speaking the same language. So whether you're building from scratch or modifying an application, changing your APIs, everyone's talking the same language. And a lot of times that helps you tap into other ideas that maybe you wouldn't have been able to if you have your C developers doing one thing and your JavaScript developers doing another. So why JavaScript? So this is kind of, I guess, just sort of making the case for that. So looking at some surveys, so this is the most recent Stack Overflow developer survey results. So JavaScript tends to top the list there with 55% of questions being tagged as JavaScript. Also in terms of their top technologies, JavaScript tends to top the list there. And what's interesting is they actually break up their top technologies a little bit further than we would. So things like JavaScript, jQuery, AngularJS, all of these different frameworks and things that are all JavaScript, NodeJS even, are all separated out. And so if you combine all of the things that are JavaScript in their survey, then it kind of becomes even clearer how popular JavaScript is. Now you could make the case that people just struggle more with JavaScript and so they're always asking questions on Stack Overflow, but I'm going to ignore that side of it and just assume that it's really popular. So obviously this is where kind of the JS Foundation comes in. So our sort of entire purpose is to support the JavaScript ecosystem and really everything outside of NodeCore. So there is the NodeJS Foundation as well. We partner with them. They support NodeJS itself and then we sort of support the entire innovation layer on top of Node as well as the browser and now into IoT as well. And so this is kind of our sort of pitch about the JS Foundation. I won't spend too much time on this, but basically what we're trying to do is create this center of gravity for open source JavaScript. Those that are familiar with JavaScript in the room probably notice how chaotic kind of the entire ecosystem is, people reinventing the wheel all the time. A lot of great innovation comes out of that, but there's a lot of wasted cycles and so our goal is to try to sort of create this focal point for that energy so that people are more aware of what already exists and get involved in what already exists and support and sustain things that already exist rather than reinventing it because they didn't like one feature. And then just a couple of stats that I just love to throw out because a lot of times people don't realize some of these things. So things like jQuery where people are like, oh, nobody uses jQuery anymore, but when you actually go and look at online usage from places like builtwith.com or whatever, jQuery is still on 80% of the top million sites, and it's still on over 18% of the entire internet, which, I mean, you think about that and that's a huge number, but then to further illustrate that, if you look at our CDN numbers, 36 billion downloads a month of just jQuery. So these are meant to just illustrate, like, I mean, JavaScript is everywhere, people love JavaScript, and even when they think things go away, they haven't really gone away. So our community, we have 23 open source projects spanning multiple segments of the JavaScript ecosystem. So that's everything from the client to the server into IoT, and that's where we'll focus here in a second. And then for those familiar with JavaScript and the node ecosystem, NPM is sort of the package management system for node, and our 23 projects are downloaded over 80 million times a month just from NPM, so that's outside of those jQuery numbers. And here are all those projects, I'm not going to go through this whole list, but if you do anything in JavaScript, you probably recognize a number of these logos, but really what I kind of want to focus on are two projects that are becoming prevalent in the IoT space for JavaScript. And those projects are JerryScript and Node-RED. So both of these projects are JS foundation projects. They came into the foundation when we launched back in October. I should clarify, let me go back real quick. So we brought in, before October, we were the jQuery foundation. A year before that, we had absorbed the Dojo foundation, so brought in all of their projects which were things like Grunt, Dojo obviously, things like that. Last October when we relaunched as the JS foundation to sort of better brand what we actually do, we brought in a number of different projects, Node-RED coming from IBM and JerryScript coming from Samsung. So those are the two projects that I'm going to focus on today. And really, hopefully here soon, I'm going to just stop talking at you and just kind of play around with these projects just to kind of show you what they do. And then we can just chat. And I should have said at the beginning, like if I'm going too fast or you have a question about anything, interrupt me. I don't mind. I would rather have this be a conversation than just talk at you. So JerryScript. So you've probably heard this a few times. I know I saw at least a couple of talks mention JerryScript. But it's a super lightweight, fully ECMA-51 compliant JavaScript engine. So I think someone mentioned yesterday that it is behind. So ECMA-51 is about two versions behind kind of the latest. That doesn't concern me too much at the moment because a lot of the stuff being added to the language, in my opinion, I mean, there's definitely useful things, but a lot of it's kind of sugar and kind of just making some of the APIs easier to use, which are good things. But I don't think there's a lot missing. Maybe typed arrays would be nice that those are in one of the later versions. But for the most part, you're not missing out too much on it being a couple versions behind. Like I said, it's really small. It's meant to be run on extremely memory-constrained devices. I think the binary itself when it's built is about 170k, which is pretty amazing for an entire language engine. I also pointed out yesterday, or I think Monday, the one thing with JerryScript is they do provide it some additional APIs into the devices, so into some of the targets that they support. But there are key things missing that you need to add on top, like IO, because that's not part of the language. So there are other tools, which I'll briefly touch on just because I have to use them to make the demo work, that you can add on top of it, which do increase the footprint a bit. So depending on what you're trying to do, the memory requirements can change, obviously. What they are doing. So TJS is the project that I'm talking about that I'll be using on top of JerryScript. It's another Samsung project, and they're starting to focus a little bit more on that now to make it more modular so that you can only have to pull in the pieces you need to keep your size down. I didn't bother with that for this because I'm just building it for Linux, so I don't need a tiny footprint. Well, so I guess the question was, what are the assumptions in terms of the device that you would be running JerryScript on? I don't think there are too many assumptions because when it comes to JerryScript, it's literally just the language, the engine for JavaScript. So the assumptions would need to be made by the application that you write on top of it. So JerryScript, really all it cares about is, will I fit? Now, when you get into when you're actually building your application, then yeah, I mean usually, especially when it comes to things that you would want to be doing with JerryScript, you're probably going to assume there's some sort of communication channel, maybe not necessarily internet, but some sort of I.O. to either call back to another application. One of the things, and I wasn't really going to get into this, but one of the things that I've been trying to convince some of them to think about is what I would love to see is sort of this idea of application composition across your I.O.T. devices. So basically spreading your compute across all of your devices. So basically it's taking the idea of serverless and going the other way. And so putting small functions that only matter to that device on the device and it can do some of your application compute there and then just give your main application the data that it needs to display or do whatever. And so there's some interesting ideas that we've been kind of toying around with not building anything, just kind of thinking through. But those could start to get really interesting when you start thinking about, so whether it's with additional libraries or if they start supporting additional features of JavaScript, they do introduce things like classes. And so then we can start looking at a device as, say, like a class instance. And it's just, we can start using that as part of our application rather than just something that's feeding me data. Again, it's all just ideas. But I don't know if that really answers your question. No, it's fine. I see. And that's, yeah. So yeah, I think you helped me answer your own question. But yes. So just to repeat, if you couldn't hear that, what he's asking is kind of what's the value prop of putting JavaScript on that memory constraint device. Once it's set up and figured and ready to go, why bother putting JavaScript on it? And then he went on to answer his own question. But yes, one of the things that, at least I'm promoting, is this idea of, because JavaScript is so approachable and so easy to just play with and learn, I mean, you can literally just, anyone can open up your browser, open up a console and start typing in JavaScript and it just does stuff. So those advantages then can translate into, like you said, here is how this device communicates its temperature data back to your application. But maybe you want it to also do motion sensing. And so you can take that little bit of code and make a few tweaks. And it's, in my opinion, much more approachable now than people make the argument of, well, if you've already learned sort of the classic or class-style program, object-oriented programming, and then you try to move to this more prototypical style, it's not as approachable, but that's another debate that we probably shouldn't get into. But yeah, that's the idea, is that you have these small bits of code that are easily modifiable. And then with different libraries out here, so even on Monday I was watching the Zephyr folks talk about the new Web IDE that they have, where now you can literally just over the Web USB protocol modify your JavaScript and push it to the device and it updates. And there's no recompilation, nothing. It's just you update the JavaScript on the live device and it runs. So that's another kind of advantage there. Yeah, sorry. No. So it depends on where you're at in the stack. So on the edge, maybe. But once you get down into your small constrained devices, no, because it's, like, nodes too big. I mean, I think, I think like, no, like, even like V8 is like 18 megs or something. Like, it's just not, yes, right. And that's so, yeah, so when I get to the demo, I think what I have, it would not work. You would need a little bit more space. Like I said, I just have it running on Linux, so I wasn't concerned with the size. But I think the one that I have pulling in all of IOTJS on top of JerryScript, plus my little tiny application, it's like 205K. So it's still pretty small, but like, it wouldn't fit on this less than 200K device, right? So, you know, a little bit more space. But yeah, so there are things you have to add on top to get some of that basic necessary functionality that you would want in your device. But yeah, JerryScript, all it's about is just the JavaScript engine. And then you have to put stuff on top. So, so Samsung created JerryScript and then gave it to the JS Foundation. They also have a project called IOTJS, which I'll be using. And from what I understand, I believe some of the stuff that they're doing next is making it more modular. From, I'm, honestly, what this demo that I'm going to show today is like the first time that I've literally sat down and played with these. I've talked about them a time, but I've never actually used them, which should also be a testament to how easy and approachable this is because I'm also just some exec that doesn't get to write code anymore. But from what I understand, they are working on making that project IOTJS more approachable or more modular to be able to pull out just the pieces you need. But they've already, basically, the idea behind IOTJS is it's taking a lot, it follows a lot of the node APIs because that's what JavaScript developers are used to. And integrates some of the most common ones that you would use in an IOT setting. And then, hopefully, they'll be able to break that down so that you can say, I just need HTTP and MQTT and a couple of things, and then I'm good to go. But right now, I think it's just all or nothing. So then the other project that I'm going to talk about a little bit is Node-RED, is anybody familiar with Node-RED? Cool. This is a project that's really, really starting to pick up steam. The very basic description is that it's a browser-based flow editor. So it's basically just a visual tool where you can map your data flows for your application, so data coming from a device into your application, into a data store. You can set rules so that it'll trigger emails or Twitter or whatever. And then they have this sort of social aspect of it where they have an entire flow library. So what they call flows are basically there's nodes which are these things like I have data coming in, and then there's flows as to where the data goes. And they call the whole thing a flow. And so they have, I forget the number, I'll pull up the website. But hundreds of already pre-built shared flows. So people can go out and just say, well, I have this device and it's sending this data and I want to put it into my database. And there may already be a flow for that. So that's pretty cool. And then, yeah, for a while now it's been shipping on every Raspberry Pi. I think, forget when that started, I want to say late 2015. I don't know which version of the Pi that would be. But at least the last version or two of the Raspberry Pi have all shipped with Node-RED already on them. Which obviously means that it also has Node already on it. All right, so let's play a little bit. So because I'm running on Windows, I mean everyone here realizes how terrible it is working with IoT devices in Windows, right? Like it's just miserable. So I have a VM running Ubuntu. So basically the idea of this demo, and I just threw this together last night, because I wanted something a little more interesting than me just talking. Basically the idea is you have some device recording temperature data. And it's sending that data back every second. And then within your app, whether it's so within your Node-RED instance, say you have that running on some edge device like a Pi or all the way up on a server, whatever, is monitoring those temperature readings and sending information back, telling it whether or not to turn a fan on. So a super simple example. So what I will start with is the, let's see, where. Yes, let me, actually that's actually a good question. Cuz I don't know how to, right? Yeah, it's not a regular terminal. This is a virtual box, and I already have it scaled up 200%. Let me see if I can just, all right, here's what I'll do. So I already have it scaled all the way up. So I have, right, I already have it at 200%. Why are you running inside of that? It's Ubuntu. It's a server, yeah, it's just console, is that font? Tab, I see what you're saying, no. Sorry, yeah, I didn't think about this part. Let me, I wonder if I can, yeah, I mean, I don't know how much that'll help, but I can, well, nope. Thanks, virtual box, space, 12X, sorry. Well, we won't be in here too much. Let me, I don't think there's even a good way. Well, all right, I guess just bear with me. We won't do too much in here. What's that? So this is a tiny JavaScript application that's meant to mimic a device reporting temperature data. So I didn't have a device with me. I was gonna use just like an Arduino 101 and it's sitting on my desk at home. So, so I just made this to fake it, but basically all this does. So this does illustrate though the need for IoTJS. So IoTJS brings in things like, so I can say require HTTP on the top. And so now I have the ability to use HTTP to do communication. And then basically all of the rest of this does is it loops every second and just sends a message over HTTP saying, this is the temperature. And then when the response comes back in here, it parses that response and says, if it tells me to turn the fan on, I basically just turn my heat factor to negative cuz I'm just faking it, right? So then the temperature will start coming down. And then when it gets down, it'll turn the fan off and it'll go back up. So that's kind of the idea. So that's all this does is kind of mimic a device monitoring temperature. That back down since that didn't help. Then over on this side, so this one I can make bigger. I don't know how useful it'll be, but I will do it because I can. So over here this is where we're gonna, so that device is running in a VM. This is gonna be my Node-RED instance running on Bash on Ubuntu on Windows, on my local machine, and then they'll talk to each other over HTTP. So with Node-RED, it's super simple. You literally just clone, actually NPM install. So you need Node, NodeJS. Once you have NodeJS, you can just NPM install dash G for global installation Node-RED. And then anywhere you are, you can just type Node-RED, and it'll fire up your Node-RED instance, and it'll be listening on 1880 by default. So then we can go into a browser, and this should hopefully get the connection back. There we go. So this is Node-RED, can we see that? Maybe a little, let's see if I can, it might fit, so we'll just scroll a bit. So as you can see, so this is the user interface side of Node-RED. Then Node-RED also has the actual server runtime running, which once you build your flows, you deploy your flow out to Node-RED. And that's what my device will be talking to, okay? So what you can do is just literally drag these nodes on and then configure them. And so what this first node is, it's just an HTTP node. And I don't know if you can see that. But basically all you have to do is tell it the methods. So it'll be a get request coming in to the URL. So it's just going to temp-monitor and then you just give it a name. Super simple to config. So then basically what any data that comes in via get request, Node-RED converts that to a JSON object. So the object is message and then the data inside is within an object called payload. And then whatever you call, so in a get request, anything you put in the query string of your request becomes an item within the payload object. So I know you can't see it, but I guess let's go back to that. Real quick. So what I'm doing down here is, so here's that slash temp-monitor URL. That's where we're gonna send our get request via HTTP. And then we just send it a query string saying temp equals and whatever our temperature reading is. And so it's sending that in. So then on the Node-RED side, what is going to come into temperature monitor is an object with an item called payload and within payload there will be temp with a numeric value. So then we have this next, let me get out of here real quick. This next one is called a switch, which is down here. So a switch node and you can just decide different paths to take based on what's in your payload. And so basically what this is doing is it's just saying if the temperature is less than 80, go this way. Between 80 and 90, go this way, over 90, go this way. That's all it's doing. And then we have these three changes, change nodes. So a change node gives you the ability to modify the payload. So you can add things, change things, whatever, inside the payload, and then send it on to something else. And so what we're doing here is if our temperature is below 80, we take that top route. We add a response that says the temperature is OK and we also tell it to turn the fan off. So we set a new value of response to the temperature is OK and a new boolean value called fan to false. Similarly at the other end, we say that there's a temperature alarm and we say turn the fan to true. And then in the middle, it's just basically just kind of a, we could do more with this, but it's basically just the temperature is hovering close to too high. So you could use this to notify, let someone know, hey, for whatever reason, this thing's starting to get warmer. What you'll notice here is there is not a fan setting because we don't want the fan to turn on until it gets too hot. We don't want it to turn off until it gets cooled off. So there's no reason to even mess with the fan in the middle. And then the last thing is it just generates an HTTP response. And so literally you don't have to do anything. You just say create a response and it automatically knows to take whatever your payload was and send it back. And so that's why you modify that original payload however you want and then it'll get fired back as a response. So let's, and that's the whole thing. I mean, this took me, including downloading, installing and building Node-RED, JerryScript, IoTJS, writing that sample app, creating this flow like an hour. And this is the first time I've played with it. So that's just to illustrate some of that, the points I was making earlier around the approachability of both JavaScript and some of these tools that have been designed with JavaScript developers in mind that are just easy to use, easy to jump in with. So let's fire it up over here. So basically all I need to do here is, I'll see, here it is. And I know you can't see it, but basically all this is doing is, so I've built IoTJS, I can pass in a JavaScript file to IoTJS and it knows that's what I want it to run once it starts up. So that's all this is doing is it's just saying, run IoTJS and pass it my message.js file, which is that file that was too small for you to see. And so we run it. And so now it's just running on this one second interval, slowly increasing the temperature. You'll see it kind of bounce around a little bit. Right now it's just still saying the temperature is OK, the fan doesn't need to come on. Now we're seeing this temperature warning coming back from Node-RED because the temperature is starting to reach a little bit higher. And then we'll see. So of course I've given control to the math.random, but here we go. So now we have a temperature alarm. And so you'll see the fan set to true. And so now, I don't know if you can see these numbers, but they're bouncing around at the high 80s, but now they're slowly starting to go down because our fan is on. And then once it hits back at 80 or 79 or whatever, it'll turn the fan off, and then our temperatures will start going back up. And there it goes. No. So the device is actually sending a get request. So it's saying, here is my temperature. Tell me what to do. You could do put. You could do post. I used get because it was easy. But it's a get from the server. Right. So you could use a post. Like so yeah, yes. And then yeah, so but then if you wanted to be storing that temperature data, it would probably make sense to do a post because now you're saying take this data and store it. It's, yeah, I mean, absolutely. And you want to give it a response no matter what, even if you don't do anything with it because your, so the HTTP object on the other end is going to be waiting on a response because it's just the protocol, right? Like it's saying here, I mean with a post, it probably doesn't care. But with a get, it's waiting on that response. And so that's why I used a get because I know I wanted to tell it whether or not to turn the fan on. So yeah, so that'll just run forever. Probably a little oversimplified example because obviously this is set up for one device. What's nice about Node-RED is as you get more complex, I mean, there's all these different prebuilt nodes. But if you need it, they have one called function. And you can literally just write massive amounts of JavaScript if you need to, to do much more complex things within Node-RED or you can create your own new nodes. So the only thing on the device is, in this example is JerryScript, IoTJS, and my little application that's mocking the data. And there would still be some little application that I would need to write to say like if I was actually getting temperature sensor data coming in, I would still need to write a little application to actually take that data and send it rather than just mocking the data. But it's the same idea. But that's all that's on our device right now. And then Node-RED is just running on my machine, acting as like a server. It could, like I said, Node-RED ships on a pie. So this could just be devices talking to a pie. Node-RED is a little bit bigger because it does require node and node is huge. What I'm hoping is that they are looking at other engines as well. Could be interesting to see if Node-RED could run on JerryScript and IoTJS, but it would have to be sort of like a Node-RED constrained, right? Like it would have to be, you wouldn't get all of the features of Node, sure? Yeah, I mean you could probably, so the only things that you have to figure out are, so like, how would the data be coming into Node-RED, right? And so I mean this will do, I mean it has, like I said, it has HTTP, MQTP, TCP, UDP, so you can just, as long as you can give a data stream to Node-RED, then you can tell it what to do and how to respond and then you'll still need something at the device, right, to like either turn the fan on or turn it off or whatever. But this can handle sort of that, Node-RED will handle the in-between. You could probably do it all down at the device too, depending on what all you have access to in terms of like an accurate clock and things like that, if you're wanting to turn it on and off at a certain time and whatever, but then the other thing I just wanted to show real quick is how easy this is to modify and redeploy. So say we just want to add, I'll just do something really simple like a debug. So I can take this debug node and also tell it every time you change the payload, also send it over to my debug window, which is over on the right there, and come in here. I can rename it if I want, so it's going to send my entire payload to the debug tab, and I can name it if I want, but debug and say done. So now I have this new debug module. This little switch on the right isn't on off. Oh, right. So you can't turn it on off until you deploy. But literally to redeploy this entire flow, or you can also say just deploy modifications or whatever, you just click deploy, and now it's been deployed to my server and it's all still running. And then this green light says that my debug is on. So now if we fire that back up, what we will see is not only the responses over here, but also our payload over in the debug window. So super simple to modify and redeploy. That's a good question. Let's try it. So let's just say don't do that one. And deploy, it's deploying. This is still running. And yeah, you can see, I don't know if you can tell, but it's still running, it's still changing. So we shouldn't actually get, we should not get a, you can see probably the red X's. The alarm has exclamation points if it actually gets there. And we shouldn't see that because that's the flow that I removed, but the fan might be on because it looks like it's going the other way, but yeah. So just turn the fan off. It should come back, but try to keep an eye on it and see if it sends that one out. But yeah, security in what sense? So I mean, you can use HTTPS. So it's going HTTPS. Oh yeah. I'm sorry, say that again. What's the size? Oh, the size difference. So it would be no different because I'm using all of Node-RED. But Node-RED, you're usually a little less concerned about size because you're probably running it on a server. On the device side, yes. So you can do HTTPS there as well. And that's already in that size that I mentioned because I'm using the whole thing. The hope is eventually we can cut out pieces and make it smaller, but right now that 35K or whatever is the whole thing. And it's just a subset of Node.js APIs. It's not all of it. But yeah, the HTTP that I'm requesting, I could have told it to use HTTPS as the protocol and it would have been just fine. No, no. So there are, let me see here. Oh, I'm over on that one. Let's see. So I know, yeah, so you can read from a file. You can write to a file. There are likely, oh, so the one, I guess we're out of time, shoot. The one thing I did want to show real quick are these flows. So there's a whole flow library out on Node.red.org. And there's probably database connectors and whatever to pull and write. So yeah, I mean it'll, and the idea is it's, I mean, it's open source. So if it doesn't do something, you can make it to it and share it, so yeah. Yeah, but I can find out. Right, right. Yeah, I mean again, I don't know if that's in the plan. I would have to ask the team. I would hope that it is because, I mean, if you're trying to get small, you should. Get small. Sure, what are you working? Are you ZephyrJS? Yeah, so we should, I was actually talking to Zachary, like we should talk more. And I'm sure they would be willing to accept, I mean, if you wanted to add that functionality, add that more modular, I don't see why they wouldn't want it. And I know they're looking for more people that are not Samsung people to work on it. So awesome. All right, I'm way over. So that's our members. I always have to throw that up just because that's who supports us. And then yeah, feel free. Reach out. That's how you can kind of keep an eye on what we're doing. And yeah, that's it. Thanks.