I'm worried that using a normal JS library would cause memory problems - in some other posts, it can be seen that the Bangle.js 1 is struggling with memory in some posts in some cases. I think I have to agree with Gordon that the upper limit for UIs on the Bangle.js is not that high to warrant very complex UI frameworks.
The reason I originally steered away from a master function is because unlike React, where there's one master function for everything (React.createElement, or jsx in newer versions) and having it always loaded everywhere is consented, a lot of Espruino apps might never want Layout (or not have it at all), so I don't think the React way of making elements is suitable for Espruino.
The way I did it in the intepreter (and what I think should be done) is without a constructor function: the JSX syntax would be a shorthand function call, basically. Esprima natively supports JSX and is used in EspruinoTools, so it would probably make sense to have it convert
<Button col="blue">Maybe</Button>
to
Button({ children: "Maybe", col: "blue" })
, though I could see why part-improvised syntax and grammar might be frowned upon.
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.
I'm worried that using a normal JS library would cause memory problems - in some other posts, it can be seen that the Bangle.js 1 is struggling with memory in some posts in some cases. I think I have to agree with Gordon that the upper limit for UIs on the Bangle.js is not that high to warrant very complex UI frameworks.
The reason I originally steered away from a master function is because unlike React, where there's one master function for everything (
React.createElement
, orjsx
in newer versions) and having it always loaded everywhere is consented, a lot of Espruino apps might never want Layout (or not have it at all), so I don't think the React way of making elements is suitable for Espruino.The way I did it in the intepreter (and what I think should be done) is without a constructor function: the JSX syntax would be a shorthand function call, basically. Esprima natively supports JSX and is used in EspruinoTools, so it would probably make sense to have it convert
to
, though I could see why part-improvised syntax and grammar might be frowned upon.