The Changelog: Software Development, Open Source - Sass, libsass, Haml (Interview)

Episode Date: June 27, 2013

Adam Stacoviak and Andrew Thorp talk with Hampton Catlin about Sass, libsass, Haml, Tritium, Moovweb and more.

Welcome back everyone. This is The Change Log. We're a member supported blog and podcast that covers what's fresh and what's new in open source. You can check out the blog at thechangelog.com and our past shows at 5by5.tv slash changelog. This show is hosted by myself, Adam Stachowiak, and Andrew Thorpe. So, Andrew, in your echoey way, say hello. Hello, coming straight from my new empty and echoey office. Yeah, you just moved, right? To Nashville. To Nashville.

To your house. That's awesome stuff. Music City, USA. Speaking of music, you can tune in live every Tuesday. That's today at 5 p.m. Central Standard Time right here on 5x5 to listen to this show. This is episode number 94, and we're joined today by the awesome, awesome Hampton Catton. He's the inventor, as you say, Hampton, of SaaS and Ham, which I think is a really cool way to talk about how you created some software. And you're also the maker of Wikipedia Mobile, mobile which you uh talk about quite a bit in

different talks and i think it's a unique story you have there too so welcome to the show yeah thanks guys it's awesome to be here so uh i think we've been i think i've personally been waiting to have you on the show since like episode number two so the episode number two of the changelog was was uh nathan and chris we talked about, Compass, and stuff like that. And I've been a user of Sass for years and stuff like that. We got a chance to hang out at Les Conf, and that was awesome. I think I didn't have a different opinion of you before then, but I definitely liked you a lot better afterwards. I don't know why, so don't take anything hard from that.

But I guess for the uninitiated on who you are, I kind of said you were the inventor, creator of SAS and HAM1 and some other stuff. But when you introduce yourself, how do you introduce yourself? Yeah, I mean, well, usually I say, hi, I'm Hampton. But I don't normally, like, I'm on the media. I'm like, hi, I'm Hampton. I'm the inventor of SAS. Don't you say, hi, I'm the Hampton?

I'm the Hampton, yeah. The Hampton, yeah. TM. Yeah. Definitely that moniker is a difficult one because Nathan and Chris have been maintaining the – well, Nathan's been involved pretty much since day one, and Chris has been involved for, I think, five years now. And they do all the hard work on keeping Sass awesome and adding all the amazing features. So I did the first version. The first commits mine, the kind of concept was

mine, the like pre-compiler idea. That was actually, there wasn't really anything like that. Like it's pretty common now with, you know, CoffeeScript and a bunch of kind of other alternatives. But, you know, that was the really crazy idea Because I think back then I was doing Rails full time. And people were asking a lot, how do I do dynamic CSS? They really wanted to do theming or user picks a color for some reason, that kind of customizing CSS. And I remember when I first started Sass, that's what people thought it was for the longest time.

They were like, oh, so let me do custom themes for my users. I'm like, yeah, it's not dynamic. It's actually compiled. And then, you know, it's just CSS that goes up. You know, and it was like variables and some other basic stuff and nesting. But, you know, all the crazy stuff that's out there now, that's, you know, Nathan and Chris are just absolutely insanely awesome at that stuff. And I have to be honest, the most advanced usage of Sassy's Day is I'm not very good at it.

I mostly use, you know, like the book I wrote on it, the pragmatic guide to Sass, the end of that book's a basic, basically the end of what I use day to day in the language. I haven't got a chance to dive deep into that book, but I've been wanting to pick it up for a while. But now that you mentioned it's pretty basic, I might just skip it. Yeah. No, it's not. It's true. No, it's definitely. I'm just messing with you.

Well, we kind of did it because the story that like I keep hearing from people is, you know, oh, like I'm at this company. I really want them to use SAS, but I can't convince anybody to like take a look at it right um and so the idea was just to have a really thin really simple book that just taught you very quickly how to kind of be dangerous with sass so how many pages is it then oh gosh i don't know i guess it's digital right so is there really pages no no there's a physical i got the book right here yeah it's pragmatic programmers um yeah it's let me see 90 i think 100 pages no yeah i mean it's sizable enough yeah it's a pragmatic guide so it's really quick and kind of like each page is like an example and that's really how it teaches you i like the way you did that book too you kind of had it in this beta form and you were releasing i think chapter every couple weeks right and um it was pretty

neat to to kind of go that route too and you didn't take that long to write it either it was a fairly quick one. I know there's another book out there that's taken a while. And there's – anyways, that's a deep topic there. Well, there's about four or five books. There's actually one in French, which is – Oh, is there really? Yes.

Wow. Yeah, that's my favorite one. Not that I'm wowed by French books, but just didn't realize that there was a French SAS book. Yeah, and Ben Frane just came out with one, I think, also. But yeah, Nathan and Chris have one they've been working on for a while. We'll see how that comes out. I feel like there's...

So what I want to do with this conversation, and Andrew, you're a full-stack kind of guy too, so you definitely play in this world as well, but I kind of want to just cover, I i guess not the entire time talking about sass but i want to talk about a lot about it i guess but not the entire time about that and uh hamill too i think it's really neat just to just how you um you know you use the word i think now you change it you say creator now i just realized that but for a while that you were seeing inventor of but which i always thought was kind of neat well i think i stick mostly with Inventor.

I don't know. Probably. It's just hard, right? Yeah. I always flip back and forth on this. I mean, I think when I've talked to you about it, you're always pretty humble. We had a chance to chat at Les Conf, and that was pretty cool to just riff about SaaS and some neat stuff and there's some there's some parallels to some feelings we have about the community and what can be done and um some likes and dislikes and stuff like that nothing in

particular but just in general we have some parallels but i think what's neat about sass is is that people don't realize how uh how old it is really like a lot of newcomers maybe the last you know one to two years maybe three years i have started to use it and have adopted it. But this is like six and a half years old now, maybe seven years old now. I think November is going to be the seventh birthday of SAS, the first commit. That brings up the other thing. I think it was like November 5th. I looked up the commit date in the Hamlet gem because it was mixed with Hamil at first, right?

Yeah, yeah, it was. It was kind of a side crazy idea I had to like just – and I convinced Nathan to help me build it as like an add-on kind of thing. It's definitely Eclipse, Hamil generally. But yeah, and actually on November 5th, so the company I'm at now, MoveWeb, we're actually going to throw a SaaS birthday party here in San Francisco. And so we're going to invite the community who want to come. So that's actually going to be pretty fun, I think. Well, you know that I'm the owner of SaaSDay.com, right? So we'll have to use that.

