This looks like it takes Vue.js's approach of creating a brand new language that you have to learn (in this case MVL which is similar to HTML). It's definitely a preference for a lot of people, but I prefer React.js style, which lets you use languages you already know (HTML and JavaScript) to do literally everything. It may be inconvenient at times, but you don't have to reference a new language's manual every time you want to do a for-loop to figure out whether the @for attribute should go on the li or the ul.
I prefer React.js style, which lets you use languages you already know (HTML and JavaScript)
No, you also have to relearn, just not as much. The React docs rightly state "JSX is not HTML" because you cannot use comments, doctype and it's a shame that JSX deviates from HTML in attribute names. Having to use className instead of class annoys me to no end and is why I prefer preact (they use class). Also autoComplete and spellCheck - just why? Converting this-that to thisThat makes sense but renaming attributes without necessity was a stupid decision.
I was annoyed with it too, but I read the developers reasoning for it and it makes sense. They didn't substitute "auto-correct" with "autoCorrect" for the hell of it, "autoCorrect" is actually the attribute in the JS DOM API.
So if you imagine that it's going through performing a document.createElement() call for each node then setting attributes then it makes sense. The only alternative is to maintain a list of mappings from HTML attribute to JS DOM attribute as part of the library, which would be a waste of bandwidth and irritating to maintain. The real problem is that JSX looks like HTML but is not describing HTML.
> it's a shame that JSX deviates from HTML in attribute names.
Actually, that's a React issue, not a JSX one.
JSX is attribute agnostic. You can use it with another view library like Mithril and not worry about those shenanigans (class, autocomplete and spellcheck will work out of the box).
With a good IDE that suggests these as you type, it shouldn't matter. I recommend VS Code, it does this out of the box. I like how it even suggests the right thing if I get the letters a little mixed up, like typing "speclh" suggests spellCheck={...} for me. It's great!
It's not all that annoying, tbh. At least there's a reason - those names are actual DOM names, right? Slightly annoying is to have a react function HAVE TO start with a capital case and use CamelCase.
React is quite consistent in naming things and if you write 100's of components (which you should easily accomplish if you use it seriously) then you will never mix up className and class. In fact almost everything in react is camel case which is also the most commonly used style for naming variables in javascript. This makes it very comfortable to create objects from variable names and spread it as props. It really did never annoy me at all (Maybe the first 10 components I wrote :D )
Also if you use a sophisticated IDE that shouldn't be an annoyance at all.
It works very well with preact so it obviously is possible. edit: And while you pass it often as a prop (<a class=...>) you usually never access it yourself in components - and if you do, just do `this.props['class']`.
A lot of my components contain something like this line: const Comp = ({children, className}) => {}.
If you need to merge it with some statically applied class names in your component you need to access it. This is an absolutely common thing. It would be terrible if i'd need to access it by using a string. And even then I would need to assign it to a name other then "class" which makes it even more confusing then naming it "className" by convention.
It's definitely based on preference, but I designed MVL to be as simple and consistent as possible. For example, there are two ways to create a for loop (one on the ul and one on the li).
<For={item in items}>
<!-- multiple elements -->
</For>
<p For={item in items}><!-- single element --></p>
This syntax works for every component ("For" is just another component).
That is awesome that you have <For>! That's one of my biggest pet peeves with Vue.js, where it has to be an attribute on an element, and it's not intuitive whether it goes on the parent or the child. (I think Vue makes it go on the parent but I think it makes more sense for it to go on the child.)
Ah right, thanks. Yes this always looks backwards to me. The body of a loop should be inside of it. But here it is the body of the loop. That is very strange.
Yeah, this is a big reason why the Polymer project is moving away from a bespoke expression syntax and control-flow in HTML, ala Angular and Vue, to using just JavaScript with lit-html.
But not only does it mean that users don't have to learn a new language and concepts, but it mean the maintainers don't have to develop a new language and all the corner cases, feature requests and bugs that come with it.
And in the case of lit-html, you also eliminate compilers completely because there's also no non-standard markup-in-JS syntax.
Comments
This looks like it takes Vue.js's approach of creating a brand new language that you have to learn (in this case MVL which is similar to HTML). It's definitely a preference for a lot of people, but I prefer React.js style, which lets you use languages you already know (HTML and JavaScript) to do literally everything. It may be inconvenient at times, but you don't have to reference a new language's manual every time you want to do a for-loop to figure out whether the @for attribute should go on the li or the ul.
No, you also have to relearn, just not as much. The React docs rightly state "JSX is not HTML" because you cannot use comments, doctype and it's a shame that JSX deviates from HTML in attribute names. Having to use className instead of class annoys me to no end and is why I prefer preact (they use class). Also autoComplete and spellCheck - just why? Converting this-that to thisThat makes sense but renaming attributes without necessity was a stupid decision.
I was annoyed with it too, but I read the developers reasoning for it and it makes sense. They didn't substitute "auto-correct" with "autoCorrect" for the hell of it, "autoCorrect" is actually the attribute in the JS DOM API.
So if you imagine that it's going through performing a document.createElement() call for each node then setting attributes then it makes sense. The only alternative is to maintain a list of mappings from HTML attribute to JS DOM attribute as part of the library, which would be a waste of bandwidth and irritating to maintain. The real problem is that JSX looks like HTML but is not describing HTML.
> it's a shame that JSX deviates from HTML in attribute names.
Actually, that's a React issue, not a JSX one.
JSX is attribute agnostic. You can use it with another view library like Mithril and not worry about those shenanigans (class, autocomplete and spellcheck will work out of the box).
With a good IDE that suggests these as you type, it shouldn't matter. I recommend VS Code, it does this out of the box. I like how it even suggests the right thing if I get the letters a little mixed up, like typing "speclh" suggests spellCheck={...} for me. It's great!
is it weird that i prefer vim rather than fancy IDE for almost everything?
It's not all that annoying, tbh. At least there's a reason - those names are actual DOM names, right? Slightly annoying is to have a react function HAVE TO start with a capital case and use CamelCase.
React is quite consistent in naming things and if you write 100's of components (which you should easily accomplish if you use it seriously) then you will never mix up className and class. In fact almost everything in react is camel case which is also the most commonly used style for naming variables in javascript. This makes it very comfortable to create objects from variable names and spread it as props. It really did never annoy me at all (Maybe the first 10 components I wrote :D )
Also if you use a sophisticated IDE that shouldn't be an annoyance at all.
let { class } = this.props
Class is a reserved word. This is why they stuck with the dom attribute names. Because it is JS, not html :)
It works very well with preact so it obviously is possible. edit: And while you pass it often as a prop (<a class=...>) you usually never access it yourself in components - and if you do, just do `this.props['class']`.
A lot of my components contain something like this line: const Comp = ({children, className}) => {}.
If you need to merge it with some statically applied class names in your component you need to access it. This is an absolutely common thing. It would be terrible if i'd need to access it by using a string. And even then I would need to assign it to a name other then "class" which makes it even more confusing then naming it "className" by convention.
You really should check out lit-html. The JavaScript parts are real JavaScript, and the HTML parts (in JS template literals) are real HTML.
It's definitely based on preference, but I designed MVL to be as simple and consistent as possible. For example, there are two ways to create a for loop (one on the ul and one on the li).
This syntax works for every component ("For" is just another component).That is awesome that you have <For>! That's one of my biggest pet peeves with Vue.js, where it has to be an attribute on an element, and it's not intuitive whether it goes on the parent or the child. (I think Vue makes it go on the parent but I think it makes more sense for it to go on the child.)
IIRC for Vue.js it goes on the child, i.e.
It is something you do have to remember. I believe you can use a template tag too if you like.Ah right, thanks. Yes this always looks backwards to me. The body of a loop should be inside of it. But here it is the body of the loop. That is very strange.
Yeah, this is a big reason why the Polymer project is moving away from a bespoke expression syntax and control-flow in HTML, ala Angular and Vue, to using just JavaScript with lit-html.
But not only does it mean that users don't have to learn a new language and concepts, but it mean the maintainers don't have to develop a new language and all the corner cases, feature requests and bugs that come with it.
And in the case of lit-html, you also eliminate compilers completely because there's also no non-standard markup-in-JS syntax.
There is handlebar, you can use it with Glimmer.js. It is still the fastest and future proof with WebAssembly.