F# vs HAML: What are the differences?
Developers describe F# as "Strongly-typed, functional-first programming language for writing simple code to solve complex problems". F# is a mature, open source, cross-platform, functional-first programming language. It empowers users and organizations to tackle complex computing problems with simple, maintainable and robust code. On the other hand, HAML is detailed 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.
F# and HAML belong to "Languages" category of the tech stack.
"Pattern-matching" is the primary reason why developers consider F# over the competitors, whereas "Clean and simple" was stated as the key factor in picking HAML.
F# and HAML are both open source tools. HAML with 3.44K GitHub stars and 544 forks on GitHub appears to be more popular than F# with 2.09K GitHub stars and 341 GitHub forks.
According to the StackShare community, HAML has a broader approval, being mentioned in 113 company stacks & 40 developers stacks; compared to F#, which is listed in 19 company stacks and 16 developer stacks.
What is F#?
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
What are the cons of using F#?
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!
Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.
After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...
I've used .NET for many years, but only in recent years, after Microsoft introduced .NET Core, I've found a new love and excitement for the technology again. The main driver for us using .NET Core is not that it is cross platform compatible, open source or blazingly fast (which it is!), but the fact that we can use (what we consider) the best programming languages (mainly F# and C#) to carry out our jobs without sacrificing the other benefits.
Today we run most of our web infrastructure on .NET Core in Docker containers, deployed into a Kubernetes cluster which spans across multiple time zones in the Google Cloud and we couldn't be happier. Due to the portability of the .NET Core platform we are even able to develop many new services as serverless functions with F# which has become an absolute game changer.
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