That would be awesome. That would be awesome. It'll be SaaSDay, not a SaaS birthday. It'll be a birthday, but it'll be SaaSDay. be awesome it'll be sas day not not a sas birthday it'll be a birthday but it'd be sas day yeah it'd be pretty awesome yeah actually when hamill was a year old i think before we started on sas maybe a year and a half so that's almost coming up on eight years i think so when i the reason why i bring up the the longevity there is that uh a while back i haven't done the talk in a while, but for a bit there, two years straight, Wynn and I, you know, we started this podcast a while ago and we were doing this talk called Design Eye for the Dev Guy and Gal. So all

you ladies out there, we were saying gal. You can go back on the slides. It's really neat the way we put the little slash there and gal. But we were, one thing we were saying in one of the slides when we were doing this talk, it was actually kind of training more than it was a talk. It was eight hours of training. And we did this, and it was like the primer into design theory and SAS what you said in your book and keeping it short and kind of making it this beginner's guide for lack of better terms. One thing that was hard to convince people of was that SaaS wasn't new. It wasn't like it was – they just heard about it, but this thing has been there for a while. So it's a mature project with some mature people behind it that really have some very insightful thoughts.

And, like, there should be no reason why you shouldn't trust it, you know? And that's why I kind of harp on the six and a half, almost seven years old. Yeah, you know, it's definitely, like, you know, less being done in JavaScript, less being the competitor. It's relatively young. And it being in JavaScript, when they did that port, it kind of exploded in popularity because it hit right when JavaScript frameworks were kind of exploding. And it's like, oh, this is in JavaScript too.

My whole world's in JavaScript, man. Right. But I like it when I hear people say, oh, so SAS is like, it's like kind of like LESS, right? Like you kind of copied what LESS did. No. I'm like, oi! Yeah. That's where you put your inventor hat on, right? Yeah.

So, yeah, I definitely talk about the age, too, because I think most people don't know how old it is. I mean, it lived for a long time. It was only used in the Rails community. It was part of a Haml project. Haml is definitely a markup language that you either love or hate or love to hate. And just I always try to tell these people, if I meet you at a conference, I don't want to hear what you think about Haml. Let's talk about anything else. I just don't need to know your opinion.

Are there a lot of negative opinions about Hamill? Yes. It's just always a whole talk that I have like three times a conference. Are you going to be upset if I have some questions around Hamill then? No, because we have a whole audience of people who we can address all at once about it. That's right. Get them all done at once, right? Yeah.

Shoot me an email if you have questions. No, actually, the part that's funny is that people think I'm really sensitive about it. Like, I'm not. But they kind of come up to me, like, oh, you know, I hate to tell you, I really don't like Hamill. I'm like, okay, thanks. All right. I'm super sad.

I'm just like... You've ruined my day. that's cool the you know and then somebody's like uh somebody tweeted the other day they were like i have to admit sometimes i still use erb templates for some things and i'm like so do i this isn't a big deal it's fine i have a confession i actually uh i'm working on a Rails project, just learning Ruby and stuff like that and getting more in-depth at it. And I actually stopped – I've always been a big fan of Hamill. And so I hope I don't make you cry when I say this, but I've gone back to ERB. How dare you?

How dare I? He just got finished telling us how sensitive he is about Hamill. I'm going to cry. No, it's funny. So, you know, a lot of times the stuff I work on, like, I definitely tend to originate things and then let smarter people than me come in if they get traction and more responsible people than me also. But, you know, I'm always looking for those ideas that are kind of really challenging. I definitely like... I have a lot of opinions that don't necessarily always match what's popular.

As a matter of fact, some of my opinions will be based around disliking what's really popular. I had a really popular video that went around at some point about me just ripping into test-driven development. And I like that it kind of offends people and makes them have to take their position. And, like, Haml is definitely, if the people out there listening haven't seen it,

it's very stark. It's very concise. It's a way to write HTML templates that's very heavy on semantic HTML. So it's kind of designed to be a pain to not write good classes for things. And it was designed in, what was it, 2004, something like that, 2005.

And that's when I was, the other developers I was working with weren't using classes, and they was getting to our design team, and they were getting very frustrated because there were all these spans and divs randomly kind of on a template and an erb template and they weren't styled right and it just kind of looked all crazy and you know they just dumped data out and i kind of wanted to design the language to kind of force people to do good habits for semantic

html and to really focus on structure and layout. But it's definitely not meant to be a beginner tool. And as a matter of fact, when I first presented it, I thought everyone was just going to hate it. It was a total hail Mary to give that out to the world. I kind of just thought I was going to be the only one who ever used it. So the fact that it is still used, that you've been using it up until now, is pretty amazing. Um, but I was just kind of hoping it would stir a bunch of other innovation and I mean, it took a while, but I, there's definitely a lot of kind of things that have taken similar approaches being kind of white space sensitive, um, you know, kind of minimum, like, uh, now

it's like data attributes trying to make that more concise, more simple. Um, so I'm proud that that kind of happened. There's a slim and stuff, I think, are now kind of gaining traction. And that's awesome. That's totally the natural flow of technology. I'm just happy to come in with my crazy idea and, you know, push people to question what they were doing before. I think it's cool, though, man, to have, and you know just a crazy idea and that's why i thought it was kind of neat like for a while i was like inventor huh and i was like oh inventor oh that makes sense i mean because i mean software is an art and it's not just uh you know propeller

head kind of stuff it's it's you know it's very much a canvas and you know that is a pretty wild thing like even if it's not the most artistic code, I mean, what it does is really unique. And it shifted a lot for people. And I would even say that Haml and Sass, I'm not sure if they're exactly responsible for it, but they definitely started a movement of precompiling and, you know, this meta level on top of something else. So Sass on top of CSS and Hamble on top of HTML. I mean, I think it started this little movement, so to speak. I mean, I hope it. That is the angle.

If I'm most proud of myself or something, it is that there are competitors and seeing CoffeeScript. I kind of had proposed a thing called Jabble years ago at a conference, and I never really got to finish up the project, but it was kind of like a CoffeeScript-like thing to make just really straightforward event-driven JavaScript.

I mean, it was different, but it was kind of applying the same principle. So, I mean, if I had any positive effect in any of that stuff, that's awesome because CoffeeScript's really, really cool. And, yeah, I mean, I think Inventor is kind of the way I think of myself, to be honest. But just because I like to look at problems and I like to try to come up with solutions that other people haven't thought of that later when you look back you're like, well,

that's obvious. That's my favorite. That's my main joy in life. It is now that I feel like people do look at Sass and go, well, okay, yeah, I mean, that must have existed. Like, somebody did that. Those are my favorite, favorite products, too, is when you're like, wait, this doesn't exist?

