CoffeeScript vs HAML: What are the differences?
CoffeeScript and HAML belong to "Languages" category of the tech stack.
"Easy to read" is the primary reason why developers consider CoffeeScript over the competitors, whereas "Clean and simple" was stated as the key factor in picking HAML.
CoffeeScript and HAML are both open source tools. It seems that CoffeeScript with 15.2K GitHub stars and 1.99K forks on GitHub has more adoption than HAML with 3.44K GitHub stars and 544 GitHub forks.
Code School, Zaarly, and thoughtbot are some of the popular companies that use CoffeeScript, whereas HAML is used by Kickstarter, Code School, and StackShare. CoffeeScript has a broader approval, being mentioned in 364 company stacks & 170 developers stacks; compared to HAML, which is listed in 113 company stacks and 40 developer stacks.
What is CoffeeScript?
What is HAML?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake 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!
Choosing to add TypeScript has given us one more layer to rely on to help enforce code quality, good standards, and best practices within our engineering organization. One of the biggest benefits for us as an engineering team has been how well our IDEs and editors (e.g., Visual Studio Code ) integrate with and understand TypeScript . This allows developers to catch many more errors at development time instead of relying on run time. The end result is safer (from a type perspective) code and a more efficient coding experience that helps to catch and remove errors with less developer effort.
We have added very little to the CoffeeScript Hubot application – just enough to allow it to talk to our Hubot workers. The Hubot workers implement our operational management functionality and expose it to Hubot so we can get chat integration for free. We’ve also tailored the authentication and authorization code of Hubot to meet the needs of roles within our team.
For larger tasks, we’ve got an internal #CLI written in Go that talks to the same #API as Hubot, giving access to the same functionality we have in Slack, with the addition of scripting, piping, and all of our favorite #Unix tools. When the Hubot worker recognizes the CLI is in use, it logs the commands to Slack to maintain visibility of operational changes.
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
All front-end / back-end is driven by Coffeescript. For the main ReactJS functionality JSX is embedded with coffee in .cjsx files / handled by Browserify.
We like CoffeeScript because it's more readable, we use it because we have a lot of libraries and functions already (plays nicely with Rails, too)