我刚刚下载了Twitter Bootstrap，看看LESS的实现。我的第一印象是LESS似乎是编写CSS的好东西，但它打破了基于浏览器渲染进行快速编辑的能力。
假设我已被交给我之前从未遇到过的现场网站，由其他人建造，因为他们经常记录的文档很少，并要求更改某些元素的属性。该网站有2000行CSS，我想做的最后一件事就是熟悉它。
传统CSS，在浏览器窗口中：Inspect Element：Matched CSS Rules：styles.css：1145。 在所选的文本编辑器中打开styles.css到第1145行，进行更改，测试，完成。
LESS，在浏览器窗口中：从CSS文件返回一个Matched CSS规则，该文件是从（在Bootstrap中）42个不同LESS文件的任意组合编译而来的。编译的CSS文件中没有指示哪个组件LESS文件发起了该属性。继续搜索42个不同的LESS文件，找到适当的位置进行更改。
因此，当你有时间/熟悉一个项目从头开始理解它时，LESS似乎真的很棒 - 这样你就知道哪个变量声明了在mixin中调用的颜色以产生一个边框在一个类声明中给出了进一步的属性 - 但是当你是一个不幸的开发人员，有十分钟的时间从别人的代码中弄清楚如何（更具体地说，在哪里）改变所有边界的颜色时，不是那么好。
我弄错了吗？是不是LESS打破了懒惰，快乐的浏览器端快速修复策略，或者是否有一些方法可以保留快速而肮脏的工作流程？
答案 0 :(得分：1)
LESS在客户端（Chrome，Safari，Firefox）和服务器端运行，包含Node.js和Rhino。 （http://lesscss.org/）。是的，你can use it also on the client-side。
只需确保将较少的样式表与rel="stylesheet/less相关联，并记住将less.js添加到HTML中，以便从较少来源生成CSS。
缺点是像Firebug这样的开发人员工具没有更少的原生支持。这与CoffeeScript的问题相同，CoffeeScript现在在浏览器中的调试设施非常糟糕。我非常肯定debuggers will evolve to support other JS languages，看到样式表语言类似的事情，我也不会感到惊讶。但是，当这些工具进入主流时，我不会屏住呼吸。
我分享你的思路，虽然LESS对于核心CSS开发来说可能是个好主意，但它也为你的开发堆栈增加了一层复杂性。在所有情况下这样做可能都不合理。