Oh. Well, people are pretty diehard fans, too, of both of these things. We're talking about Sass and Hamill. Like, those who love Hamill really love hamill and those who love sass like really love sass in fact um a couple years back um me and john long and a couple others got together and started this i guess uh blog i guess on uh on sass called the Sass Way and it was a riff on the Ruby Way and the Rails Way and so they kind of set the track

in terms of the name but we thought there's some positive graceful arrogance when it comes to the Sass Way in quotes because I think there's the way you'd write it in CSS and that's kind of stupid in a sense because why would you waste so much time hand crafting that CSS whenever you can let SAS do the indentation for you and make your output beautiful or condensate or compress it down or whatever your flavor might be.

SAS could help you do that. So there was this level of arrogance when it came to this, I guess just using this. How do you feel about people being so diehardly appreciative and just stoked about using Sass or Ham when almost fighting to the tooth and nail about it sometimes? Clearly great. It's pretty awesome.

I haven't seen my first Sass tattoo yet, but I'm sure somebody will get one one day. It's really, really cool to see people be so passionate. I think the iconoclastic kind of element, especially earlier on, I mean, these days, you know, especially SaaS, it's just more accepted. I think there's less, you know, bare knuckle fights required. You know, here in the Valley, I just, like LinkedIn's using, I mean, that's why Chris

Epstein recently got a job at LinkedIn. They're kind of officially supporting SaaS. Sorry, I know Yelp is using them as using it. A lot of the big companies here just, they'll kind of silently think they're the only ones doing it and are now internally using it. So, I mean, and that's just so cool to me. There's like kind of these secret companies right now that are all using it internally, not really telling anyone. And, I mean, I think because they're initially challenging ideas, that's why people take it on as a belief, you know. And that's why they get so passionate about it, because they don't understand why other people don't understand and that's i think it's really cool so uh there's tons of stuff we could talk about but i'm really curious about this and i've heard you talk about it elsewhere but uh sass and him were both kind of iconified

i guess in a sense by this imagery that came with it. You got the dude with the muscles, right? You got the girl with the phone in her hand. And especially when we did the Sass, people new to Sass are like, why is your icon a girl talking on the phone? And we're like, and why is it this pinkish purple? What's the tones? And what are all these choices made? Why did you make these choices? And I'm like, well, is it this pinkish purple? What's the tones? And why are all these choices made? Why did you make these choices?

And I'm like, well, I'm just following the groove. I didn't choose the girl. I mean, she's sassy though, right? And then you've got the dude whose hand, he's kind of got this, he's got his little muscles out there and he's flexing. So what's the deal with the images? Where did they come from? So it definitely started with the kid. I had a photo that I found at a yard sale of this.

It was like a 1950s kid, and he's on his porch, and he's probably like eight years old. And he's got his dad's boxing gloves on, and they're oversized, and he's kind of like trying to pose at the camera like he's fighting. And that was one way I just loved that picture. I bought it immediately. I still have it. I just love this idea of innocence and having a weird idea and standing up for something.

I don't know. I just thought it was really adorable. I don't know. I felt like there was a lot of me in that picture. I was working with Lucas Drea, who's a designer. Color.me, I think is the name of his design firm in Toronto. And he helped on the original design of the Hamill site.

And he had like a bunch of kind of open source, or not open source, public domain images. And that was one of them. And I was like, oh, that's what I wanted. That's the same spirit in that kid that I saw in the other photo. And I think actually the, when I look at them, the core thing is being mischievous. That's the idea to me like that. That's the heart of that kid. He's like, it's kind of showing off, but it's kind of like a cheeky, um, mischievous way. Um, and then I don't know. So I, yeah, I also, I picked the woman's photo of her on the phone. I honestly, I've been asked this question a lot and I just really liked the photo. I mean, it looked a little mischievous. I thought she looked cheeky. I thought it was kind of fun. Um, I thought I didn't want to with a name like sass. I, I thought it would be kind of interesting to, I don't know, like play with gender roles. Maybe.

Um, I definitely know some people have been offended by it it's it's i'm a pretty strong feminist uh i know guys can kind of be feminist um yeah so you know it's so funny to me when i hear people say oh i you know it's offensive to me um and you know that's definitely not the intention the new design doesn't have that it's not meant to kind of offend anyone but i just kind of thought like she seemed empowered to me she seemed like she kind of had a secret like there was something mischievous going on um she seemed kind of happy and friendly too at the same time and that's kind of thought, like, she seemed empowered to me. She seemed like she kind of had a secret, like there was something mischievous going on. She seemed kind of happy and friendly, too, at the same time. And that's kind of what I thought about Sass itself. And as far as the color, I believe actually Nathan picked.

He just took the Hamill site and then, like, picked a color and threw it on top of the photo that I sent him. So I don't really know why I went with that color. I don't really like that color, to be honest. It kind of drives me crazy. But that's why the never-ending Sass redesign is going on. What does that look like for the Sass redesign? Because Hamill,

I don't ever see the boy anymore on Hamill. It's gone. Slingshot now. Yeah, that got redone. Yeah, so what about Sass? When's that going to drop? I can send out the link. I mean, the main thing is, so Berman Painter and Gina Bolton have been working really hard on it.

And basically they did all this work to kind of flesh it out. And, I mean, I think it basically, as all kind of open source design projects happens, people get distracted. And, you know, I think the initial version, they were trying to do a lot more tutorials, a lot more kind of interactive information sharing. They were trying to make it not just a better design, but better content. It's kind of a central place to go to learn about SaaS. And I think it's that content part that was the biggest struggle to actually get all that written and put in there. A couple weekends, actually, my husband Michael and I spent a weekend, and we kind of went through it since we did the SAS book.

We're also working on material. We're working with Treehouse right now, actually, to put together a SAS module for that. So we're like, okay, fine. We'll come in and help with some of the content. So hopefully soon. I've been bugging Gina about it. We'll see.

I mean, honestly, even I think as it is right now, not completely polished, it's still better than the current site, which we just need to kill. That's kind of my position. Um, and you know, once you get something up there, it's easier to iterate, you know, like kind of,

it forces you cause people are looking at it. But I think there's a lot of pressure because the site's been so ugly and the competitors have all had really nice websites that you kind of don't want to put up something that isn't just clearly better. Do you know what I mean? Right. Like, Oh,

all this weight and all this time we said we'd finally make it. Okay, now we've done it. Oh. Yeah, the pressure's there to, like, really deliver now, right? Like, you can't. Yeah, you can't have that. You can't put up your draft number one and be like, yeah, we're going to iterate. Yeah.

