Hamlet: A type-safe Haml template engine for Go
github.com
github.com
In this case that would be accomplished by supporting the following instead:
@hmlt HomePage() {
%SiteLayout
%p This is the home page for Hamlet.
}
- if user != nil {
%strong The user exists
- } - if user != nil
%strong The user exists
1. https://github.com/ruby/syntax_suggest/blob/main/lib/syntax_...
- else if other_condition
%span other content
- else
%span another bit of content
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" ^_^
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)