Proposal: ESX as core JS feature

💡 Ideas
29

for clarification sake, I'll answer these first:

  • Why can't template tags support this?
    • because there's not standard syntax around string chunks in a template literal. ESX (and JSX) is syntax. So spreading that way in library-x tag will produce the unexpected in library-y tag. In ESX there won't be any issue.
  • It's true that syntax errors won't be thrown until you're actually running that piece of code, but
    • that but is a show-stopper for developers
  • if you're tagging with a built-in tag, an editor can know how to highlight it.
    • that assumes libraries exporting html as tag all work the same and offer same syntax features: they don't, because there's no standard around what you can write in a string (rightly so)
  • It doesn't get more standardized than having a standards committee do so :)
    • the committee doesn't care at all about the differences between uhtml, htm, lighterhtml, hyperHTML, and lit-html differences within the string chunks (or any other library to date) so this is not an answer, actually the problem underlined
  • I don't see why any of these options couldn't be serialized when you're not dealing with user-defined components.
    • I will answer Bergus in details, but template tags are unique, not just an array, and they are dependent of the tag consuming these, hence not serializable across libraries in a meaningful way, as those arrays can contain syntax not allowed, or ignored, in other libraries ... interoperability is template literal tag dependent there, not syntax and its standard representation dependent. The basicHTML example out of the DOM world can render the same ESX anywhere, even in current JSX based libraries. A template as array with non-specified syntax? I strongly doubt so.
  • You're claiming that ESX is interoperable with JSX, but I don't see how that is.
    • anything using a transpiler/transformer/tool around JSX will work out of the box with ESX, because they transform the code, so ESX doesn't exist in their final output. Any library compatible with ESX, will work with previously written JSX components or templates, because it will understand ESX. ESX is a migration pattern for old to new libraries parsers, and a zero-trouble for anyone already using JSX out there based on their transformer. It's 100% backward compatible due tooling removing it from the equation, and 100% forward compatible due new libraries understanding JSX too, as their parsers will recognize ESX instead and work with it.
  • it's more clunky to use template tags in regards to interpolation
    • that's the tiniest detail behind this ESX proposal, as much more than that is solved out of the box.

Please let's move this conversation in the other thread (and thanks for opening it) if any extra clarification is needed.

1 Like