Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to libSass #1916

Closed
7 tasks
chriseppstein opened this issue Jan 13, 2015 · 23 comments
Closed
7 tasks

Port to libSass #1916

chriseppstein opened this issue Jan 13, 2015 · 23 comments

Comments

@chriseppstein
Copy link
Member

This issue will track the top level tasks that are required for Compass to be ported to libSass. When this issue is closed, we will release Compass 2.0.

Vision

Compass 2.0 will not use ruby and will run libSass for compilation by default. However, It will allow you to opt-in to using ruby sass.

TODO

  • libcompass - a C++ library that can be used to compile a Sass file in a Compass-compatible Sass environment.
  • compass compiled binaries for mac, linux, and windows that implements a large subset of the commands supported by the ruby compass command including a watcher and sprite generator.
  • ruby ecosystem - Most compass extensions do not need to use ruby for much more than to self-register themselves. However, some do use ruby to define Sass functions. Obviously, this won't work going forward as it is implementation specific and it is not feasible to embed a ruby interpreter into libsass as most extensions expect not just a ruby language, but the ruby sass implementation specifics to be present. I think Lua may be a better language to allow Sass extensions in. It is trivial to embed a lua interpreter in both ruby and c++ and to creating bidirectional bindings of the public API that we want to expose to that environment.
  • New config format. Either Sass introduces an extensible config format or compass creates one that is portable between both ruby and libsass. (probably start with compass and then if we like what we make, migrate that to sass as a standard. See: Project configuration for Sass sass/sass#1155)
  • Decide if compass 2.0 should be written in Rust instead of C++ and simply use rust/c bindings to call out to libSass.
  • Ensure that libSass is feature compatible with the features compass uses or dumb compass down to make it so. Especially around the importer architecture which in libsass seems to assume sass files on disk.
  • Installer & upgrader - get updates to the binaries as well as the sass files and caniuse data.
@chriseppstein
Copy link
Member Author

Please let's keep the comments on this issue on-topic. I appreciate the enthusiasm, but I need this to be a useful issue that can be used to discuss the work and track the issues so I will delete any +1 or other such comments that are intended to voice support or excitement. Feel free to send me a tweet if you need to emote as such.

@KittyGiraudel
Copy link
Contributor

I will not be able to help with C or Rust, but once you have a working skeleton, you can count on me for extensive testing.

@saschaeggi
Copy link

Ping me if you need testers for this! This is huge! :)

@ritcheyer
Copy link

@chriseppstein This is fantastic news and would make many a Frontend Developer's Day! 😄 I know the nature of OSS timetables are…flexible but wondering if you have any ideas for when this may be completed?

(in light of your first comment, feel free to delete this)

@chriseppstein
Copy link
Member Author

Sorry, no dates at this time.

@xzyfer
Copy link

xzyfer commented Jan 14, 2015

I'm happy to lend any help I can in regards to Libsass. I'm also happy to contribute to compass c/rust side of things.

@chriseppstein
Copy link
Member Author

An alternative approach would be to port Compass to Javascript and target only node-sass. This is less generally re-usable but it would make compass easier to contribute to. I'm still leaning towards having a core for compass that is statically compiled.

@chriseppstein
Copy link
Member Author

I researched it and it turns out to not be that hard to embed resources like the sass files into a compiled binary. But it will require a custom importer to extract them from the executable without unpacking them -- though we will still need to provide a compass unpack compass like we do now which will put the compass stylesheets onto disk.

@lolmaus
Copy link
Contributor

lolmaus commented Jan 18, 2015

It would be too good if nobody were unhappy about this, right?

As a happy Ruby user, i'm very concerned with what will happen to Ruby Compass. The matter is that Compass is an umbrella term for a number of entities:

  • A library of handy Sass mixins and functions.
  • A standard for organizing Sass code in a project and a correpsonding configuration file.
  • A command-line tool to create, compile and enhance projects.
  • A standard for bundling Sass extensions.
  • An ecosystem of those extensions and an effortless way to import them.
  • A mean of effortlessly enhancing vanilla Sass functionality with custom behavior.