I mean, it's still looking good, though, and I think anything better is better. So that's open source. Can we talk a little bit about the, I guess, maybe, I wasn't trying to cut you off. Did you have more to say after you were done? No, go, go, go, go. I just wanted to kind of paint a little bit of the history for those who haven't been closely watching. I know you originally started both of these projects. We've been talking about the hand one sass

you kind of stepped away for a bit and then you came back we talked a little bit about this not last week but the week before we had phil up here from thought bot on he's the maker of bourbon maintainer of bourbon that's uh kind of i'm not really sure if you would consider it a compass competitor it's just more of like a parallel to Compass, just in pure SaaS. But we talked a little bit about just how you stepped away for a bit and came back. And it sounds like you're a bit more involved in the day-to-day of SaaS now. Is that right? So the primary SaaS project, that is the kind of Ruby engine and the new language features.

Today, that's definitely still Nathan and Chris primarily. Um, Nathan has, he's at Google and he gets his 20% time to work on that. Um, and you know, I mean, there's basically so many years of sweat equity in that and,

and they know so many of the edge cases, um, that, you know, like, and, and I'm not, since I'm not a super,

super advanced SAS user, um, you know, I mean, I, I try to pitch in on stuff in the forum, but, you know, when they're talking about super edge case things, I might, you know, I'm like, you guys are, you know this stuff way better than me. But what I've kind of been trying to do, so, I mean, yeah, I left and basically have been, I did a bunch of iPhone apps that got pretty successful. Um, and, uh, I did the Wikipedia mobile site. I ran that for three years, um, and kind of was just doing random projects on my own and, you know, focusing on my career and stuff. And, you know, they were doing such a good job with it. I just kind of, you know, it was the wayward father. Um, but about a year, I think it's over a year at this point now. Yeah. Maybe a year job with it. I just kind of, you know, it was the wayward father. But about a year, I think it's over a year at this point now. Yeah, maybe a year and a half. So the company I work at

MoveWeb, we're a software tool company. And there we, you know, we have a whole framework for developing mobile sites. And it's really a way to transform websites. So imagine CSS Zen Garden, but where you can actually change the HTML too. And you can do this on any site on the internet. So you can redesign Hacker News and mobilize it or change it to something else or make it ugly. One of the guys I work with just made a really ugly version. So we have this tool set. And part of our tool set, because it's a framework, you generate a project.

So we have SaaS in it, and basically having SaaS, we had to include Ruby. And our core framework is no longer written in Ruby. So Ruby is like a 200 megabyte or 300 megabyte download now. So we had this distribution in our cloud servers too where we had this 300 megabyte executable. It's free, actually. And just kind of for compiling these SAS files. And it was slow. We had some really big projects.

And when we were using Compass, it could take up to 30 to 40 seconds to compile. So we kind of, well, I kind of decided that we had a guy in-house who wrote the parser for Tridium, which is the language that MoveWeb has, and we decided to do the totally insane idea of writing a C and C++ implementation of Sass

to basically take those seven years of development of edge cases, of features, and try to have one person redevelop it. So MoveWeb's been sponsoring that for the last year and a half, and every build of our SDK and product has had it embedded for the last year. So basically, that's called LibSaaS, and that's the actual C and C++ code. It's designed to be super ridiculously modular.

So, you know, higher picture, when you look at pre-compiled CSS languages, SaaS is still, most people use the Ruby version, and most people don't use Ruby. So, you know, at, for instance, at LinkedIn, they have, you know, a whole set of compilers and computers just meant for building SaaS. Actually, Jonathan Lambert, there's this guy who his main, one of his main jobs is to keep their compilation farm running of Ruby servers. And it's like this whole infrastructure just because it's kind of slow and in Ruby. And so that's definitely a downside that people have to do this extra install and get on the command line and stuff. And there's apps to help with this, but it's hard to have a real development team. We can't just bundle this into Eclipse, right? So they use Java

or they can't just add this quick thing. So, you know, and Les had decided to do JavaScript, which was a great idea, because basically every browser can compile Les. You don't really have to install anything. You can just do it in the browser. So kind of I realized, hey, we have to do better than that. Like how do you go past that? And that's by writing a library that has no dependencies, that you can just drop into anything and compile it and it would have SAS in it. So it's a collection of like

20 C and C++ files. It compiles into something very small. You could drop it right into Firefox today and build Firefox and it will compile in there. It doesn't need any dependencies. It doesn't use any weirdness. We wrote our own parser from scratch to make sure that's possible. So the idea is, you know, what's better than JavaScript? Well, let's try C. So that's the LibSass project. When you actually look in,

this is where it gets confusing to people. When you go to hcatlin slash LibSass on GitHub, it's just some C files. It's not an executable. It can't actually do anything. It's a library itself. And that's where you see Aaron Leung, who's the guy from MoveWeb who's been working on this,

that's where he puts all of his time, reworking that stuff, coding it, expanding it, fixing bugs. And it's meant to be compiled into something else. So there's the other repositories called SassC, and it's basically just a lightweight wrapper that's an executable. So you can actually type SassC when you install that on your command line, and hey, input, output, file. It's very similar to the Ruby Sass executable that most people use

when they're using a different framework. And then we also have some other. There's Node Sass, which compiles into a Node server. So check, we've even got JavaScript. Nice. So yeah, Andrew Nesbitt works on that. And it's basically, he just pulls in the lib Sass repo, puts the wrapper around it to make it execute

and compile within Node environment. And then, hey, there you uh, and compile, uh, within node environment. And then, Hey, there you go. NPM module. Um, so that's out, uh, we, there's a Ruby one I've kind of been working on. Um, it's very complicated and I don't have much free time to work on it. Uh, but the goal of that is eventually that it'd be a drop-in replacement so that you could go into your rails app, comment out, import SAS and say import sass c, and then it would kind of alias itself in and be able to compile sass files and you wouldn't really know the difference. And so there's still more work to do on that, especially to get full Compass support, because Compass is not just a sass library that includes a bunch of sass files, it also includes a lot of Ruby functions that kind of extend core SaaS functionality. And as today, LibSaaS fully supports Bourbon

because Bourbon doesn't do anything crazy. Compass, Chris is definitely part of his job at LinkedIn is going to be to help get Compass running on LibSaaS. So at this point, there's actually kind of three companies move web linkedin and google who are all kind of supporting sass development like with actual office hours and uh and move web it's pretty much a full-time person um so that's pretty cool and at linkedin it's a full-time person so you took you have kind of these two divergent paths at this point right like the original sass path and this new one that you're kind of trailblazing with. What is the long-term plan for how these two would...

Will these two both continue on indefinitely? And if so, how... Or if not, how is the community of developers that are working on SaaS with Nathan and those guys handling the thought of potentially that not continuing or, you know, any thought into that at all? So, I mean, at the moment, it's definitely Ruby SAS is going to continue to be the spec implementation, and they're going to continue to develop the language there.

