JavaScript For The ESP8266

The ESP8266 is a popular WiFi chip that provides a relatively transparent connection between the TX and RX pins of a microcontroller and a WiFi network. It was released a little more than a year ago, and since then developers and hardware hackers have turned the ESP into much more than a serial to WiFi bridge. It’s a microcontroller platform unto itself, with a real development environment and support for the scripting language Lua.

Lua is okay, but a real win would be a JavaScript interpreter for this tiny WiFi platform. It’s taken months of work, but finally there’s an open source version of JavaScript available for the ESP8266.

This build is based on the Espruino firmware, a JavaScript interpreter for microcontrollers. This interpreter runs on dozens of different microcontrollers, but being the latest, greatest, and most popular new microcontroller platform means a new solution for the ESP is very, very exciting.

Right now the JS interpreter for the ESP is in testing, with expectations high that everything will be brought over into the main branch of the Espruino firmware. There are samples of JavaScript running on the ESP available, and binaries that can be flashed onto an ESP are available here.

Thanks [Richard] for sending this one in. He’s set up an Espruino board on the ESP8266 community forum, that should eventually be filled with new examples of JavaScript running on an ESP.

50 thoughts on “JavaScript For The ESP8266

  1. Hi all,

    I am wondering how that little board can be so cheap. Other wifi board are all quite expensive. Does it have less functions than other boards? A higher consumption ? Could it be explained only by the fact that it has no FCC certification ?
    Thanks for the article and answers if you have some.

    Arno

      1. Thanks for taking the time to answer me. But I know what an esp8266 is… IMHO, the fact that it has no docs should no impact that much on the price of the device. There is no ESP with FCC certification (written in the doc, even the version where it’s written on don’t have the certification).
        My question was more practical. How can someone justify a wifi board at 25$ or more when you can make one at a few $ like the esp ? I have never seen any article talking about that. Thanks for pointing it to me if I missed it.

        1. Are you asking why a business in the USA or EU can sell stuff at a huge mark-up compared to a Chinese seller even when both items are made in China? Because most people are buying a service or function, and not an object, and with a known brand comes an implied guarantee of quality based on reputation. It is easier for many people to just spend more than to shop around and think about what they are buying.

          1. yes, i have been looking closely at ESP8266 and I think part of the reason has to do with the level of integration achieved by ESP8266; boards using ESP8266 have less than 10 components whereas other WiFi modules are using more than 50 components! so that’s 7-8x difference. ESP8266 boards are also much smaller! These things probably do add up to the cost and failure rates of the modules in the manufacturing process, and hence the cost difference.

      1. Yeah – the issue I have with LUA on the ESP8266 is the problem trying to do ‘async’ stuff. I want to have a web interface while the in background reading the temp from onewire, decide whether to turn on or off an GPIO port. I was able to do it, but it was incredibly slow, like 10-20 seconds slow to bring up the webpage.

  2. Eugh, I guess this was coming eventually.
    I will never understand the need to run a language as terrible as JS on everything, but the more the merrier.

    What would be really exciting to see is a language like Rust supporting the ESP8266. It has major advantages to the current crowd (even C and C++) in moving type safety and error checking overhead to the compiler, thus removing the burden from the embedded system but still retaining the benefits.
    The language’s package manager could be a real boon for distributing current version libraries for use on embedded systems, too!

  3. I attempted to use the NodeMCU firmware for MQTT. The firmware alone would take substantial memory, and would randomly break running lua code with a “critical error message.”

    C thus far has been very reliable and it’s nice to know if your program has a syntax error before you upload to the uM. C isn’t extremely difficult also.

    What is the advantage to using Javascript for the eap8266? Some type of web design?

    1. There’s no serious advantages to running js on this system. Perhaps one “advantage” would be lowering the barrier to entry, but at the risk of covering up true nature of the limitations inherent with the embedded system. Yes, the abstractions that js can provide can be useful, but are also ripe for abuse and lots of head-scratching when something doesn’t work as intended.

      The aim of the game for embedded systems is to have verifiably “good” code running with minimal overhead – js achieves none of these. The ludicrous type system and the very nature of being scripted make these goals difficult.

      Same kind of goes for Lua, too.

      I really wish that Lua and JS were never ported to this device, instead the development effort should have been focused on better community documentation, coherence and toolchain niceness in C (or even better, Rust, as I suggested in a comment above).

      1. Maybe the itch that was scratched here was the porting of the language to the the device? Instead of wishing that someone spend their time doing something you think is a good idea, why don’t you go and do some of that work yourself?

      2. One advantage is that someone knowing JS can use the ESP8266. Another advantage in comparison to C is that, even if you know a lot more than JS but want to control a GPIO from a web browser, it is more time-efficient to use JS instead of setting up an environment just for this one particular need.

  4. To my mind, choices of programming languages come close to religion and no-one is going to be happy until all languages are everywhere. I was one of the chaps doing a lot of coding on the port … however … prior to that … I spent months writing up a book on the ESP8266 ( http://neilkolban.com/tech/esp8266/ ). I mention this as one post asked why effort was being spent on a JS port when effort could be better spent on better docs … I think the answer to that one is that both are being done.

    As for why JS? There are many answers to that. Some are frivolous in that (for me) working on the ESP8266 is a hobby and fun so since there is no personal compensation for doing work I don’t want to do … I do work that I do want to do (a JS port in this case).

    However, and this is where we get into religion, to me the “secret sauce” of the ESP8266 as an MCU is that it is a first class WiFi device for a few dollars. If my needs were more electronics based, I’d look at an Arduino. If I needed power and a full OS, I’d probably look at a Raspberry PI … so why then would someone want to use an ESP8266? The answer (to me) is that they want to connect to the Internet … and for a large number of applications, that means browser based interaction. It seems (opinion) that the language of browsers is JavaScript with connectivity via HTTP (REST) and data format of JSON. If I am writing my browser side apps in JavaScript that means that we can assume a programmer is already familiar with that language. To complete the puzzle, there may also be server side programming needed … and that is where the JavaScript port to ESP8266 comes into the story. With that available, programmers now have a choice that they did not have previously.

    I also note the growth of server side JavaScript with projects like NodeJS … and also the notion that the JavaScript engine that was ported (Espruino) was designed from the ground up for execution on embedded devices and was funded by a successful kickstarter project.

    Today the separate port of Espruino (the JavaScript engine) to ESP8266 has been merged into the core Espruino github code base. This means that enhancements to Espruino itself will immediately carry forward into ESP8266 land.

    Testing and functions of the ESP8266 port are still in their infancy. However, the full JavaScript language as found in Espruino is now 100% present as is networking and basic GPIO. So there is enough present already to see what the story is all about.

  5. What’s everyone’s beef with LUA. Is it just that metatables are hard to figure out and you need ’em for OO?

    It’s a really nice, lightweight, flexible language, and metatables are straight up magical if you can be bothered to learn how to use them. JS has some serious problems, but I don’t hate using it. Seems like a serious step backwards from LUA in terms of performance and simplicity though.

    1. Agreed. And I couldn’t tell you.

      Perhaps it is because NodeMCU is buggy as all hell and they attribute the problems to Lua. Or the language-of-the-generation being somewhere else it shouldn’t be is appealing. I can understand that one, even if it isn’t correct – I’ve done the same thing with another language myself, and it was fun. My feeling is that it is more of an ignorance of Lua combined with an overabundance of JS writers and enthusiasts looking for something else to infect.

      But I really have no idea.

      1. I’ve been doing quite some Lua embedding in my own applications. Never had stability issues with it. Unless you mess up the lua stack yourself.
        Main issue with Lua is that the C API requires you to think like a stack based CPU. Making it easy to mess up LUA->C calls.

        I think JS and Lua are just as bad at OO programming. As they both don’t really have the concept of “classes” in the language and just use other language features to work around that. (prototype vs metatables) giving odd syntax.

        (I have not tried embedding python in applications yet. But I do like the language)

  6. I do professional JS development and this really baffles me.

    JS is a perfectly fine language for what it’s used for – web client-based scripting and light serverside application development. It’s fast to work with and has a great deal of library support.

    None of these things are an advantage in an embedded realm. The weak typing is going to be a PITA for dealing with I/O and memory management. The JS infrastructure and community is all dedicated to resource hungry, web-oriented applications. There’s not a lot relevant material that you can leverage here. Maybe a barebones Express server to run a lightweight website would be marginally useful but do you really want to be serving up dynamically generated websites from a device with a few dozen kB of RAM?

    IMO, the most you should be doing from the ESP is some sort of barebones API endpoint to a RasPI or dedicated server running a full NodeJS stack. There you can be running actual databases and have enough iron to make JS a worthwhile proposition.

    Lua sounds decent and if you’re going to use a scripting language, that seems like a superior choice to JS. Personally, I just skip the middleman and just use C/C++. Those are languages specifically designed for an environment like this. It kind of annoys me that people are willing to put themselves through so many artificial hoops to just avoid learning a new language.

    1. If all you are doing is an API endpoint then does all that stuff matter? I am using several ESPs to record temp/humidity/external relays. They communicate via an MQTT server and the data is handled by a node red instance. The ESPs are currently running nodeMCU and programmed in LUA. It would be nice to just use javascript everywhere (node-red uses it). If i needed to push the performance limits, I’d go with the espressif C SDK, but I’m not so I could use a language I’m already using or use something that I use nowhere else but the ESP.

      Something doesn’t have to be the best thing technically for it to be the best thing practically, in certain cases.

      1. What Dan said is absolutely right. You hipster javascript guys try to take over the embedded world now. Keep your javascripting, apply it on the web, that’s it. This javascript hype is spreading like cancer, I really do not understand it.
        All you wannabe coders stay out of the embedded world if you can not code some lines of C or Python.

  7. Hi, I’m the guy that does the ‘official’ Espruino boards…

    Just wanted to try and address some of people’s complaints about JS on MCUs, although I probably won’t convince you ;)

    LUA is nice, but JS is much more popular – there’s masses of example code and documentation. It’s also available pretty much everywhere thanks to web browsers and node.js. Suppose you’re serving a Web UI up to your IoT device – now you can write the same code (maybe decoding some data?) and use it both on the device and the user’s browser. That saves dev time and reduces bugs.

    JS isn’t perfect, but it’s good enough. And like many things (x86?) it was in the right place at the right time for widespread adoption. In some ways it’s been sabotaged by its popularity – they can’t fix the design bugs because it’d instantly break most websites. Unlike Python, where nobody seems to think the syntax changes that broke totally valid Python 2.7 code on 3.0 were a big deal – I was fed up when it broke the Espruino build, if I was a company with a million lines of it that would be a massive problem.

    So why put JS on an MCU? Toolchain basically. Getting a decent toolchain working really sucks. Arduino is ok now, but if you’re running Linux like me then 10 years ago the situation for embedded dev was pretty dire. If you’re running something non-mainstream (Linux on ARM, Chromebook) then it’s still not great. And then there’s debugging – which people just seem to ignore. When dealing with hardware that could also be broken, being able to debug is vital – but it seems to be pretty much ignored on Arduino and mbed (at least at the moment).

    Also, dealing with strings in C isn’t much fun, and most IoT work tends to use strings all the time, with HTTP requests and JSON for a bunch of stuff. I imagine the majority of developers will hack up their own JSON parser, using malloc without proper checks, and I wonder how many bugs have crept in because of reimplementation of the same old stuff that was built into JS all along.

    Oh, and don’t forget that letting a small RTOS (that Espruino effectively is) handle your scheduling means that the device can sleep when idle and drastically reduce power consumption.

    Anyway, hope that was interesting to some of you :)

    1. [Gordon]

      Uncertain if you found the comment om the STM32 JavaScript blog post, just want to share some name ideas for you and any future iterations of newer ARM components.

      caffuino
      ritaluino
      adderuino
      methamphuino
      nzt-uino

      P.S. It would be nice if any of the future variants of the ‘official’ boards might offer the ability to switch firmware spaces say a jumper or tiny dip switch to choose between standard Node.js env vs Baremetal.

      P.P.S. Many folks might mention “ewww, JS on MCU”. *shrug* Sure, it’s not awesome. But, if you want to PoC something quick OR are transitioning from working with Middleware and Websites to more hardware oriented tech. It’s a great pathway. I’ve met many different types of folks, Java-script wizards that couldn’t navigate a CLI, lowering the bar of complexity and making things accessible is always a plus.

      There will always be people that will say just use an Ardunino, when in truth 1 discreet chip, a 555 and 2 more passives will do the job. Remember something that is Elegant is NOT simple, what elegant really means is to take something complex and MAKE it LOOK simple. The fact that you can run code and if it doesn’t work you can make changes live is a big deal, not having to reflash the entire firmware is what makes interpreted languages cool. I know and used JS and Python live interpreters. (just saw now that LuaJIT 2.0 also includes that in the VM). That said, the Espruino seems like a decent gateway into IoT stuff.

    2. I’ve been working with the esp8266 for ~6 months now. Before that I used to code arduino stuff when it came to embedded. What I realized in those 6 months is that a qualitative change is happening. If you have religious qualms about JS then stop reading here :-).

      All the embedded work I’ve done recently was with wirelessly connected devices, i.e. they have some RF radio. With the esp8266 for the first time I found a cheap device that has Wifi and that changed the world for me. Wifi is so ubiquitous and that makes it so much easier to work with than all the esoteric other RF stuff. The reasoning path goes as follows:
      – if you want to sell wifi in quantity you need to speak WPA2, HTTP, MQTT, and SSL, because unencrypted communications in today’s world are a ticking security bomb (in general)
      – by the time you can do HTTPS you pretty much need a 32 bit uC, >32Mhz, >128KB flash and >64KB ram
      – judging by the specs and price of the esp8266 and emw3165 this can be achieved at a price point where price is not an obstacle anymore at hacker’s quantities (not speaking of selling many thousands of units)
      – most of the applications I see for these little devices are pretty simple: read some sensors, send the results, receive some commands, actuate some relays/servos/LEDs
      – thus agility in writing these simple apps becomes key and with wifi it’s awesome to integrate with REST services or MQTT, both of which often scream json
      – at that point C/C++ just becomes a boat anchor for most people and javascript is awesome and natural
      – plus it’s nice to be able to write things in an evented/callback fashion and, uhhh, I guess that’s where JS is great again
      – performance and memory: quite irrelevant by the time you’ve got the mhz and KBs to do HTTPS (look at prior Wifi shields for arduino, invariably the processor on the wifi shield had higher performance and more memory than the AVR328)

      So while I could do most things using a 4 bit process in ASM I really don’t pay more and have a lot more fun doing it in a language like JS.

      Note that one area where the above is not true is for systems that operate for long periods (>month) on a small battery: I have not seen any Wifi system that can do that and it’s not the fault of the 32-bit processor or JS, it’s the fault of the way Wifi works.

      If JS specifically is not your cup of tea, there are alternatives out there and that’s a good thing, but the basic points are still valid.

Leave a Reply to daid303Cancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.