After you migrate Compass off Ruby, what will be left of that?

@chriseppstein
Copy link
Member Author

The only aspect of compass here that will be called into question is:

A mean of effortlessly enhancing vanilla Sass functionality with custom behavior.

If by "effortlessly" you mean to ruby users using ruby code then that aspect will cease to exist. I hope to find a way for the "sass language" provide a standard mechanism for extensions that can be used in different implementations. I have started a conversation about this here: sass/sass#1608

@scottdavis
Copy link
Member

we could even consider something like mruby: https://github.com/mruby/mruby

@klojniewski
Copy link

+1

@saschaeggi
Copy link

What's the status here @chriseppstein ?

@saper
Copy link

saper commented Apr 23, 2015

I'd vote for a simple C instead of C++/Rust/whatever. libsass does not require the client to be written in C.

@scottdavis
Copy link
Member

Im pretty sure we have transitioned away from this and are setting up suport for a compass like system on node-sass (libsass or node) using the https://github.com/sass-eyeglass/eyeglass project.

@Zauberfisch
Copy link

@scottdavis you/they/we are? that's bad news, at least for me :S
not that I am per se against node, but swapping ruby out for javascript doesn't sound like a good idea to me. We would just trade people complaining about having to install ruby for people complaining about having to install node+npm.
Obviously the performance gains are the main factor, and I see the argument of ease of contribution, but I think having binary of compass is quiet a big thing as well.

I have actually migrated systems away from compass, just because I can deploy libsass easily to my server infrastructure.

@lolmaus
Copy link
Contributor

lolmaus commented Apr 23, 2015

Node/npm are a standard for web development. I can't imagine a modern web site/app developed without the use of Node.

@Zauberfisch
Copy link

I can.
While I do have node installed, and use npm and bower, I have projects where I successfully avoided using those.
It is obviously often a trade-off, but to me, avoiding unnecessary dependencies where I can is an important issue.

@chriseppstein
Copy link
Member Author

A much higher percentage of Sass users know javascript than know ruby. As a result javascript is a vibrant ecosystem for front end tool development. In most user's stacks, node has become a must-have for front end tooling. Ruby sticks out in these applications like a sore thumb. The plan stated above made Compass even more inaccessible to our users because even fewer developers know C/C++, but eyeglass makes the core features of compass available in a much more accessible way which means our users can contribute to development and that's a huge win.

I know not everyone will be happy about this. There's nothing I can do about that. This is progress and a big win for the Sass community at large.

@acusti
Copy link

acusti commented Apr 23, 2015

That’s exciting! It will very much simplify my readme files that I write with instructions for developers how to get the development toolchains up and running, and the issues those developers are then likely to run into it.

For those of us who subscribed to this issue to know when we will be able to use Compass + libsass, is their another issue we could follow to get updated on the migration to node-sass (and the resulting compatibility with libsass)? Or is the Compass functionality only going to be installable as smaller NPM modules and no longer be recognizable as its current form?

@chriseppstein
Copy link
Member Author

@acusti It is my goal that most compass projects could be ported to eyeglass with only minimal changes. What I'd like to see is an eyeglass-compass-compat module that provides a shim for compass-based stylesheets.

In the javascript world, autoprefixer is a better solution than the css3 module, so there's currently no plan to port the css3 module to eyeglass, though obviously it is something that could be done by a member of the community.

@lolmaus
Copy link
Contributor

lolmaus commented Apr 23, 2015

I've been using Autoprefixer with Ruby Compass first from npm, then from RubyGems. :P

@alanhogan
Copy link

Hey Chris,

Appreciate all the thought that went into here and think the resolution is a sound one.

Just a little note — you may want to consider editing the description on this issue, as a quick read gives the impression Compass 2.0 with lib-sass support was released, and this is a top search result for “compass lib-sass.”

screen shot 2015-07-13 at 11 25 03 am

Cheers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests