3 ms·
I'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 unhelpfu
by bwarp 15y ago
I'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.