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 haven't used any of these but recently I went down a rabbit hole of reading about prototype-based vs. class-based OOP, which took me to NewtonScript. It went prototype-based (inspired by Self, the common ancestor of NewtonScript and JavaScript) and because of this, many "classes" could have default data and functions point back into the ROM, meaning it was possible to have hand-held GUI apps and OS with 128KB of RAM.
Does Espruino take advantage of this technique to save on RAM, and does using JavaScript's prototype-based OOP make it more suitable than Python for low-memory situations?
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 was just about to comment saying that it was nice that they mentioned Espruino in the article and it would be great to see an Espruino build without the limitations of the old device. Great to hear you're already working on it!
Any idea which Zigbee isn't mentioned in the press release, when it seems to be available in the new SoC - would it be problematic to make use of it in the micro:bit?
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.
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?
While going in-depth with this would be fun, it think mentioning some of the proprietary cables they force onto their users is one simple example:
* Non-standard headphone connectors (to force license costs onto manufacturer)
* Proprietary bluetooth codec (to force license costs onto manufacturers)
* Not using USB connectors on phones even though they were a part of the EU
group that concluded that all phones have to have USB connectors
Absolutely this. Safari's lack of support for WebRTC is extremely frustrating. And I think has more to do with their app ecosystem/income than any technical hurdle.
Hi Gordon! Nice to meet you :) I am the author of the article, and I am quite fond of Espruino, it's a great project. Wasn't aware that Espruino has FFI API!
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...
I definitely experience it a lot with math. I think the way we learn and "write" math is somewhat different from how our brain does it. So you need to give it a bit of time to translate everything to its language and back to the formalism we use.
Sometimes I feel like a problem is way easier in unconscious space, like I'm sure solution is there, I can almost see it but it needs time to encode it in the much slower conscious form.
Patrick Rothfuss (Kingkiller Chronicle) mentioned a similar thing in writing, I think. He'll be stuck trying to describe something and he just can't get it "right", so he'll go for a walk or something and later his mind will come up with the perfect prose to insert at the part he was stuck on.
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.
Ok, Wikipedia says it's KL26Z, also 16K RAM, good. I was concerned there may be some cheating with higher RAM available on it. But nope, folks now will really need to optimize stuff to do something useful in 16K ;-).
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.
I'd be willing to help put Lua on the thing, if that's of any interest. I guess I'll start thinking about that when the boards ship and I have one available.
Am I right in understanding you put Espruino on the micro:bit - care to tell us more about that?
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)