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.
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.
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.
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.
This sounds like maybe more of a people problem than a technical problem.
"Sass consists of two syntaxes. The original syntax, called "the indented syntax" uses a syntax similar to Haml. It uses indentation to separate code blocks and newline characters to separate rules. The newer syntax, "SCSS" uses block formatting like that of CSS. It uses curly brackets to denote code blocks and semicolons to separate lines within a block. The indented syntax and SCSS files are traditionally given the extensions .sass and .scss respectively."
"Sass and LESS both use the standard CSS syntax. This makes it extremely easy to convert an existing CSS file to either preprocessor. Sass uses the .scss file extension and LESS uses the .less extension. The basic Sass or LESS file can be setup like below:
As you may have noticed, this is just regular CSS, which compiles perfectly in both Sass and LESS.
It’s important to note that Sass also has an older syntax, which omits semicolons and curly brackets. Although this is still around, it is old and we won’t be using it past this example. The syntax uses the .sass file extension and looks like this:"
Some compiler geek should create a tool to translate code from one preprocessor to another, so mixin support would not be an issue.
The key problem is that Stylus doesn't make a clear visible distinction between control structures, mixins, and other meta-level constructs. With Stylus, you can trivially override built-ins and it's very difficult to "go to definition", so to speak. SASS has very obvious symbols which call out the presence of preprocessor stuff. This makes it much easier to visually scan stylesheets and map what you're seeing in the inspector to what you're seeing in the source files.
Simply put, because the gap between CSS and the preprocessor language is so narrow, it makes sense to call out differences. Unlike, say, C and x86, it's too easy to look at Stylus and CSS side by side and be confused by their similarities.
SASS is a more mature project with a solid design.
LESS and SCSS are syntactically conservative. I feel they retain the grammatical conventions of CSS (curly braces) as a way to ease the learning curve for conservative developers.
They introduce developers to the powerful features (mixins, variables) of extended CSS. But retain their familiar CSS curly bracket syntax.
Eventually it makes sense for said conservative developers to take the next step and adopt SASS's clean syntax.
There is also another advantage to Less/SCSS, which is that existing CSS files are already compatible, so you can start a gradual migration without effort.
This means for instance that an outside designer, that does not know Sass, can come in and contribute directly to the codebase without his workflow being disrupted and without me having to tutor him in Sass. This is how design works anyway - you start with a bunch of PSDs that get accepted, you transform that into static HTML and CSS (that have to be emailed around and approved), then you start adding dynamic features, you then go back to the designer to fix the design in case the dynamic content doesn't blend well, then you start refactoring the HTML/CSS to be clean and easy to maintain ... but this is only the last step, because the other steps, like getting the design right, are more important.
When you say that Sass should be the true successor to CSS, you're thinking like a programmer. I also wish that Gimp would be the true successor to Photoshop, but that won't happen.
Not sure about SCSS, but in my case Less choked on some complex hacks like IE filters. Not arguing about their evilness, but the fact remains—not always you can simply rename .css to .less and gradually start using new features. (In the end I kept CSS as is, with a separate Stylus file with overrides and new styles. SCSS wasn't an option, and I have a feeling it also suffers from these issues.)
Personally, I like bracing, because it is a better visual indicator, for me, of structure. I dislike indent-based blocking (Python, SASS) because I think it looks cluttered; I like brace-based blocking (C, LESS) because they're unambiguous and stand-out 'signposts' for my eyes as I read code. (I'd use SCSS if it wasn't Ruby-based. I like tools I can hack on and working in Ruby is, for me, a miserable experience.)
There are more reasons make that stylistic decision than "it's easier", even if you don't like it and even if, heaven forfend, it's not part of what you consider "the only true successor".
That said, I'm not sure why haml isn't as popular as sass.
Total pull requests:
Number of commits in the last month in LESS: 11
Number of commits in the last month in SASS: 35
I really wish that was true. From my experience, almost every time I jump to the forks sections of libraries I'm using (or interested in using) I'm disappointed when I see that 99% of thos forks contribute nothing. Forking by definition was a serious move, now (on github/bitbucket) it's not - most of the time it's just one-click copying the project to your own collection and it's just noise when I'm really looking for an alternative fork. Just my 2 cents why I'm not impressed by numbers of forks as a project sustainability measure, it's not an opinion on less/sass specifically.
I agree that it's hard to find real forks, watchers are a good indicator but you can't search/filter by that. On the other hand, meaningful forks tend to change their name the moment they detach from the original.
I use them both on daily basis, SCSS & Compass for a Sencha Touch project and LESS & Bootstrap for web dev work, along side with CodeKit to compile them and the major difference that I see is the speed of compiling. The projects I work on are both pretty large and with many .scss/.less files but LESS compiles way faster for me and this is a big plus.
Also, LESS is pretty useful for rapid prototyping since you can use the less.js and skip the compiling part altogether.
Not just. It's a plus for someone who already uses CoffeeScript in a Django project and don't want to bring in another huge piece of infrastructure as a dependency.
For anyone who is curious, the steps required to use SASS on Windows are something like:
1. Download RubyInstaller from rubyinstaller.org and run it. (This is a self-contained Windows installer for Ruby and the related tools/documentation.)
2. Run "gem install sass" at a command prompt. (This downloads and installs SASS itself, including SCSS.)
Personally, I'd love it if Ninite picked Ruby up as an option, because I already install many other tools that way in a single step. However, installing Ruby manually is no harder than installing any other piece of Windows software you download, and installing SASS on top is literally a one-liner.
Unless you're developing on a relatively old and low-powered system, I don't see any downside to having the extra software installed either: it's just another tool, occupying a few MB of hard drive and a few characters in your PATH, and IME it's perfectly friendly toward development toolchains for other languages.
cssom - https://github.com/NV/CSSOM
* edit: fixed typo
I'm not sure I'm going to use it, because of the compiled dependency (I'm on a Scala/Vert.x stack and I like being able to just check it out and hit "go"), but it's at least a practical option for me and I'm glad it exists.
I have on occasion had reasons to be mucking around in the LESS codebase. I cannot do that with SASS (well, I could, but I'd have to use Ruby and that's a non-starter for me).
Horses for courses, the real story is that these pre-processors are getting serious traction.
Not sure on my history here but i'm pretty sure i remember only the SASS variant being available (no braces among other things) while LESS stuck to a more css-like grammar. later SCSS came along which was CSS grammar for SASS.
It seems like I've run into more projects using LESS -- anyone know of any statistics?
All the twitter bootstrap mixins available to you in sass format.
I don't do a lot of FE dev but I can count the number of times I've used `@` on one hand. However, I could see myself making use of `$` as a parent selector quite often. How would SCSS adapt to this?
When I'm at my day job I use Less (well, more specifically Lessphp) for the simple reason that there's a Drupal module for it, which integrates very well with building Drupal sites.
Can we get past this silly attitude that my coding style is better than your coding style even though the outcome is the same?