Hellos,

JavaScript is still being used for some "IoT" embedded products, presumably because "JavaScript is the language of the Internet".
This implies the reason I want to use JavaScript is because I want web sockets, workers, Promise/async, and the fetch() interface so I can quickly cobble together a secure API server on my robot chihuahua.

But, what this wish list does is push the JS runtime over into the pi domain. You need to boot a minimal linux environment to support a Lua or V8 JavaScript runtime, so JavaScript comes with all the right Internet goodies. (The Tessels were the hardware equivalent of a Teensy LC with a wifi chip and a sluggish boot up into a tiny OS. They ran out of memory easily and could slow down to a crawl if I overwhelmed them with callbacks which made calls into the expansion ports.)

I am going to suggest that many of us like JavaScript because we like the JavaScript language itself, and we would still use it even if it did not come with native web-enablement objects. I would like a JavaScript interpreter for the Teensy that by default only exposed the same runtime features we already see in TeensyDuino: gpio, pwm, i2c, i2s, spi, etc etc. (things like sockets would be an optional library.) I would prefer a JavaScript runtime that was honest about the limitations of the memory and hardware. This also implies some way to roll-your-own JS-to-native bindings so I can easily invoke C++ things from JavaScript.

What that would mean would be I could use native JavaScript objects like Object, Array, String, etc. I would be able to create dynamic arrays/strings, but would be able to wrap creation in try/catch if I wanted to handle out-of-memory situations.

Finally, (and this is the controversial part for some folks I am sure), I wouldn't mind if this JavaScript environment for Teensy literally used the same Arduino pattern for application lifecycle:
Code:
function setup(){
}
function loop(){
}
--> That would be a departure from Node.js, where everything is top-down event-driven. But for a "version one" implementation of JavaScript, I really don't care about that. Being able to build an express.js API server is _not_ my motivation for using JavaScript. (Being able to support node-like web projects and npm would be sweet.... but only if the cost in terms of effort and overall performance is reasonable. ) The truth is, not having npm support is absolutely not a deal-breaker. I want JavaScript much more than I want the whole npm ecosystem.

Just my two credits.

Ben