Haml: Haml 6 feature candidates

[k0kubun]

Sometimes we need breaking changes for some reasons. As a note, here is the list of it for the future.

• Change escape_html option default to true https://github.com/haml/haml/issues/898
• Force to escape HTML-safe attribute https://github.com/haml/haml/issues/925
• Resolve inconsistent whitespace issues https://github.com/haml/haml/issues/465 (and more)
• Stop sorting attribute values (just merging https://github.com/haml/haml/pull/882)
• Move some Rails monkey-patches to haml-rails, and require (unreleased) haml-rails 2.0.0
• Carve out parser as another gem, for haml-lint or hamlit

[hcatlin]

I'm going to an Open Source Hackathon next weekend, and I'm going to help get the students to work on some of these.

Seems like Haml 6 makes a lot of sense.

[slimdave]

Do you have a target minimum ruby version for 6?

[k0kubun]

No. Perhaps it's a good time to bump it, but I don't have such a concrete plan yet.

[k0kubun]

Some have been merged, and we also have https://github.com/haml/haml/issues/1031. Closing this issue.

[hcatlin]

Oh gosh, I forgot this ticket from forever ago! It's a great summary though.

[konung]

Hi @hcatlin.

I saw the announcement on RubyWeekly today about haml 5.2 being the "long goodbye" and that future HAML 6 is going to be "StimulusJS-like" in it's development. I was wondering if you could clarify what does that means, as I'm not familiar with the Stimulus development pattern? ( Other than how StimulusJS works - I played with a few tutorials)

Thank you

[hcatlin]

My main meaning is that heavy use of data-attributes really makes it a slog to write Haml. When I first designed Haml, attribute-heavy HTML was frowned upon, so we made multi-line expressions nearly impossible, or at least unpleasant– to help keep code quality high.

These days, data-attributes are in heavy use in many, many libraries if they are HTML + Javascript. If you aren't in the world of React/Vue that is!

Haml doesn't make it very elegant. Just look at this sample line of code I have in my repo...

So, ideally some way to actually chop-down the attributes!

[konung]

Got it :) You were referring to the actual way StimulusJS and similar libraries work. I misread it as in some kind of development paradigm like Agile Development. As in sprints & quick / often releases. 🤦
This is what's called "professional deformation", too much time thinking about product lifecycles. 🤣
Thank you very much for clarifying.

---

On the topic of too many data-attributes, I agree with you but lately, have little exposure to it & Stimulus in particular. Due to changing my development stacks the use of Elm + Ruby, Elm + Elixir or Elm + Crystal, or even avoiding frontend JS completely. For the types of internal apps I write, JS is rarely needed. 🤞 I'm closely following Elixir's Phoenix LiveView and similar projects. Essentially they are using the same approach as the Ruby/Rails community used 6-8 years ago with PJAX. But the speed provided by Elixir or Crystal actually makes it a viable options for large applications.

When possible I prefer to generate as much as possible server-side, and only sprinkle a little bit of JS when unavoidable. Having to maintain a big frontend stack, in addition to backend application, is very taxing on a small dev team, such as ours.
However, I've been looking at Alpine.js for that specific purpose of sprinkling JS when required because it "favored" by developers/community of TailwindCSS, which we are starting to use, and they make heavy use of custom attributes. _So targetting that kind of approach in HAML 6 would definitely help there._

1. From that perspective, do you think the changes in HAML 6 are going to be completely incompatible with existing projects? How hard would it be to upgrade?
2. Also I've noticed that @k0kubun is also a maintainer of HAML which I haven't realized before. And I'm a big fan of Hamlit. Are you considering adding performance tweaks from Hamlit to Haml for version 6? I guess I'm asking: how big of a rewrite are you planning?

Thank you so much for all the time & effort put into HAML.

[k0kubun]

And I'm a big fan of Hamlit. Are you considering adding performance tweaks from Hamlit to Haml for version 6?

The project was called Haml 5. The ideas which could be copied from Hamlit to Haml have been already ported to Haml https://github.com/haml/haml/pull/860 https://github.com/haml/haml/pull/893 https://github.com/haml/haml/pull/904. However, Haml is still not as fast as Hamlit yet mainly because Haml has some helpers which require the special buffer, Haml::Buffer, which Hamlit doesn't support. I have an idea to lazily create Haml::Buffer to improve Haml's performance without breaking compatibility, but obviously it's not "adding performance tweaks from Hamlit to Haml" and it's a big work, and for now I'd rather like to focus on raising my baby and developing Ruby's JIT.

[konung]

@k0kubun Thank you, Takashi for everything you do. Just wondering what the "roadmap" is for HAML. 😄

[k0kubun]

I do have a bunch of ideas, a part of this issue's description and the above comment, but as I already said, I'm not planning to work on them soon and thus it doesn't really matter. You should probably mention other maintainers to know any roadmap they may have.

[hcatlin]

Honestly, until recently I haven't been that aware of Hamlit, but @obie mentioned it to me and I guess I totally forgot that it's by the wonderful Haml-maintainer @k0kubun.

I'm not familiar with the Hamlit code, but I'm going to read through it to see the approach. It's my opinion that our current regexp loop need to be totally restarted.

For more context, here is my current Gist that includes my ideas for Haml 6.

https://gist.github.com/hcatlin/6c5d24d27897b9fa0888a012b612e824

To note... ability to chop-down attributes and the use of & to make a BEM-style parent appender.... in the sample, &__primary turns into .content-area__primary

[k0kubun]

I'm not familiar with the Hamlit code, but I'm going to read through it to see the approach.

As said above, most of the implementation ideas which would be useful for Haml have been already copied from Hamlit. Looking at Hamlit is at least not useful for optimizing Haml's rendering performance without dropping support of some Haml helpers.

However, I remembered old code which is probably useful for Haml, while its design decision is a bit hard to understand for others. Thus I ported the portion by myself at https://github.com/haml/haml/pull/1043.