Hey everyone! I'm the creator of this. Glad to see a few of you have tried it and enjoyed it. Any questions, just let me know below and I'll do my best to answer.
Most battery powered devices spend most of their time asleep. If your device spends 1ms awake every minute instead of 0.01ms then honestly in most cases that's not a big deal, because the power consumption of everything else in the system is 100x that.
Low.js/Moddable/Jerryscript/etc are bigger, faster more complete JS engines that provide a more Node.js-style experience, but generally for more powerful devices. With Espruino we're saying if you're willing to make a few small tweaks to the way you write code then you can use amazingly low power devices: 0.003mA sleep for nRF52 vs. 80-500mA for Raspberry Pi or 0.8mA for ESP32 (with RAM retention)
I think there were just a bunch of other features they wanted to give exposure (ML, speaker, etc), and the kid-friendly tools out there for it won't support Zigbee.
However I bet Nordic's examples for Zigbee on nRF52833 would work pretty much as-is (maybe just changing a few pin names) so you could get up and running pretty quickly.
Espruino (a JS interpreter for MCUs) runs really nicely on this too now - you get wireless programming and debug, and a full Bluetooth LE stack (you can run Web Bluetooth on the device and use to control other consumer electronics).
I'd like to see Apple implement Safari's missing functionality before they try and come up with a replacement for WebGL.
Where are getUserMedia, MediaRecorder, WebRTC, filesystem, vibration, screen orientation, Service Workers, Web Bluetooth ? What about WebGL 2? I'm sure there are a few more I missed too.
Those are things that are really holding the web browsing experience back on iOS/MacOS, not an extra 20% 3D performance and slightly shinier graphics.
Or why not lift the app store restrictions so that Google/Mozilla can actually ship non-crippled web browsers and implement it all for you?
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.
I get this too - thought it was just me/my family.
I never seem to actually 'dream' the answer, or know what it is ahead of time. It just seems obvious when I look at the code again later, and I totally rely on it now.
As others have said, actively thinking about the problem makes it less likely I'll solve it. Usually I just keep looking through my open issues, maybe writing a few lines, until I get that feeling I know how to do it.
Any other disciplines where this is 'a thing' - or is it just programming? I heard someone mention maths...
Oxfordshire countryside in England. I tried working from a small flat in London and I got totally burnt out. I like being able to look out the window and see trees, fields and a river - I've been working full-time for myself for 7 years now, I'm personally finding it's hugely important to be able to keep stress under control and get some perspective... and for me, being able to get outside really helps.
Ideally I'd move to Wales where it's cheaper and prettier, but realistically I need to be able to get to London and airports relatively quickly, as well as to not be too far from friends and family.
Thanks! Yeah, the phone apps that do it turn on the phone's flash and it works much better - but I can't find a way to do that from JS. It seems like one of those things that's in the pipeline but hasn't made it in just yet.
I'm under NDA, but I believe we can talk about things that have already been disclosed.
If you do a google image search for large micro:bit images, you'll see there's a Nordic NRF51822 chip (Which is an ARM Cortex M0, with BLE), and a Kinetis ARM chip connected to USB. It's running an mbed-compatible bootloader that appears as a USB mass storage device. You just copy hex files onto it and it programs the NRF51822.
There is currently a version of Espruino for the Micro:bit too, so kids will have the ability to use JavaScript. You can even program/debug it over BLE as well :)
However there's been virtually no interest in it so I haven't spent as much time on it as I'd have liked. Hopefully that'll change when the boards start appearing though.
As someone who's now shipped 2 hardware KickStarters on time (both of which were bigger than KoalaSafe), I find it a frustrating when people post up 'hardware KickStarters never ship'. It's just not true.
It's definitely 'buyer beware', and if you back a KickStarter that shows loads of renderings and no working finished product then you may hit trouble - but many people come to KickStarter with a working product, having already done their homework and made arrangements with a manufacturer. Those people will almost certainly ship, and it's a shame that other failed KickStarter projects make them look less legitimate.
But I totally agree with polar8 on this...
1. Design with the factory has been true for me. I did one KS in China, one in the UK - and the factories work totally differently. The time it takes to get things arranged is insane, and you absolutely need to not only have a manufacturer, but to have a design that they're happy with and can source parts for before you KickStart if you plan to ship on time (even if you plan on tweaking the design a bit later).
2. Sourcing - When you order 1000s of something, suddenly lead times matter. Generally you can't just go to Farnell and get things next-day, if they're not in stock, 13 week lead times are not uncommon - and a company can have 4000 items in stock one day, and they'll be gone the next (so checking stock levels is not enough!).
3. Features - definitely be sensible. Listen to your backers but be very careful about adding their suggestions. Changes really set you back, and the most vocal backers views are almost certainly not those of the majority. Adding features in software after the ship date is easy and people like it, but delaying the ship date for features would rarely be appreciated.
4. Margins. I think people feel bad about adding a big margin, but you've got to. There are loads of hidden costs, and most backers would prefer to pay a bit extra and have you still making and supporting devices 2 years from now.
Just to add: Overall open source has been great in my case. It's just that it's very easy for someone to make a comment on the internet - it doesn't mean they're particularly bothered about it or are prepared to do anything about it!
I actually had a lot of success with Open Sourcing. After a year of making virtually nothing out of selling Espruino as software (while being bombarded with sometimes abusive comments about the fact it wasn't Open), I decided to put it on KickStarter as Open Source hardware a year ago - and the result was very good. My second KickStarter is about to finish in 24 hours too.
It's a shame yours didn't work out - I think I was lucky I had something that could be crowdfunded more easily.
Having said that, none of the people that berated me for being Open Source have contributed anything back (others have been very helpful though). I've also had to cope with cheap clones, the possibility of competitors using my own software, and a huge support burden from users of other hardware.
As one of buro9's users, I have to say I was very happy to hear that the software was going to be Open Sourced, however I was dreading having to migrate it all to my server.
In the end I'm much happier that buro9 found a way to keep it ticking over. Given the choice of continued service vs. Open Source I definitely would have chosen continued service - but it's even better to have both!
Yes, it'd be really handy... Having said that, to be truly useful you'd need to be able to access whatever it was from some API that was common across platforms. Sadly I think it's very unlikely that any simple communications protocol will get exposed to webpages, because of potential security concerns.
Just to answer some of the stuff below:
Yes, you could write something faster and smaller in C. However chances are you'd spend a lot more time doing it, eg. https://github.com/classycodeoss/nrf52-ibeacon/blob/master/m... vs http://www.espruino.com/iBeacon
Most battery powered devices spend most of their time asleep. If your device spends 1ms awake every minute instead of 0.01ms then honestly in most cases that's not a big deal, because the power consumption of everything else in the system is 100x that.
Low.js/Moddable/Jerryscript/etc are bigger, faster more complete JS engines that provide a more Node.js-style experience, but generally for more powerful devices. With Espruino we're saying if you're willing to make a few small tweaks to the way you write code then you can use amazingly low power devices: 0.003mA sleep for nRF52 vs. 80-500mA for Raspberry Pi or 0.8mA for ESP32 (with RAM retention)