I'm not sure. It seems like a big waste if you're going to run an interpreter for a decent language and use it exclusively as a compile target for an awful language.
I think the appeal is that web developers won't need to learn another language in order to do embedded development. That's another barrier to entry to embedded development lowered.
If you want to do new things, why not learn appropriate ways of doing those things? Is it really so hard to use more than one language when that makes technical sense?
As a member of a small startup (4 person technical team, all of us holding down day-jobs as well), the _prime_ decision trigger for technology is "what 'way of doing things' is the person allocated to a particular task going to be most productive in right now?". That's driven us in some directions that're non-obvious to outsiders - our stack is basically ARCH Linux, CherryPi, Python, Arduino, HTML5/JS - I can easily see people thinking "WTF? Why?", but there's some very good reasons behind those decisions - reasons which have probably allowed us to get to market 6 months earlier than if we'd chosen the stack based purely on technical merits rather than considering the skills and competencies of the existing team.
If we'd had corporate funding behind us, it'd almost certainly be different. But as a small startup, I'm 100% sure our slightly odd choices are the right ones for us. (And I could easily see why a different startup might decide node.js/javascript on the hardware was the correct choice for _their_ technical/development team)
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.
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 ))
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).
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).
For some people it may be easy. For others they may have awesome ideas but decide not to execute on those ideas because learning Arduino C++ or figuring out how to install Node on a RaspberryPi seems like a large barrier to entry for them. Maybe some of those people are those that make those awesome websites, and maybe with an embedded controller that feels more like the environment they're used to, they're more likely to bring their awesome ideas to fruition.
Disclaimer: I went to school with the Tessel folks.
From where I sit - it seems a lot of the UI for "internet of things" hardware is going to be your phone, so your end user facing code is likely to be html5/javascript web apps served from the webserver on the embedded hardware. There's tehn a lot of good reasons to run javascript code on the device as well. (Which isn't the approach we're taking, we've got html5/js for the UI and Python running most of the code on our hardware (for details and shameless self promotion, see http://dev.moorescloud.com/ ).
I know right? I wish there was a recording of the talk-- the slides are glossing over something that was probably either in the QA or explained during.
