Leveraging the great node ecosystem comes at a significant cost in terms of power consumption, complexity of the manufacturing process, board size and of the system itself.
Power consumption and, to some extent, board size have been very significant drags for the Internet of Everything. Mindlessly throwing libraries at them just to help people who are too lazy to learn a new programming technology is only adding a drag on it.
I certainly don't want to drag this into the mud. It's certainly a good learning platform which can provide exposure to a range of devices for people who would otherwise not even hear about them, or for whom the initial technological barriers would be too high to overcome in a single evening. But this is far, far from adding any kind of value to the struggle towards universal Internet connection.
I'm not disagreeing with you completely. I don't think I would be thrilled creating a consumer product with this kit. However, you have to admit that this would be very ideal for rapid prototyping. Unlike you, I have never programmed hardware. I think that what I would do with this product is build a prototype or two or three, just to a point where I get a proof of concept nailed down. From there, I'll be extra-motivated to reduce the size and improve power-consumption, reliability, and responsiveness by learning C in the context of embedded programming.
If what you say is true, it's a bad sign for the future of hardware. If we fundamentally can't leverage existing libraries, we can't build the standing-on-the-shoulders-of-giants complexity pyramid that allows for such reliable, rapid development in other spaces. It will always remain a niche field.
Of course we can leverage existing libraries and standing-on-the-shoulders-of-giants complexity pyramids. Slapping a webserver on them isn't necessarily a good approach though.
I think this is a great idea for getting more people to experiment with hardware projects. Then they can move on to learning more things. But for a first try the barrier to entry needs to be as low as possible.
i quote "leverage the great node ecosystem" : which is not written with performance on embedded in mind => useless.
Embedded dev is all about performances, power consumption ,etc ... it is about focusing on hardware , not about how much libraries you can throw at a problem, since you usually do not throw any,because of limited memory, computation power...
If you use node.js, you have both JavaScript and native modules.
Use JavaScript for the non performance critical parts, use C for the parts that touch the hardware, and leverage the great node ecosystem.