haml

Funding Links: https://github.com/sponsors/haml

Name: Haml
Kind: organization
Followers: 19
Following: 0
Total stars: 5113
Repositories count: 7
Created at: 2022-11-02T16:42:33.734Z
Updated at: 2025-03-28T14:39:13.155Z
Last synced at: 2025-03-28T14:39:13.154Z

GitHub Sponsors Profile

Haml was the first HTML abstraction language in the world, focusing on structured, clear, and semantic HTML. It was first released in 2006 and over its first 5 years or so the language evolved rapidly. And over that time, Haml has been implemented in Python, Go, PHP, Perl, Javascript, Common Lisp, ASP.net, Lua, and Scala..... and even more, it has inspired a whole generation of templating languages.
And, we can't forget to mention that Sass was originally a submodule of Haml!
Unfortunately, over the last 11 years, Haml's evolution has slowed to a crawl. A handful of very generous maintainers have done their best to keep up with changes needed to keep Haml running, but very little has been done in the way of innovation.
I'm Hampton Catlin, and I'm the original creator of Haml. And, I feel like it's about time that we actually move Haml into the 2020's with a whole new fresh start.
A lot has changed since I first designed Haml back in 2006! Back then, CSS and "Semantic HTML" were all the rage. No one had even thought about BEM or Atomic Design or OOCSS or even data-attributes! As a language, if we are honest with ourselves – Haml no longer properly supports modern looking HTML.
We are changing that.
Project Plan

Stabilize Take the initial codebase and finish fixing the remaining outstanding issues, clearing the backlog of 'bugs'
Fork The existing codebase uses Regex to parse Haml files and build an intermediate representation in Ruby... this was a fine approach, but it's slow, buggy, and won't allow us to use multiple lines or new syntax easily.
Rebuild Haml needs a real parser under the hood. Regex isn't enough. This will be a backwards-compatible Haml parser, but it will also work with a new syntax...
Redesign Haml needs syntax changes. The focus on id's and classes just doesn't work well with HTML5-style development (more below on this design and my thoughts there). Specifically, we will make the language work well with Stimulus.js-style modern HTML-focused workflows.
Portable Haml will support seamless transition from the old syntax to the new syntax, allowing you to easily port existing projects.

What we know

Haml is still extremely heavily used, but is no longer fit for purpose for many projects
We will make sure that we are backwards compatible
We will focus on HTML and modern browser technologies
Javascript-heavy SPAs will not need us, so we don't need to worry about them
Conversely, we will be more inspired by Javascript syntax than by CSS going forward

What we don't know

Can we migrate the existing syntax exactly, or will we actually need to make changes?
The exact design (see more below) of the new features
What target language we will use for a rebuild
Who we can get to help with this project
There could be modifications to the plan above if we make some breakthroughs

What do you need money for?
Developers! I plan on hiring contractors to help with some of the heavy lifting that will be needed. Users of Haml are NOT the same people who write parsers. There are tons of people who love writing parsers– and I intend on paying them. I most likely will use talent from around the world to get this done.
The goal here is to help the thousands of teams who are using Haml in parts of their code base and give them a huge performance and productivity boost... taking Haml from being "that weird language in some files" to the chosen language for HTML development in the browser.
What's this new design you are talking about?
(Here follow some random thoughts… hold onto your butts!)
Initially, I chose %tag as the indicator for a tag, because I wanted to encourage people to either use the .class or #id syntax and discourage people from using anything but a . However, times have changed and HTML now has a wide range of interesting tags that bring their own semantic meaning and can help with accessibility and more.
Literally it was % because it’s the furthest you have to stretch your fingers further on a US keyboard as a mechanical language design choice! And now, every poor person who wants to use a %section tag has to reach! :O Sorry about that!