Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

HTML-builder APIs like this are a pretty bad idea, IMO.

They assume that HTML is a closed system with no new tags, and don't account for custom elements or new tags. It doesn't even have support for existing tags like <track>, <b>, or <i> (<i> is used by some systems now for icons). It doesn't appear to have a way to emit comments.

We have the ability to embed real HTML strings, with expressions, directly into JS, which means that the rendering library doesn't have to have any knowledge or opinion of what the tags are.

This is what Lit does with lit-html templates. The example in the Van readme would be:

    const Hello = () => html`
      <div>
        <p>Hello</p>
        <ul>
          <li>World</li>
          <li><a href="https://vanjs.org/">VanJS</a></li>
        </ul>
      </div>
    `;
Such template strings can contain any HTML - any tag, comment, attribute, entities, SVG, etc.


Interestingly the `tags` object seems to support any tag name: https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...

And it still allows to provide specific types for the known HTML elements: https://github.com/vanjs-org/mini-van/blob/57b686ced075754ee...

Cool stuff


You can just add a generic version tag function that takes a tag name as its first param to solve that issue. Lets you create your own generator functions with ease for tags that aren’t included by default. Don’t see any reason you can’t add a comment() function either.

If you use a template string like that then you lose a lot in terms of type checking/IDE tooling/etc unless you add a ton of complexity, which is antithetical to this library’s goals. I definitely think they went with the right option.


> <i> is used by some systems now for icons

This is somewhat alarming. <i> is still a valid tag and used, e.g., for marking up titles of artistic works, etc. (which is not a use case for <em>, nor for <cite>.) Similar goes for <b>, which is (semantically) different from <strong>.


For most icon libraries that use <i> for their icons, it's usually just a suggestion and using <span> instead works fine. They mainly use <i> because it's "pretty".


Actually, it should be a label (or a button, depending on the use case).




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: