That's the thing, though, I deeply beg to differ on that and I really think your view and statement that using HTML syntax is so much better is just very subjective. Both of our projects create and manipulate the DOM. Which syntax to use for that purpose is IMHO irrelevant as long as it produces correct results. To me HTML syntax is nothing more than a necessary evil (Btw. I've worked w/ HTML since '95), and something I'm more than glad to have almost eradicated from my professional life, nor is it something I want to still actively embrace. Judging by the popularity of XML I'm not alone... thousands of Clojure/ClojureScript users using hiccup syntax on a daily basis also do not want to go back to literal HTML after using hiccup for more than a day.
Isn't also a large appeal of working with components to compose UIs in a more abstracted manner, with different semantics? The hiccup format doesn't use anything alien to web developers and is (objectively!) less noisy in terms of punctuation to express the same concepts. And array manipulation in JS is (again objectively!) easier than manipulating the same kind of data in some <template> DOM. Hdom's syntax is arguably also less tainted by HTML, and that makes sense and was desired, precisely because it is NOT only aimed at the browser DOM, which is just one target (the default). Since the syntax is just `[tag, attribs, ...body]` it's sufficiently general to work equally well for many other use cases not aimed a browser DOM, e.g.
- Server-side rendering
- Static site generation
- WebGL UIs, shader definitions, entire scenes
- Tagged data interchange format between different apps (on top of JSON)
- 3D printing (use as interim format before generating final G-code)
- ...
Lastly, from your new examples given, in my mind, it seems your project is simply aimed at not just somewhat different use cases (albeit there are of course large overlaps), but also a somewhat different audience. Note, I'm not saying that hdom is worse or better than lit-html, it's simply based on a (quite) different philosophy. So please don't compare apples with pears!
Isn't also a large appeal of working with components to compose UIs in a more abstracted manner, with different semantics? The hiccup format doesn't use anything alien to web developers and is (objectively!) less noisy in terms of punctuation to express the same concepts. And array manipulation in JS is (again objectively!) easier than manipulating the same kind of data in some <template> DOM. Hdom's syntax is arguably also less tainted by HTML, and that makes sense and was desired, precisely because it is NOT only aimed at the browser DOM, which is just one target (the default). Since the syntax is just `[tag, attribs, ...body]` it's sufficiently general to work equally well for many other use cases not aimed a browser DOM, e.g.
- Server-side rendering
- Static site generation
- WebGL UIs, shader definitions, entire scenes
- Tagged data interchange format between different apps (on top of JSON)
- 3D printing (use as interim format before generating final G-code)
- ...
Lastly, from your new examples given, in my mind, it seems your project is simply aimed at not just somewhat different use cases (albeit there are of course large overlaps), but also a somewhat different audience. Note, I'm not saying that hdom is worse or better than lit-html, it's simply based on a (quite) different philosophy. So please don't compare apples with pears!