4 ms·
I won't use LESS CSS for anything. Why? Because it's another layer of abstraction which is a pain in the arse to debug when it goes wrong, which it does regular
by bwarp 15y ago
I won't use LESS CSS for anything. Why? Because it's another layer of abstraction which is a pain in the arse to debug when it goes wrong, which it does regularly. It's ok for about 3 months which is enough to build some false confidence in it, then WHAM problems.
- jacobr 15y agoThe error messages you get from the command line less compiler are.. less than helpful. Say you have a typo and use an undefined variable - if you use @imported files, which you will do for any site of a reasonable size, it's just a JavaScript error and you will have no idea whatsoever which file the error is in, much less which line in the file. It's terrible, actually.
- ddagradi 15y agoTry SCSS instead? It provides much better errors for debugging (by virtue of not being javascript-based). "when it goes wrong, which it does regularly" requires more substance though; LESS or SCSS have never presented a real problem for designers or developers I've worked with. These are valuable tools that address a deficiency when crafting CSS, and should not be discredited so quickly.
- untog 15y agowhen it goes wrong, which it does regularly. What do you mean by "it goes wrong"? Do you mean the LESS parsing engine fails? Because I've used LESS extensively and it's never happened once. If you mean "my code was incorrect" then yes, LESS errors could be more descriptive. But it's hardly world-ending stuff.
- bwarp 15y agoI'll explain further: I used it extensively for about 3 months on a project and ended up binning it and going back to plain CSS. I experienced utterly unhelpful parse errors resulting in head scratching for literally hours. Small behavioral changes between versions resulting in broken CSS. Zero error checking in the code whatsoever. Completely 100% incompatible with some browser hacks. Each of those, plus the non-portable learning curve eats time and therefore cash resulting in a net loss versus plain CSS.
- untog 15y agothe non-portable learning curve eats time and therefore cash resulting in a net loss versus plain CSS Shrug. I've never experienced the problems you mention so I can't say much, but using plain CSS seems like a huge time-waster after having used LESS extensively. It cuts down my CSS work dramatically.
- crazygringo 15y agoI don't think I've ever met a new "language" with a smaller learning curve. It took me about half an hour to master everything in LESS. It's so basic and intuitive. And with the benefits it has brought, in terms of code intelligibility and structure, and lack of redundancy, I'm not sure I'm ever going back to pure CSS again. I am literally baffled by your experience. What version changes created problems for you? And as for error checking, pure CSS has no error checking at all, so I don't understand how LESS could be anything but better in that regard. As for using browser hacks with LESS, I've never tried, but since you can always include conditional stylesheets to account for browser differences, it doesn't seem like that should be a dealbreaker. It would be pretty cool if LESS supported inline browser detection per-rule, however.
- ianstormtaylor 15y agoHonestly, you are right about LESS but not about the abstraction that pre-compilers provide. Try Stylus. It has way better error reporting, and less broken stuff too. http://learnboost.github.com/stylus/ http://learnboost.github.com/stylus/ If you are working on a project of any size, a pre-compiler becomes essential. And without all of the braces and semi-colons, nested selectors in Stylus become a really nice representation of the module your describing.
- bwarp 15y agoI'm working on a project with about 5000 HTTP endpoints and over 2 million lines of code. We don't need a precompiler!