Talking to people in web development
I had a thought the other day and on a whim I asked a couple people if I could get an informal interview. I email them questions, and they give me the answers. I originally planned to ask people that were not in the top tier of popularity…you know, people like…well…me. The ones who write web development blogs because they love what they do, and working in the trenches. People that have something to say that most of us wouldn’t know about otherwise. That plan has somewhat changed when I got a “yes” from someone I didn’t expect to. I plan on doing a bunch of these, but this first one makes me very happy. On to the first of what I call “Informal Interviews.”
Chris Eppstein – Creator of Compass
Chris is the creator of Compass, a stylesheet authoring framework, and is on the core team of Sass — the stylesheet syntax upon which Compass is built. On top of that, he is the Software Architect at Caring.com, a website devoted to caregivers of the sick and elderly. How he has any time left to relax, I’ll never know. On to the Q & A!
How did the creation of Compass come about? Were you already on the core Sass team, or did that come after? And did Nathan Weizenbaum or Hampton Catlin have any input?
Chris: I found Sass because I hated ERB (the ruby on rails default templating engine) and as the architect of
Caring.com, I decided that we would switch to Haml. Sass came bundled with it. Sass & Haml were already at 2.0 at that point. Our website also used the Blueprint CSS framework and I always hated the presentation class names that blueprint forced on us and we were beginning to feel the pain that they were causing. I saw that mixins could “cure” that pain point and that the calculation features of Sass lent themselves very well to the regularity of a grid based design, so I decided I would port the blueprint grid to sass. At that time mixins didn’t accept arguments and there was no looping constructs, so the
first version of the blueprint grid was about 450 lines of sass (compared to the
current version which is about 250 lines). The first time I contacted Nathan was to show him this grid and discuss how we could make it more concise. We brainstormed the argument passing semantics of mixins and the first control flow directives that night.
I threw my quaint little blueprint grid up onto github and suddenly started getting watchers in much larger numbers than anything else I had put up there before. I remember being very excited to get 10 watchers.
Eventually I ported the entire blueprint framework to sass and then I approached the blueprint team to see if they were interested in using Sass as an underlying technology. They thought the idea was interesting and told me to pursue it. I got a little carried away and basically threw out all of blueprint and replaced it with a custom tool chain. While working on this, I realized that much of the tools I was making could apply to any css framework. At some point the blueprint team decided not to merge my commits. I was actually pretty happy about this… and so I converted all my work into a new project called Compass that I could use to support lots of CSS Frameworks.
I worked on compass for about a year before I asked to join the Sass team. At the time there were rumblings about it splitting off from haml to it’s own project. That will finally happen very soon with the Haml/Sass 3.1 release.
I’ve only spoken to Hampton a couple times. He hasn’t been very involved in Haml or Sass in the time I’ve been around.
When you are working on a release for Sass, do you call N. Weizenbaum and go over things/exchange code, or video conference? How do you all communicate and exchange code, and who handles what?
Chris: We chat over IM when we have decisions to make or ideas to discuss. We send emails sometimes. Nathan does a bulk of the coding on Sass, my patches to Sass generally are to the bits that concern how Sass interfaces to applications, configuration options, etc. I’ve made relatively few changes to the core language at the code level. Mostly we just collaborate on the language semantics and syntax. Because the number of touch points is low, there’s not much coordination required. Git & Github are very useful for doing code reviews and sorting out issues on the bug tracker.
Do you have any stats you can share on how many people are using Sass? Any growth surges?
Chris: It’s hard to say. I’m curious to know as well. Based on traffic to the compass website, I estimate there are 15k – 25k active compass users. I would suspect that there are 3-5x that many Sass users.
Traffic has grown consistently over the past couple years. Here’s some charts:
- Compass
-
Sass
Anecdotally, I’ve seen the number of peer-to-peer twitter recommendations to use Sass or Compass go up considerably in the last few months. Having a high net promoter score is a key indicator of growth, so that makes me very happy.
Who is Sass intended for in your opinion? Is it mainly for hardcore Ruby developers?
Chris: Sass is for people who have to write CSS, irrespective of their background. One of the reasons I made compass was so that people who didn’t have a Ruby app could take advantage of Sass. We try to make features that operate at low levels for the more programmery users so that they can enable the less programmery front-enders with features that they will find easy to use. It’s a really tough balance to achieve, which is why we are always eager to get feedback.
Are there any goals to try and make Sass and Compass more accessible to wider range of people? Was the SCSS syntax part that?
Chris: Yes. CSS sucks. We think the power of Sass should be available to everyone. Lots of people didn’t like the aesthetic of the indented syntax, so SCSS was introduced to bring the core technology behind Sass to more users. We hope that Sass will be integrated with more products like CSS Editors and eventually we hope to see the concepts brought to browsers themselves.
Related to the previous question, did you have any hand in creating Compass.app by Handlino? If not, what do you think of it? I’m also curious on why it costs $7, when Compass itself is free. That seems backwards to me.
Chris: They consulted with me ahead of the release and I offered feedback on the features it provided. Compass is MIT licensed, which means that people can sell it and embed it if they want to, so I can’t stop them even if I wanted to at this point. But Compass needs a GUI and so far no one has made a free one, so if people are willing to pay a few dollars to avoid using the command line, I think they should. I granted them access to the Compass trademarks on the condition that their code is open. So anyone who wants to, can download the GUI and compile it for free. Of course, you need to know the command line to do that.
Also, if you didn’t have any part to play in that, do you intend to ever create one yourself? Maybe an an app with more of an interface to try and get away from the command line?
Chris: I don’t have time to build it — I have built the core compass infrastructure in a way that I think should enable it to be integrated into a GUI with relative ease. It’s been years since I worked on desktop applications, I’m sure others will have a much easier time doing it then I would.
I’ve only been using Sass, along with Compass for only a few months or so (and only on personal projects so far), even though I have read about it before that. It seems like a lot has been added recently though, like CSS3Pie and Lemonade. Are there any other things like those two that are in the works for Compass?
Chris: To be honest, I don’t plan the Compass features, I just react to the needs of the community and the ever changing technological landscape. I will continue to do what I always have done: listen to the users’ needs and help them find solutions to their biggest pain points.
Speaking of CSS3Pie, why was that added? Css3Pie really only effects IE, and a very limited amount of CSS3 properties (with some drawbacks I have personally seen already). Was it a trivial amount of work to add it to Compass, making it a no-brainer?
Chris: It was probably the #1 requested feature. I would have preferred it to be an extension, but it wasn’t really technologically feasible. I was at a conference with
Jason Johnston so we got together and hashed out the integration. It was a couple days of work.
Why is Compass still in Beta mode? Are we ever going to actually see 1.0?
Chris: The big remaining feature on my roadmap for compass is to make it easier to share, install, and find compass extensions and plugins. At that point, I will make compass 1.0. I’m actually quite eager for compass to hit 1.0. But just because it’s not 1.0 doesn’t mean it’s not ready for production use. It means that I might change some APIs still. But if you look at the
compass changelog you will see that I’m very careful to maintain the APIs so that they continue to work across point releases — though there are deprecations in each release.
I really like the look of the beta website, but why did you decide to get a more “hip and updated” look now, and why didn’t you design it?
Chris: I’m not a designer. The reason it wasn’t done sooner, is it’s a ton of work and I wasn’t exactly in a position to pay for a good design. I have a couple hundred hours invested in documentation and documentation infrastructure. It’s easily 2-3x more work to create the docs than it is to make the code. Eric Meyer (Creator of Susy) did a quick pass for the first design to make it bearable for the v0.10 release, Brandon Mathis did the
new version over a couple weeks leading up to v0.11.
Do the Sass vs. LESS posts and arguments bother you? And do you think LESS is any good?
Chris: No. I think competition and experimentation is good for an emerging technology segment. When Less was first announced, I was actually very excited and wanted to support it in Compass. But it lacked some key features that would enable Compass to integrate with it. I approached
Alexis Sellier and asked him to build them into Less, but he did not like some of those features and did not want them in the Less syntax. So that was that. Instead the popularity of Less showed us that users did really want a CSS-based syntax so we added a new parser to Sass allowing both syntaxes to be used interchangeably and importable by the other. This was clearly a better outcome for users, but a lot more work for Nathan.
My opinion of Less is that it is actually less CSS-like than SCSS is. Sass has far fewer defects, a testament to Nathan’s prowess as a developer, his attention to detail, commitment to quality, and the longevity of the project (4 years now). Alexis has quite a few active open source projects and a day job, and it’s pretty clear he’s spread too thin to do as good of a job on Less as it deserves. That saddens me, and I’ve often worried that it will reflect poorly on this class of technologies. The idea to implement Less in javascript is clearly an interesting one, I hope that Alexis will continue to work on Less.js — he has a lot of users.
On Sass’ website, it says that it is a meta-language, or what I call an abstracted language. Do you think this is going to become a popular trend? Where someone takes an existing language and abstracts it, like Sass does to CSS or CoffeeScript does Javascript?
Chris: I think these speak more to the entrenchment and importance of browsers as a fundamental vehicle of software delivery and how hard it is to change them in any sort of cohesive way because users have to install and upgrade them. A compiler is something that developers can install and control independent of that cycle.
If someone like say…me…who can now use Sass, wanted to start learning Ruby, can you recommend any books, or where and how we should start? Take into account that this someone doesn’t know PHP.
Chris: I’ve been programming since I was 12 (I’m 36 now) and I’ve learned a dozen or more programming languages in my life. But I learn languages through analogy now, and not from scratch, so I don’t really know. I have some friends who want to learn, so maybe I’ll figure this out soon.
And lastly – .sass or .scss – who wins in a fight?
Chris: I write a lot of SCSS lately for Compass. I find the flexibility it offers very useful for complex stylesheets. I use Sass when writing application stylesheets — I find the constraints it forces on us to be ideal for team-based development. If I had to pick one to the exclusion of the other, I would probably choose SCSS, but I don’t.
And that is a wrap!
I hope you enjoyed reading Chris’ answers as much as I did. This was a real treat for me, because I got to ask him things I have been wanting to know for a while. I wanted to ask more, but I didn’t want to bombard him with a million questions and piss him off. Thank you Chris for doing this for me, and I look forward to what you do with Compass this year!
![]()
Coupon Code: webmachine
![]()
