使用 LESS 进行 CSS 渲染会破坏基于浏览器的开发吗？

Question

我刚刚下载了 Twitter Bootstrap 来看看 LESS 的实现。我的第一印象是 LESS 似乎是编写 CSS 的好东西，但它破坏了基于浏览器渲染进行快速编辑的能力。

假设我收到了一个我以前从未遇到过的实时站点，它是由其他人构建的，并且通常没有记录，并要求我更改某些元素的属性。该网站有 2000 行 CSS，我最不想做的就是熟悉其中的大部分内容。

传统 CSS，在浏览器窗口中：检查元素：匹配的 CSS 规则：styles.css:1145。 在选择的文本编辑器中打开 styles.css 到第 1145 行，进行更改、测试、完成。

LESS，在浏览器窗口中：从一个 CSS 文件中返回匹配的 CSS 规则，该文件是从（在 Bootstrap 中）42 个不同的 LESS 文件的任意组合编译而来的。编译后的 CSS 文件中没有任何迹象表明哪个组件 LESS 文件源自该属性。继续在 42 个不同的 LESS 文件中搜索进行更改的适当位置。

因此，当您有时间/熟悉项目以从头开始理解它时，LESS 似乎真的很棒 - 这样您就知道哪个变量声明了在 mixin 中调用的颜色以产生边框在类声明中被赋予了更多的属性——但当你是一个不幸的开发者，他有十分钟的时间从别人的代码中弄清楚如何（更具体地说，在哪里）改变所有边框的颜色时，就不是很好了。

我都搞错了吗？是 LESS 打破了懒惰、快乐的浏览器端快速修复策略，还是有一些我还没有想出的方法来保留快速而肮脏的工作流程？

Answer 1

LESS 可以在客户端（Chrome、Safari、Firefox）和服务器端运行，使用 Node.js 和 Rhino。 (http://lesscss.org/)。所以是的，你can use it also on the client-side。 只需确保将 less 样式表与 rel="stylesheet/less 链接，并记得将 less.js 添加到 HTML 中以从 less 源生成 CSS。

一个缺点是像 Firebug 这样的开发工具没有原生支持 less。这与 CoffeeScript 的问题相同，目前浏览器中的调试工具非常差。我很确定debuggers will evolve to support other JS languages，如果看到类似的样式表语言发生类似的事情，我不会感到惊讶。但是，当这些工具成为主流时，我不会屏住呼吸。

我同意您的想法，虽然 LESS 对于核心 CSS 开发来说可能是一个绝妙的想法，但它也为您的开发堆栈增加了一层复杂性。这样做可能并非在所有情况下都是合理的。