Avatar for MrB

MrB

Member since Jan 2019 • Last active Jan 2019
  • 1 conversations
  • 3 comments

js & mobile developer (objective-c/swift, react native)
industrial automation & iot enthusiast but amateur (at now)
some (few) experiences in medical devices, motor control, environmental analyzes (agriculture) and failures in energy harvesting prototypes (on behalf of third parties) :P
favorite mcu: Esp32

Most recent activity

    • 6 comments
    • 631 views
  • in General
    Avatar for MrB

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

  • in General
    Avatar for MrB

    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... ;)

Actions