At first glance it looks a bit like Vue.js - did you create this to scratch an itch or learn something? Was there an objective when you created this library, to solve a problem that the current set of front library tools currently are not addressing? Sell me on why javascript developers should be using your library over the other tools that dominate the front end landscape.
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.
At first glance, this seems like it would be painful to write for. It doesn't seem like it really makes anything easier than HTML and vanilla JavaScript.
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.
JSX vs Templates has almost evolved into a holy war at this point within the js community. There are benefits and drawbacks to both, so you'll find people coming down on either side of the argument.
My main reason for preferring templates over jsx is that it allows to separate the functional component code behind the scenes from the actual rendered html in a cleaner fashion, imo, than just embedding the html directly into the JS code. I could also say that, due to my background, I am just more comfortable with it, as well.
And to elaborate on the other side of the argument: JSX creates plain JavaScript objects instead of exposing an "almost-JS" templating language. Additionally you get an enormous amount of flexibility. For some types of apps that is very important.
I'm not certain I would call Vue.js templates as an 'almost-JS' templating language. It is pure html. A browser could render it without any js backing it up.
I can't speak for many other template specs, but I believe Angular.js was just pure html, as well, using custom properties to perform the binding between the html and the backing js, which is very similar to what Vue.js does, in that aspect at least.
I should have said that it's the best in my opinion. I think people from different backgrounds do prefer different methods, for example Vue seems very popular with PHP.
I came from a java background. Company I started at used an old templating approach using freemarker, and you could say it just stuck with me. I'm not 100% opposed to JSX, and I think it has its uses, but I prefer to keep the rendering layer separate from the functional code behind the component. I'll grant that a lot of frameworks like Angular.js and Vue tend to blur those lines a little bit with their approach due to directives, but in the end, it is still html, at least, and I like that kind of simplicity.
Agreed. I'm hoping JSX (or another JS-first approach) becomes the de-facto standard for frameworks. Svelte seem interesting but giving up JSX is too much to ask. A framework like Svelte that "compiles away" the JSX would be worth looking at.
If you use functions DOM/JS can become really powerful. You are only limited by your imagination. If you are into functional programming (FP) you can combine a function that returns an entire app.
I really like Developit's (makers of Preact) JSX alternative 'htm'[1] which was inspired by lit-html[2]. It uses tagged template literals so you can run them in the browser during development without needing to compile to hyperscript first (but you should compile during production builds)
Interesting - it seems more verbose but fairly expressive. Two thoughts: (1) a (more) declarative model would interesting vs. all the callbacks, and (2) where's your to-do app, lol -- all the frameworks have one? :P
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.
Fantastic example of everything not to do. People seem to forget languages are meant for humans to actually write in and be productive in. I think there tends to be this idea that if you make a language constrained/annoying enough to write in then it makes bugs impossible, and that's not true -- it just makes productivity impossible.
This API makes little sense to me. If you are going to manually create a vdom, why not just use the native browser APIs to manually create an actual DOM? Most developers tend to prefer not to manually construct DOM elements, but in this case it looks like vanilla DOM would be both easier and less verbose.
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.
There are too many non constructive negative comments. Not many web engineers understand how the dom really works, or how to make a library. I applaud this tech demo.
Would I use this in production? No. But the author is not asking for that. It takes a lot of guts to create something and show it to this community. I really enjoyed looking at how the code progressed, how the author tackled a difficult subject, and their replies to constructive comments. Keep it up!
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.
I really like the angle of the project. Today it is very hard to talk with people about such approaches. People are so close minded about how to do stuff. I would really love to see a hands on how you use it because it must be brilliant. I would hope more people have this kind of out of the box thinking. It is the innovative spirit that drives world forward.
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.
reminds me of Jack Slocum's original Ext.JS with Yahoo UI components .. circa 2006/2007..
Appreciate the awesome effort! even though the industry overall moved to templating model (JSX) which makes it easy.
51 comments
[ 3.3 ms ] story [ 114 ms ] threaduserinterface.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.
I'm glad you're even asking the question, thanks.
Input:
UserInterface.model({ name: "children", method: UserInterface.appendChild, properties: { tagName: "div", className: "model", children: [ { tagName: "div", className: "child", textContent: "My first child" // and so on.. } ] } });
UserInterface.runModel("children", { parentNode: document.body });
Output:
<body> <div class="model"> <div class="child">My first child</div> </div> </body>
My main reason for preferring templates over jsx is that it allows to separate the functional component code behind the scenes from the actual rendered html in a cleaner fashion, imo, than just embedding the html directly into the JS code. I could also say that, due to my background, I am just more comfortable with it, as well.
I'm not certain I would call Vue.js templates as an 'almost-JS' templating language. It is pure html. A browser could render it without any js backing it up.
I can't speak for many other template specs, but I believe Angular.js was just pure html, as well, using custom properties to perform the binding between the html and the backing js, which is very similar to what Vue.js does, in that aspect at least.
1. https://github.com/developit/htm
2. https://lit-html.polymer-project.org/guide
Because someone wrote it and wanted to share it. That's reason enough.
Kudos to the author for sharing and good luck.
edit: what I don't get is how this post ended up at #10 of /news (I'm jealous)
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:
Or with JSX that compiles down to what you have in your `properties`: 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: 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.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.
Would I use this in production? No. But the author is not asking for that. It takes a lot of guts to create something and show it to this community. I really enjoyed looking at how the code progressed, how the author tackled a difficult subject, and their replies to constructive comments. Keep it up!
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.