using modules in modules?

I did not walk through the code yet. But somehow I feel that the elements act too individually and independent. I did not encounter the notion of focus. In a UI all elements interact somehow with each other... like the view (UI) elements are connected through the controller with each other and the model in the MVC concept. May be this interaction is there but I didn't notice.

The other challenge is a typical javascript challenge - but it is only a challenge when thinking C/C++ (or any other) - so called - compiled language... Sorry - and not sorry at all - to repeat myself and pointing to some 3 cents contributed in a different conversation: simple explanation how to save code that espruino run on start?.

What trips most non-Javascript-natives off is the fact that when the code is uploaded, 'things' already happen. I was used to Smalltalk before being 'brain-washed' with Javascript. What is kind of common in both of these languages, that after the code is loaded - there exists a cluster of objects (instances and class instances, so to speak). In Smalltalk, this is called an image, and when something new is defined, for example, a class, it is added to that image of objects. Similar to key words in Javascript, of which one the function f() is a very important one, especially when used as a constructor / 'class' object. The concept of an image - memory with alive objects - is the same in Espruino. On save() Espruino saves all - variables/state AND code/class/function definitions in its current state in RAM - as an image - into the Flash EEPROM. When powered on again, RAM is loaded by copying this image back from EEPROM and execution is kicked of by Espruino invoking onInit() and all ```E.on("init",function(){})-registered functions.

Btw, above aspects made me chose the DOM approach in my UI setup to follow the Browsers' great implementation choice. Last but not least is the Browser the world Javascript was born into:

While HTML(5) is streaming into the Browser, the browser interprets the incoming tags... and so also the script tag. All what follows this tag is directly passed on to the Browser's Javascript engine and interpreted(note1) by it: if it is in top level / level 0 - it is executed directly, such as var v = 5; and var d = new Date(); and require("module"); and - 'worse' - require("module").connect(); (or what ever method/function is invoked on the required module object - static or dynamic). The same happens with function f() { ... }, which creates a function object which is reference-able with fin the object space (syntactically equal with: var f = function() { .... };. The same happens when code is uploaded to - streaming into - Espruino(note2): top/level code is executed immediately(note3).

You mention space / memory concerns... a reason that I separated data from code and chose the cheapo-oo approach for my UI implementation: data is in simple and fast arrays and code are methods on the UI singleton. Your perfect oo representation and legibility just costs a bit too much in memory because of the amount of source code that is required to describe each element. Agreed, it allows you to have a nice omitting and defaulting of values when a property is not provided in the constructor parameter object. On the other hand, practically every time the core attributes show always and create a lot of property name repetition. Yes, the methods can easily be attached to the 'class' with prototype, but that's about it. Similar challenge is faced by the color info... Even though I like very much the freedom, most UI's (have to) use a color palette and a single integer can pick the color. When it comes to MCs, frugality is of the essence - I hated to go down this route and [leave the path of oo-virtue by going for parm list and storage in arrays - but it paid off in terseness without compromising ease of use. I could go even further, and make the UI elements definitions in top-level/level-0 in nested array and thus save even more space...

I could think of your UI implementation to be used as a generator for condensed code to be executed on a runtime implementation (GWT uses such an approach, where stuff is even developed in a different language - Java - and cross-compiled/generated into Javascript and paired with a runtime piece).

I hope some of this brain-dump is useful to you in moving your stuff forward.

(note#)s in next post...