Live data from Hacker News

mJS – A new approach to embedded scripting

mongoose-iot.com

51–60 of 61 posts

Re: mJS – A new approach to embedded scripting

#51
post #45

Earlier quoted context omitted.

Duktape website: "Embeddable, portable, compact: can run on platforms with 192kB flash and 64kB system RAM"

Also http://www.esp32.com/viewtopic.php?t=497

Ah, thanks, wrong about flash footprint. Neil has done a great job adopting Duktape on ESP32.

Re: mJS – A new approach to embedded scripting

#52

25k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language's compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM. How's the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through…

1kb RAM and 25k of flash is impressively low for Javascript engines for embedded system. I know it is still heavy for MCUs. Other JS engine implementations like Ducktape [1] and Jerryscript [2] takes more than 10kb of RAM and 150 of FLASH. Javascript is simply much heavier you might think. But I personally don't see any benefits neither.

[1] http://duktape.org/

[2] http://jerryscript.net/

Re: mJS – A new approach to embedded scripting

#53
post #42
post #40

Earlier quoted context omitted.

> none of the popular scripting languages have been designed for the embedded environment in the first place Also false for Lua. It is designed to be embedded.

Embedded environment in this context means hardware low on resources, e.g. microcontrollers. Your perception of that word is "embedded into the C/C++ program". These are two different things. I agree that Lua (like some other languages) were designed to be embedded into C/C++ apps.

Something like this? http://www.nodemcu.com/index_en.html

Re: mJS – A new approach to embedded scripting

#54
post #32
post #18

Earlier quoted context omitted.

Agreed that on-a-whole JS is not appropriate for embedded devices. However allowing scripting may be useful in particular pieces of the code, to allow easy extension / customization.

I recall that very much the same opinions were expressed about the JS and backend programming, until node.js appeared. Now the reality is different. To be honest, we do not think that JS is a good language for embedded. Like any other existing popular scripting language. Perhaps scripted Go would be a better choice. The point is that in many, many cases scripting brings a lot of benefits to the embedded environment.…

I would prefer to see a scripted Go over JS for embedded environments.

Re: mJS – A new approach to embedded scripting

#55
So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support?

Why is there so much stigma against _learning_ to code in something other than $favlang these days? Most hard core developers I know appreciate the importance of using the right tool for the job, I don't see embedded/desktop developers shying away from using whatever the native toolkit/language is for their chosen platform and instead shoehorning $x to fit as much as we see this constant trend to try to use "web tech" everywhere. (Scripting in embedded systems has long been a solved problem: use lua.)

Re: mJS – A new approach to embedded scripting

#56

So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support? Why is there so much stigma against _learning_ to code in something oth…

For example, I'm working on a dashboard for wifi routers that displays information beyond what is provided by OpenWRT's ubus system. We're get this information from the kernel, but it needs to be converted to JSON to be consumed by the dashboard frontend. Right now, I'm converting the information to JSON using Go, but there are some platforms that Go can have problems compiling binaries for. We have also written a lot of C for these routers, but doing this kind of thing in C would just be overly cumbersome. Shell could be an option, but it is also cumbersome. Lua could be an option, but I don't know much about it and I don't know how well it supports JSON. Most other developers that will work on this don't know much Lua either.

mJS might also be an option. I don't really see what's wrong with that if we have the space for it.

This can probably get types from Flow, since it is valid es6. Flow has no compilation step or runtime component.

You may have a point about the debugging, but JS is pretty easy to debug by printing to stdout.

Re: mJS – A new approach to embedded scripting

#57

So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support? Why is there so much stigma against _learning_ to code in something oth…

_learning_ is an investment, and most times it doesn't make sense to invest years to learn a couple of languages to be efficient.

I'd say it's better to know one language and know it well.

Re: mJS – A new approach to embedded scripting

#58

Earlier quoted context omitted.

None of which are particularly appropriate for embedded programming.

I've adopted a rule where I try to replace a sentence, thought, or expression with, "That's different from how we do things right now," and then try to see if it changes the meaning of what was actually said. Mostly, this is useful when the comment serves to justify shooting down another idea. "We can't do things that way, because we do things a different way", is something that many people will automatically recogni…

The answer is nothing is wrong. Some form of shell, stack or scripting language is a super useful tool in the prototyping stages. It might not meet timing requirements for a final system, but at the beginning of a project it's great.

Re: mJS – A new approach to embedded scripting

#59
post #48

Espruino's had an FFI interface for the last 3 years! Nice to see they did their research :)

Hi Gordon! Nice to meet you :) I am the author of the article, and I am quite fond of Espruino, it's a great project. Wasn't aware that Espruino has FFI API!

Hi! Thanks, v7 looked great too. mJS looks like a good idea - IMO it'd be nice to standardise a sane, minimal subset of JS that can be easily implemented - it'd be a huge help for all the developers of embedded JS interpreters, and could potentially be targeted by transpilers too.

Re: mJS – A new approach to embedded scripting

#60
post #56

So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support? Why is there so much stigma against _learning_ to code in something oth…

For example, I'm working on a dashboard for wifi routers that displays information beyond what is provided by OpenWRT's ubus system. We're get this information from the kernel, but it needs to be converted to JSON to be consumed by the dashboard frontend. Right now, I'm converting the information to JSON using Go, but there are some platforms that Go can have problems compiling binaries for. We have also written a lo…

Lua is the easiest language to learn I ever saw. It has a fantastic json support with the cjson library (https://luarocks.org/modules/luarocks/lua-cjson). It's there by default on many firmwares. Do check the docs for nodemcu, for example: https://nodemcu.readthedocs.io/en/master/ (a firmware for the ESP microcontrollers)

Not to mention Lua itself can be used as a data / configuration language, their tables syntax is made especially for that. Normally when I work with Lua I don't feel the need to embed any other parsers for configuration, but cjson is there if you want.

Post reply on HN