Yeah, removing Ruby as a dependency for a Java + JavaScript application was a big win for us as well. What still bugs me is things like this (from the gulp-sass docs):
gulp-sass is a very light-weight wrapper around node-sass, which in turn is a Node binding for libsass, which in turn is a port of Sass. Because of this, the issue you’re having likely isn’t a gulp-sass issue, but an issue with one of those three projects.
I’m still three levels removed from the actual tool. It’s better than the ruby dependency I had before, but it’s why I’m looking to remove Gulp from my equation.
I can see how that would be confusing. What I meant was that “it was a dependency written in Ruby.” I’ll change the phrasing to match @flyingfisch’s suggestion.
I’m surprised more people don’t just use the template system they use for html (whatever it is) for css. I suppose there’s magic support for mixins or whatever, but there’s something to be said for plain templating too (maybe with fragments if needed). No additional language to learn, no additional tooling, etc.
In addition to compiler warnings, using a preprocessor instead of text-based templating means you can lint the source code, including the “extra” features.
We don’t seem to care about this for html, where I think it’s easier to inadvertently insert mistakes. Sure, there are some programmatic generators, but they seem more the exception.
I’m torn. That’s a good reason, but maybe it would be better to use a validator on the final output (HTML and css) because who knows what’s going to happen between parsing and output.
You’ve got some good points there. However, personally, I’d much prefer to use a programmatic template engine to a string-based one. JSX and Ember’s Glimmer engine seem to be along those lines (though I’m not certain.)
I think validating the output is great. However, it doesn’t have all the benefits of linting the source code and being able to enforce that the source is being written “the right way” for maintainability.
Yeah, removing Ruby as a dependency for a Java + JavaScript application was a big win for us as well. What still bugs me is things like this (from the gulp-sass docs):
I’m still three levels removed from the actual tool. It’s better than the ruby dependency I had before, but it’s why I’m looking to remove Gulp from my equation.
It sounds like you’ve replaced a ruby dependency with a node dependency.
Can you bind directly to libsass from Java? (I’m not a Java dev, haven’t looked into it).
Isn’t this backwards? Ruby does not depend on Sass.
Yeah, I think that line was supposed to read: “And while we love Sass, we didn’t love the fact that it had a Ruby dependency.”
I can see how that would be confusing. What I meant was that “it was a dependency written in Ruby.” I’ll change the phrasing to match @flyingfisch’s suggestion.
I’m surprised more people don’t just use the template system they use for html (whatever it is) for css. I suppose there’s magic support for mixins or whatever, but there’s something to be said for plain templating too (maybe with fragments if needed). No additional language to learn, no additional tooling, etc.
The main benefit I’ve seen is that Sass gives you parse errors (before you load the page) rather than browser warnings.
Tools like autoprefixer are also worth the added complexity if you have to support multiple browsers.
In addition to compiler warnings, using a preprocessor instead of text-based templating means you can lint the source code, including the “extra” features.
We don’t seem to care about this for html, where I think it’s easier to inadvertently insert mistakes. Sure, there are some programmatic generators, but they seem more the exception.
I’m torn. That’s a good reason, but maybe it would be better to use a validator on the final output (HTML and css) because who knows what’s going to happen between parsing and output.
You’ve got some good points there. However, personally, I’d much prefer to use a programmatic template engine to a string-based one. JSX and Ember’s Glimmer engine seem to be along those lines (though I’m not certain.)
I think validating the output is great. However, it doesn’t have all the benefits of linting the source code and being able to enforce that the source is being written “the right way” for maintainability.