@Dennis. you hit a crucial subject regarding the 'qualities' if Javascript: do yo want to use Javascript in a light weight and hybrid mode geared towards the (memory and execution speed constraint) Espruino / uController platform/implementation or for 'strong' desktops and even stronger backends. Being very familiar with the latter, I was glad @Gordon made me think about this and 'adjust my attitude'. No insult here for that a-word, but it matters. For sure I do not want to be stupid and forget what I 'learned' about software modularity, robustness, reuse, maintainability, etc., but it IS a different way of thinking and doing things.
In todays approaches, one tries to keep the namespace 'clean' by using the various require techniques. But even those have their differences. This though does not come for free, and is even more - up to prohibitive - 'costly' on execution time, especially in Espruino context, where interpretation happens from source code and not from an internal JIT compiled 'byte'/'token' code. Any extra 'layer' eats over-proportionally into the resource pie(s), even more so if these layers are not natively implemented. Javascript's core has come quite far from the way it has been incepted. - and I like it. On the other hand: It is not the language that makes the life, it is what we say with it.
Currently I'm working on things in the WebIDE... and that would be the perfect place to make such things happen as using just any source and make sure on upload to take care of what has to be taken care of. It works as long as all participating pieces (modules) follow the same structure... since globals are a crucial part of (plain) Javascript and execution context, it is easier said than actually followed. How would the 'system' know what it pulls in? There is just so much semantics you can put into the .js file extension: Javascript... and that means a lot of different things for different contexts.
Espruino's require('moduleName') has a very simple, straight forward implementation. Again, no offense taken for any of these characterizations. The function serves well balanced what it is intended for and has even neat features for in what sequence it looks where to find the module and what shape the module is in it. Personally, I would like a bit more details in the reference doc, especially about how it works, when it applies, what it does when... assuming that most Javascript users venturing into Espruino come from a Web usage and node.js context as best. Latter does not even apply to me, even though have a server-side oriented past but worked most on the client-side/browser in regard to Javascript.
Therefore, I'm still adjusting my thinking for and shaping of solutions to run in Espruino context without giving up pushing the envelope(s)...
Looking forward to hear about progress and experience over a coffee... ;-)
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.
@Dennis. you hit a crucial subject regarding the 'qualities' if Javascript: do yo want to use Javascript in a light weight and hybrid mode geared towards the (memory and execution speed constraint) Espruino / uController platform/implementation or for 'strong' desktops and even stronger backends. Being very familiar with the latter, I was glad @Gordon made me think about this and 'adjust my attitude'. No insult here for that a-word, but it matters. For sure I do not want to be stupid and forget what I 'learned' about software modularity, robustness, reuse, maintainability, etc., but it IS a different way of thinking and doing things.
In todays approaches, one tries to keep the namespace 'clean' by using the various require techniques. But even those have their differences. This though does not come for free, and is even more - up to prohibitive - 'costly' on execution time, especially in Espruino context, where interpretation happens from source code and not from an internal JIT compiled 'byte'/'token' code. Any extra 'layer' eats over-proportionally into the resource pie(s), even more so if these layers are not natively implemented. Javascript's core has come quite far from the way it has been incepted. - and I like it. On the other hand: It is not the language that makes the life, it is what we say with it.
Currently I'm working on things in the WebIDE... and that would be the perfect place to make such things happen as using just any source and make sure on upload to take care of what has to be taken care of. It works as long as all participating pieces (modules) follow the same structure... since globals are a crucial part of (plain) Javascript and execution context, it is easier said than actually followed. How would the 'system' know what it pulls in? There is just so much semantics you can put into the .js file extension: Javascript... and that means a lot of different things for different contexts.
Espruino's require('moduleName') has a very simple, straight forward implementation. Again, no offense taken for any of these characterizations. The function serves well balanced what it is intended for and has even neat features for in what sequence it looks where to find the module and what shape the module is in it. Personally, I would like a bit more details in the reference doc, especially about how it works, when it applies, what it does when... assuming that most Javascript users venturing into Espruino come from a Web usage and node.js context as best. Latter does not even apply to me, even though have a server-side oriented past but worked most on the client-side/browser in regard to Javascript.
Therefore, I'm still adjusting my thinking for and shaping of solutions to run in Espruino context without giving up pushing the envelope(s)...
Looking forward to hear about progress and experience over a coffee... ;-)