It seems like the biggest win here is not having to use a transpiler, though I feel like most projects would already have Babel in there. Other than that, not sure if this buys the developer anything that JSX doesn't since the syntax is still somewhere in between HTML and JSX. However, cool and interesting approach!
You still need babel if you want to compile it for production, to get rid of the extra bytes.
To me, the benefit of actually using it in existing Preact/React code is that it is actually much closer to HTML. Being able to use class instead of className is nice :)
What I meant is that either way you are taking a bunch of markup syntax and translating it to React.createElement() calls. Whether you import a library function and do that work there or let a Babel plugin do the work, it's up to you. The latter is a bit cleaner IMO but it requires a transpile step. If you're doing that anyway then may as well use JSX.
Yes exactly, in most build setups using HTM will be compiled just like JSX is.
After thinking about it a bit more, these are my reasons why to use HTM over JSX:
it's less magic, as you can see that it's a Tagged Template
because of less magic, it's also more beginner friendly
it's closer to HTML, without JSX limitations like class/className
And the biggest reason: no build step! I mean, look at the example... it's a 3.7KB js dependency and you can build preact apps!
To me, this is a taste of the future. A future where build tools won't be necessary anymore. Until then, we still need to transpile, code-split, optimize etc. using build/bundle tools like webpack.
Yeah. In most cases these days, the transpiler is a given. However, I could imagine a lot of circumstances where evaluating without transpiration is much more convenient. Enough so to possibly drop the need for jsx altogether.
Had these two things come along at the same time, good chance we don't bother with the rigmarole of jsx.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It seems like the biggest win here is not having to use a transpiler, though I feel like most projects would already have Babel in there. Other than that, not sure if this buys the developer anything that JSX doesn't since the syntax is still somewhere in between HTML and JSX. However, cool and interesting approach!
You still need babel if you want to compile it for production, to get rid of the extra bytes.
To me, the benefit of actually using it in existing Preact/React code is that it is actually much closer to HTML. Being able to use
classinstead ofclassNameis nice :)What I meant is that either way you are taking a bunch of markup syntax and translating it to
React.createElement()calls. Whether you import a library function and do that work there or let a Babel plugin do the work, it's up to you. The latter is a bit cleaner IMO but it requires a transpile step. If you're doing that anyway then may as well use JSX.Yes exactly, in most build setups using HTM will be compiled just like JSX is.
After thinking about it a bit more, these are my reasons why to use HTM over JSX:
And the biggest reason: no build step! I mean, look at the example... it's a 3.7KB js dependency and you can build preact apps!
To me, this is a taste of the future. A future where build tools won't be necessary anymore. Until then, we still need to transpile, code-split, optimize etc. using build/bundle tools like webpack.
If Babel isn't necessary, I wonder what would happen under the hood if you bundled a new project with Parcel.
Yeah. In most cases these days, the transpiler is a given. However, I could imagine a lot of circumstances where evaluating without transpiration is much more convenient. Enough so to possibly drop the need for jsx altogether.
Had these two things come along at the same time, good chance we don't bother with the rigmarole of jsx.