Good intention, but have to forward with template literals

[gybfefe]

I think ES6 has a good evolution too, so why not implementing template literals?

[whiteinge]

Sounds like you want hyperx which can work alongside and with hyperscript.

Speaking for myself: If the markup will be primarily created by JS developers then I strongly prefer not using strings. Strings might be advantageous if the markup will be written by non-JS developers such as designers, UX, or CSS front end developers. Enclosing markup in a string sidesteps (or makes harder) all the programmatic advantages that come with generating individual elements via a direct JavaScript function -- syntax highlighting and parens balancing in my editor, linting, type checking, function composition, complex object/array spreading, and generating/combining arrays of elements via map/filter/reduce. Although the HTML syntax might be more familiar inside a string that's a temporary and small barrier to entry.

tl;dr: Choose whatever is best for the team doing the actual work. :-)

[gybfefe]

@whiteinge Not sure about your editor, but mine has a Template literal editor: https://marketplace.visualstudio.com/items?itemName=plievone.vscode-template-literal-editor

• thnx the direction toward hyperx by the way

[nclu]

I had the same thought about using templates, and decided to try out the same wrapper idea on the "emmet" thread and made my own:
https://github.com/nclu/template-literal-hyperscript

t`div#page
  div#header
    h1.classy ${{style: {'background-color': '#22f'}}}h
  div#menu${{style: {'background-color': '#2f2'}}}
    ul
      li one
      li two
      li three
  h2 ${{style: {'background-color': '#f22'}}}content title
  p
    $so it's just like a templating engine,${'\n'}
    $but easy to use inline with javascript
  p
    $the intention is for this to be used to create${'\n'}
    $reusable, interactive html widgets.`