And then the goal of libSAS is to stay, I mean, honestly, at this point, SAS development when it comes to features is pretty slow. I mean, rightfully so. It's seven years old. I know when Nathan and Chris, if you see in a comment, in any of their pull requests, when they're debating whether or not to add a language feature is an extremely intense and detailed and long debate, going up to nine months' worth of debate sometimes. You know, sometimes somebody says something three years ago, and then, you know, it's been still debating, and they're kind of saying, you know,

maybe probably no in that case. But, you know, they take a long time to consider new language features. So, I mean, I'm actually not too afraid about keeping the two projects in sync. I mean, you know, if I think I have to look at this, I think there's basically a SaaS release every nine months on average, I think something like that might be a little longer even. And, you know, having nine months, you know, our software product, this is really important to it.

I have a full time person. We can totally to it. I have a full-time person. We can totally do it. There's no plans here for the Ruby version. Nathan and Chris are going to continue to work on that. Chris is definitely helping out with libSaaS. Nathan is just sticking with the Ruby implementation. And, I mean, you know, as far as the future, I don't know. But, I mean, one thing that's really kind of important to me that I'm trying to,

if you look in the SASE repo, it's hcatlin slash Sass C. That's with a C, sorry, S-A-S-S, and then the letter C. It's hilarious, right? Sass C. So there's a big test suite in there, and it's basically I copied all the, the tests are in Ruby for the Sass repo, the main one. Like they're actually in a Ruby class file. There aren't like executable. So it'd be impossible for us to run the tests quickly in a different implementation. So I basically pulled those out into files. We have

all these input output kind of examples. And, you know, the goal is we're going to continue. It'll eventually move out of that repo. We just have it there because it's a quick place to test. But the real goal is to have a whole test suite so that if somebody wanted to write a pure Java implementation, they'd really be able to know that they're behaving correctly and according to the spec. So that's a kind of ongoing bit of work. And I know that Nathan and Chris are definitely up for helping with that.

We'll eventually unify everything. When Sass revs or gains new features, what is it like to keep the two in sync when you say that? Can you give us an example for those who don't code in C and don't know what you're doing with this, but what it takes to keep those two in sync? It takes air and lung. Because C and C++ code is very intense,

and hand coding a parser is very intense also. Definitely LubeSass is more of a traditional parser than the SaaS implementation. I'm sorry, the Ruby implementation. But, yeah, I mean, basically, you know, you end up having to add a feature, like keywords to the parser, you know, for you to match on a new media query or a new, you know, behavior to extends. You know, you basically write the test function. We all agree on what the input output should be.

And then you go into that actual parser and try to modify the parsing function or the output function to work with it. So it's pretty hand-holdy. It seems like it's very hands-on. It's not just, you know, import the new library and call new bindings or something like that. And it seems like it's pretty...

Well, I mean, our goal is... So we would... If a new feature gets added... Actually, we might... If we see it coming out soon in a SaaS release, we'd probably already be developing it. And then we'd probably just synchronously release a libSaaS update. And then all the adapters that use it like node sass or whatever would then go out with the release and hopefully we're going to synchronize

the version numbers on everybody so if you're using node and you look at your npm package you'll see it's you know 3.4 and you can know that that's sass 3.4 compatible library so that's basically the idea one thing i don't know if you may have already said this, but with NodeSass, and I think it was, it's Andrew Nesbitt, I've actually spoken with him before, but with NodeSass, and they're kind of coming from the other side, right? So as things go into Sass, you have to kind of keep up with LibSass and keep that in sync. Have you spoken to Andrew about his experience with implementing NodeSass? Because I'm assuming that he's probably the first other than Sassy to actually implement a wrapper for the bindings. Have you actually heard about his experience or anything?

I mean, we've talked a little bit. I mean, at this point with libsass, there's definitely a lot. Like, it's usable today. Um, if you have a very large, very complicated project, um, that was in pure SaaS, there might still be a couple incompatibilities. Um, we're, I mean, right now, actually we're finalizing a new release. Uh, I was kind of hoping to be able to announce it on here, but it looks like it's going to be a couple more days. But yeah, I mean, there's a ton of fixes coming out to kind of edge case stuff. Yeah, so I mean, I haven't really talked to him. The API is super simple, though. I mean,

what you actually have to implement, the kind of base stuff. There is, so we have, in MoveWeb, we use Go as our primary programming language. So there's actually a thing called GoSass, and so we keep that up. So that is implemented into our framework, and you can call Go functions to compile Sass. I think there's a version of Web.Go, which is one of the libraries that supports it natively. So yeah, we've kind of been in touch. I know he kind of did his a weekend project. And then I think he was looking to pass the project on. But no, I haven't heard. Wait, have you have you heard something more specific? No, no, I was just wondering what you were saying what you thought. But as you said that

I looked at the what I think is the ghost s library under move webs, GitHub, and you're not lying, man, that's a pretty simple uh api to to wrap around the whole thing it's like 100 lines of code yeah there's the the header file has like six functions there's like uh compile a folder compile a single file and then compile a string that you pass to it and then you know an options object or something but our goal was to make the simplest stupidest way to integrate. Where it gets harder is callbacks. That's a thing we've been...

So, you know, Sass now in the Ruby version allows you to define functions in Ruby. And, you know, it kind of creates... You get past this, you know, Sass colon colon integer, Sass colon colon string, you know, color. And you can manually work with these kind of things in Ruby land. The long-term goal, and this is when you, if somebody wants to make a super good adapter, you can actually kind of map the C objects into, you know, Ruby objects or Go objects.

Right now there's this kind of simple C focused callback library, um, where you can register custom functions and that's how we're probably going to get, um, initial compass support, just actually go code it and see like, why not? Um, so, you know, there's, there's that aspect, but yeah, so, I mean, that's when it gets more complicated, but I mean, if you actually, you know, if you're in job and you're like, I just want to compile some stuff, um, or I want to write my own command line app, it's super, super, super simple. Somebody asked in the – well, that's somebody. Scott Killam.

He asked about – I guess it kind of becomes a tongue twister, too. So I'll preface it a little bit with the fact that there's two two syntaxes for sass and i know that that's its own freaking debate and uh i don't even want to go there but sometimes you just have to but so there's there's the newer version which is more css like which is s css i'm not sure if other people have a different name or how to say it but i just say s css and then you have the kind of classic style, right, which is Sass. And the file types are.S-A-S-S for those listening, and.S-C-S-S

