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

1. Stabilize Take the initial codebase and finish fixing the remaining outstanding issues, clearing the backlog of 'bugs'
2. 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.
3. 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...
4. 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.
5. 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