Espruino vs. All

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

• vs. DukTape/low.js
  
• vs. JerryScript/IoT.js
  
• vs. mjs/Mongoose
  (or vs. other embedded Js engine?)
  
  
  

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, ...

(edit: see @neoniousTR's post below)

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?

Hello everyone, hello Gordon,
I'm Thomas from neonious. Just noticed this thread (Google).

Regarding your post: you are incorrect with that the async functions of low.js will block somewhere. low.js provides 100% async read/writes. The async calls go into a different thread, which does not block the code thread. The neonious one even utilizes an additional SPI flash chip for the file system, so there is no call to esp_partition_read/write or whatever which would block.

Regarding speed of byte code vs source code, the following code runs multiple minutes with Espruino, while it only runs for 5 secs on low.js:

var k = 0;
for(var i = 0; i < 1000; i++)
    for(var j = 0; j < 1000; j++)
        k += j;
console.log('Done', k);

Over all, we're trying to be 100% truthful, so if you see anything wrong in our comparison on our website, please tell me exactly what we shall change.
Thank you,
Thomas

Hi neoniousTR,
wow, that's quiet a difference in speed! - albeit it was stated Espruino isnt as fast, i'm interested if you compared the memory utilization between the two while running this? was the code compiled or interpreted as a script at the time of running? i'm assuming both are on ESP32 as the same clock and latest releases?

thanks

The ESP32-Espruino numbers seem to be valid. Did some tests (only with 100x1000 iterations, didn't want to wait minutes). All boards with 2v03, code running in memory, timing just with new Date()

• ESP32 (240MHz) - 42.7 sec
  
• Pixl.Js (64MHz Cortex M4) - 32.6 sec
  
• Espruino Wifi (100MHz Cortex M4) - 21.6 sec
  
• ESP8266 - watchdog reset even at 100x100 iterations...
  
  

Looks like the ESP32 at 4x clock speed was slower than the Cortex M4 in Pixl.JS. I think we all knew that the ESP32 port needs some optimisation. The two M4 cores run at roughly same speed if you compensate with the clock rate.
If my math is right, the ESP32 is 4.7 times slower for the same clock rate. No PSRAM on my ESP32 board, all code is ran from memory, so neither flash nor PSRAM access speed could affect this.
Did someone / can someone (with enough time) run some arbitrary benchmarks in C on an ESP32 and some ARM core? Is this the lack of optimisation in Espruino port, or the Xtensa core itself is significantly slower than ARMs?

@neoniousTR your board + the dev experience looks cool! Added it to the waaaa-looks-interesting-but-don't-get-on­e-already-have-too-much-stuff category :)

Hi Thomas,

Thanks for posting! Did you modify the https://www.lowjs.org/lowjs-vs-alternati­ves.html page? It sounds a lot better now.

Neonious looks like a really neat package with the IDE. Having some non-open source parts is a clever move as well, and hopefully allows you to develop a real business around your boards while keeping the core open. Being 100% open is something I've struggled with for Espruino, and has meant that to investors the business is effectively worthless.

That's impressive speed-wise. Are you actually using V8 under the hood, or is it Duktape, JerryScript or something else?

It's worth noting that with an official Espruino board you can do:

function test(){
  "compiled"
  var t=getTime();
  var k = 0;
  for(var i = 0; i < 1000; i++)
      for(var j = 0; j < 1000; j++)
          k += j;
  console.log('Done', k, getTime()-t);
}

And it takes 0.00004 seconds to execute - the code is converted to C with integers, compiled on a server, and the loop is optimised away by GCC. Simple JS written that way will outperform pretty much any JS interpreter because it's basically just optimised and compiled C code.

It's always problematic when people compare speed - Espruino would run that code on a microcontroller with only 4kB of RAM and I believe has been ahead on memory usage since the start - but pretty much every other JS interpreter will beat it on speed.

I guess on the plus side, it carves out a nice niche for Espruino - as everything get more powerful, micros capable of running Espruino just keep getting cheaper, lower power and smaller.

Personally I think Neonious and Espruino cover very two different areas: Espruino was designed for and works great on low power, low memory micros, and Neonious provides a more full-featured Node.js experience with the ability to use NPM packages.

Well, we might have changed it, but I do not remember when. A while ago most probably.

I understand you can compile JavaScript code to C. But it is not valid JavaScript anymore, it is a subset of JavaScript. But a cool feature non-the-less...It lets you do things with very small devices if you are willing to do it "the Espruino way".

low.js uses DukTape, but we've added a small JIT layer (does not optimize that much, however). And we try to become 100% Node.JS. We hope to get some people in the industry use it for industrial automation and things like that. A few customers we already have here.

All in all, I agree on your comparison.

@AkosLukacs thanks for running those benchmarks - that's really interesting.

I think with some work ESP32 speed could probably be improved a lot (just by making sure a few core functions stayed in RAM) - however even with that, it's going to get destroyed by most other JS engines.

I've been meaning to add a proper JIT interpreter for a while which should give it a huge speed boost, but actually there's been very little demand for it - and even if I did it, it's something I'd probably never get around to porting to Xtensa for ESP8266/32.

Just wondering: Do you actually use float with Espruino instead of the standard-conform double? We are thinking about the switch, because then we can use the FPUs. But this might break some people's programs.
This would explain btw why Cortex M4 is faster for you: ESP32 has a not really fast FPU.

@AkosLukacs yeah i ran this in 336.30secs on a puck.js with the full 1000x1000
this dropped to 77.00secs with dropping the k += j for assembly add r0, r0, r1

and then 0.00064086914 secs with

var c = E.compiledC(`
// int loops(int)
int loops(int k){
 int i = 1;
 int fiboPrev = 1;
 for(int i = 0; i < 1000; i++){
  for(int j = 0; j < 1000; j++){
    k += j;
  }
 }
 return k;
}
`);
function go(){
  var t=getTime();
  var k=0;
  k = c.loops(k);
  console.log(k,' in ',getTime()-t);
}
setTimeout(go, 500);

i didnt know about the "compiled" thing, thanks @Gordon

@Gordon sad to hear that 100% opensource has been a negative on your.
all your hardware is awesome, and your content and dedication is incredible
i'd invest if i had a few 100 mil

@neoniousTR Is https://estimote.com/ related to you, or just found another company doing JS on micros?

https://blog.estimote.com/post/186818671­945/estimote-ai-beacon
"Cloud ide": https://ide.estimote.com (note for the webdevs out there: they ship sourcemaps, if anybody is curious :) )

Nope, we have nothing to do with estimote.

Thanks, that was my guess, as it looks different than your solution.