I haven't looked into the details about how server side rendering is done. It should have something equivalent to generate HTML. But the point still stands, it should be possible to follow the same pattern to create a JSXesque template for HAML
I haven't seen many projects where people attempt to use SLIM templates as an alternative to HTML; rather, they are used as a complement. SLIM is for deeply nested structures and layouts, while HTML is for actual content.
I love Haml / Pug / Slim. I think it's very clear what problem it solves: you don't need to worry about closing tags, and doing it in the right order, because the tree is visually in front of you. It also means less code (because of no closing tags), which means it's easier to read.
It's like HTML but less verbose, less errors prone (<p>foo<b>bar</p></b> is impossible to write), and basically the formatter is part of the language. What is there not to like?
In my experience, adding a layer between you and what you are doing adds a potential layer to every bug, and a layer to what new developers need to learn. That needs a lot of justification.
True, but almost no one is writing HTML anymore. So if I'm anyway post-processing my tsx / jsx / vue / whatever files, I might was well use a language that's great.
As for adding a layer to what devs needs to learn - that's why I don't generally use this at work. In those situations you often need to pick the most common tools and not the best tools.
One of these major “no closing tags” templating languages had been chosen for a Rails project I once onboarded to. I wanna say it was Slim, but it may have been another.
It was dog slow and it had some really stupid api you had to use if you needed to handle nesting that you couldn’t determine until runtime (on account of the no closing tags—use case: rendering a tree of data in a streaming-records sort of situation, not exactly a super-rare need).
There was a faster implementation, several times faster… but it achieved that in no small part by ditching the bits of the api that allowed you to manipulate nesting, so I couldn’t use it.
That project made me hate crap like this. HTML isn’t scary, hard, or even (in a halfway modern editor) slow to write, FFS. I’ll never ever pick this sort of templating language when it’s my choice.
Not having to worry about closing tags can be solved in numerous other ways without having to invent a new language. And strictly speaking, Haml doesn't actually remove closing tags - it replaces them with whitespace defined structure. This introduces new classes of problems. Like having to deal with when it is unclear when the whitespace is part of the structure versus when it is part of the content. There is a reason why the Haml reference has a section on this.
Then there's all the other syntax that needs to be crammed in to make the language do what you want. HTML doesn't have lots of special characters strewn about the place that have meaning, but Haml does. You now have to understand HTML, Haml and how Haml is turned into HTML. That's a lot more complexity than sticking close to HTML.
It seems like a lot of unnecessary work to use Haml (and impose it on other people through code) if your reasons for using Haml are purely superficial.
If you'd rather write raw HTML, keeping track of closing tags etc, then don't use HAML. No need to bash it because you personally feel it is ugly or unnecessary. FWIW I personally feel the exact opposite.
My perspective is that of someone who usually has to make choices for software projects that are going to exist for a while and that will have lots of developers on them. If you manage software projects you will tend to always feel some pressure from developers who want to use marginal technology. Developers whose only perspective is what is right in front of their nose will tend to have different perspectives from people who have to think about "how do we maintain this 5-10-15 years from now?".
Haml is marginal. Haml for Go even more so. That's simply observable fact. Most Go developers will not have heard about it even though it has been around since 2006. Which doesn't make it an obvious candidate. If you choose it over the standard library templating language you will have made a choice that means almost every developer involved will have to learn Haml rather than use what they already know. And possibly just for that one project that uses Haml in Go.
Every technology you introduce into a project places a further burden on anyone who has to understand the code. If you choose marginal technologies the chance of developers being proficient in them goes down sharply. The chance that you have to replace them later also goes up. That can have considerable cost and take a long time.
Using Haml in Go projects is a big ask, which means you have to be able to rationally argue why developers should leave the beaten track. If we start by looking at the Haml implementations for Go, I'd say there is no reason to consider it now. There are a handful of libraries, but none of them seem to have that much of a well organized dev team and a community around them. It seems unlikely to displace existing solutions.
This means that if you choose it and weave it deeply into how your application works, you might end up having to maintain (one of) those libraries yourself. Exposing your project to that kind of risk is unprofessional.
And note that this is before we even consider the language itself.
And by the way, accusing other people of bashing the language simply because they express an opinion you don't agree with isn't very productive. Yes, I have read the documentation - and yes, I still don't see what problem this is supposed to solve. We already have lots of languages for expressing things that will render to HTML. I don't see how Haml is significantly better than other ways of doing that currently in more widespread use.
He was working on a web app and we deduced he hated HTML, because 1) he liked HAML, and 2) the two most technical people spent a lot of time cleaning up bugs he authored.
That whole project was a mess so that never achieved high priority status. I would have distrusted HAML anyway, but that experience certainly punctuated that feeling.
This is not an arena where an impedance mismatch has any payoff worth paying. You're working on a web app. Use HTML and CSS (SCSS if you must)
That's great; Haml is one thing I like most when doing web development on Ruby/Rails. The only thing I don't like about this implementation is the blocks with inline code:
I use Haml in my web framework, I use syntax_suggest [1] to count the missing pairs so I can insert them automatically at the end of the block. It would probably not be too difficult to do the same thing in Go.
This is something I would like to have working, the subtraction of the braces that is. I did have a naive solution where it would insert the braces for you if the left the opening brace off and it would assume you wanted the closing brace too. This caused problems when I would put in a continuation of an if statement like:
- else if other_condition
%span other content
- else
%span another bit of content
I pulled the broken solution completely and do plan to revisit dropping the brace requirement because not having the braces aligns with the idea/reason why you'd use Haml in the first place.
The biggest problem with Haml is probably that it's really difficult to write a tree-sitter parser for it. In this case, you would have to parse both haml, go, CSS and JavaScript and be aware of indentation.
41 comments
[ 3.2 ms ] story [ 109 ms ] threadIn this case that would be accomplished by supporting the following instead:
Which is much cleaner IMO.Both SLIM and HAML resemble a DOM tree, it looks somewhat similar to what you would see in the browser inspector.
It's like HTML but less verbose, less errors prone (<p>foo<b>bar</p></b> is impossible to write), and basically the formatter is part of the language. What is there not to like?
As for adding a layer to what devs needs to learn - that's why I don't generally use this at work. In those situations you often need to pick the most common tools and not the best tools.
JSX?
It was dog slow and it had some really stupid api you had to use if you needed to handle nesting that you couldn’t determine until runtime (on account of the no closing tags—use case: rendering a tree of data in a streaming-records sort of situation, not exactly a super-rare need).
There was a faster implementation, several times faster… but it achieved that in no small part by ditching the bits of the api that allowed you to manipulate nesting, so I couldn’t use it.
That project made me hate crap like this. HTML isn’t scary, hard, or even (in a halfway modern editor) slow to write, FFS. I’ll never ever pick this sort of templating language when it’s my choice.
Then there's all the other syntax that needs to be crammed in to make the language do what you want. HTML doesn't have lots of special characters strewn about the place that have meaning, but Haml does. You now have to understand HTML, Haml and how Haml is turned into HTML. That's a lot more complexity than sticking close to HTML.
It seems like a lot of unnecessary work to use Haml (and impose it on other people through code) if your reasons for using Haml are purely superficial.
"Haml accelerates and simplifies template creation" https://haml.info/
If you'd rather write raw HTML, keeping track of closing tags etc, then don't use HAML. No need to bash it because you personally feel it is ugly or unnecessary. FWIW I personally feel the exact opposite.
Haml is marginal. Haml for Go even more so. That's simply observable fact. Most Go developers will not have heard about it even though it has been around since 2006. Which doesn't make it an obvious candidate. If you choose it over the standard library templating language you will have made a choice that means almost every developer involved will have to learn Haml rather than use what they already know. And possibly just for that one project that uses Haml in Go.
Every technology you introduce into a project places a further burden on anyone who has to understand the code. If you choose marginal technologies the chance of developers being proficient in them goes down sharply. The chance that you have to replace them later also goes up. That can have considerable cost and take a long time.
Using Haml in Go projects is a big ask, which means you have to be able to rationally argue why developers should leave the beaten track. If we start by looking at the Haml implementations for Go, I'd say there is no reason to consider it now. There are a handful of libraries, but none of them seem to have that much of a well organized dev team and a community around them. It seems unlikely to displace existing solutions.
This means that if you choose it and weave it deeply into how your application works, you might end up having to maintain (one of) those libraries yourself. Exposing your project to that kind of risk is unprofessional.
And note that this is before we even consider the language itself.
And by the way, accusing other people of bashing the language simply because they express an opinion you don't agree with isn't very productive. Yes, I have read the documentation - and yes, I still don't see what problem this is supposed to solve. We already have lots of languages for expressing things that will render to HTML. I don't see how Haml is significantly better than other ways of doing that currently in more widespread use.
(i've been using haml for 17 years lol. if I'm going to need a template language, i find it more enjoyable to read and write than everything else)
He was working on a web app and we deduced he hated HTML, because 1) he liked HAML, and 2) the two most technical people spent a lot of time cleaning up bugs he authored.
That whole project was a mess so that never achieved high priority status. I would have distrusted HAML anyway, but that experience certainly punctuated that feeling.
This is not an arena where an impedance mismatch has any payoff worth paying. You're working on a web app. Use HTML and CSS (SCSS if you must)
1. https://github.com/ruby/syntax_suggest/blob/main/lib/syntax_...
The biggest problem with Haml is probably that it's really difficult to write a tree-sitter parser for it. In this case, you would have to parse both haml, go, CSS and JavaScript and be aware of indentation.
Although to be fair, it's hard not to name a Haml library "Hamlet" ^_^