Espruino vs. All

Posted on
  • I ask some help to understand the substantial differences between Espruino:

    1. Is there a comparative to evaluate pro/contro ? (scenario is
      pro/semi-pro. We are testing esp32 with LoRawan & modbus but we can change mcu. We would like have also profibus but this is another issue)
    2. Is there a ecosystem around Espruino like ClearBlade or
      other iot infrastructures ? (or... does Espruino has partnerships with other system or consortium ?)

    Many Thanks
    MrB

    P.S.
    It is not a race on who is stronger!
    I would just like to understand better... ;)

  • Hi,

    My take on this is:

    • Most of the other solutions out there are designed mainly for embedding some JS inside a larger C application. Espruino is designed primarily for writing purely JS, and you can create your own builds with C in if you need.
    • As a result of the above, Espruino should have a far shallower learning curve for getting started than most of the others (eg you don't need any C knowledge or toolchain at all).
    • We put a lot of work into making Espruino easy to use and get started with - eg loads of docs and tutorials. As far as I can tell, the other options all fall seriously short here.
    • Espruino's designed for devices with very low amounts of available RAM. You'll find your memory goes further with Espruino, but that Espruino's execution speed isn't as fast as some of the others.
    • The others generally attempt to implement all of JS ES5. Espruino implements most (but not all) of ES5 and several ES6 features - we attempt to implement what people use. http://www.espruino.com/Features
    • We don't try and tie you in to a specific ecosystem for IoT on Espruino. Espruino supports MQTT/HTTP/JSON/etc so generally you just use it with whatever IoT service you're interested in.

    These projects all consume a huge amount of time to develop and maintain - so I think it's important to look at how they're funded:

    • low.js - selling the Neonious board. The ESP32 port isn't Open Source so I'd be a little worried where you stand here.
    • Iot.js - Samsung - I'm not sure where you stand with support
    • Mongoose - they're selling their platform so they'll want you to use that, however they also provide paid support by the look of it.
    • Espruino - is funded mainly by sales of the official Espruino boards that run Espruino. We make nothing from ESP8266/ESP32 so offer no support - apart from what the (very good) community provides.

    Hope that's some help!

  • Thanks Gordon, you should think about to add this great piece of information to the Espruino home page and your conference slides!

  • Thanks - I'll make sure I add that to the links page at the least :)

  • Many thanks Gordon.
    Your intervention is very useful to better understand the "philosophy" behind Espruino.

    But there are some technical issues, dictated by the different design choices, which at the moment we still can not evaluate and understand the implications.
    For example, Espruino is not 100% compatible with ES5/6 but is it really a problem? I think no.
    Instead I consider more interesting criticisms like this:
    From: https://www.lowjs.org/lowjs-vs-alternati­ves.html

    The API of Espruino is less powerful than the API of low.js is, as Espruino does not provide the Node.js API, which would not fit into the smaller microcontrollers. Espruino provides some API calls which mimic Node.js API calls, such as fs.writeFile, but they do not work the same way. fs.writeFile for example is blocking (there does not seem to be any way to write a file asyncronly with Espruino).
    The JavaScript engine of Espruino does not compile to byte code, but rather runs of the source code, thus is usually slower than low.js.

    Is synchronous writing a big limit (imho yes but sometimes)?
    Node.js "porting"? No, thanks. It's cool.... but maybe in the future.
    Does not using bytecode have only the slowness of execution as the only side effect? Speed is not a problem in my opinion. (moreover Espruino can compile on official boards...)

    While the ram out of memory is a problem.
    Working with sockets, json parsing, many variables, bluetooth access, use of different modules, etc ... is better a (a.e) DukTape or Espruino approach? (but then we make a breakthrough and use a Raspberry et similia :D )
    These are my/our concerns ... if someone has already experiences/opinions about it is welcome. :D

    Obviously my most technical questions will come as we encounter problems :) , for the moment I am asking only an overview to those who have already had the opportunity to use different embedded js engine. ;)

    MrB

    P.S. / Disclaimer
    In my team I choose Espruino at now because... it's funny! :)
    I like its webide, repl, life cycle of script, community, docs, ...

  • That section on the IoW.js page isn't very truthful. We implement quite a lot of the Node.js API - not all of it for sure, but enough that a lot of http/etc runs without modification.

    Is synchronous writing a big limit (imho yes but sometimes)?

    Not that I have found - especially as reads from something like an SD card are more predictable than a hard disk. Realistically IoW.js will probably have sync writes as well, it'll just 'hide' them by allowing a callback (which Espruino could easily do - it just hasn't been requested).

    Does not using bytecode have only the slowness of execution as the only side effect?

    Well, it's significantly faster to execute new JS code. It's also far more memory efficient as there's no parse tree or bytecode needed, and you get line by line debug and stack traces built in as well.

    While the ram out of memory is a problem.

    I think you'll find that Espruino works better in a low-memory environment because it doesn't care if memory gets fragmented, and GC passes are rare and very fast.

    Working with sockets, json parsing, many variables, bluetooth access, use of different modules, etc ... is better a (a.e) DukTape or Espruino approach?

    Honestly, I don't have enough experience of the other options to say. I believe Espruino is more efficient at storage of small objects, and is pretty fast with string appends. Personally, I think it works well. The Bluetooth implementation on NRF52 chips is pretty good as well - I'd be extremely surprised if the other platforms really hit that level of features/stability.

    Only thing I'd say is when dragging in external modules you might want to look at other options (or at the very least tree-shaking your code before upload).

    Maybe someone else with experience of the other platforms can chime in here?

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino vs. All

Posted by Avatar for MrB @MrB

Actions