| (OP here.) This is true to a good extend but a library such as blaze-html can't offer at least two things I've in mind. One is the very lightweight syntax. You can for instance have a look at the reference page source code[1]. Writing that in blaze-html is a lot more verbose. Two, although it's possible to introspect a blaze-html -generated tree, you can't easily have tooling to, say, list HTML fragments, where they are used, which one are full HTML documents (i.e. starting with a doctype)... One of my goal with Slab is to have a "refactorable" language to write "large" HTML code bases (I'm mainly thinking of design systems reference implementations). Having a tool that can "see" the tree structure, the fragment calls, the list of files, ... opens new tooling opportunities. I'm one of those people that says syntax doesn't matter; we should talk about semantic instead (and thus just adopt s-expressions for syntax). Yet, in this case, I think that a very lightweight syntax that maps clearly to HTML, in particular for non-programmers (e.g. designers), is very valuable. Note also that I make available a statically-linked `slab` binary that makes super easy to start using Slab. You don't need a programming environment with a compiler and so on. (I'd like to try to create a Cosmopolitan[2] binary in the future.) The `slab` binary also has a "watch" feature that rebuilds pages and reload the browse as you edit `.slab` files. I guess I mean that having an integrated tool can offer a very good developer (or designer ?) experience. [1]: https://github.com/hypered/slab/blob/main/content/reference.... [2]: https://github.com/jart/cosmopolitan |