11–20 of 131 posts
LESS is beautiful as it is. But processing LESS code in the browser would mean that I can't use LESS.js for mobile web apps. Although there are mobile devices with 1ghz processors already out in the market, there is still a lag in rendering mediocre-weight pages that contain js on mobile devices.
P.S: Congrats on keeping LESS simpler.
I don't know. It's not bad, but it's not for me. But going as fas as to say it will obsolete CSS, that's just too much.
The Sass compiler was (is?) more mature, and the language feels more consistent (see the '&' operator in Sass vs the :hover special case in Less). The editor/tool support was quite a bit better too.
Sass doesn't have a javascript in-browser implementation (afaik), but for rapid development it can watch a folder/file for changes and automatically recompile to static CSS files.
Plus there's a firebug plugin, so you get Sass line numbers / references instead of compiled CSS line numbers: https://addons.mozilla.org/en-US/firefox/addon/103988/
Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as poss…
I don't know. As a fan of CSS I don't really "get" Less.js ... Sure I understand the benefit of defining certain properties, but are the benefits good enough to warrant depending on an additional javascript library for something like this? What happens if people block javascript? I don't know. It's not bad, but it's not for me. But going as fas as to say it will obsolete CSS, that's just too much.
Nothing, in production you'd use the compiled ver. The article should make this clearer though.
Running a compiler in the browser in production will never be a good idea. If you care about the speed that your website displays -- and you should -- the slowdown caused by parsing, processing, and concatenating large amounts of CSS will dwarf over-the-wire time. People who seriously care about the usability of their sites have been spending a lot of effort recently figuring out how to get load times as fast as poss…
less and sass both allow you to compile to css. The live, in browser compiler is just intended to speed up development.
"Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, no CSS pre-processing, LESS will handle it live."
No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.
That way, you'd also have the benefit of defining often-used attribute values (e.g. colors) in a variable, and you could also group often-used combinations of attributes together in a variable or sub template.