6 ms·

The example has left me with a strong impression I should avoid this and HAML. That syntax frightens me.

eterps 3y ago
SLIM is similar, but a bit cleaner: https://github.com/mattn/go-slim https://github.com/mattn/go-slim Both SLIM and HAML resemble a DOM tree, it looks somewhat similar to what you would see in the browser inspector.
- toasted-subs 3y ago
  Is HTML really that scary for people?
  - eterps 3y ago
    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.
  - mplewis 3y ago
    HTML isn’t a templating language like HAML or Slim are.
bborud 3y ago
It looks unnecessary. The syntax is ugly and by looking at the examples I can’t say what problem it is supposed to solve.
- yoavm 3y ago
 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 (foobar is impossible to write), and basically the formatter is part of the language. What is there not to like?
 - shp0ngle 3y ago
 Why invent a new language so you don't have to close tags? Do I miss something?
 - milkshakes 3y ago
 > so you don't have to close tags
 - yoavm 3y ago
 sure, I guess lighting the house with fire also works!
 - dash2 3y ago
 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.
 yoavm 3y ago
 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.
 uticus 3y ago
 > almost no one is writing HTML anymore JSX?
 chrisoverzero 3y ago
 That’s right, JSX is also not HTML.
 3y ago
- uticus 3y ago
 > I can't say what problem it is supposed to solve "Haml accelerates and simplifies template creation" https://haml.info/ 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.
 - bborud 3y ago
 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.
caseyf 3y ago
there is a better side by side of the syntax here https://haml.info https://haml.info (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)
hinkley 3y ago
Had a lead dev who really liked HAML. 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)

SLIM is similar, but a bit cleaner: https://github.com/mattn/go-slim https://github.com/mattn/go-slim Both SLIM and HAML resemble a DOM tree, it looks somewhat similar to what you would see in the browser inspector.

toasted-subs 3y ago
Is HTML really that scary for people?
- eterps 3y ago
  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.
- mplewis 3y ago
  HTML isn’t a templating language like HAML or Slim are.

bborud 3y ago

It looks unnecessary. The syntax is ugly and by looking at the examples I can’t say what problem it is supposed to solve.

yoavm 3y ago
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 (foobar is impossible to write), and basically the formatter is part of the language. What is there not to like?
- shp0ngle 3y ago
 Why invent a new language so you don't have to close tags? Do I miss something?
 - milkshakes 3y ago
 > so you don't have to close tags
 - yoavm 3y ago
 sure, I guess lighting the house with fire also works!
 - dash2 3y ago
 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.
 - yoavm 3y ago
 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.
 uticus 3y ago
 > almost no one is writing HTML anymore JSX?
 chrisoverzero 3y ago
 That’s right, JSX is also not HTML.
 - 3y ago
uticus 3y ago
> I can't say what problem it is supposed to solve "Haml accelerates and simplifies template creation" https://haml.info/ 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.
- bborud 3y ago
  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.

caseyf 3y ago

there is a better side by side of the syntax here https://haml.info https://haml.info (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)

hinkley 3y ago

Had a lead dev who really liked HAML. 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)