You don't need to make your markup language programmable. Just write a library for a full-featured programming language which outputs the markup you want. Then you don't have to re-implement parameters, variables, loops, and such. See Lucid or Blaze in Haskell for good HTML DSLs. You can do more in one of those, combined with all the features of Haskell, than you can with Slab, Haml, Pug, or whatever else. And you don't need to write plugins for VSCode, Vim, Emacs, or whatever else just to edit it. See also Elm, which has an HTML DSL built in.
(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.
(OP here.) Indeed, Slab is a templating language, just like Pug or Haml are. Slab was initially a reimplementation of Pug, but it evolved a bit.
In particular, I tried to respect a principle often found in programming languages: user-defined elements (fragments) are no different than builtin ones. For example notice how `page` (which is user-defined) is used in the same way as as `body` (which is builtin) in the first code snippet of the introduction[1].
(In the future, I hope that instead of providing builtins, Slab will instead use libraries of elements. There is an undocumented feature to define elements[2].)
In Pug, to reuse bits of HTML, you can define mixins, but they are called with a `+` sign in front of their name. I also believe mixins can have expression arguments, but not other blocks of HTML. To pass blocks of HTML as "arguments", Pug provides the `extends` keyword, but I think it can only be used at the toplevel of a template. In Slab, the concept of fragments is a bit more uniform: a fragment can be used with expression arguments, and block arguments.
You don't need to make your markup language programmable. Just write a library for a full-featured programming language which outputs the markup you want. Then you don't have to re-implement parameters, variables, loops, and such. See Lucid or Blaze in Haskell for good HTML DSLs. You can do more in one of those, combined with all the features of Haskell, than you can with Slab, Haml, Pug, or whatever else. And you don't need to write plugins for VSCode, Vim, Emacs, or whatever else just to edit it. See also Elm, which has an HTML DSL built in.
(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
similar project https://pugjs.org
(OP here.) Indeed, Slab is a templating language, just like Pug or Haml are. Slab was initially a reimplementation of Pug, but it evolved a bit.
In particular, I tried to respect a principle often found in programming languages: user-defined elements (fragments) are no different than builtin ones. For example notice how `page` (which is user-defined) is used in the same way as as `body` (which is builtin) in the first code snippet of the introduction[1].
(In the future, I hope that instead of providing builtins, Slab will instead use libraries of elements. There is an undocumented feature to define elements[2].)
In Pug, to reuse bits of HTML, you can define mixins, but they are called with a `+` sign in front of their name. I also believe mixins can have expression arguments, but not other blocks of HTML. To pass blocks of HTML as "arguments", Pug provides the `extends` keyword, but I think it can only be used at the toplevel of a template. In Slab, the concept of fragments is a bit more uniform: a fragment can be used with expression arguments, and block arguments.
[1]: https://slab-lang.org/reference.html#introduction
[2]: https://github.com/hypered/slab/blob/main/examples/el.slab
reminds me of haml too https://haml.info
From GitHub -
Slab was initially a port to Haskell of the Pug.js templating language.
similar library: https://github.com/weavejester/hiccup
Hideous in my opinion. Can't see where a tag starts and ends