You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
In deed... listening to you is about re-listening to myself... With a similar background and with the options of shimming/polyfilling/frameworking specific platforms to a common platform, things just work portably perfect. 'Unfortunately' with the resource constraints and a non-ES(X) JavaScript interpreter/vm, things aren't as forthcoming. I recall my first request to have a module to be able to deliver 'class'/constructor and at the same time mentioning browser-side require.js/AMD - because that was the 'thing' I was used to. In the meantime I know that require() looks the same, delivers (almost) the same but works a bit different...
Espruino JavaScript puts as a bit back into the time where it really really mattered in what Browser Web pages with JavaScript had to run in... to not have a run in... ;-). I feel it is amazing how far Espruino came from when I experienced it the first time - and that was already way beyond version 1v00. Just to mention a small detail: Promises. I started out with just callbacks.
Just recently I contemplated to extend require(). With different styles of Web communications and Promises available, AMD is done... and Espruino becomes an IoT/Hardware/Controlling-'Browser' in an M2M environment vs. the original - known for quite some time now - UI/Rendering-Browser in a U2M/C2M environment.
Espruino's frugalness in just everything - power, (eep)rom and ram, and even size (w/ Espruino Pico and now Puck) - except performance and ease-of-use made me reconcile with being put a bit back in time. If mentioned resourcefulness does not matter, no need for Espruino, any other environment of dog bones and xyz berries and ... what ever single board computer you find on the market - in numbers like ants in a hill - would do (btw: rasp means obsolete... because raspberries had to be consumed right away after picking because they mush and rot/ferment quickly... may be that's why the French originally made wine out of them).
Have no answers to your questions(*), because "Was der Bauer nicht kennt, (fr)isst er nicht!" - What the farmer does not know he does not eat!... but I'm willing to learn and become an educated, gourmet farmer... ;)
(*) except for the last one: may be because reality - hardware with sensors to the real world - is involved, which is not that easy to (unit/integration-test-)emulate as what we call real databases (and other emulatable) system, even though I did that serveral time already when (cross) developing (in the Browser only) logic that uses sensor and display and motion sub-systems. The Sensors, Displays and Motions were DOM nodes. Another reason is: doing IoT on MC level, the targeted environment is pretty given and not much changing. The software is dedicated and not intended general and universal, because latter virtues are just not affordable by the available memory resources. Extensibility has to be 'thought in' in a different way.