It sounds like a very good idea! However, on Linux in Firefox as well as in Chrome the UI (helix) doesn't seem to be very responsive, i.e. the slider is jittering making it feel very sluggish. Is that a bug? However, I see multiple cores being utilized. Same on mobile...
I don't really buy the template argument. Think declarative layouts such as QML, React, etc. are there for a reason...
Why focus that much on mjs? Wouldn't you use Typescript anyway? i.e. you still have source map (beside I never had problems with source maps)
did you try using the mouse-wheel? (scrollY does zoom, srollX rotates). please let me know in case the performance doing so is not nice.
so far neo.mjs is just using input type="range" for sliders, which are ok-ish on MacOS. real sliders are on my todo list, but to implement them i need to create drag and drop first. this one is an epic, since drag happens inside the main thread while the handlers live within the app worker. i will update the vision file today to shed some light into what is coming next.
the template discussion is a big one :) you could argument that most APIs were XML 5+ years ago and now close to all are JSON based. imo writing string based markups is a legacy thing which should get replaced. think about it this way: to compare virtual dom and get the deltas, vdom structures have to be json based (js objects & arrays). in case you write markup strings, they need to get converted into JSON, which is expensive. you could argument now, that those replacements can be done as a build process, which is true if you want to limit your components to just a few states. imagine you would create the helix using states and how many templates you would need => there would be a massive overhead to load all those parsed templates.
neo.mjs goes one step further: you can not just define your markup as JSON, but this structure(s) are persistent throughout the component lifecycle. meaning you can change them the same way before & after a component gets mounted.
the whole scoping madness including functions or variables into strings just does not exist, which can save a lot of time. also, the part where you put a component based tag into a string based template which automatically creates a matching JS instance does not exist, which makes it very convenient to re-use the same components (think about a list with component based items).
i would use TS in a heartbeat if browsers would support it out of the box. one major design goal of neo.mjs is to not have any JS related build processes for the dev mode. the benefit to debug the real code should be obvious (transpiling code can create bugs).
I think I hit the dom tree update limit on my machine. Reducing the number of items to 100 makes it work all right (using the mouse wheel, slider still not working good) but its also not really impressive.
Maybe have a look at old multithreaded BeOS demos and consider to implement something like that. For example, do some heavy work in some workers while the UI thread renders the ongoing results in a smooth animation and let users dynamically change the number workers (BeOS had a demo which allowed user to switch cpus on/off during rendering with fully responsive UI).
i would like to add: that neo.mjs is not using TS does not mean that you can not use TS for your app code. in case you really want to, it should be possible.
i recommend to take a look into the ES class system extensions as well, especially the config system (see src/Neo.mjs).
I don't really buy the template argument. Think declarative layouts such as QML, React, etc. are there for a reason...
Why focus that much on mjs? Wouldn't you use Typescript anyway? i.e. you still have source map (beside I never had problems with source maps)