for S-E-S-S. But when you did this, we're talking about lib Sass, and the ins and outs of that, and go Sass, and all that good stuff, but I'm not familiar with the details around this, but the question he asked was, you know, Ham was a simplified syntax, and so is Sass syntax, and he's wondering why

you decided not to support the.Sass syntax, S-A-S-S. So, well, first of all, I hate the name SCSS very, very much. So you're only supporting the SAS syntax, not SCSS? No, no, no. I hate the name in all caps, SCSS. Oh, okay. So the initial conversations on SAS, we were going to make it more like CSS. Kind of after testing the idea with people I knew, like when we were kind of brainstorming,

like before we actually started building it, most of them were Haml users. And so since it was kind of part of Haml, they were definitely, people were like, no, no, no, no, it should look like Haml. Keep it simple. You know, I want to have Haml in my CSS. So we kind of... Our initial idea was that we were going to try to support semicolons,

brackets, and whitespace. And then Nathan came back and shook his head and was like, no way are we going to be able to support that. So at the time we kind of chose to go with a more Haml-like syntax. And that's what, you know, kind of is the.sass format. Then, you know,

we definitely... And that's like whitespace-aware. It's all space-indentative. To nest, you know, a property or a rule set, you're going to nest it underneath the previous one. So just to make that clear for those listening, it's not very visual. Well, and actually the thing people don't know. So Hamill's designed that there's a, the first character on any line is the control

character. And it basically defines what's going to happen on that line. And the idea is that you can read along the edge of the file and it's white space sensitive and kind of know what's going to happen. So that's why, you know, equals space, you know, my variable. The idea is I can kind of look at it and on the left-hand side as a developer, I know what's going to happen. I'm going to print something out. So actually the original version of Sass, it was colon attribute space, or, you know or colon width space 20 pixels.

Because it was trying to steal that concept that actually saying colon means I'm an attribute, starting with a control character. And basically over the years, we heard more and more that having a jarringly different syntax confused people, especially people who were not Ruby programmers, but were really more CSS developers. They were used to looking at CSS all day. And when you saw a different syntax, there was a lot more mental switching and learning required to understand what SAS was. So, you know, at the time, if I was a developer at a company and I said, hey, guys, I heard about this new SaaS thing. I'm going to convert our project. Then what you

would do is, you know, especially the very first version, the file would look drastically different than it did before. And all the other developers in the company would be like, hey, hey, whoa, whoa, what is this thing? What did you just do? So over time, it became very, very clear that we had kind of, in my opinion, made the wrong decision on going, make it more Hamill-like. And then, you know, Les definitely took the CSS-like approach and, you know, it dawned on us like, oh man, we've been so stupid. Here we have, you know, all the hard work isn't the syntax. The hard work is like the engine, how it functions, the decisions, the edge cases, working those edge cases out.

And we're watching less grow very quickly and struggle with the fact that they're a young project and did not, there's a lot of edge cases even today that less doesn't really cover. And it's kind of their focus is keeping it simpler, where SAS is really focused on stability and predictability. Like, you don't file a SAS bug, and then we say, oh, sorry, that's just a quirk. We're not going to fix it. Typically, we're like, oh, we'll get to that. So, you know, at least from my perspective, it became very clear that we needed to move to a CSS-like syntax. And Nathan and Chris were definitely on the same page. And this was probably, you know, honestly, this was the last major interaction that I had with the core project.

And I was proposing that we should just call it SAS 3.0 and be like, hey, sorry, after 3.0, the syntax is different. SAS 2 or something, give it a name. Just something, you know, kind of draw a line in the sand on something different. But I think their feeling definitely was that since it's the same engine and we don't want to alienate our community, we should kind of have two syntaxes. And I very much disliked the all caps SCSS. As people who follow me on Twitter know, I'm the it's SAS, not SAS guy. It should not be all caps. Yeah, I can understand that, though.

I think that's a crazy debate to have itself. But a lot of people do the all caps S-A-S-S because of CSS being an acronym, right? Yes. I think it's just capital S, lowercase A-S-S because of C-S-S being an acronym, right? Yes. I think it's just capital S, lowercase A-S-S. I mean, I'm not sure it's a word or anything, but that's how it's spelled. Well, it's a backronym, just to be clear. There are letter, syntactically awesome style sheets, but really that wasn't like, we weren't like, that's the most logical name.

Oh, look, it spells SAS. I just thought the word SAS was funny. I thought to have come in, like, an effeminate name for technology isn't really common. Things are normally called, like, you know, Thor and Rake, Hammer. So, like, hey, let's just call it SAS. Like, why is it bad to call something like that? And I loved how, when I was, by the way, was first announcing it, like, people were like, you, let's just call it Sass. Why is it bad to call something like that? And I loved how when I was, by the way, was first announcing it,

people were like, you really called it Sass? Are you kidding? That's a terrible name. Which made me like it all the more. Well, that's no, sorry to interrupt, that's no worse than what Vagrant's original name was, which was Hobo. Oh boy, yeah, that was funny.

Yeah, so SCSS kind of became this alternate syntax. It's definitely through the years, SCSS is far, far, far, far more popular. And so what I've kind of been re-engaging over the last two years in the project, at least with the community, the Pragmatic Guide toass and lib sass uh they only use the css like syntax um and i don't really differentiate

scss anymore uh in my mind scss is now just the extension on the file or s, SAS CSS, or super CSS or something. I don't know. But yeah, that it stands for that. The language is still SAS. I'm actually not a fan of having two syntaxes because I think it's kind of bad marketing to say, well, what is this? I feel like it's been like an anchor to you guys.

And I don't mean like an anchor in a good way. I mean like it's dragging you down. It was hard to anchor to you guys. And I don't mean like an anchor in a good way. I mean like it's dragging you down. It was hard to get people to adopt when there was the older way because you talked about the different syntax and how different it looked. People didn't want to adopt it and they got to learn something new. The same reason people don't want to use or people would resist Hamill versus ERB or HTML straight. It's just one more hurdle to get over. And so we were on the show, the most recent show, 93, with Phil LaPierre from ThoughtBall. We were talking and he asked me and I said, well, I know that Nathan has said from the SaaS point of view that it's going to continue to support both syntaxes. But do you know, or do you think that it would be just wise just to, you just said it basically, but, you know, is the longevity of SAS going to keep supporting these two syntaxes?

And I think it comes with a tail end to that question, too, by saying that every time you have a conversation about SAS and its syntax, you have to have two conversations, and it forks in. It makes it confusing. Like even in the 5x5 IRC room, we got somebody in there asking questions about it, and Andrew thoroughly answered the question, but they're still asking questions because it's a confusing subject.

