Sourcemaps and JSX
After trying out a lot of tag template plugins for HTML syntax highlighting, autocomplete, and formatting, I really can't find something with enough support. Also there are issues like ESLint's indent rightfully not knowing what the indentation level ${...} content should be, since it's not an HTML parser...
HTML parsing is hard. Very hard. I've read enough parsers from precise HTML5 parsers like htmlparser2 (100kb) to lightweight, more fragile, parsers like HTM (1kb!) and choo/nanohtml. It's a tradeoff between size, features, speed, and developer experience. When parsers start deviating from the spec it's really interesting too because you think, yes, elements should end in <//>, or what a great idea to support <div#menu.is-active>. That's a good ecosystem to see development in, but these deviations can make developer experience better and worse when it comes to tooling and editor support.
The issues I'm having with Sinuous/HTM is not having any error handling on HTML errors like self-closing tags or void elements (input, br, textarea, etc). In JSX, ESLint can autofix these issues, but in a runtime parser like HTM it silently parses wrong. There may be ways to do this at compile time in babel-plugin-htm and friends, as well as creating VSCode extensions to support indentation rules based off of the code from eslint-react/jsx-indent, but it's a huge reinvention of the wheel in some ways. It's important to consider why it makes sense to use a runtime parser like HTM - especially in Stayknit's context of already using Typescript and needing Babel for that; I transpile the HTM to hyperscript! I treat it like JSX! Because I know how expensive it is to run and think "I wouldn't make anyone parse this if they don't have to". I even take it further by wanting to remove hyperscript calls entirely in favour of SSR+hydration. Slowly favouring performance and complexity? Maybe, or that's what makes sense for the health of the web at scale; a constant balance.
I preach HTM as a no friction, no build step, "view-source://"-friendly alternative to JSX. There are cases where that's true! Just like there are cases when using choo.js is okay (despite all of its inefficiencies). I also want to advocate for web development to be accessible, easy, and fun enough for friends to hack away on. In reality though, people don't want to use "view-source", they want the real source code with type annotations and git history. If the source code is the page source, then the browser is working really hard for that to happen - if no one ever sees it, is it worth it? For people who open the page source, many would be happy to see names of modules and a repo link next to minified code.
Really, they'd love some sourcemaps. That's supported across the board in all browsers to auto fetch them as-needed when their devtools open.
All of this comes from me having a strong philosophy around malleable systems and empowering users to be developers to fork their own applications. The most important part of that is the developer experience, not about whether or not there's a build or transpilation step. Once you step past the level of weekend LAN hackathon project then there you will always have a build step for basic browser support of ES5-ES.Next transpilation. The best thing to do is lighten the load on browsers by targeting a build specific to their User-Agent and having everyone do less work.
Less work means not parsing HTML in JS.
Developer experience means helping them with sourcemaps, an intuitive web_modules layout, build metadata, and documentation. Everyone should have an editor - it's not realistic to assume they will need HTM in userland "in case they want to develop in the browser session" (which is something I tell myself from time to time).
It's not a lot of work to support an editor, whether that's locally, in a CodeSandbox, or in the web app itself via Monoco/Ace (exactly as CodeSandbox does or tools like online REPLs such as Babel). It won't be a devtools console.
Using JSX unlocks tons of available community work on linting, autocomplete, typing, etc in ways that's aren't really possible in tag template strings (since it's not an AST, to start). For developer experience it makes the most sense.
I love that the hyperscript community has options. Things are built to be flexible and support any combination of tools. HTM is a wonderful project and is doing great work. I'll still use it for those weekend LAN projects.