LESS到底好不好?

01-14

從實用角度來看,我為什麼要用它?我感覺這只是二次包裝而已,是程序員的玩具,是奇淫巧計.

隨便說點實際開發中的體會吧。

優點：

結構清晰，便於擴展。對於模塊很多的應用特別是單頁 app，經常需要用 selector 來劃分不同模塊的 CSS 的 scope。如果滿眼望去全是 .module .action .list a, .module .action .list a:hover 很難直觀地理解樣式應用的範圍；而寫成
.module {

　.action {
　　a, a:hover {
　　　//styles
　　}
　}
}
//other modules
這樣要清晰得多。這樣可維護性必然會高很多，舉個例子：如果要改變樣式的應用範圍，增加一個適用的 action，只需把 .action 改成 .action, .action2 即可，而純 CSS 就悲劇了，要修改每個相關 rule set 的 selector。
可以方便地屏蔽瀏覽器私有語法差異。這個不用多說，封裝對瀏覽器語法差異的重複處理，減少無意義的機械勞動。
可以輕鬆實現多重繼承。
.box {
　display: block;

}
.thick-bordered {
　border: 5px solid black;
}
.notice {
　.box;
　.thick-bordered;
}
這樣無論父類有什麼改動子類都會同步更新。有人說這個在 HTML 中把 class 寫成 "notice box thick-bordered" 就好了，但是這樣增加了HTML 與樣式的耦合，如果模板中有多個 .notice 在修改時就難免做重複勞動，同時除了修改過的 CSS 文件外，客戶端緩存的 HTML 模板也需要重新下載。在 LESS 中，如果利用 mixin 來作繼承在編譯後都無需生成無用的父類樣式代碼。
完全兼容 CSS 代碼，可以方便地應用到老項目中。LESS 只是在 CSS 語法上做了擴展，所以老的 CSS 代碼也可以與 LESS 代碼一同編譯。

缺點：

須要編譯。無論是放在客戶端還是伺服器端，都是一種額外的花銷。
作者更新不夠活躍，對社區的力量使用不足。作者對 GitHub 上的 pull request 基本置之不理，他解釋說是 GitHub 上的通知讓他看不過來所以基本都無視了。所以使用中遇到的一些問題可能官方代碼得不到及時的更新。

If you』re a web developer or designer you probably faced this kind of situation before:
「I wonder if we should use a different theme on our website, can we try a blue one instead of the current green?」
2 possible answers:

A pure CSS developer: 「Damn… Can you come back in 15 minutes?」
A Less CSS developer: 「Sure! Wait just a second… Done, look!」

http://verekia.com/less-css/dont-read-less-css-tutorial-highly-addictive

這篇文章的warning也挺有意思的：

WARNING: If you like copy-pasting, find-replacing, scrolling in giant messy CSS files, not reusing your code, writing hundreds of times the same thing, you should definitely LEAVE THIS PAGE RIGHT NOW. I』m serious, if you start reading this tutorial, you might like it and could dangerously become way more productive. At the end of this read, you might even think crazy things like 「pure CSS sucks」 ! You』ve been warned…

最後抱怨幾句，在使用less的期間曾經因為 less.js 的 bug 讓我有種上了賊船下不來的感覺，就如 @顧軼靈說的一樣，作者幾乎不 merge pull requests，原作者已經三個月沒有動過less.js的代碼了，遇到問題還得自己找補丁，自己合併補丁。

本來看到問題還以為是想比對SASS和LESS的... 我高估了。

提到這個問題，應該是項目經驗還不足吧。實際項目裡邊很強調可用性和模塊化，想想以下幾個場景：

1. 要做各種內核都兼容的圓角效果，這個CSS效果是有固定模版的，那每個用到圓角的地方都複製一遍同樣的代碼的話，那如果圓角有一天都要改得更加圓一些怎麼辦？這個時候是不是可以把這些模版封裝起來會比較好？

2. 網站每個地方都要用同一種紅色怎麼辦？是要`#E7253D...#E7253D...#E7253D...#E7253D`，還是要`$red: #E7253D; $red...$red...$red`