Yeah, I should be in that room. Yeah, I mean, so i definitely think the nathan is behind and i believe chris is behind uh the kind of naming scheme that it is just sass the word sass refers primarily to or exclusively to the css um, which is awesome because with that, you just point SAS at your folder of CSS files, change the extension, and it just works. You don't have to worry about anything. You don't have to go backport everything. You can use CSS libraries. It all just works. Yeah. Um, and that, that's where, you know, it's really a killer thing. So I think it's not, you, you can stop having two conversations, uh conversations as long as you feel comfortable with that.

SAS is now CSS compatible. Its extension is SCSS. The pragmatic guy to SAS barely mentions he exists. I think there's a little sidebar where they say, there's an older syntax called indented SAS. You know, to find out more, go here. That's basically, we've changed all the examples, what's an older syntax called indented SAS. To find out more, go here. That's basically, we've changed all the examples, what's on the website. So it's definitely people, there's definitely, I know a lot of diehard people who love the older syntax because it is kind of more minimalist.

Yeah, we use it at Pure Charity. So Andrew and I both, our full-time jobs, we work together at this company called Pure Charity. And we use SAS there and we use the indented version of SaaS. Yeah, so the Ruby version will – Before I went to Pure Charity, I always used the SCSS version. And it took me a little bit to get used to it. But now I actually do prefer the indented version. So now it's like I – but, but you know it's funny because you're

you're bringing up a problem that i think kind of plagues the uh i don't know if it's every community but especially in the ruby community and and especially in the rails community um i think like four you know four years ago five years ago people wanted to get in and get started with rails and it was really easy like to get up and running and running. The zero to Rails was so easy. But now there's so many choices you have to make. And I think that when a potential developer is making these decisions on templating engine and how to do their style sheets and how to do authentication, there's all these choices you have to make to get started. Then you get to SaaS, and you're like, okay, everyone uses SaaS, but which version of SaaS

should I use? More choices, choices, choices. I think the zero to Rails is a lot harder now for people. I think that removing features or removing, if you removed the indented SaaS version, you'd have a battle probably. The good and the bad of open source is guess what if you remove support from sass then somebody would fork it and get the old version back and people would start using it and it's like this thing that plagues the community but it choices are a good thing but they're hard for newcomers so i don't even know where i stand on that but yeah it is funny that you say about that because

i always like i was a diehard about the SCSS version on all the projects I ever did before I came to Pure Charity. Come to Pure Charity, it's all indented SAS. Like, it was cutting teeth and I hated it and I had to spend time just, like, getting used to it again. And now everything I do on the side, I do indented SAS with. So I'm all screwed up. You guys are just spreading the chaos. Thanks. Now, look, so indented SAS is fairly popular within experienced Rails programmer groups.

If you look outside of Rails, which is where all the growth has been in SAS usage, it's hands-down SCSS. They're really not aware that anything else exists, to be honest. Like, when you look at the tutorials when you're learning when you're bringing it to your company you're using php but you have this sass you know your your framework supports an adapter it just is sss to you there's no concept so well it makes sense i mean sass is css compatible when you use that version and that

alone is like the sales pitch that makes sense why you would do that. You're zero to SaaS, for lack of better terms. Just to put on what you just said there is super quick. As a matter of fact, what got me to start the SaaS way with John Long and others was just that because I was writing a tutorial because somebody was asking me how to get started with SaaS. And I'm like, well, it's so easy nowadays. You literally just do what's necessary to get the Ruby compiler, you know, before LibSAS and others that are available.

But, you know, get the Ruby compiler to your local machine. And pretty much from there, it's just renaming your file from CSS to SCSS. Like, that was easy, wasn't it? Like, now go rinse and repeat in your projects and just start adding variables and incrementally just sprinkling, you know, SASE, CSS, to use your word, Hampton, in there. And boom, I mean, you're incrementally just stepping into this unknown world you never knew was there. And that's the magic sauce right there. Yeah, I mean, well, that's definitely when you see, like, I mean, it's really fun to teach SASE, because it's in pragmatic guide to SAS and also the stuff we're doing with Treehouse

it is very much the first lessons like okay so you show some CSS this is also SAS you've now learned step one and then you say try indenting, try to put a subselector and then

you're like now you've done magic. Like this is like, and then you can do a variable and it's like, it blows people's mind. Yeah. People are just like in CSS, but haven't seen it before. Yeah. They have a little aneurysm. They're like, wait, what? Oh, what? I don't know what just happened. You can do that now. Can you talk a bit about what you're doing with Treehouse just to kind of give that a little light?

Yeah. So, I mean, Michael and I are both working with Treehouse to kind of, we're currently working on the scripts, but we're going to be doing a whole module. Treehouse, if people don't know, is the training company that basically you log in and they have videos and tutorials to help beginners learn different web technologies. And so SAS is going to be one of the featured web technologies and have a whole unit and they've asked me to come in and do the videos and you're gonna go there record and be the person teaching i am i am going to be the person teaching wow that's awesome

i got a friend that's working on there you'll have to i'll have to hook you two up when you go yeah it was actually it was uh all the guys at less conf there was a bunch of the treehouse guys and uh i know uh andrew chalky's been a friend of mine for a long time and uh they were just like hey wait you should come do it and i was like let's do it i'm not busy uh was it uh was it your your mask raid on the beach that uh got them to think that way or what we don't talk about that what happens at less comp stays at Les Conf. That's the magic rule. Good one. Touche.

So, yeah, let me. Yeah, that's it. I don't have any more. Let's ask Hampton our famous questions, Andrew. Yeah, so I guess the first one, and the listeners to the show will know this, but any newcomers, we kind of have two questions that we ask to all of our guests and the first one is for who is your programming hero um i'd say tender love he's a he's a alumni of the changelog for those that don't know tender

love is aaronson. Well known. Rubious out there and a funny guy on Twitter. Yes, he is. No, I just... There's not only... His project, Nokogiri, was a major inspiration to the crazy stuff. We're doing a Move web now.

And his code is beautiful. He's just the sweetest guy in real life just the most down-to-earth nice guy out there and uh he has an extreme in his surrealist sense of humor um and uh pictures of uh gorby puff his cat um just complete the whole thing for me um and i love when i see him at a conference and he's usually sitting down and actually just coding the whole time. You know, I like to think of myself as a pretty passionate programmer, but man, like, I'm just like, Hey, when's lunch break? Like, Oh, we can talk to some people. I'll check Twitter. Like he's just sitting there like hacking with somebody and building something really cool and amazing. And I just so much respect. And then plus having the kind of weird,

surrealist sense of humor. And I do have a, back on my laptop, I have a Gorby Puff sticker of his crazy looking cat. So he's winking. Awesome, yeah. I think he's a,

