最近我一直在讀關於HAML/SASS的內容，我不太清楚爲什麼有人不想使用它。它似乎很容易切換，使事情變得更清潔和更高效。對HAML/SASS做出決定的原因是什麼？
更新：
怎麼樣使用一個或其他？我聽說的大多數投訴（我幾乎沒有抱怨）似乎是關於HAML的，混合和匹配XHTML/HAML和CSS/SASS會有什麼問題嗎？
更新：
對不起，最後一個更新的問題。在我看來，從SASS切換回CSS是無痛和簡單的。從HAML切換回HTML是什麼？
如果您使用Rails，是的。去吧。但是，您將遇到的一些問題將會是，隨後任何其他開發人員加入團隊也必須學習它。如果你已經和一大羣Rails的人一起工作，那很好，但是HAML/SASS可能會混淆使用純HTML/CSS多年的設計師。
但是，如果您不使用Rails，那麼很好的HAML/SASS集成系統很難實現。這裏有幾個，但我想他們沒有得到很好的支持，或者跟規範一樣。
但是，是的。 HAML/SASS絕對值得。你會遇到的唯一真正的問題是它還不是標準的。
至於mix-n-match，HAML和SASS在風格上非常相似，我認爲兩者都適用，但它又歸結爲個人偏好。嘗試使用兩種方法一天，如果您不喜歡其中一種，請切換回去。沒有關於它的技術問題，所以你喜歡什麼。
這是爲什麼..
%p
hello world
比這更好的..？
<p>hello world</p>
線索..如果你不是在做紅寶石，它不是。不幸的是，添加結束標籤和大括號並不是製作網頁最具挑戰性的方面，因此大多數專業人士並不會真正在意。使用任何你喜歡的。
這絕對是個人決定，但OP已經確定他更喜歡HAML/SASS。 「這不是更好」在這種情況下不是一個有效的騙局。 – Matchu 2010-02-07 20:28:06
它可以治療基於RSI的角度支架。 – 2010-02-07 20:31:47
OP如何讓他的偏好無效？ – 2010-02-07 21:03:41
有很多使用HTML和CSS的工具。語法並不漂亮，但是HAML和SASS的改進對我來說似乎並不那麼戲劇化，對於很多人來說這並不值得。當然，對於那些開發Web應用程序的人來說，他們的框架差別很大（與Rails不同），但更難找到一個理由去集成如此陌生的東西。 （例如：小心解釋我將SASS整合到Java/Stripes/JSP環境中所需做的事情:-)
從HTML到HAML的差異基本上是美觀的，你是對的。但是，SASS提供了CSS中不存在的功能，例如變量，混合，算術（尺寸和顏色），循環等。它真的把CSS放在一個完全不同的層面上。Sass的新版本3實際上支持兩種語法模式，並且他們現在正在推廣SCSS語法（帶有大括號的CSS樣式），因爲人們已經掛上了空白感知的SASS語法，並沒有意識到它有更多的東西而不僅僅是他們可能不喜歡的不同語法。 – 2010-06-20 10:58:48
Sass不必「融入」您的環境。它只生成靜態CSS文件，所以你可以使用任何方法來調用它。我通常總是在sass之上使用指南針（一個樣式函數庫），它提供了一個「compass watch」命令，用於在保存時自動編譯sass文件。 [投票給你-1因爲你已經有6（！），並沒有那麼好的信息......沒有硬性的感覺。 :-)] – 2010-06-20 11:03:01
@Andrew通過「整合」我主要是指「融入構建過程」，我認爲這樣的工具在某種程度上將不得不。要麼它成爲應用程序構建的一部分，要麼它成爲一個獨立的*構建。無論哪種方式，它必須「融入」我工作的方式。例如，「自動編譯」工具在我習慣的那種構建環境中（我更喜歡）完全沒有用處。問題在於徵求意見，所以基於*你對我的*情況的明顯不完全理解來降低我的意見似乎很荒謬。 – Pointy 2010-06-20 12:31:49
我一直在志願者項目中，HAML的語法曲線（語法空白，自動生成標籤等）被視爲一個障礙：對於項目學習的新手程序員來說還有一件事。個人而言，我認爲SASS是值得的，但是我對HAML很感興趣：在開始調試HAML模板之前，看起來您不需要使用HAML進行打字就可以克服您花費的時間調試您的模板中出現錯誤的原因。不過這可能是（HAML）新手的觀點。
我同意，我發現HAML比純HTML更難工作。每當瀏覽器出現錯誤時，您都必須將HTML輸出映射回原始的HAML ......我只是不明白這個好處是什麼意思。新的語法，不可容忍和不適當的空白，額外的調試層。 – 2010-02-08 02:11:45
HAML/SASS確實可以使用，但它們確實引入了技術和知識導向的依賴關係。如果你的開發和產品環境受到足夠的控制和預測，新手可以接受足夠的培訓（或者在進入組織的過程中接受主題知識的檢查）來實現這一目標，但這些都不是問題，但所有這些都是開銷被承認。
我傾向於同意這個問題;它是易於切換，語法不那麼複雜，它確實使事情更清潔和更有效率。這也使得無意中生成無效的HTML變得更加困難。
我也認爲學習曲線足夠淺，以至於無法處理它的程序員可能是一名程序員，如果沒有團隊成員，你的狀況會更好。這聽起來很刺耳，但我相信。
唯一的缺點，我可以看到是，如果你在ASP.NET開發或一些地方改造Haml的和無禮的話將是一個痛苦，是方式意想不到的其他任何人使用這個平臺，和可能的苦差事到保持在生產環境中。在Rails上，儘管去吧。
我不認爲使用HAML會給項目帶來很多好處。
另一方面，SASS有效地引入了變量和計算以及其他真正有用的功能，這些功能在大型項目的長期運行中可以節省您的時間和精力。
對於任何大於簡單單頁形式的項目，使用SASS都非常聰明。
我嘗試使用SASS，但發現使用MacRabitt's CSSEdit（僅限Mac）編輯CSS對於我工作的方式來說更容易和更高效。我是一個非常具有視覺效果的人，喜歡在對樣式表進行更改時進行實時預覽，並且不希望投入大量時間來處理我沒有遇到的問題。
從開發者的角度來看，Haml和Sass絕對是搖滾樂。然而：從設計師的角度來看，Haml和Sass可能不可讀。這真的取決於誰是你的團隊。
如果是一羣不害怕學習DSL的開發人員和/或設計人員，那麼絕對不會這麼做。
如果你有一個混合的團隊，設計師把他們的CSS和HTML工作交給那些將它翻譯成Haml/Sass的開發人員。
如果你有一個設計團隊，通過工作的開發者和工作流回設計師，你可能不想用這個，因爲設計者可能無法使用他們的工具來編輯這些文件。
如果你有一個小團隊，營銷人員和商業人士需要編輯網頁，他們只知道HTML和一點CSS，那麼你可能不應該使用Haml/Sass。
但是，您無法在此做出一攬子聲明。考慮到至少在Rails中你可以在視圖中混合使用模板類型。所以，你的一些模板可以是簡單的HTML卡在.erb文件中，而其他頁面則是.haml文件。您可以將部分類型插入另一個類型的模板中。 （我認爲混合類型可能是一種不好的做法，但如果您只需「完成工作」，那麼這是一種選擇。）
大多數人不知道的一件事是HAML sucks for content。這對結構標記很有用，但不要試圖推得太遠。 （您可以在您的HAML文件中混合使用&匹配HTML！）
Sass絕對是必不可少的，尤其是從長遠來看。這不僅僅是在你把所有的樣式表寫在頭腦裏，而是要把它們保持在路上。新的Sass3將語法問題排除在等式之外：如果您更喜歡花哨的SCSS語法，則可以選擇它。
我現在在Django項目上使用SASS。我喜歡它，並且會繼續使用它。然而，我發現的一個問題是，錯誤信息並不總是特別直觀，特別是如果你離開}。
在我看來，幾乎沒有切換的學習曲線，所以如果有人與純HTML/CSS工作學習HAML/SASS是一個問題？ – GiH 2010-02-07 20:19:24
真的不應該，但是那裏有頑固的人，不能學習新的方法。這是一個騙局，但這是我唯一能想到的。 HAML/SASS非常棒，如果它最終適合你（或者你的團隊），那麼就去吧。它在系統本身並沒有很多固有的缺陷，所以人們似乎認爲它們是唯一真正的障礙。 – Matchu 2010-02-07 20:27:09
你不能簡單得多HTML/CSS。你真的認爲運行ruby進程爲你添加結束標籤的「唯一真正的問題」是基於你的源文件的標籤刪除：「它還沒有標準」？ – 2010-02-07 21:10:08