Your comments means a lot to me. And by a lot I mean a number that even a quantum computer would have a hard time dealing with!
I will keep on doing what I like to do and keep a very close eye on my enthusiast so that it will never leave my side. We are very much a like in the regard, variety make for a great part of the world in its own.
I am not sure if there would be anything for you to gain today but if it's not today I surely will be making something that is at least worth seconds of your time.
I think you have a great point, how about code snippets or renaming the global object in your index.html or application entry point? Thanks for looking at it, I appreciate.
With those kinds words I feel like could reach for the farthest unknown places of space. A never ending thank you for those kind words. And a big thanks for even looking at it, it means a lot to me.
UserInterface.model({
name: "children",
method: UserInterface.appendChild,
properties: {
tagName: "div",
className: "model",
children: [
{
tagName: "div",
className: "child",
textContent: "My first child"
// and so on..
}
]
}
});
vdom was probably the wrong terminology for me to use. What I'm getting at with that is that your properties are like a virtual dom tree.
The majority of what I see being painful to use here is caused by exposing all of that manual boilerplate. You can do something equivalent with a hyperscript-like syntax:
h('div.model', [
h('div.child', 'My first child')
])
Or with JSX that compiles down to what you have in your `properties`:
<div class="model">
<div class="child">My first child</div>
</div>
You could even trivially add a helper function with low runtime costs that makes it easier to write out the properties. Just using `h` here since it's like hyperscript, but you could call it something better:
function h(tagName, attributes, ...children) {
return {
tagName,
...attributes,
children
}
}
That alone would make it easer to read and write properties. The example would become:
There are other things that you can't fix with syntax changes, though. For example, each model defining the `method` used to add it to the parent seems backwards to me. Shouldn't a component only care about its own state? Down the road, if you wanted to add one of these `children` things to another element by prepending it rather than appending it, you'd have to have to change the child.
The helper function is one hell of a great idea. I like it.
I get your point, and it's a fair one. Right now if you want to "prepend" you have to add a container as first child and give it a className to identify it and then use the "runModel" on it.
I like the idea of going the opposite way and I also share your thoughts about component only caring for its own state.
Thank you (again) very much for your feedback, much appreciated.
You're right, I will surely make one. I am not sure if you found the few demos I listed in the README? Were they not welcoming enough? Thanks for the feedback.
To begin with, by all mean use React, Vue and others.
I think they're amazing and got me super excited whenever I deal with them.
userinterface.js was made out of the frustration I went through when I was maintaining multiple Browser Extensions.
I wanted it to exploit my existing knowledge of DOM API and JavaScript language. Something that would at least try to befriend CSS, HTML and JS to make them work together in a semantic fashion.
Giving their own world to each of the parts of the UI was for the most part the core aspect of it.
Most of the frameworks you mentionned have their own ecosystem, I find them pretty hard to integrate in contexts such as Browser Extension if you do not wish for a never ending build toolchain.
I think a fair comparison for userinterface.js would be the Web Components API.