I completely appreciate that there're many people who much prefer the separation between code and markup, however, if you ever worked w/ Lisp you'll also learn to appreciate that code is just data and that the earlier separation really is just a convention. Maybe that convention is much better suited for supporting different job descriptions in companies (UX vs. dev), but it's also somewhat arbitrary...
The benefits of the component as plain, non-stringified data are not the avoidance of closing tags, but what you can do with those components computationally. E.g. instrumentation, behavior/attribute injections, configuration, filtering etc. An approach based on string interpolation can only go this far, whereas having everyting as arrays, objects, iterators your possibilities of composition & transformation are almost endless...
Also, take for example the hdom-canvas support library which doesn't target the DOM itself, but defines virtual elements translated into drawing calls. Using the string interpolation approach would be complete overkill since these elements would have to be re-parsed again, in which case SVG would be faster. But I can easily manage 10k+ moving particles @ 60fps with the hdom approach:
Writing HTML in HTML isn't so much about separation of code and markup (for everyone at least, for some it admittedly is), but about representing DOM in the same way as HTML. The rules and semantics are the same (because we use the browser's HTML parser), it looks the same, children and attributes are represented the same. It'll be familiar and understandable to programmers new the library, but familiar with the web.
FYI, lit-html isn't string interpolation and templates are data, so you can transform and compose templates, operate on arrays/iterables of them, or Promises or async iterables of them, etc.
And it doesn't re-parse HTML (because it's not string interpolation), so that particle demo could also be fast - elements can also represent draw calls like a scene graph. I've been meaning to do a similar demo actually...
Thanks for the clarifications & apologies if I misunderstood some parts earlier. Will definitely check out your project more closely...
From a quick glance at the docs, though it seems to me there're a lot of other differences in approach (apart from the syntactic differences), especially WRT state. I will have to study these further before being able to comment properly...
Just one more note about XML vs. JS syntax to describe elements. As I said earlier, am sure there's ton of people who prefer the familiar way, but objectively, do you really find hdom's approach less readable? Honest question!
Absolutely, because it just looks more like HTML. It becomes much more apparent as you have attributes, larger static sections of templates, and styles.
Check out this app component in PWA Starter Kit: https://github.com/Polymer/pwa-starter-kit/blob/master/src/c...
Or the template from the js-framework-benchmarks: https://github.com/krausest/js-framework-benchmark/blob/mast...
Or the template from one of the wired-elements: https://github.com/wiredjs/wired-elements/blob/master/packag...
Given HTML-specific syntax-highlighting and large templates, I really think the HTML format is easier to read.
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!