Comment by micheljansen | Hacker News Reader

Comment by micheljansen | Hacker News Reader

I think the individual comparisons are good, but the conclusion is wrong. Yes, Sass is technically superior to Less; it can do a lot of things that Less cannot. That does not mean that you should use Sass over Less.

The truth is, for 99% of use cases they are exactly the same. Sass is a bit more mature and it allows more programming, so it is potentially more powerful than Less, but that also allows it to deviate for CSS further, which is not necessarily a good thing if you have to work with people who only know CSS.

I personally use Less because it helps me develop faster. Less is implemented in JavaScript, which means it can run in the browser. Less.js' "watch mode" is awesome for speeding up development: save your .less stylesheet and the browser immediately shows the new styles. This is something SASS cannot do and.

Finally, to correct some factual errors in the article: Less does allow some programming, loops etc. It's just incredibly awkward and barely useful, but you can use JavaScript (I used that to make this: https://github.com/micheljansen/dynamicgif.less). Also, the "Helping with CSS3" point is moot if you use http://lessprefixer.com/ and keep that updated.

>Sass is technically superior to Less; it can do a lot of things that Less cannot. That does not mean that you should use Sass over Less.

No, this does mean that you should use Sass. This is how technical decisions are made. You create a list of categories with weights and then you score all available options and add their points. You then use the one with the most points. Y'know, the best one.

>This is something SASS cannot do and.

Sass also has a watch mode. Well, you'll need Ruby, but so what?

If you use a static website generator (like Middleman) for your quick and dirty prototypes, there is zero overhead involved. You use "example.css.scss" as file name and reference "example.css". That's all you have to do.

I think making CSS more like a programming language is a bad idea. Insofar as LESS lets you do dumb programming tricks in your faux CSS it's a bad idea. I think SASS is going in the wrong direction of putting more ability to create convoluted rubbish in the hands of people who create enough convoluted rubbish with simpler tools.

And I think the signs of activity on LESS vs. SASS reflect not that SASS is in mor aggressive development, although it might be, but tha LESS is more popular but the developers are more cautious in adding features.

> I think SASS is going in the wrong direction of putting more ability to create convoluted rubbish in the hands of people who create enough convoluted rubbish with simpler tools.

This sounds like maybe more of a people problem than a technical problem.

>I think SASS [...]

Based on what? Sass helps me to write cleaner, better organized code. Furthermore, it reduces typing work. It's great, really. There is a reason why more and more people are using it.

Did you see the vendor prefix debacle? With Sass/Compass, vendor prefixes aren't an issue anymore. Everyone who used Sass/Compass correctly was not part of the problem.

How do you handle sprite sheet generation? How do you handle cache busting of your background images? How do you handle vendor prefixes? These things are very annoying to handle if you have to do that manually.

You don't need dumb programming tricks to handle vendor prefixes. What I'm against is making CSS more complex.

Sass has an implementation of "watch mode": sass --watch + livereload (either the guard-livereload gem or the app). This allows you to save you file and have the browser immediately refresh. If you use middleman to build out your templates this functionality is built in with "middleman server --livereload"

Reply on news.ycombinator.com