HAML vs JRuby: What are the differences?
Developers describe HAML as "HTML Abstraction Markup Language - A Markup Haiku". Haml is a markup language that’s used to cleanly and simply describe the HTML of any web document, without the use of inline code. Haml functions as a replacement for inline page templating systems such as PHP, ERB, and ASP. However, Haml avoids the need for explicitly coding HTML into the template, because it is actually an abstract description of the HTML, with some code to generate dynamic content. On the other hand, JRuby is detailed as "A high performance, stable, fully threaded Java implementation of the Ruby programming language". JRuby is the effort to recreate the Ruby (http://www.ruby-lang.org) interpreter in Java. The Java version is tightly integrated with Java to allow both to script any Java class and to embed the interpreter into any Java application. See the docs directory for more information.
HAML and JRuby can be primarily classified as "Languages" tools.
"Clean and simple" is the primary reason why developers consider HAML over the competitors, whereas "Java" was stated as the key factor in picking JRuby.
HAML and JRuby are both open source tools. It seems that HAML with 3.43K GitHub stars and 544 forks on GitHub has more adoption than JRuby with 3.31K GitHub stars and 829 GitHub forks.
Kickstarter, Code School, and StackShare are some of the popular companies that use HAML, whereas JRuby is used by Groupon, Soundcloud, and Lookout. HAML has a broader approval, being mentioned in 113 company stacks & 40 developers stacks; compared to JRuby, which is listed in 13 company stacks and 4 developer stacks.
What is HAML?
What is JRuby?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using JRuby?
Sign up to get full access to all the companiesMake informed product decisions
When we rebooted our front-end stack earlier this year, we wanted to have a consolidated and friendly developer experience. Up to that point we were using Sass and BEM. There was a mix of HAML views, React components and Angular. Since our ongoing development was going to be exclusively in React, we wanted to shift to an inline styling library so the "wall of classnames" could be eliminated. The ever-shifting landscape of inline CSS libraries for React is sometimes difficult to navigate.
We decided to go with Glamorous for a few reasons:
As you may or may not know, Glamorous has ceased active development and been mostly superseded by Emotion. We are planning to migrate to either Emotion or @styled-components in the near future, and I'll write another Stack Decision when we get there!
Personally, I really like HAML. Not having to use open and close tags is a huge time saver. As a result, writing markup with HAML is much more pleasant. HAML essentially forces you to be very strict about spacing, organization, and structure. It also makes the markup easier to read. Protip: I use this pretty frequently: htmltohaml.com