3 ms·

I'd still rather write markup in a format that looks like markup. I think this is why JSX is so popular. This is why I prefer something like lit-html with actu

I'd still rather write markup in a format that looks like markup. I think this is why JSX is so popular. This is why I prefer something like lit-html with actual markup. Example from hdom readme: // component w/ local state const counter = (i = 0) => { return () => ["button", { onclick: () => (i++) }, `clicks: ${i}`]; }; In lit-html: const counter = (i = 0) => { return () => html`<button @click=${() => i++}>clicks: ${i}</button>`; } Yeah, there some extra weight to the close tag, but it looks like HTML. Disclaimer: lit-html author. https://github.com/Polymer/lit-html https://github.com/Polymer/lit-html

toxmeister 8y ago
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: https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k
- spankalee 8y ago
  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...
  - toxmeister 8y ago
    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! // lit-html list = html`<ul>${items.map((i) => html`<li>${i}</li>`)}</ul>` // hdom list = ["ul", items.map((i) => ["li", i])]
    - spankalee 8y ago
      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/components/my-app.js 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/master/frameworks/non-keyed/lit-html/src/index.js#L136 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/packages/wired-combo/wired-combo.js 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.
      - toxmeister 8y ago
        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!
gwn7 8y ago
Let's start some controversy. I think JSX is popular because of historical reasons. Not the history of JSX, but the Web in general, specifically about HTML being the primary API to build web interfaces since the early days. Everyone feels at home with HTML because of this. We all started with it and it is unquestionable for many. DOM is the second way to build a web interface. But nobody in their right mind would prefer DOM over HTML as long as HTML is sufficient for the task at hand. The advent of stuff like Hyperscript and virtual DOMs of today introduced a new alternative to HTML and DOM: Now we can build our interfaces using simple data structures (POJOs). This was already possible from the beginning, but the interactivity requirements of the modern application forced us to invent the "UI as a function of the state" paradigm and this approach became mainstream after that (AFAIK). But wait... Isn't HTML a data structure as well? Not sure. It clearly started as some kind of DSL for building web interfaces. Then XML is invented and HTML was declared as being an extension of XML; thus some kind of data structure (roughly). Then it got complicated. Today I have no idea about what HTML is. This is the first part of the story. The second part is about RPC. This one is short. XML used to be everywhere until the advent of JSON. Suddenly everybody started to embrace JSON and hate XML; for several reasons most of which are reasonable. The question is.... Why isn't the same thing happening with user interfaces? HTML is a subset of XML (or something like that), and the syntax proposed in this article is clearly JSON. Why is everybody embracing JSX like crazy. Do they not find it extremely ugly, as XML is, compared to a POJO? Is HTML really a better way to represent user interfaces than a solution such as the one presented in this article? It may be hard to answer as we are all biased in favor of HTML. I'm not experienced enough to make big claims, I'm just thinking out loud, I find this topic interesting. Corrections and feedbacks are welcome. Not trying to start a flame war.
- toxmeister 8y ago
  Will respond more about that later, but just wanted to point you to Phil Wadler's 1999 paper about both XML and the S-expression approach (HTML/XML are essentially S-expressions too): http://homepages.inf.ed.ac.uk/wadler/papers/next700/next700.pdf http://homepages.inf.ed.ac.uk/wadler/papers/next700/next700....
- zeroname 8y ago

toxmeister 8y ago

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: https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k

spankalee 8y ago
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...
- toxmeister 8y ago
  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! // lit-html list = html`<ul>${items.map((i) => html`<li>${i}</li>`)}</ul>` // hdom list = ["ul", items.map((i) => ["li", i])]
  - spankalee 8y ago
    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/components/my-app.js 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/master/frameworks/non-keyed/lit-html/src/index.js#L136 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/packages/wired-combo/wired-combo.js 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.
    - toxmeister 8y ago
      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!

gwn7 8y ago

Let's start some controversy. I think JSX is popular because of historical reasons. Not the history of JSX, but the Web in general, specifically about HTML being the primary API to build web interfaces since the early days. Everyone feels at home with HTML because of this. We all started with it and it is unquestionable for many. DOM is the second way to build a web interface. But nobody in their right mind would prefer DOM over HTML as long as HTML is sufficient for the task at hand. The advent of stuff like Hyperscript and virtual DOMs of today introduced a new alternative to HTML and DOM: Now we can build our interfaces using simple data structures (POJOs). This was already possible from the beginning, but the interactivity requirements of the modern application forced us to invent the "UI as a function of the state" paradigm and this approach became mainstream after that (AFAIK). But wait... Isn't HTML a data structure as well? Not sure. It clearly started as some kind of DSL for building web interfaces. Then XML is invented and HTML was declared as being an extension of XML; thus some kind of data structure (roughly). Then it got complicated. Today I have no idea about what HTML is. This is the first part of the story. The second part is about RPC. This one is short. XML used to be everywhere until the advent of JSON. Suddenly everybody started to embrace JSON and hate XML; for several reasons most of which are reasonable. The question is.... Why isn't the same thing happening with user interfaces? HTML is a subset of XML (or something like that), and the syntax proposed in this article is clearly JSON. Why is everybody embracing JSX like crazy. Do they not find it extremely ugly, as XML is, compared to a POJO? Is HTML really a better way to represent user interfaces than a solution such as the one presented in this article? It may be hard to answer as we are all biased in favor of HTML. I'm not experienced enough to make big claims, I'm just thinking out loud, I find this topic interesting. Corrections and feedbacks are welcome. Not trying to start a flame war.

toxmeister 8y ago
Will respond more about that later, but just wanted to point you to Phil Wadler's 1999 paper about both XML and the S-expression approach (HTML/XML are essentially S-expressions too): http://homepages.inf.ed.ac.uk/wadler/papers/next700/next700.pdf http://homepages.inf.ed.ac.uk/wadler/papers/next700/next700....
zeroname 8y ago