Why use HTML and not HAML? [closed]_问答_开发者

开发者 https://www.devze.com 2023-02-14 16:00 出处：网络

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references,or expertise, but this question开发者_StackOverflow社区 will

相关专题：haml

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question开发者_StackOverflow社区 will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

In various forums and blogs, I see some people promoting HAML and some promoting HTML. What are the advantages and disadvantages of using HAML vs HTML?

I just want to understand what I'm missing out on if I use HAML in favor of HTML (if any).

You are trying to compare Apples to Oranges. Browsers only understand HTML. HAML is just a templating language that gets transformed into HTML (e.g. same final output). If you find the HAML syntax to be easier than HTML then go for it. However IMHO - abstracting away what actual elements you are generating just makes applying CSS and doing JavaScript navigation that much more difficult.

Personally if I wanted to "trim" my HTML, I would put content into tags (depends on your serverside technology)

<!doctype html>
<html>
<head>...</head>
<body>
  <x:awesomeListThing data="$foo"/>

  <x:foreach data="$bar">
    <x:renderBazWidget/>
  </x:foreach>
  <div>random content that hasn't been "tagified" yet.</div>
</body>
</html>

Then inside any tag's template you'll be able to see the actual HTML structure that is being generated.

The main disadvantage of using HAML over HTML is simply that HTML is just about universal among web developers, where as the HAML community is still a relatively small community. This would undoubtly make finding developers to work on your project in the future a more daunting task.

But if you have the resources, you could argue that to be an advantage. Ensuring you only hired developers that were capable and experience in HAML.

The other major down side I can see is that if you have graphics/web designers working on your templates, separate from your development team, they would also have to be familiar with HAML. As you can imagine there are very few graphics/web designers who capable of it, and few tools to help them.

On Stackoverflow - HTML has 65k followers. You WILL get an answer, most likely many answers, in a very short amount of time. HAML has 157 followers. Simple math.

Google HAML. I am sure, you will get relevant stuff to understand it.

Haml is:

Easy to read and visually expresses your DOM hierarchy
Easy to learn
Ported to other languages
Well-maintained and has a huge community
Popular with designers because it borrows CSS syntax
Almost as fast as plain ERB
Makes many types of error impossible (or very difficult)

See here :

Your attitude to Haml?

When major IDEs (such as Aptana) learn to parse HAML, we can return to the question. Right now I see HTML's superiority in that it's widely supported and understood by common parsers. You get proper syntax colouring and any errors or validation problems get marked instantly. This is not true of HAML.

Additionally, consider web templates. They're usually (X)HTML + CSS, be them ready templates for hire or the designs your designer cuts for you. What are your odds of getting a, say, HAML+SASS template instead of the usual XHTML+CSS?

HAML needs to gain more field and its community needs to grow much more before it's a viable alternative to HTML. Currently most web coders don't even know what HAML is, not to mention writing anything in HAML.