5 ms·

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

by bborud 3y ago

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.
 - wharvle 3y ago
 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.
- bborud 3y ago
 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.
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.

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

by 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.
    - wharvle 3y ago
      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.
bborud 3y ago
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.

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.