jlitola / play-sass

Sass asset handling for Play Framework 2.0 *DEPRECATED*
MIT License
90 stars 28 forks source link

Use Java LIBSASS instead of path executable #42

Open mdedetrich opened 9 years ago

mdedetrich commented 9 years ago

In the old days, SASS only worked with Ruby, but there is now a reference SASS implementation as a C library (called Libsass). Because of this, many other languages are able to support SASS, including Java through Jna.

There is a libsass-maven-plugin (https://github.com/warmuuh/libsass-maven-plugin) which is a Java wrapper around libsass.

It would be more ideal if play-sass used libsass instead of having to rely on sass being available on path, this would provide many benefits

Definitely willing to make a pull request to implement this, assuming there are no real objections

andrewgies17 commented 9 years ago

Admittedly I'm not completely sure, but some of the tools I use make it sound a lot like libsass isn't compatible with compass. Would that be a potential drawback of this switch?

On Tue, Sep 1, 2015, 00:21 Matthew de Detrich notifications@github.com wrote:

In the old days, SASS only worked with Ruby, but there is now a reference SASS implementation as a C library (called Libsass). Because of this, many other languages are able to support SASS, including Java through Jna.

There is a libsass-maven-plugin ( https://github.com/warmuuh/libsass-maven-plugin) which is a Java wrapper around libsass.

It would be more ideal if play-sass used libsass instead of having to rely on sass being available on path, this would provide many benefits

  • More guarantees on correctness (can fix libsass versions, and can use specific libsass versions if there are known versions that cause problems)
  • Speed/Performance. The reference libsass is implemented in C, so it should offer superior performance compared to the ruby version
  • (Possible) Better cross platform support. The libsass-maven-plugin provides dynamic libraries for linux64/mac OSX/windows, although its possible to add more platforms by compiling our own binaries and adding them to -Djna.library.path (or we can just make a pull request for additional builds with other platforms). Although people can argue that Ruby is also cross platform, setting up Ruby deterministically in separate environments is much harder than just supplying built dynamic libraries
  • Much easier to work with build tools/deployment issues (building on from the previous point). Assuming your server is using the one of the supported OS's, you don't need to do the whole hoopla of setting up RUBY/working with $PATH variables, etc etc.

Definitely willing to make a pull request to implement this, assuming there are no real objections

— Reply to this email directly or view it on GitHub https://github.com/jlitola/play-sass/issues/42.

mdedetrich commented 9 years ago

According to https://github.com/sass/libsass/issues/82 and https://github.com/sass/libsass/issues/82#issuecomment-77489099, there are multiple solutions for compass for libsass, one of them is wellington (https://github.com/wellington/wellington)

I think this would be annoying, and would be calling for a bump in major version, but due to huge momentum from node.js, a lot of stuff in Ruby land is being converted from Ruby to C

I don't see a problem with supporting both, since some people will still want to use the ruby implementation

mdedetrich commented 9 years ago

There is also https://github.com/Compass/compass/issues/1916

Apparently compass 2.x uses libsass and not ruby's sass by default?

Also this http://stackoverflow.com/questions/26088529/using-libsass-with-compass