With a simple example you will not see much of a difference indeed, but I would not use the second version in a bigger project.
One of the reason would be that is too abstract and less verbose and will lead to a lot of extra code when doing something custom. If I just want to add a simple <i class="me"></i> I do not want to define it as a function, send a parameter and so on, I just want to insert a HTML snippet, as it is.
The reverse applies too, looking more like the end product (HTML), the first solution is easier to understand when things get bigger. The overhead is bigger in Hyperscript, you need to stack all the calls in your head and compile it to HTML to understand it.
Hyperscript looks like Flutter/Dart, and there I guess makes more sense, first of all you don't have HTML and you have strong typed objects.
Could you elaborate on how hyperscript leads to extra code? I don't see much difference between adding <i class="me"></i> or i({ class: 'me' }) in the view code.
The function i would normally be provided by whatever hyperscript library you're using, it's not like you need to implement a new function for each html element that you decide to use.
In this example yes, but it does not matter who wrote the function, is extra JS code that does not carry its weight. It does not add any benefit, it is just syntax sugar. It is extra code that runs on VM, is downloaded and you have to learn it.
It is not ebough to learn html, you have to learn what elements are in hyperscript as functions, again, a layer of useless complexity in the developers head.
As far as I know, JSX compiles to only one function, the h function (or hyper function). The type of element you create is actually passed as the first argument as a string to this function. Therefore, as long as you only create built-in HTML elements (and not, let's say, custom react components) there are no additional functions involved.
The h-function takes three parameters:
The name/type of the element as a string
The properties of the element as an object
An array of child elements, in turn produced by the h function
With a simple example you will not see much of a difference indeed, but I would not use the second version in a bigger project.
One of the reason would be that is too abstract and less verbose and will lead to a lot of extra code when doing something custom. If I just want to add a simple
<i class="me"></i>I do not want to define it as a function, send a parameter and so on, I just want to insert a HTML snippet, as it is.The reverse applies too, looking more like the end product (HTML), the first solution is easier to understand when things get bigger. The overhead is bigger in Hyperscript, you need to stack all the calls in your head and compile it to HTML to understand it.
Hyperscript looks like Flutter/Dart, and there I guess makes more sense, first of all you don't have HTML and you have strong typed objects.
Thanks for your input!
Could you elaborate on how hyperscript leads to extra code? I don't see much difference between adding
<i class="me"></i>ori({ class: 'me' })in the view code.In this example the extra code is the function named i and the code that handles its properties
The function
iwould normally be provided by whatever hyperscript library you're using, it's not like you need to implement a new function for each html element that you decide to use.In this example yes, but it does not matter who wrote the function, is extra JS code that does not carry its weight. It does not add any benefit, it is just syntax sugar. It is extra code that runs on VM, is downloaded and you have to learn it.
It is not ebough to learn html, you have to learn what elements are in hyperscript as functions, again, a layer of useless complexity in the developers head.
But JSX also compiles into javascript functions, doesn't it?
As far as I know, JSX compiles to only one function, the
hfunction (orhyperfunction). The type of element you create is actually passed as the first argument as a string to this function. Therefore, as long as you only create built-in HTML elements (and not, let's say, custom react components) there are no additional functions involved.The
h-function takes three parameters:hfunctionSo, this example:
<span><i>Hello!</i></span>would compile to something like this:
h('span', {}, [ h('i', {innerHTML: 'Hello!'}, []) ] )sounds reasonable:)