Sass, Pug, Haml, Slim, Stylus, and their friends all aim to make writing various bits of your frontend easier. And they mostly deliver on this primary promise. But they are all victims to the vagaries of open software development, and seem to have mostly fallen by the wayside. I loved using these through my career, so its with a bit of sadness that I realized I don't want to use them for new projects.
CSS has been growing a lot of “super powers” lately, that used to require a pre-processor. Custom properties (variables), nesting, calc, and color-mix used to be things we’d reach for a preprocessor for, but can now be done 100% in pure CSS. And generally, the CSS based versions are better than their old preprocessor counterparts. calc can mix units, so you can easily do things like calc(100% - 1rem) to subtract a rem from 100% of the parent container. Can’t do that in Sass. Custom properties can be set by Javascript, or by media queries, and follow CSS scoping rules. Thats how I handle light/dark mode on my site.
Nim does a lot of things very well, I love writing JSON and parsing JSON in Nim, probably the best experience I’ve had with JSON, followed shortly by just implementing it as a protocol in Elixir.
Karax’s pattern of just using language constructs to assemble HTML isn’t really novel, as nice as it is; Ruby has had one for ages in Builder (and several offshoots), Elixir has Temple, and there are probably some in other languages. They’re sort of one level of abstraction less than slim/haml, but its quite pleasant writing them. But they suffer some of the same issues Slim/Haml suffer, but also can suffer when trying to use them with component frameworks, or anything that exposes custom tags. This can, of course, be solved via metaprogramming or language-level templates, but it is a concern
The Temple examples look very nice; the Builder ones to my eye look quite cluttered in comparison, which I’m guessing is due to differences in syntax between their respective languages.
I tink the main downside of templating in general is that it ends up making interfacing with JavaScript and plain HTML harder, compared to CustomElementRegistry based components.
Builder is mostly targeted at building XML files, and so compared to XML its fairly terse. HTML is just a nice also-have. There are template langs in ruby that are a lot closer to the Elixir temple variant, but I can’t remember any of them off the top of my head haha.
A good template would make interfacing “easy”. JSX[1] is a very good example of how you can interface quite easily, and the templates used in Surface work really well to bridge some of the complexities of a server-rendered but client-dependent syntax.
I know JSX isn’t a template language, the differences don’t matter for the purpose of this discussion ↩︎
Well it’s pretty much just HTML without brackets and closing tags. There are a few oddities to enable this, and it falls down on inline styles (in the same way json fails vs XML for inline formatting), but it is still pretty fun to write
But with the issues these languages are starting to manifest, that 18% isn’t worth it anymore
I know this isn’t applicable to the authot, but… what the hell is up with so many people being averae to just WRITING CODE. 18% fewer characters, are there seriously people who think that’s meaningful?
The amount of code you save grows with your codebase. It was 18% for that one, small example. In a larger codebase it can be quite a bit higher.
While I have, more or less, moved to just writing html-style templates, I do miss how easy it was to refactor something to have a different tag name. Vim and other editors do have shortcuts that make it easy to change both the opening and closing tag, but in indent based syntax, I didn’t have to worry about this. There was only one tag to change.
It used to be pretty meaningful when autocomplete was not as powerful as it is today. Only very serious emacs users could achieve fast and flexible static completion before LSP forced everyone to step up their game.
Now that everybody and their grandparents have LSP available (or even more powerful tools if you’re using Very Professional IDEs), it’s not nearly as much of an issue, just hit tab and never type close brackets again.
It’s not that folks are averse to writing code, it’s more-so averse to actually typing out a shitton of boilerplate and feeling the slog until you actually get to the juicy bits where you have to think.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@beehaw.org
All things programming and coding related. Subcommunity of Technology.
18% reduction (max) for learning a different language than html? Hard pass.
Especially with css you can give most of those small web design studios (and most wordpress plugins) a run for their money.
I think it’s unnecessary to learn some obscure „alt-sub-language“ if the improvement is so little.
I’m personally a big fan of SCSS over both CSS and regular Sass. Keeps the same syntax so it’s not hard to pick up, but fixes some of the CSS jank.
That said, I think they’re rolling out a new CSS version that covers some of those tweaks? I recall hearing abt that
That sounds cool! I didn’t know that. Thanks for elaborating.
CSS has been growing a lot of “super powers” lately, that used to require a pre-processor. Custom properties (variables), nesting,
calc, andcolor-mixused to be things we’d reach for a preprocessor for, but can now be done 100% in pure CSS. And generally, the CSS based versions are better than their old preprocessor counterparts.calccan mix units, so you can easily do things likecalc(100% - 1rem)to subtract a rem from 100% of the parent container. Can’t do that in Sass. Custom properties can be set by Javascript, or by media queries, and follow CSS scoping rules. Thats how I handle light/dark mode on my site.Karax has the appeal that it is just Nim code, so there is no new syntax.
Nim does a lot of things very well, I love writing JSON and parsing JSON in Nim, probably the best experience I’ve had with JSON, followed shortly by just implementing it as a protocol in Elixir.
Karax’s pattern of just using language constructs to assemble HTML isn’t really novel, as nice as it is; Ruby has had one for ages in Builder (and several offshoots), Elixir has Temple, and there are probably some in other languages. They’re sort of one level of abstraction less than slim/haml, but its quite pleasant writing them. But they suffer some of the same issues Slim/Haml suffer, but also can suffer when trying to use them with component frameworks, or anything that exposes custom tags. This can, of course, be solved via metaprogramming or language-level templates, but it is a concern
The Temple examples look very nice; the Builder ones to my eye look quite cluttered in comparison, which I’m guessing is due to differences in syntax between their respective languages.
I tink the main downside of templating in general is that it ends up making interfacing with JavaScript and plain HTML harder, compared to CustomElementRegistry based components.
Builder is mostly targeted at building XML files, and so compared to XML its fairly terse. HTML is just a nice also-have. There are template langs in ruby that are a lot closer to the Elixir temple variant, but I can’t remember any of them off the top of my head haha.
A good template would make interfacing “easy”. JSX[1] is a very good example of how you can interface quite easily, and the templates used in Surface work really well to bridge some of the complexities of a server-rendered but client-dependent syntax.
I know JSX isn’t a template language, the differences don’t matter for the purpose of this discussion ↩︎
Well it’s pretty much just HTML without brackets and closing tags. There are a few oddities to enable this, and it falls down on inline styles (in the same way json fails vs XML for inline formatting), but it is still pretty fun to write
But with the issues these languages are starting to manifest, that 18% isn’t worth it anymore
Thanks for elaborating! :) TIL
I know this isn’t applicable to the authot, but… what the hell is up with so many people being averae to just WRITING CODE. 18% fewer characters, are there seriously people who think that’s meaningful?
The amount of code you save grows with your codebase. It was 18% for that one, small example. In a larger codebase it can be quite a bit higher.
While I have, more or less, moved to just writing html-style templates, I do miss how easy it was to refactor something to have a different tag name. Vim and other editors do have shortcuts that make it easy to change both the opening and closing tag, but in indent based syntax, I didn’t have to worry about this. There was only one tag to change.
It used to be pretty meaningful when autocomplete was not as powerful as it is today. Only very serious emacs users could achieve fast and flexible static completion before LSP forced everyone to step up their game.
Now that everybody and their grandparents have LSP available (or even more powerful tools if you’re using Very Professional IDEs), it’s not nearly as much of an issue, just hit tab and never type close brackets again.
It’s not that folks are averse to writing code, it’s more-so averse to actually typing out a shitton of boilerplate and feeling the slog until you actually get to the juicy bits where you have to think.