What is LESS CSS? Hints and tips | Hacker News Reader

What is LESS CSS? Hints and tips

blog.bugsense.com

33 pointsPanosJee17 comments

I've used scss and less and I prefer SCSS.

When I first started using less I found the javascript parser missing some functionality that was in the full ruby gem. Also, since I use django, I found integrating with scss much easier, especially with pyscss.

I find that scss provides a level of abstraction that I am comfortable with. Because of pyscss I can run it from the command line and figure out exactly what is going on pretty easily.

With compass I find that I write much cleaner css code. But the big win is being able to nest my css. Nesting CSS brings it much closer to the HTML that you are styling.

In my mind this is the huge win.

Can you tell me what the syntactical differences are between LESS and SCSS? Because they seem to do basically the same thing, as far as I can see. I use LESS right now, but for no good reason- I just happened upon it first.

Last time I checked, Stylus provides more powerful abstractions and a cleaner syntax

http://learnboost.github.com/stylus/

Very pythonic. Me likes!

Can't recommend Stylus enough. Some features not found on less or scss: optional colons, semicolons and braces and referencing properties:

  body
    color black
    a
      color @color

will compile to

  body{
    color: black;
    a{
      color: black;
    }
  }

And you'll never have to worry about the missing semi-colon error from the article!

+1 for Stylus.

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.

The 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.

Try 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.

when 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.

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.

the 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.

I 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.

Honestly, 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/

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.

I'm working on a project with about 5000 HTTP endpoints and over 2 million lines of code. We don't need a precompiler!

I got bit by the switch from Ruby to Node.js. The Node.js arrangement was considerably more difficult to set up on the older systems we maintain. Most annoyingly lesscss.org makes no mention of the switch away from Ruby. Our plan right now is to abandon less-css and just check the converted CSS into our repo - the (server setup complexity) costs far outweighed the benefits.

[edit] Well I guess the old repo did mention the switch :\ https://github.com/cloudhead/less still frustrating

I had been thinking about using LESS/SASS for a new project, but ultimately I decided on PHP. Overkill perhaps, but it gives me access to the rest of the site variables, database calls, etc.

Reply on news.ycombinator.com