[BWStearns]

This is perfect logic for a small startup, it is less so for a hardware team that is going to be pay dearly for changing decisions they make today (moreso than a software team). Hitting a big ecosystem is definitely a viable reason to do something when targeting developers, but what about the longer term costs associated with it? Their goal is to be the bridge that lets web devs start bringing hardware online. I think it's fair to say that other less painful languages with large developer bases were available, and some have the holy trinity of sucking less, being able to run faster, and having a sufficiently large ecosystem around them.

[bigiain]

FWIW, we are a "hardware team" as well as a software team - and we're fully aware of how much some of our decisions might cost us down the track if we don't get things right enough" today… (details masquerading as shameless self-promotion http://holiday.moorescloud.com and http://dev.moorescloud.com ))

[BWStearns]

Admittedly my comment (as most comments on the internet) was a bit of armchair generalship. I honestly wish you guys the best because it's a cool concept. Would you guys consider building something for programming in Lua directly as an alternative to the JS to Lua bytecode conversion?

I just wish it hadn't been in JS, partially for the selfish reason that JS inexplicably makes me un-focus in a way that no other language can (it might be the formatting? honestly don't know why).

[bigiain]

So I (and "we" in my posts upstream) are not the original posts JS hardware team.

(FWIW, on _our_ hardware, flipping the "dev mode" switch to "on", ssh-ing into your xmas tree lights, uncommenting the ARCH/ARM repos in mirrorlist, and running "pacman -S lua" should just work. The API for our compositor (which abstracts the fine timing details of controlling the WS2812 LEDs) is available and documented both on our dev site and on github (or if it's not today, it is scheduled to be up there by next week I think).