if a lot of people try and get creative uh when they answer that question and they'll you know come up with some obscure you know unix developer from the 70s and you know like but i think if a lot of people that have been in the ruby community were honest he would be on that list for for a lot of people he's an inspiration to me i mean yeah big big fan of his so uh before we go on i just want to mention so those listening if um if you want to pick up another episode of the changelog to go back and listen to if you go to 5x5.tv slash changelog slash 44 you'll pick up the episode we talk uh uh i think it was me and win that talked i know it was just win on that show talked 1.9 so this is pre 2.0 obviously talked

Ruby 1.9 Nokogarian Tender Lovemaking with Aaron Patterson so go back and listen to that show which is his website tenderlovemaking.com

I think yeah can I throw in another answer too yeah sorry that's really weird yeah go for it no because when

Donnelly Brad Fitzpatrick I don't know he invented Memcache and he works on Go now. And we use Go a ton and really love that language. And I just think that's really amazing to be on such two projects that I use all the time.

Anyway, that's it. Yeah, I think I saw his name. I think he was associated with OpenID at one time, or he started it, I don't remember, but I used to use OpenID to log into, I want to say Stack Overflow. Yeah, I believe he's... I've never seen his name on that. Yeah, he started OpenID, I believe, yeah.

Yeah, cool. So our other question, and this is for you to pick, Hampton, the different libraries that you work in, and we kind of asked for a call to arms. So being that we do support open source and we love open source, what would you like to see the community get involved with on any of your many projects that are out there? Okay, so definitely hcatlin slash sassc or rubysass, I believe is the name of it.

Both those need help, and normal people have the ability to help on them. If you're crazy into compilers, then you can try to dive into the lib Sass stuff, but it's a little intense. It's kind of hard to just jump into. But Sass C, especially the test framework area, needs a lot of help. I mean, that's a thing where the community,

if you're really passionate about Sass and want to see Sass go from even just being a Ruby implementation to not just being a C implementation, but other things really being a language, we really need to have a compelling spec that kind of works for all implementations and can really help people

and help solve projects that work with it. So that's, if I had a wish, it'd be people to go people, and help solve projects that work with it. So if I had a wish, it'd be people to go in there and help write tests. The tests are simple right now. We don't have options yet. We don't support some of the different compile methods, and it's not its own project. I'd just absolutely love to have somebody come in and pitch in and help with that.

It's not always the sexiest thing in the world to work with a spec library, but it would make a huge difference to the overall community and the health of SaaS itself. Yeah, I think you can make it the sexiest thing in the world by offering free iPads. That's what I do at Peer Charity to get my code reviewed.

That's what he does. He's like, here's a pull request with a free iPad attached. I mean, no one ever gets free iPads, but it seems to give them a shot. I like this one test you have in the SASE library, huge.scss. That's kind of cool. Well, that's our speed test. So we have a couple of ones we use for benchmarks.

Yeah. Because definitely it's the, like, a really simple file is, you know, I mean, especially Ruby boot time is when you're doing performance differences. But, I mean, I don't know about you guys how large your project is, but there's a lot of people with very, very large SaaS projects. And, you know, Ruby is not so great with handling so great with handling 100 million strings in memory all at once and then trying to write that out to disk. And that's why you see really slow performance with Ruby, SAS, and big projects.

And libSAS, it's super fast. Yeah, I guess one question on talking about the testing piece. It never really occurred to me that these tests would be written in SAS. I guess that kind of just makes sense. But for those who are like uber SAS enthusiasts that like write compass extensions and are like frameworking to the nth degree, what would you recommend for them to like dig into in some of these projects just to learn from some of the code you've written or you guys have written?

That's a tough question. I mean, definitely, you know, I mean, compass is a crazy invention itself and has, you know, nice components that you can go look into. LibSass is pretty challenging to look at and, and the main SAS repo itself. It's very, you know, LibSass is pretty challenging to look at, and the main Sass repo itself. It's very, you know, mature optimized code is typically ugly code, to be honest. Sorry, Nathan, it's not, like, ugly, but there's just a lot of stuff you do to, you know, optimize and get around things. It's not this kind of pure, perfect, you know, ideal. It's not the kind of thing you do like a training on, and this is

how your coach would look. Um, yeah, I don't know when people want to learn what to work on. I mean, honestly, like share your SAS code, go, go look at some of the crazy mix-ins that people write. Um, there's a ton of stuff on CodePen. I love to see that stuff floating by. Um, just, you know, I'll randomly see a tweet of like, Oh, look at what I built in CodePen. Was that the question? No, it's good. I definitely think Compass is a super good resource, especially if you're working with Compass. You already know about that.

But definitely diving into the source code. So if people want to know how do I write my own mixins that do X, Y, Z, they're going to go jump into into compass or bourbon or something like that or if they want to drop down into ruby and write some sort of ruby extension that does something in addition to you know on top of sass or whatever then they can do those things but i just i had really hadn't really occurred to me that your tests will be written in sass so i was like that's kind of neat neat. And looking at some of your variables in there, I just didn't really think about them being written in SAS. Don't ask me why. What would you write them in?

I don't know. That's what I'm just, I just don't even know. I haven't done this kind of work, like writing tests against this. I just, I don't know. I just didn't think it would be written in SAS. Well, so, you know, Tridium, which is my newer language, that's, I imagine it's like Nokogiri, kind of, but a language, or a really stripped-down JavaScript.

And, you know, its test framework that I wrote is giant. Because it's basically input HTML, the Tridium that you want to change on it, and then what we expect to come out of that. And you, you know, every single build that we do internally the company you know goes and kicks off like i think it's near 2000 tests at this point anytime that we get a bug you go prove it out in one of those snippets and so that's basically what we're trying to do here it's very early version though right now it's's very simple. Primarily what we're running though is we run the Ruby Sass and then we run Sass C and run them right

next to each other and make sure they match for ones that don't have expected output. Awesome. Well, Hampton, I want to thank you for joining us today. It was definitely a fun chat talking with you about Sass, Haml, Wikipedia Mobile, MoveWeb, and all the crazy stuff you guys are doing there. Definitely appreciate your inventor hat and hope you keep wearing that hat and don't stop inventing. I'm sure that you won't. I can't help it. I can't help it. Stop me, somebody.

Exactly. And if you want to follow him, you can follow him on Twitter. He's hcatlin, both there as well as GitHub. This is episode number 94, show notes. And this show will be available tomorrow at 5by5.tv slash changelog slash 94. Next week, Andrew, we don't have anybody lined up for next week, do we? We have some pending things. Some pending.

So guests for next week has not been pinned down. But nonetheless, next Tuesday at 5 we'll be broadcasting live again. So thanks for tuning in, and we'll see you next time.