SASS instead of LESS?


#1

Looks like you can only use LESS to style themes and stuff. Any chance of a SASS option?


Stylus in addition to LESS
#2

Some context from IRC:

[02.27. 03:23:09] <SneakerXZ> it is kind of interesting, they used CoffeScript but they used Less, why not SAAS? If they like indentation
[02.27. 03:23:26] <kevinsawicki> SneakerXZ:  LESS has a JS compiler
[02.27. 03:24:20] <SneakerXZ> kevinsawicki: Sass doen't have?
[02.27. 03:24:32] <kevinsawicki> SneakerXZ:  it didn't when we started using LESS
[02.27. 03:25:23] <kevinsawicki> or at least there wasn't a complete Sass implementation available in JS

#3

Yes, but they talk about the advantage of using node with C++ libraries for example the Regex lib:

Interacting with native code is also really simple. For example, we wrote a wrapper around the Oniguruma regular expression engine for our TextMate grammar support. In a browser, that would have required adventures with NaCl or Esprima. Node integration made it easy.
Atom Blog

Why not use libsass with the same benefit?


#4

@lukeholder: likely for the same reasons my team still shells out to the Ruby SASS compiler: up until recently (been a while, but think I last tried ~6months ago) the libsass version didn’t support all of SassScript.

I’ve been informed that this is different now, but it was probably too late for them to change.


#5

Honestly less makes total sense with the JS base of this project. I’ve never understood the desire to request this. Aren’t sass and less simular enough that you can work on this project regardless?


#6

Sadly libsass isn’t up to date with the Ruby-based Sass compiler. Less is a good choice for a JavaScript-based project - but it has also quirks. Anyway you could ask why they didn’t choose rework, too, as it is very similar to plain CSS and integrates nicely into the npm packaging structure.


#7

Stylus, javascript compiled, with a syntax close to coffeescript and much more powerful would be a great choice too, in my opinion.


#8

+1 for Stylus instead of LESS


#9

Why does a JS lib need to be used at all in the development? Can’t the theme build process be customized to simply compile sass files for you? Or is it absolutely strictly JS lib’s that are used? I like JavaScript, but not everyone spends all their time in Node.js.

Hopefully the process will be customizable so that people can use whatever they want (LESS, SASS, Stylus, plain CSS, etc).


#10

FWIW, I can’t speak to the choice of implementing Less over Sass, but I can say that I dived right into using Less to create the Fizzy syntax theme, and it was nearly identical to using Sass IME.

I know there are differences between the two, but just saying as someone who has used Sass faithfully for a couple years, and never once used Less, I didn’t have any trouble accomplishing what I needed to do with it.

I’m still a Sass faithful, but I don’t have one complaint about styling things within Atom using Less over Sass, and if someone does I’d really love to understand more about why other than just that it’s not what you’re used to. What are the biggest limitations or challenges to using Less instead Sass?


#11

That’s exactly how I see it, and that’s been my experience here with Atom.


#12

Ideally, I’d like you to be able to write stylesheets in whatever language you want. Like everything, it’s just a matter of time and effort to make the stylesheet translation mechanism more pluggable.

We chose to use LESS for two primary reasons:

  • SASS is a favorite here at GitHub, but it’s implemented in Ruby, and we wanted to ship with a default format that had no external dependencies.
  • LESS is used by bootstrap which we leaned on as the foundation of our styles. Opinions vary, but bootstrap has a lot of traction and GitHub employs one of its developers, so we thought it was a reasonable choice.

Stylus in addition to LESS
Have a question for the Atom team? Check here first!
Archived FAQs (see FAQ category for all current FAQs)
#13

Stylus seems like the best choice on a purely technical level, but LESS is probably better in that more people actually use it. It’s one thing to go all Coffeescript, but to also make people use Stylus? I understand that.

Considering Stylus is also compiled by JS, perhaps we could have a whole Stylus replacement package. Stylus is rediculously flexible. The fact that you can write actual valid CSS, semicolons and all and then on the next line go full on minimal Stylus syntax with meaningful indentation and no colons is pretty damn cool.


#14

+1 for SASS instead of LESS.


#15

+1 For SASS instead of LESS


#16

You guys know they won’t be adding SASS instead of LESS right? It requires ruby. You’re going to have to wait for a package that figures out how to integrate over it with a ruby dependency.


#17




#18

Guys, SASS is requiring ruby which would be complicated to build and deliver a node-based package when ruby is a requirement.
LESS is found as the simplest and therefore best solution I’m afraid.


#19

I’m with @jglovier - I’m a long time Sass user but the decision to use LESS here makes complete sense. A Ruby dependency is a pain when the net gain is trivial.

There is parity for the most oft-used features in each language (variables, mixins, nesting, extend) so switching between the two should be fairly trivial for all but the more complex tasks. Furthermore, a JS compiler (e.g. LESS/Rework/Myth) makes it far faster for style iteration over Sass, which until libsass gets feature parity/stability with Ruby Sass, can feel glacially slow in comparison.

Sass lovers (and I include myself) are defending a weak argument here until there is a fast dependency-less compiler for the language (e.g. libsass).


#20

For what it’s worth, you can create themes with vanilla CSS instead of LESS files - so you could use SASS to create those CSS files