Evangelizing beyond the Rails developer
Back in 2008 I heard about this thing called Rails, and a fellow developer told me about a new CSS language called Sass. At the time I was working for a company that heavily leveraged Microsoft technologies. Ruby was not something that we could plug into our environment. Sass was a new toy I could read about, that’s as far as it went.
Fast forward just a year, when I began working with a Rails team. Their first question, “You know Sass?” I replied, “Nope, but it’s a great time to learn!”
Since then I have been a huge advocate for the use of Sass, and still continue to promote awareness. This is pretty easy to evangelize within the Rails community, but apart from Rails, it is difficult to convince people. I went on various speaking engagements, and spoke about better ways to manage our growing CSS libraries of code.
As part of raising awareness, I continue to speak with groups of designers and developers. We as UI devs need to understand UI patterns and build larger, more complex modules from smaller base UI parts, and accept concepts like state, assembly, and layout. All great ideas.
When Jonathan Snook’s SMACSS came out, I at least had validation in the market on these ideas. But what really separated me from Jonathan was the fact that I did not see a way to make this work without Sass, and that was a problem. Out of all the early speaking events I did, only one of 12 was to a Rails group, and that was a 15-minute lightning talk. Speaker says, “Sass,” Rails devs say, “Duh!”
For the other 11 engagements, speaker says, “Just install Ruby,” crowd says, “Ummmm, not hip to that.”
For those who really wanted to play with Sass, but had no idea how to get Ruby working or install Ruby Gems, tools like CodeKit, Scout, and Compasss.app came to their rescue. LiveReload includes a Sass processor, and Web Workbench is a great attempt at trying to solve the issues of working with C#/.NET.
While these are great tools, they all have a serious flaw: they work outside the development environment. In the past few years, development environments have continued to grow in complexity. We are easily past the days of FTP sites and working from a remote server. Development environments, for even the most common of web sites, are built and run locally and use tools like Git, Github, and production deployment strategies. Using tools that are outside these environments are awkward, to say the least.
Version control and deployment are the key issues here. As your project’s resources grow in complexity, version control becomes even more paramount. When using tools like Git, processed files are a conflict nightmare. When using Sass, you only want to commit your actual resources, not their static output.
When using Git as a key part of the deployment strategy, you typically use a build process on the production environment to create the static output files.
Abstracting your dependencies away from the application means that somewhere along the deployment process, you need to create an asset that is committed to the repository for the sake of deployment and then is destroyed. This is called a “dirty commit” and is not a best practice.
When it comes to Sass, Rails developers have a solid solution for this. This was the only environment where I found it to be a seamless operation to have Sass files as resources in the app, then processed into their static output versions on the production server. All other development environments, not so much.
There are those in the Sass community who say, “C’mon, is it so bad to pin on a Ruby dependency?” The lead developer says, “Just to process CSS? No way!”
Isn’t it just development dependency anyway?
Some will advocate that Ruby is only a development dependency, and that only those who use Sass have personal workstations with the tools necessary to edit and process Sass. On some teams, this may be true, but I have never worked on a team that feels that way.
Why should only a select few have access and/or the ability to edit a project’s resource files? This is an unnecessary silo. That’s like saying that the UI dev on a team has no business ever touching the app’s core PHP, Ruby, .NET, or Python code. While there are those who are better at some tasks than others, there is never a good reason to make one code base exclusive over another. If it’s in the project, it’s fair game to every developer on that team.
Not to mention that making Sass and Ruby a “developer” dependency puts us back at the dirty commit state. Even worse, we are not only dependent on a language that is not completely integrated into the application, but we are now dependent on specific people to do a job.
That’s a horse of a different color
I admit, I was in this camp. I lived in a bubble where other stack developers were very open to the idea of a Ruby dependency, and I was working pretty exclusively with Rails devs as well. But I quickly discovered this was a small bubble.
I interviewed for a consulting position where I was asked to discuss the core differences between Sass and LESS—an easy argument. Then the lead dev asked, “How do we get this to work in our Python environment?” To which I replied, “Install Ruby?”
I didn’t get the contract.
I sat in many conversions as the expert on Sass and lost argument after argument, as exemplified above, in regards to using Sass over LESS in non-Ruby friendly development environments. The theme of these conversations was that if there is not a passionate front-end dev on the team when it comes to CSS, then all the power features of Sass fall to the side and the issue of dependencies takes precedence.
Writing awesome mixins and making the most of your CSS using the power given to us from Sass doesn’t matter. Having a good handful of features available is more then enough to suffice, and the lack of adding another dependency is the winning argument.
As long as we are on the subject . . .
Without going too far on the evangelism trail, languages like LESS and Stylus have another core difference with Sass. Sass is 100% dedicated to the CSS spec. This is important. CSS has a certain way of working; there are real rules, like inheritance and the cascade. The core Sass team looks at each new feature with a very specific microscope and decides qualitatively if the new feature is inline with the CSS spec or not.
LESS and Stylus, on the other hand, don’t have this level of regard in my opinion. There are things that each language does that override the CSS spec. As a result, I have heard from developers that this creates confusion and implementation issues.
Just putting that out there.
Getting to the metal
Libsass, the C/C++ port of the original Sass language that we have all come to love and admire, was born. It is more universal, and it is fast—four thousand times faster, to be exact.
Some of the key differences between Ruby Sass and Libsass is that Libsass is only the core library. There is no task runner and none of the add-ons that we have become accustomed to in the Ruby version. There is no direct integration of this library into any application environment. In fact, you can’t even run Libsass without some kind of wrapper, the first of which was the C wrapper called SassC. Cute, huh?
Wow, did this just get harder than Ruby Sass? No, this actually made it easier. Now in order to use Sass, someone just has to write a wrapper for their language and plug Sass directly into their development environment. There are no bolt-ons or issues with running Sass outside the app. You’re a Python dev? Cool, run Sass as if it were built in Python. You’re a .NET dev? Run Sass as if it is a standard part of your solution.
In order for Sass to break out of its Ruby and Rails encasement, we need to allow all the other kids to come into our sandbox and play with our toys the way that they want to play with them. That’s the key right there.
Is Libsass perfect?
At the time of writing this article, there are issues with Libsass. I’m not going to deny that. It doesn’t have all the amazing features of Ruby Sass 3.3 that Nathan Weizenbaum and Chris Eppstein just released. It does have bugs and a key feature like
@extend isn’t working as we expect it to either.
Will it get there? Yes. Hampton is committed to this project and will see that it gets there.
Do we just cast it aside and ignore it? No.
As a development community, Libsass needs our help. It needs our support, and it needs our appreciation.
Are there others interested in helping with these issues?
Yes! For example, one of the key arguments is that Libsass does not support things like List-Maps. Lu Nelson threw his hat in the ring and provided a solution. Others are getting involved too. The community is growing and it was announced at CampSass that the original whitespace Sass syntax is to be included as well.
Why do we need Libsass?
The way I see it, we have a two choices here:
We say to hell with Libsass and maintain use of the Ruby version. Will this gain respect in the community or increase user and mind share? No. Will others who are not interested in a Ruby dependency look at other solutions? Yes.
Hampton gave us the idea of Sass, and Nathan played a huge role in breathing life into that idea. Hampton, while diverse in his implementation (C/C++ over Ruby), is not divergent in the core thinking that is Sass. With regards to how it works and how it is part of the CSS community, Libsass is not something that tries to dominate a space the way others might.
Libsass is a new bridge for getting all development teams excited about using the language. When I tell devs how easy it is to get Sass running in their project, I relish in their excitement that they too can play with these tools.
Previous work is not wasted
I also want to make this point very clear: I in no way am advocating for Libsass in a way that encourages developers to simply walk away from Ruby Sass and only embrace the new hotness. The work that Nathan and Chris have done is irreplaceable. They have created something amazing and I don’t want to take anything away from that.
I am saying that we live in a world where great ideas need to evolve. If this were not true, then we would all still be writing apps using COBOL. I really hope that everyone who came together to create Sass in the first place can find a way to continue working together and help Sass evolve into its next evolution.
Libsass isn’t perfect, but it’s better than the alternative
In the past six months I have had opportunities to work on some really cool projects, and each project has a theme. Want Sass, no Ruby. Two of these projects are Node.js and one is .NET. These teams were very excited about bringing me on because they are interested in the way that I use the language to solve larger scale problems. They were even more excited when I explained to them that we can use Sass, even though it’s not perfect.
I’d prefer to use Libsass with a few less features and some bugs than a language that completely lacks these features and the community to support it.
Getting these issues solved isn’t all Hampton’s issue. Hampton is giving this to us for free. We need to pull together as a community and help. Jed Foster and I recognized that there was a lack of understating with Libsass, which is why it is now included in SassMeister. I encourage you to try things out for yourself. If you find a bug, make an issue in the repo. If you know how to fix the bug, pitch in. After all, this is what open source is supposed to be about, right?
Adding to this, I am also working with other developers to create similar projects for Python, .NET, and PHP. In short, with a world lacking in resources for this, I am pitching in to help fill that gap. If you are interested, I ask that you do the same.
It takes a village.