3. 比較花哨的需求可能是要整個網站換顏色，如果頁面裡邊有帶染色的陰影，傳統方法只能是做多套css，每個都算出不一樣的顏色了。但是為什麼要自己算？為什麼不讓CSS被自動生成出來，帶染色的陰影顏色用顏色相關的函數算出來。

4. 如果html層級結構比較複雜，怎麼結構化你的css，做到selector的精確打擊。這個怕是很困難的吧。

上邊這些SASS和LESS都可以解決，而這還只是給CSS帶來的最淺顯的好處。

如果你視這些東西為奇淫巧計，那從實用的角度，還是離「做東西（make internet things）」遠一些吧。

如果想比對SASS和LESS，這裡有一篇文章講得很詳細，推薦閱讀：

http://css-tricks.com/sass-vs-less/

我就用來做模塊和嵌套，其他的功能暫時木有用到，但是跟node項目結合已經很爽了。。。。。

層級嵌套設計的實在是不好, 看起來似乎很美好, 但寫多了就會發現亂得跟漿糊一樣. 至於變數和運算當然是比較實用的東西, 但若只為這點功能就不太值了, 特別是客戶端版 (JS), 明顯會令網頁變慢.

看標題我還以為是sass來戰。。。

唯一不爽的時是寫好代碼之後，第二天來修改頁面上某個地方的樣式，不方便直接在頁面上copy樣式，然後定位到less代碼中....

比如我在頁面上要修改樣式的元素所應用的style為 .agent-list .column ，然後再less中找對應的代碼不方便...

不管好不好，自己實踐一下就有定論，別人說好不好沒用。

說下自己的感受。

最先是在bootstrap的網站上看到的，一下就被吸引了。

最心動的幾點如下：

1：變數定義，@navColor:#96CDCD,這樣後面就不用還去取樣，查表之類的。

2：mixin，減少n多代碼量。ps：帶參數的更帥。

3：嵌套，邏輯清楚。

4：顏色函數。

像顏色運算，條件判斷語句那些，感覺一般吧。

項目中用的話還是用less解析器編譯後的壓縮文件或者在服務端運行，把less.js引入項目確實有點得不償失。

什麼reset,base樣式,一個頁面上只載入它所需要的樣式模塊，一個頁面只需要引入一個單獨的css文件,減少伺服器請求,模塊清晰,可重用度高。大型項目上重複的模塊樣式很多,乃less的首選。

以前項目用C++的人表示：css根本不能算編程語言啊，less才有了語言的那些特性。

結構化的去寫樣式，寫起來比較舒服。對於小項目挺適用的（超大項目沒做過）。上面有人說需要編譯，看情況唄，你也可以直接就用編譯好的css。

之前一個人的項目用過，很好用，主要是模塊化和變數。

不過要說服團隊都用這個並且思路一樣還是有點小困難，就算是用less，要有完善的開發文檔，比如顏色的變數，頁面寬度。

less最管用的就是嵌套，讓css關係很清晰，雖然增加代碼量，我認為也是值得的，不用less的話會有些懷念嵌套的各種優勢，但是層次太多，嵌套太長會讓可讀性變得很差，這點也是個問題

忘了說mixin了，至於一下css3的特效圓角陰影，可以去國外網站直接抄成熟的mixin，大大節省了開發時間，而且兼容性也不錯

今天第一次用less寫樣式，感覺好爽

很好的實現了項目中的可用性和模塊化,並且提高了工作效率，何樂而不為

好處是測試起來比較方便,因為可以引用JS直接在瀏覽器上編譯,這比sass好

總覺得這是依賴，我還是喜歡傳統的笨辦法。當然自己的能力也是一方面。

挺好的，用用就知道了。

具體用less做項目的有么？如果less解析會耗費額外資源的話，貌似較大的項目就要放棄了

css本來就是比較簡單的標記語言，用它們得不償失。 css文檔真正寫好了，可維護性是很強的，另外，配置好編輯器，css寫起來很快的。自己玩玩可以，多人合作的項目就算了。學好，寫好css才是王道

不好，邏輯判斷不應該用在表現端，小項目玩玩可以，大的不行了。