優點：

1. 結構清晰，便於擴展。對於模塊很多的應用特別是單頁 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。
2. 可以方便地屏蔽瀏覽器私有語法差異。這個不用多說，封裝對瀏覽器語法差異的重復處理，減少無意義的機械勞動。
3. 可以輕松實現多重繼承。
   .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 來作繼承在編譯後都無需生成無用的父類樣式代碼。
4. 完全兼容 CSS 代碼，可以方便地應用到老項目中。LESS 只是在 CSS 語法上做了擴展，所以老的 CSS 代碼也可以與 LESS 代碼一同編譯。

缺點：

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

less的優缺點