In this episode, I sat down with Hampton Catlin to talk about his Ruby survey, the implications of the data, and about the evolution (and naming) of Sass. Show notes can be found at http://developertea.com
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I have the pleasure of interviewing Hampton Catlin. Hampton is the third of the three interviews that I did at Ancient City Ruby. Hampton created Sass and he created Hamel and now he's working on a project called WordSet. We talk about that in the second part of the interview with Hampton. I apologize in advance for the background noise that you hear. Unfortunately, Hampton and I could only meet in a location that was right next to a cafe. So I've done my best to try to edit out as much of the background noise. Hopefully you can hear Hampton and I as we talk about all of the amazing things that Hampton has been working on. We talk a good bit about Sass, so if you don't know what Sass is, make sure you go and get a little bit. familiar before you listen to both episodes and also follow Hampton on Twitter. His Twitter handle is HCatlin and let him know how much you appreciate him being on Developer Tea. Now, let's get to the interview with Hampton Catlin. I'm here at Ancient City Ruby with Hampton Catlin and I'm really glad that Hampton has a few. A few minutes to sit down and talk. We've passed each other a couple times and luckily, based on all of the breaks we've had at the event, we've been able to actually sit down and do a few interviews here and so I'm really excited. So we're going to talk about a few different things. It's kind of an open format, so it's kind of a last minute interview, but I'm excited to do it. Happy to be here. It was good we could schedule it. My people called your people. We worked it out. Yeah, it was really fun. It was really intense. We've got these PR people that follow us around. The entourage just worked it out, so it's good. So Hampton gave a talk that was really interesting about data that he's been collecting. You might have taken Hampton's survey, even if you don't know if you took it, but he collects data on a yearly basis. Tell me a little bit about that. Eight years ago, it was 2008. Time travel. Yeah, so I was... I've been doing Ruby for about four or five years at that point, I guess. And I don't know, I felt like nobody was really doing a survey of what was changing in the community. I could already see things changing. For instance, back then, Merb was really gaining traction. But nobody really knew how much. You couldn't answer the question. Maybe a friend was working on it and you're like, I don't... And I just thought, well, let's do a survey. So I kind of haphazardly built a quick little online survey. And then the next year... I decided to ask the exact same questions again and added on some new ones. Over the eight years, I kind of got a little lazy about it. Certain years when I was working on other projects, I just totally forgot. Actually, it was Ethan Light who helped me get it back up. Because a couple of years ago, he wrote me and said, Hampton, you've got to keep this going properly. So I kind of turned it into an official project recently. But we've done six surveys. The lowest year, we had only about 200 people fill it out. Biggest years have been about 1,000. Which this year, I think 1,000 people took it. So, yeah, we're just trying... You know, there's always new questions. But I really like... My favorite twist is that we ask the same... Even questions that are super dated, I just keep asking the same way. So I apologize if you have to take the survey at this point. After eight years now, it's like, do you use MooTools? And it's like, no, I don't use MooTools. That's a long-forgotten JavaScript library. Yeah, but it's been fun. This is the first time I've ever kind of presented. I put up the data usually. But I felt like doing some recaps, looking through the data. We rebuilt the site, actually. Relaunched it in a couple of days before this. It's now called Askr, like Flickr. Oh, okay. Well, it's the worst name. It used to be called Hampton's Ruby Survey. Just because I thought it was mostly just me tweeting it out. But I realize it's kind of gotten bigger than that. And also, you know, it's cute naming something. You're just like, I'm going to name it after yourself for the first couple years. And then you're like, that's not so cute anymore. So yeah, instead of coming up with a good name, though, I think it's better to just be like Askr with just an R. Like there's no E-R. Is this why you named Hamel Hamel? Is this even remotely? Yeah, I get that. I've gotten that question a lot. That's a weird one. Like, it was not to name it after myself. Okay. However, the fact that it did happen. I mean, it was HTML, and it was an abstraction, and we're already the A. And I'm like, it's a markup language. And I was like, that does kind of sound like my name. Let's go with it. Yeah, but actually, the name was, it actually was from writing it down, kind of, what I wanted it to be. And then, yeah, just the fact that it happened to match my name. I was like, I'm going with this. But the main thing when I first presented it is I named it after Mark Hamel. So I showed a big photo. Usually when I give a Hamel talk, Mark Hamel's the person I show. Photo, yeah. I mean, why not? If your name shows up in a thing, or it starts to be. Right. I guess what makes me weird is that other people would be like, oh, I can't possibly name it a thing that kind of sounds like my name. And I was like, screw it. Let's go. Yeah. Yeah. So back to the survey. All right, yeah. There are so many interesting things that kind of come out of data, which is, I guess, an entire conversation on its own about how, you know, you aren't, like, trying to skew the data. Of course, there's certain, like, parts of, you know, you said, it's me tweeting it out. So obviously, a lot of people are going to be using SAS, for example. But there was a lot of really interesting pieces and parts and conversations that were started, even amongst the people that I've been around since you presented that data. So, for example, you showed the server, the web server, that people basically, like, everybody uses, right? Yep. And the one that has kind of risen is Puma, right? And Unicorn, like, showed up really strong and then kind of tapered off towards the end. Yeah, awesome. And I was sitting next to, I don't remember who, but we were talking about why that might be the case. And I said, it's most likely because Heroku officially supports Puma now. It recommends it. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. See, this is the, I guess, why I wanted to start the survey. I could go back to the beginning of the question, too, which, like, there's a lot of things to say about data. I don't really trust data. Like, I am not actually a data-driven person. Like, when I manage teams, I don't. I mean, that's not, sorry. Graphs are cool. I like graphs. Like, performance graphs and, you know, like, whatever. Metricing people on, like, dropping the, like, my ops team, I used to metric on uptime and stuff like that. Whatever, that's fine. It works. It's a tool. But I feel like nerds, we overemphasize and overtrust data. I'm as skeptical as anyone of the data we pulled out. Because you just, there's so many forces acting on it. So, for instance, you know, the question, do you use SAS, right? That's one of the ones on there. And I think it's, like, 77% say yes. Or, sorry, maybe it was 82. Maybe. Maybe it was 82 because that's my lucky number. It was a lot. I think it was 82. But it's, I mean, I'm going to sound really horrible. In a way, that's low and high. Sure, sure. So, there's a lot of people taking that survey and they answer another question where they say they don't do any web work at all. So, do you use SAS? No. However, you know, SAS's main competitor, LESS, is not as popular in the Ruby community. So, it drives up the number. Right. So, it's really, like, that's not even, it's interesting to have a number. It's not even a number to talk about. But it's also, yeah, you just can't trust it. Like, there's no way to know what percent of people actually use SAS. Like, the best I've looked at is, so, it's like Smashing Magazine has tweeted out a couple quick surveys on that. And it's funny. It ends up being about 82%. Interesting. Yeah. It's been cool because SAS lost a lot of ground to LESS, like, maybe three or four years ago. Sure. So, that'd be poor. But it's been fun. Kind of interesting to see. I'm sad I didn't ask that question for over the years because I've had to piece it together. Which is, like, SAS or LESS. Yeah, yeah. Or Stylus. And I have some data on that. But it's funny. SAS has made, like, a big resurgence. And it's basically kind of knocked LESS pretty far back. And I think there's a few reasons, I'm sure. Bootstrap is on LESS. A lot of people, for that reason, probably were introduced. That's why I was introduced to preprocessors in the first place. Oh, yeah. And so, I came in. I was like, wow, this is really cool. And then, you know, Chris Coyier, for example, was like, SAS is the winner. Like, we've been talking about this for a long time. And I, okay, clearly I'm opinionated. I tend to agree. There's still people who like the other thing. Like, there's still people who use it. But what's interesting is there are people probably listening to this podcast who use SAS without even knowing it. Right? Because it's. Definitely. It's. First of all, it comes. It's default in Rails. So, and I kind of want to ask you another question about this, by the way. About the functional difference between SAS and SCSS. And if there is one. There's no functional difference. Okay. It's the same language. So, it's a preferential thing, right? Yeah, it's just. I mean, so we don't. We tend to call it. So, SAS is both. Okay. Yeah, yeah. Which is. SAS is both. There's the indented syntax. And then, the standard syntax. Okay. Which is SCSS. Right. It was just. You know, SAS started as a. A kind of sister project to Haml. Mm-hmm. I convinced Natalie to. I wrote up the spec for what I thought the language should do. Mm-hmm. And I started coding out part of the project. And then, I convinced her that it was a good idea. Mm-hmm. And kind of wrote up the list of, like, philosophies. And then, she just went crazy. And on an airplane ride back from, I think, RubyConf. Maybe 2007. I think. Yeah. I think it was 2008. Yeah. 2007, I think. Just started. Just took my code. Just like, went crazy. That's awesome. And the whole thing flew from there. But we, you know, it was written then with an indented syntax. Only because it was the sister project to Haml. Like, I've never. I'm not. I don't have any strong opinions on indentation. I don't. Right. Hate it. I don't love it. It felt right with Haml. Sure. Especially with structured documents. That. Something about that is what I was looking for at the time. So, yeah, sorry. No, you're good. So, Haml, Sass was just kind of naturally expressed that. Like, we wanted to try to make it kind of close. But it wasn't, you know, that wasn't like a huge deal for us. And then, when the project spun off officially into its own thing. And actually, Natalie doesn't work on Haml anymore and is just doing Sass. You know, Less came out at this point as a Ruby project. And was compatible with CSS. Just like a. Yeah, CSS. And obviously, we were like, oh, yeah, that totally makes sense. Like. Sure. Oh, yeah, wait. We can do that. Like. Why not, right? Like, it's just curly brackets and semicolons. We can add those into our language already. That's not a. It's just one phase of the processing. Mm-hmm. Yeah. So, all the back end is the same for the two. Like, actually, I mean, you can mix and match them absolutely. Sure. In different files. But. Yeah. Yeah. Like, the internal logic and everything is exactly the same. But, you know, it was definitely less than we were. Like, it's funny. You just back it up. Yeah. You just back it up. Because, you know, it's something that's kind of dawned on us. It's such. Technology is like that. Mm-hmm. Yeah. Like, you see an obvious idea and you're like, oh, of course we should have made it CSS compatible. Yeah. Sure. Like. But, you know, honestly, we never. We didn't. I could have never imagined that it would, you know, kind of start approximating some sort of industry standard. Like. Mm-hmm. HamL is a weird language. It was meant to be a weird language. Like. Yeah. It's part of its philosophy. It's very opinionated in that way. Yeah. And I just. You know, I wanted to build something that at a time is what I wanted. Right. I remember when I gave the first Haml talk, I was just like, well, nobody's ever going to use this except for me. It doesn't matter. I'm just going to, like, at least I'll get a conversation started. And, you know, it turns out still, I think, 40% or something, I think almost 50% of Rails developers use Haml, which is crazy. Wow, yeah. It's actually, sorry, it's been showing up higher on the server than I could have imagined. Sorry. But so we weren't envisioning Sass as, like, okay, let's change CSS. We weren't thinking that. We were just thinking in our development workflow, what would work best with our Rails flow? Like, don't, I don't know. It's a very different way to think of something. And then when we saw Less and we're like, oh, the things we're doing could be kind of, we could pretend like this is CSS. Sure. And it was so obvious. And it only took, like, I think after Less came out, I mean, I think it was maybe a month later that we, or now, I don't know. I'm not coding. But, you know, SCSS came out. And it, you know, the focus changed then because a lot of, actually the syntaxes I hate most in SCSS come from trying to be as close to the way the W3C thinks about CSS as possible. Sure. I mean, it's clearly not strictly on spec. And it will never be. Right, right. Things like using the at symbols, like, that's something that is very much in the language of CSS. So we won't ever violate CSS rules. Mm-hmm. By using those. So it's funny now, we developed with a much different view than we started. Now it's very much like we have to be future compatible. We really need to think about the future of how this language is going to change. The debates, it takes, and this is why I think we have been beating Less, to be honest, is, you know, the project's eight years old. Mm-hmm. And it's mature as it can possibly be. Right. And every single small change to that language, Natalie is very strict. Mm-hmm. And very skeptical of any change. So there are long debates about how to change things, how to do it slowly. And I think that's, you know, Less was much more of a, it's funny the newer one was kind of a much more, they were a little more whole hog. Yeah. And Stylus is like, they just kind of, there's some stuff in there that is not CSS syntactically. And there's some edge cases that you can hit. Mm-hmm. Where Sass, I mean, I'm pretty proud to say, there's, the edge cases are... Pretty well taken care of. Extremely well defined. I mean, except, if they're there, they are very rationally worked through. Because that's all Natalie, by the way. That's not me. Right, right. It's all incredibly, because I'm, honestly, if I'd been running Sass all these years, and I had final say, actually, even Chris Epstein, too, we're both pretty like, that's a great idea, let's build it. Right, right. Like, go, go, go, new ideas, crazy things. Yeah. It really takes somebody, you know, to make these projects work who's like, very skeptical of anything new. Yeah. Or anything that could break, or worrying about that. And she really takes it seriously. And so, I think that's where, you know, when you do this as your full-time job, I think doing less can sometimes, you know, like, there's definitely things you just can't do. Or you'll hit, you're like, oh, I named it this way, and I've screwed now. Right, yeah. There's some strange mix in syntax and stuff, too. Mm-hmm. Where, you know, I'm proud to say in SCSS, like, it just doesn't really happen. Right. And that's why most people who are professional tend to kind of switch over. Because they're like, oh, I'm not going to get, find a surprise bug that the developer says, nope. Yeah. Like, we just can't do it, or we won't, or. Yeah, because it's backwards compatibility. Once you add something to a language, you can't take it back. Right. And that's always the fear. That's why you see these super long discussions. And that's why we, you know, take at least six months before we add a feature or it comes out. Sure. Because you test it and think about it. And try to think of any way that in the future we might regret why we did it this way. Right. Yeah. And it's exhausting. Yeah, I can imagine. Well, it sounds like, basically, like you have your own W3C. Like, you guys are, you're running essentially what is like a spec, like, long process. Because, you know, on those mailing lists and stuff, people go back and forth. Like, people like Tab Atkins, they're mailing for, you know. Years. Yeah. Forever about these things. Yeah. And they're, like, specing stuff for years. And, you know, going and talking to people and seeing if this, like, if they ever see any issues. Because it's really difficult. You're writing for the past and the present and the future. Like, all of these features that you're deciding have an effect on projects that have been built before. Yep. And they're going to have exponential effects on projects built in the future. And so, you know, and you also have the CSS spec that's being developed in parallel. Yeah. That you have to keep in, kind of, in your mind. Kind of in your view at the same time. It's a pretty massive undertaking. Well, so we, we like to think, like, or I always think of it as, like, it's like riding a bull. Right. What we're doing. Mm-hmm. I mean, we get a lot of freedom because we're an independent project. So. Sure. You know, honestly, if Natalie gets convinced, that's it. Right. Mm-hmm. Yeah. She's definitely the, it's the right thing. I mean, Chris and I are like, you go ahead. Go ahead. Take it. It's fine. Yeah. We'll argue with you and try to make our points. Mm-hmm. Which, yeah. Yeah. It's the natural order of things. Sorry, but it, but you're kind of having, we're having to listen into those, or Chris spends a lot of time being aware of the W3C stuff. Mm-hmm. Because, yeah, we have to, you know, when we're seeing them talk about a syntax that might appear in 12 years, we want to make sure that that is something we are already thinking about. Even if it never comes in. Right. Right? You just kind of got to, like, it's bucking underneath you and these threads are happening and some things are moving, some things aren't. And, you know, there, it's funny. We're very much beholden to them. They, they are absolutely not beholden to us. Right. If not slightly disgusted at our existence. But that's fine. Yeah. Well, it's interesting you mention that, though, because I, it's probably debatable that what SAS and LESS and Stylus have done to CSS is pushed it forward. They, they've definitely, it's almost like a testing ground for potential features in the future. Right? So, like, in, in some ways, because, you know. Yeah. I mean, if you have a question about will people use variables, well, that question has been answered now. Like, in. Yeah. I, I think the downside is, okay. Variables are funny. Right. Because variables, they don't, they don't make as much sense in the browser. They don't really give you a lot of savings. When you're compressing the kind of values we have in CSS, like 1px. Right. Putting the word width there, I don't know, sidebar width or something, like, is, I mean, with compression, it's a wash. Sure. It doesn't even matter. Like, I, actually, if anything, you made the parser slightly slower because it's got to remember state in a way that it didn't. Right. The CSS parser. Like, it's, it's just kind of a wash for a developer. Um, and, and then load odor is all weird because you can't control it. And namespace collisions between CSS files. And also, if you include a library that has variables. Like, there's something very nice and clear about resolving all this before you go to production. Right. Um, like, there, and it, sorry, it happens with a lot of languages. Like, when you compile Java into a bytecode, you know, there's a very different job being JavaScript, sorry, Java bytecode and being Java. Right. Like, Java needs to resolve everything. It's got variables. Uh, it, you know, so it, it's interesting the variable spec. Uh, when I first saw it, um, tab, yeah, tab, just couldn't work on that one forever. That's, that's his baby. Yeah. Uh, I, I did not like it. Right. I mean, I, I still, I still don't. I don't think it's beautiful. I'm with you. I'm in the same place, yeah. But, but here's the thing. And this is what I kind of found out. I got a call from him, and he's pretty public about it now. Uh, what he did was include a syntax that now opens the door to a lot more dynamic, uh, manipulation of CSS during runtime. Yeah. So it's, it's not that, so variables do have some things, uh, CSS variables do some things that are not like normal variables, and they're totally useful in a couple really interesting cases. However, they're not the same thing as using Sass variables where you set colors for your website. Sure. They're not even meant to really be that. Uh-huh. Um, and a lot of the new features that Tab's working on right now are this kind of extensibility in CSS. Mm-hmm. Which is something we can't actually do from the preprocessor. Sure. So a thing like being able to include, uh, dynamic layouts on the page. Mm-hmm. That are calculated on the fly by JavaScript very efficiently. And you can write your own style CSS, use attributes that don't exist on the page. Ah, interesting. That's stuff that preprocessor, I mean, we're still there. Mm-hmm. I mean, we'll support those. Right. We'll help you write those. Mm-hmm. Um, but we're not the browser. Sure. And I think that's, it's funny, variables, uh, he calls it his Trojan horse, um, because what it did is, uh, all the browser manufacturers had to do a couple, you know, this is all super weird internal browser building. Right. Yeah. Purser stuff. Yeah. But it was, it, it was to open the door to be able to do a lot of this extension stuff that he was really pushing for. Yeah. Um, so, you know, I think that there's always gonna, I mean, there's always a knock on wood. Uh-huh. Uh-huh. Um, but, uh, in terms of writing CSS, uh, I think preprocessors at some level makes sense. They're really just compilers. Mm-hmm. Like, uh, ES6 has some compilers that you can do now. Um. Yeah. To, like, make sure that when you deliver to the browser, modules are resolved. Mm-hmm. Everything's sorted out before it gets there. Mm-hmm. It makes sense to do some quote unquote preprocessing, like compressing an image before it gets to the browser. Sure. Um, but I, I would say the only exception is as long as we're doing CSS. Right. Um. Right. You know, who knows what. I think we have a much bigger problem with the browser. Mm-hmm. Generally with layouts and how it works. Yeah. And, you know, Sass helps some. Right. It's just giving you a, like, you're building the same building, but you just have, like, a hammer that's a little more efficient. Like. Right. Yeah. It's, it, the house is still, the plans are the same. Right. And I don't think, I, I don't think that, like, this, this future looks like moving a bunch of stuff that currently is in preprocessors into CSS. Right. I don't think that that's the point at all. Yeah. Necessarily. But I think that there are, like, influences. No. Because. No. People who are writing the spec for CSS are now aware, okay, there's, there's a lot of people using these preprocessors, preprocessors now. So, we have to figure out a way to, you know. You'd be amazed how little of a crap they give. Really? Yeah. Uh, I mean, I, I can't, I mean, hopefully, you know, I'm, I'm, I, I love having my ego stroke that we're affecting them. Uh. I mean, I, okay. The one exception I can think is, uh, using extends, which is incredibly complicated to pull off in SAS. Mm-hmm. And I don't, I don't think we should have had it, just to be clear. Uh, I, I think it's to be avoided. Though it, it helps in some really nice situations. And yeah, the extends feature in SAS, uh, uh, is something the browser could do extremely efficiently. Hmm. Interesting. We're doing a bunch of hacks to try to simulate something like it. But. Mm-hmm. It is the, it'll slow down. If your SAS is slow, it's going to slow down. If your SAS is slow, stop using extends. Like. Wow. Yeah. Go refactor, get rid of it. Um, and we're, we're pretty hopeful. I think, uh, tab recently got the W3C to, uh, roughly agree to include a, an extends style syntax. It's not exactly the same. Oh. Uh. Very cool. Yeah. So that, that one I'm looking forward to. Because that's definitely one where we were trying, you know, we're simulating, I guess. Mm-hmm. We have to, when you use extends, we actually have to go build a tree of what we assume your document might look like. Mm-hmm. And it ends up being billions. Oh, wow. I'm, I'm not kidding about, it can be, depending on how your, how big your style sheets are, it can be billions of nodes. Um. Wow. Uh, and we have to prune that down to something that you can put print into a line. So. Oh my goodness. Because it, and all we're doing is assuming likeliness. Mm-hmm. So it's unlikely that it was an A tag, which probably meant a div. And it's unlikely that the hover style is the one that you were intending. Yeah. So we just like take all possibilities and cut it. And it's, it's a hack. It mostly works for people though. Uh, but it is, uh. It's like a experiment more than, more than anything to see like how, how efficient can you get this really big job, right? Well, you know, I'll say that's one of the, it's one of the few features we added that we kind of got bullied by the other languages on and kind of collapsed too early. Yeah. Uh, they all had something like extends and I mean, I'm pretty proud to say that their implementations had, or were much worse. Um. Performance wise. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. At least they were. this and then natalie came up with a way to do it better sure and like it was reasonable and then it was like all right let's add it thank you so much for listening to the first part of my interview with hampton catlin hampton thank you for being on the show once again make sure you'd catch the second part of the interview in the next episode of developer t we talk about word set and we talk about why words need to be open sourced again thank you so much for spending time with me today listening to this show you are the reason that i create the show if you have any feedback you can reach me on twitter at at developer t or at gmail at developer t at gmail.com and until next time enjoy your tea