Tools like Sass can help us write code faster and more consistently—big benefits for any workflow. But adding complexity can also add problems—and create barriers to entry by making people think they need all of this stuff just to get started.

What we discussed

• Preprocessors, postprocessors, transpilers: what does all this terminology really mean?
• Are we complicating a simple language?
• Why might you want to use a preprocessor? Why not?
• When are they more work than they’re worth?
• Is it possible to be a front-end developer without using these tools?

Featuring

Rachel Andrew

Speaker, An Event Apart and cofounder of Perch CMS

Lyza Danger Gardner

Cofounder of Cloud Four and Responsive Field Day 2015

Jeff Lembeck

Speaker, CascadiaFest and OSS developer at Filament Group

Susan Robertson

Speaker, Future Insights and author, A List Apart

Transcript

Rachel Andrew: Okay—hello and welcome. Welcome to the second A List Apart: On Air event. My name is Rachel Andrew and I’m a web developer. I’m one half of the team behind the CMS Perch, and when I started building websites, we didn’t even have CSS. So, I’m the moderator for today’s panel and Q&A. So, what we’d like to do today is chat with you about some tough questions and try and create the space with a feel of a local web development meetup.

I’d first just like to mention our sponsor. Our sponsor for the A List Apart: On Air event series is Pantheon. So, we want to extend a big thank-you to them. Pantheon provides managed hosting for Drupal and WordPress sites, so you can focus on building websites instead of fiddling around with servers and infrastructure. So, check out Pantheon.io to learn how they can fit into your projects.

So, our topic today is all about tools and workflow. So, if you take a look at the articles in many web sample applications, it can seem as if it’s just not possible to write only HTML and CSS anymore. Many of the tutorials we’re looking at assume a setup that includes a task runner, such as Grunt, and the use of a preprocessor, like Sass, and that’s a sort of standard thing. And there are obvious benefits to using these tools, and obviously they can be a really useful part of our workflow. I don’t think anyone would disagree with that.

But there’s also problems inherent in adding complexity, not least in that we make the barrier to entry far higher if people think they need all of this stuff just to get started as a web developer. So this is a big topic right now, and even today I saw some tweets on Twitter, someone saying, you know, “Do we need all of this?” And it’s a big topic right now, and there’s a number of pros and cons, so we wanted to have a chat through it.

So, we’ve got some panelists today. We have Susan Robertson. She’s a freelance front-end developer who focuses on CSS, style guides, responsive, and accessibility. She also writes for the Pastry Box and will be a speaker at Future Insights.

Lyza Danger Gardner is a developer and cofounder of mobile web startup Cloud Four, and is coauthor of the book Head First Mobile Web. She specializes in devices and browsers accessing the web globally, and is cofounder of Responsive Field Day 2015.

Jeff Lembeck is a developer at Filament Group, and a former member of the jQuery mobile team. Jeff is also a guest lecturer and TA for Ada Developers Academy, and a speaker at Cascadia Fest.

So, that’s our panelists, and I’ll be moderating, and I’ll be keeping an eye on the questions that you’re asking. And we’re going to start off with a few questions to our panel, and then in the second half we’ll take some of your questions, so the panelists will have a go answering those, too.

So, there’s a lot of discussion these days about tools to help us write code faster and more consistently. Essentially, it sounds like front-end development requires more than just HTML and CSS. But why exactly is there pushback in some circles against using tools? So, as our first question, for anyone new to this, we’re going to start with an overview of the terminology. I think there’s a lot of confusion out there about preprocessors, postprocessors, task runners.

So panelists, what exactly is a preprocessor, and what are the main benefits of using one?

Lyza Danger Gardner: I’ll take that—why not start up here? So, typically when people are using a CSS preprocessor, it allows them to do things that aren’t inherently supported by CSS directly, at least not in all the browsers that people use today. And they also help with making CSS work in different browsers. They also give you lots of handy shortcuts, and as you continue using them, can even give you sort of the ability to do some almost logical work to process your CSS against.

So usually when you’re writing something for a CSS preprocessor, you’re not writing CSS exactly. You’re writing something in that preprocessor’s domain-specific language—like Sass has a syntax that you write for. You can use preprocessors to manage variables and keep you from having to retype the same thing over and over again for consistency. So that’s one of the, er, many of the reasons that people use preprocessors—they’re handy, they help you get your job done faster.

Rachel: Cool. So, we’ve also got postprocessors. And so, what’s the difference between those or any of the other terms you might hear in this space?

[05:00]

Lyza: So, I find postprocessors very interesting, and one of the problematic things is that that terminology isn’t ironed out yet; there isn’t general consensus. But typically when I think of a postprocessor, I’m thinking that you’re writing CSS to the published specs and standards, even if those standards and specs aren’t adopted by or implemented in all the browsers that are popular out there. You’re writing CSS directly, and then a set of tools is taking that CSS and translating it into the kind of CSS that browsers understand more globally.

Another term that people use that’s starting to be intermingled with postprocessor is transpiler, which may actually be a little bit more accurate for that scenario.

Rachel: Okay, so if someone wants to get started, if we’ve got any real beginners out there that have not started using any preprocessor or postprocessor, what are the first steps that someone might take if they’re really new to this world? I think we’re going to have quite a spread of people asking questions today. Are there any good resources? Are there things that you think are a good way to get started?

Susan Robertson: I’ll take this one. So, I would say the first, best step is no matter what preprocessor… If you’re going to move into preprocessor land, which I’ll admit I’m a little more familiar with than what Lyza just explained as postprocessors or transpilers, you can actually just take your written CSS and change it to be like an SCSS file, and start very slowly. So, you could just start by using color variables. And if that’s the only thing you do, just get used to how those work and just keep your same CSS that you’ve already written, and start off with color variables.

And then as you understand more and you can kind of read more, you can move into the world of mixins, which might be something that you use in order to maybe do your fonts in REMs with a pixel fallback. If that’s interesting to you, you can move into functions for creating a grid. But I think you can just start by writing straight CSS with just one or two of the options that are available to you in a preprocessor, such as Sass.

Jeff Lembeck: To add to what Susan said there: yeah, Sass and Less, and I think every preprocessor I’ve used so far is a superset of CSS, so they just add functionality onto it. So if you’re new, you could do exactly what she just said. Like, you could write your file in just straight-up CSS and add the .SCSS extension to it, and it would still compile to the CSS that you’re looking for.

So if you’re new to it, you never, ever have to worry about, like, “Ugh, is the CSS I’ve written not domain-specific enough for this?” The preprocessors that people tend to use widely, at least any of the ones that I’ve run into, they’re all just additional syntax that you can add in.

Susan: Yeah, I think the only one that that would be hard with is if you use Stylus, since it’s white—it’s actually whitespace-based. Like, your spacing makes a huge difference. You don’t have to use any colons or semicolons or… You have to use colons, but you don’t have to use the semicolons in the brackets, so you couldn’t probably move to Stylus as easily as you could other things.

Rachel: Cool. I think most people have heard of Sass and would realize that that’s a preprocessor. But that’s not the only one out there, and I know amongst the panel there’s quite a bit of experience of different preprocessors. So how do people get started and choose which one should they use? Why might they use something other than Sass, given that that seems to have a lot of adoption?

Lyza: I’ll say something really basic: Sass was written in Ruby originally, and most people seriously deeply using Sass are using Ruby. There is a Node version, libSass, that people are starting to use, and people use it because of its performance. But it’s not where Ruby Sass is, it hasn’t caught up version-wise, although it’s making great strides. So one reason that people might choose different preprocessors is the technology stack upon which those run. So, that’s one minor thing, but I don’t think it’s the most important.

[Correction from the panelists: LibSass is almost at par with Ruby Sass. Cf. http://sass-compatibility.github.io/#stats —Ed.]

Susan: Yeah, I would say the times I’ve used Stylus is because it is more native to Node, and people are running their front-end stack on Node. So, that’s why it was chosen. But I would agree with Lyza, that that’s only one consideration to make.

[10:00]

Jeff: Yeah, the environment that you’re running it on, of course, is a first… like, “Do we want to deal with dependencies on our Node project of adding Ruby as a dependency here so we can have Sass via Compass,” which is the Ruby gem that most people use to process their Sass. So, it comes to that.

But then there’s also what the team’s familiar with. If everybody on the team knows Sass, you don’t necessarily want to have everybody have to go through the cognitive overhead of adding Less onto the project, or Stylus onto the project. You know, if there’s syntactical differences, or different ways that they write functions… if they’re big differences, then it can be a big problem, like, to get everybody up to speed quickly. So yeah, environments and experience.

Rachel: So, if someone were starting from scratch, they’re not really working with a team, maybe they’re just going to be using desktop tools, would you suggest people start with Sass? Or is there a better option for a real beginner?

Lyza: I would actually suggest starting with CSS, which I realize is sort of a “flip” thing to say. But everything we keep coming back to, there’s a baseline—everything is centered on CSS, and that’s the thing to know. So, if you’re really actually just starting out, I highly recommend really coming to understand CSS itself. [Laughs]

Susan: No, I would actually agree with Lyza. If you’re just starting to learn how to write markup and CSS, I wouldn’t use anything but straight HTML and CSS to start, and actually understand the intricacies of the cascade, and how CSS works, and what makes it the way it is. Because if you understand that, then when you move into using a preprocessor, you’ll understand what the preprocessor is doing for you.

But if you just start grabbing preprocessor functions off of some GitHub repos and things like that, and you don’t understand what they’re actually doing but it works, when it breaks you might have a really tough time. So, I think it’s better to get a good baseline in CSS and then layer on preprocessors after you have that, or postprocessing, or whatever you decide you want to do.

Rachel: Cool. So, going on with problems that people might run up against, what are the potential downsides, or the main problems that you’re seeing when people are using preprocessors? And how have you handled those kind of problems on projects?

Lyza: Well, I’ve seen Sass projects that run the gamut from one person to a Fortune 100 company—massive, massive scale—and what tends to happen when things get a little beyond what’s well-managed in the team is that… first and foremost, the thing you’ll hear quoted a lot is “nesting depth,” because Sass and other preprocessors allow you—you don’t have to write the full selector on every line; you can nest selectors within selectors within selectors.

Sometimes, especially if you’re importing other things into that Sass file you’re working in, you might already be nested, in a way. You can end up with selectors that are hundreds of characters long, and also repetitive rules for selectors, and repetitive selectors, and hyperspecificity, because as the selector grows longer, it becomes more fragile because it’s too specific. So I think that’s usually the very first thing you hear people complaining about, especially with Sass nested output.

Jeff: Yeah, what Lyza said completely… That’s always the first massive explosion in any Sass project that I’ve ever dealt with, is nesting got four or five levels deep. And then… It doesn’t matter how big your monitor is—at some point, you’re trying to go back up and going, “Okay, where is this in this file?” and then you scroll, scroll, scroll… Even that part, better yet all of the other stuff that comes along with that hyperspecificity that makes your CSS really brittle and huge, because it will just build out… A lot of that comes with the fact that Sass is, in particular, a Turing-complete language.

Like, you can write code code in there and cascading stylesheets are not really meant for that. [Laughs] And so you’re shoehorning things in, and you’ll find a lot of the time that when you give people the ability to come up with solutions for problems that don’t fully exist yet, they’ll do that as much as possible, and so I see that all the time in projects, like Sass Gone Wild all over the place, where “Really, are nested IF statements necessary here? Okay, uh…” And really clever mixins. So yeah, it’s a lot of just not knowing when to stop.

[15:00]

Lyza: Right. I think what Jeff’s hitting on is a controversy that comes up in this space of separation of concerns and kind of questioning, like, “What should you be able to do in CSS or CSS-related technology?” And for many designers who are becoming increasingly technical in Sass or in other preprocessors, their first exposure to the ability to do sort of logical manipulation of their CSS rules, and there’s a point at which, if you evaluate it, you have to answer the question, like: “Is that the appropriate place to be doing computation like that? Or is there a more appropriate way that might be different? Or are we over-obfuscating things by writing these really fantastically complex mixins that are very concise in the end but very difficult to understand what they’re doing as you share them across the team or external teams?” So, there’s that piece to the puzzle, as well.

Susan: Yeah, I would say I’ve walked into code repos where it took me a long time to understand their grid system because of the functions and the way the functions were written, and, like, it was actually very confusing. I’m fairly old-school. I do use a preprocessor, but I probably don’t use it as much as a lot of people—like, all the things I can do with it—because I just prefer to read a grid written out as I’m used to it. [Laughs] I think it’s faster, I understand what’s going on. And I think when we get too crazy with functions or mixins, I think there’s some danger there.

Lyza: I think in part, too, because it’s a fairly young situation and I don’t feel like conventions have really been established for consistency in the way that people implement certain kinds of things, as well. So, you’ll see grid systems in one way and a completely different way somewhere else, and there is that cognitive load of deciphering that and deconstructing it, for sure.

Jeff: Yeah, not to mention have you ever worked in a Sass project where the functions were unit-tested? Like… I just don’t think that they’re—I’m gonna be completely honest here, I’m not even sure that people have built a framework for that anywhere.

Lyza: Yeah, is that even possible? Like, I’ll admit, I don’t even know. [Laughs]

Jeff: And the second you start writing logic, if you don’t have a way to… Like, “Here, via some type of testing system, we have in place this that says that if it breaks, we can make a change to it here and now we won’t have that problem anymore.” How do you catch your edge cases without being super-meticulous in ways that maybe you could have just avoided, and just written some extra selectors?

Rachel: Yeah, so kind of following on from that actually: a lot of these preprocessors that we’ve discussed can do an awful lot of things. They can really let us write code in our CSS. So, which parts of our preprocessors should we kind of allow people to use within our team? And as a side of that, how do we deal with all of the dependency management issues that come up?

Lyza: So, just as the way that the deeply nested stuff tends to pop up, it’s the first issue you see—or most manifest issue you see commonly in bloated Sass output to CSS—I think one of the first things that teams ought to do is establish a nesting depth limit. It’s very straightforward and it’s easy to quantify. But that’s on a convention level, right? You’re still using the features of the preprocessor, but you’re kind of defining how you want to use them. But that’s the first thing.

Jeff: Yeah, and most projects that I’ve worked on, it always seems to be conventions along the way. You set it up at the beginning of the project, like: “Hey, if you’re going to use a mixin that has, like, functional elements to it”—you know, some type of case statement, if…else if kind of a thing—“the documentation on that better be really, really good.” And this is a thing that you should walk through with other people before you break this in and say, “Hey, this is what we’re going to be using every time we need to...”

I think my favorite example of this is Jake Archibald has an IE8-specific one that he wrote a long time ago that still gets used really, really heavily, where it makes an IE8-specific stylesheet at the end that isn’t responsive. So you can just say, “Here, media queries go into this one,” and they don’t show up in the IE8-specific one; it’s a fixed point of 1024 or whatever.

[20:00]

So, that’s it. It’s a pretty big mixin and it changes the way that you have to write things throughout the entire project. You have to sit down and set up conventions beforehand of, “Hey, we’ve all decided we want to use this. Here’s this module. Here we go.” Just going at it and adding big sweeping changes like that can get you into trouble. But some of them are really powerful and really, really useful. So, those team conventions… Really, really good.

Rachel: So, what do you feel that the benefits have been of actually using these tools in your workflow? And also, are there any differences if you’re working on your own—say, on your own projects or whatever—and when you’re working in a team? I guess we’ve touched a little bit on team working and conventions. But should people be doing a different thing if they’re alone or on a team? Are there different things people could be doing?

Susan: Well, I’ll go with the first part: the thing I love the most about using a preprocessor honestly is still the color variables—super simple, but those are the things that can get… I mean, I’ve walked into projects where there were literally a hundred different hexes for shades of gray, you know? So, those are the things that can get out of control really, really fast. So, that is still, still my favorite part of Sass, is just color variables, and thinking them through, and using them wisely. Um, now I forgot the second part of the question, so I’ll let someone else go… [Laughs]

Lyza: Yeah, you got me off on a mental tangent with the CSS color variables, because what you said about the complexity then coming back to conventions—like, at my company we actually had an internal meeting last week, an internal discussion just about CSS color variable naming, like “blue, blue-lighter, blue-lightest,” and looking at potential tools.

So, one of the things we were looking at, although we didn’t end up using it, is there’s a plugin for our PostCSS chain, a postprocessor that will map all of the CSS3 color names, like original color names that you know from CSS, to your own kind of hex so that you can continue to use things that look like CSS color names. There are so many options, and man, that is a Pandora’s box. Sorry to distract everyone! [Laughs]

Susan: No, it is. You’re right.

Rachel: Yeah, I think the second part of the question really was: “What are the differences between working on your own things and working on a team?” Would you be using these tools working alone? Would you recommend that people do? Or should they really be for team working?

Susan: So I think, like we said before, if you have a really good base of CSS, and you understand what’s going on in CSS, and it’s just you working on a side project, I say go for it and use whatever you want, because you can learn more and it can make your life easier. I mean, on my personal website—which, no one ever does anything to that code but me—I use Sass. And I use it for the little things that I’ve talked about: color variables, a couple of mixins that I really like that kind of provide some fallbacks that I don’t have to worry about, and that’s it. But it’s just me, and it still works better, and I like it; it makes it faster to work on the site.

But I think teams are using it a lot, and I think it’s great in a team setting, too. The only thing when you’re in a team setting is—you have to be pretty careful about your output; I wouldn’t version-control your output files necessarily because you can run into merge nightmares or constantly have to re-output them to get past merge issues, so… But otherwise, I’ve used it with teams over the last several years and it works great.

Lyza: I think typically, working on my own, I try to write code as if I’m writing it for a team, because you never know where things are going to end up. Having said that, it does give you the ability to choose based on your preference, and in my personal projects right now, I’m writing CSS and then tacking on PostCSS, transpiling, so I can get Autoprefixer, which is a tool that many people use to deal with vendor prefixes and little syntactical details between browsers that diverge from the specification. But that’s my personal choice: to keep it really light, really simple.

And my source is CSS, right? So, if I decide I don’t really like those tools anymore, my source is still CSS, so I don’t have that lock in to what I’m doing. But in teams, I think it’s really just a scaled version of the same thing. I just think that conventions become really important, and shared conventions, and understanding how you name things, how you structure things… But that gets bigger.

[25:00]

Really, this isn’t a logical issue when you get down to it. It’s a question about systems, and patterns, and how you’re designing your CSS systems overall, whether you’re using BEM Syntax—if you know about that—or certain kinds of Object-Oriented CSS. I think it kind of falls into that bucket, where you’re working as a team to find a solution that is this whole picture.

Rachel: Yeah. As someone who’s written a lot about CSS in the past, and obviously I teach people, and I speak at conferences and things, something I’m a little bit concerned about is that we’re creating a very complex toolchain around front-end development, and I’m kind of worried that’s creating a barrier to entry in terms of learning to create websites. Because I think most of us got in by viewing source and just playing around with CSS and HTML.

So, does the panel have any thoughts about how we ensure that what we’re doing and the work we’re publishing remains accessible to beginners?

Lyza: [Laughs] Okay, I’ll take it a little. This is very much up my alley because I spend a lot of time saying that we really need to be able to do as little as possible. Like, the future of the web, and its success, and the ability for new people to join us in building our future web really relies on the systems, processes, and details being as minimal as possible.

So, what I think is that we keep coming back to this notion that we need to continue treating CSS as the core here—CSS per spec, CSS per the way that we’ve decided as a corpus, as a group of people building the web that what CSS is—I think just needs to be maintained at the center of what we’re doing. And as we add onto that, we need to realize that we’re adding onto that. So, that gives us a place to start, like core CSS stuff, and then we’re adding these tools.

Having said that, I do agree that a lot of the documentation and things that people are talking about nowadays assume that you have a workflow, assume that you have a task runner, and I don’t immediately have a great idea about how to make that not be. I will say, on the flip side, that setting up some basic structure and getting a task runner going has become quite a bit easier. But it is still potentially a barrier to entry and understanding, so…

Rachel: Yeah. So, before we head into a Q&A, because we’ve got quite a lot of questions coming in, I just wondered: do you feel this is kind of a transitional stage? Will CSS eventually make all of this preprocessor use completely redundant? Will these things just become part of CSS?

Jeff: I think that’s the hope, right? These things were built because people found fundamental flaws in CSS itself, and where it was, and what it can do for them… Especially with something small, like Autoprefixer. If you ever have to do animations and deal with keyframes, and then have to prefix every single one of them, it adds just so much time and overhead to the whole process. And so being able to have something that simplifies all of this, and have that be a tool, is something that spec writers can look at this and go, “Well, this is popular, and this is popular for a reason. Maybe we should add this kind of functionality and see what we can do to make this work in our system.”

And that’s why I have great hope that—Lyza mentioned the postprocessors earlier—I have great hope that that kind of a thing really becomes what we move toward, is: “Hey, we’ve found the tools that we like,” or “We’ve found the new functionality that we like, here are the pieces to that that we like.” And so now they’ve been spec’d, and now we can use those, and we’ll actually be writing CSS here. We’re not writing in some other domain-specific language.

Lyza: Right. What I find really exciting about working with postprocessors and transpilers, as it were, is that because we are writing CSS per what the specs are right now, we can spot where the holes are where there’s things that we still can’t do. And what’s really happy for me is that I’m not running into a lot of those. I’m using things like custom media queries, and variables, and calc. And the transpiler process abstracts the nitty-gritty browser-level details away from me, but I don’t consider those to be the important pieces—those are the variances, those are the bugs, those are the details. But our team is able to write CSS without having any layer between us and it, and we can see how the future of CSS is and it’s really neat, because I think that there’s sort of this gradual obsolescence that can happen and should be encouraged as those things get into CSS.

[30:00]

The concern I sometimes have about preprocessors is: because you have all those tools that are specific to that preprocessor to get beyond these things, you’re not necessarily keeping the mindset of “How do we get this into CSS, or even into the CSS spec, or even know when it actually has landed?” Because you have these other alternative ways of doing it, which are abstracted away from the resultant CSS.

So, I think that—I would hope that—preprocessors and postprocessors become less necessary, and where they do exist, they’re tools for smoothing out the noise and not actually functional tools, if that makes sense.

Rachel: Okay, that’s great. We’ve got loads of questions here, so I’m going to dive into those. A lot of them are sort of relatively technical and about workflow and things, so we’ll just see how many we can get through. So, Anne Tomasevich—and I’m really sorry if I pronounce everyone’s names badly—she says, “Do you have any tips on maintaining DRY code and a sensible Sass file structure when working with a team, where multiple people are touching the files?”

Jeff: I can take this one. Breaking into modules is an incredible thing, and actually we were talking about features of Sass to use earlier. Sass’ import functionality is so, so good. Our standard structure is to just have Sass build all of our CSS, and so I’ll have one main Sass file that includes a few Sass files, and they’ll be modules and layouts, and then it’ll just hold folder structure basically, and it’ll do it throughout Sass. That has made it so Sass handles the build process; it handles if I declare a variable that’s going to be global, such as color variables that Susan was talking about earlier. If I declare that in one of my early imported files, I can use that throughout and not have to really worry about re-declaring in places, or having repetition—making sure that my code can stay DRY.

Lyza: I think two things I would add to that great list that Jeff started is that one is: keep your selector specificity fairly reasonable and constrained, because that will help you arrange your CSS a little bit more modularly and a little bit more flexibly. And also that a piece of this is with your team beforehand, determining an actual CSS design strategy in terms of what kind of approach you’re going to take to module naming. Naming things is really important, and it’s really, really hard, so having that discussed with your team before you jump into this and really discussing your approach…

I feel like even though there’s pieces of this problem that are technical in nature for sure, a lot of this comes back to design and architecture of your systems. So, really taking a little bit of time before you jump into these projects and getting on the same page with the other designers and developers about the approach you’re actually taking to your CSS structure and naming…

Susan: The only thing I would add to that is code review, code review, code review. The team I was on last fall, PRs didn’t get merged in until they got reviewed by a couple of people who were… you know. And so, everybody had to look at the code to make sure things weren’t getting out of control. And you were staying within your conventions that your team had already discussed and made happen. So, code review I think is just as important for this stuff as others, and I think code review of CSS sometimes gets lost in the shuffle, unfortunately. But it really shouldn’t.

Rachel: Cool. I think the question about dividing Sass into multiple files is something a lot of people were interested in thoughts on, so it’s great to hear some discussion on that.

Something else that’s been asked: Jay Sitter says, “What are your thoughts on Sass directory structures?” He rarely finds any discussion about that.

Lyza: I feel like, again, that might come back to more of the CSS pattern overall system design, because there’s many schools of thought, and I’m not going to answer that question because there are many schools of thought. So, I’m not going to answer it directly, like, “You should do this, you should have your variables here, your atomic pieces here, and your components here.” But I think that, at least in my experience and our experience on our team here, is that the structure of our directories is typically informed by the shape of the patterns.

[35:00]

So in our case, we typically use sort of an atomic design approach in our stuff, which breaks things down to their smallest elements, like styling a heading or styling a paragraph, and then combining them into components, and we might keep components in another directory, and then combining those into more complex… like, uh… working-together sub-elements. Ah, obviously I’m not a designer! [Laughs]

So, that’s one approach. But I think that directory structure—there is no one single thing that I would say works for everything, and it really does come down to design choices. Yeah, sorry for the wishy-washy answer…

Rachel: So, I think Susan mentioned not committing compiled CSS, and this is a question from Johanna Bates: “Committing to Git: do you commit source SCSS, compiled CSS, or both?” I don’t know if anybody else has got any thoughts on that.

Lyza: It’s a challenge, first of all. One is definitely committing source—like, that’s not a question. As to whether to commit transpiled or compiled CSS, it depends on your structure. One route that we’ve taken is that when we have our local working environment, our compiled code—you know, our working served area—is not in a version-controlled directory. It is not version controlled, but when we’re ready to release, and publish or deploy, we build that into a different directory, which is version controlled, so that we sort of have release history and we can manage that.

But managing version control across your team, when you’re working in local environments with the output-transformed CSS or other assets you have, can be very challenging. So, I don’t necessarily recommend that you version-control your working copy, as it were.

Rachel: So, Kyle Gach says: “Thoughts on BEM versus something like BassCSS or Tachyons?” So, lots of utility classes in the HTML is really the question—you know, should you be doing that? Is that a good idea?

Susan: So… I do. [Laughs] I think I probably use the least features of Sass that are available to me. So, I learned how to write CSS and got into the habit of it with Object-Oriented or SMACSS, and I still write it that way. I don’t nest at all, just because of the way I write the CSS. And the team I’m on currently, we kind of have a nesting “ban” because we all want to write it more Object-Oriented or SMACSS-type stuff.

So, I mean, I still use all those conventions because, again, it just helps me not get into the danger of over-nesting, it helps me keep my code more modular, and it helps me just… that’s what I’m used to. It’s how I work fastest, and it works for the people I work with. So yeah, I still use all of that stuff.

Rachel: Malik Dixon asks: “What is the best tool to use when using Sass?” Obviously that’s a very wide question, but perhaps the panelists could just let us know which tools they’re using and which they like and find useful.

Susan: So, with Sass, I’ve used everything since I’ve freelanced with a lot of different teams. So, I’ve been in a Rails app where it’s happening in the background and I don’t have to do a thing to compile; I’ve used Grunt and Gulp for compiling and watching; I’ve used the straight Sass command in the terminal when I’m doing down-and dirty-prototypes and I’m working on something that’s a flat file system but I want the benefits of some of the Sass stuff. I’ve also used things like Scout and CodeKit, so it just kind of depends on what flavor—how much of a GUI you want and what your comfort level is with various tools.

Lyza: My personal current favorite right now, just personally, I’m really enjoying… I use Gulp as a task runner typically; sometimes Grunt. But I run through PostCSS using CSS Next, which is a collection of CSS4 to CSS3 transpiling tools. So, basically it can write in CSS4 and what comes out the other end automatically is CSS3 that’s supported widely across browsers. I really like that. It’s really easy. It contains things like the ability to use CSS variables and those sorts of things, as well as the ever-popular Autoprefixer postprocessor, which takes care of those vendor prefixes for me. Personal pref.

[40:00]

Jeff: I basically have used Compass pretty much since I started using Sass-related things, mostly because I really, really, really like the vetted-out amount of mixins and functions that they have. And every once in a while… Like, Compass source is pretty easy to read. So, if you ever want to just dive in and take a look at what their stuff is doing and why it doesn’t work the way you think that it might, because their documentation is sometimes—well, it’s missing a lot of examples. So, it’ll have “Here’s how this method should work, blah, blah, blah,” but it doesn’t have a ton of examples. But you can just dive right into their code, and that gives a little bit of power in “I want something that does kind of what this does in Compass right now. How did they get to this? Okay, well, now I can write myself a function that works like this and talk it out with my team because I don’t want them to be like, ‘Why did you do this?’ later.” But yeah, I’ve been using Compass for as long as I’ve been using Sass.

Lyza: Another piece of my current workflow that I really like with relation to this is CSS Next gives me the ability to use the import keyword to import things that I’ve installed with as Node modules, as if they’re in the local CSS directory. Which is really sweet, because I can modularly, say, install—like, we sometimes use SUIT CSS, which is a very modular, sort of basic CSS framework—I can install that as a Node module and then import it into my local CSS as if it were local, but it’s something I don’t maintain, right? So, it’s nice to keep it abstracted away from my working copy, but I can import it using the same CSS standards intact, which is really handy.

Rachel: So, Trace Meek asks: “In a large organization, there may be a handful of people (including vendors) touching and contributing to a site's CSS. Can you offer any strategies or trainings for getting a whole organization's web teams up to speed on using SASS?”

I guess one of the issues here is where you’ve got a range of experiences within the team, and people who maybe sometimes just edit a bit of CSS. I’ve certainly been in those situations where someone’s got real control—someone owns it—but other people kind of poke into it every now again. I mean, how does that work? How does that scale?

Susan: So, I’ve been on teams where there is a range of abilities. You might have designers who feel comfortable enough to come in and make changes to padding, margins, font sizing, that type of thing. But then there are other folks who are probably doing the more down-and-dirty building the modules, making the grid system, that kind of thing.

And then, I don’t know that I have a great way to help everyone, but I think you just have to work internally with your team and make it a culture of being able to ask questions, so that the folks that are maybe not as up to speed on everything that’s going on in the CSS feel comfortable asking. Which sounds kind of, I don’t know, wishy-washy in a way, but I think that’s how people learn, is working with other people and that kind of thing.

As far as vendors coming in: in the situations I’ve been in, vendors’ stuff is always kind of excluded. [Laughs] I don’t know if that sounds right. But any CSS or stuff that’s coming in from a vendor isn’t really… That’s going to be in a different file system, or directory, or something, so that they’re not always mixing up… I’ve never had a situation where vendors had to get right into our core CSS, so I’m not sure how I would handle that, but… Like, a lot of times they’re just providing one module or something like that.

But if they’re vendors that you’re bringing in to work on your stuff and they’re going to be a part of your team for a few months and help you speed up the process of maybe a redesign or something, then they just have to learn about the conventions and conform to them like everyone else, and kind of all work together and ask questions, and you do a mini-training, I would think, on your team conventions at the beginning.

Rachel: So, Tim Arnold asks: “How have you addressed compilation slowness on larger files?” And as a second question: “Anyone know how long until libSass supports all of the SASS features?”

[45:00]

Lyza: [Laughs] I was just going to say I’ve had experiences where a Ruby-based Sass, especially with Compass, is, by two magnitudes, the slowest part of our build process—like multiple, multiple seconds, and really getting rid of the Ruby-dependency is something that we really prioritized because of that. LibSass just had a recent release, they’re making strides. But I hear you: if you’re using the advanced features of Ruby Sass, it’s disappointing because there are things that are not supported yet. But if you’re looking for performance, I think, getting off of the Ruby build of Sass and Compass is probably in your future unless, you know, something amazing happens.

[Correction from the panelists: LibSass is almost at par with Ruby Sass. Cf. http://sass-compatibility.github.io/#stats —Ed.]

Susan: And I do want to make one correction to something that was said earlier: libSass actually runs on C, not Node. So, it’s not a Node-based tool, it’s actually running on C, so… For anyone who was interested in it.

Jeff: Yeah, I think the big dream for everybody is that libSass gets up to date, and then we can just “Hey, if you use Ruby, you use Ruby with a C extension for libSass…” and Node Sass already wraps libSass, and any other language that you use at that point can use the standard of libSass, which is monumentally faster than any other thing that they’ve got out there. So, we’re all hoping that it comes fast.

Susan: Although I would say that I think the Ruby folks are working on getting things faster as well, so I don’t want to just bash Ruby Sass. They’ve done a lot for us and I think they’re working towards that, as well.

Rachel: So, Santino Valenzuela says: “When working with Sass to a number of projects, we'll come across using a plugin that uses CSS that’s not Sass files. So, do you convert those into Sass or do you just leave them as they are?” Anyone have any thoughts?

Jeff: It kind of depends on what I’m going to do with them. If I need them to be part of my build process, like if it’s important to me to have them as part of the Sass build process in any way, shape, or form, like they need to fit in certain parts because, hey, cascading style sheets overwrite pieces of one another, then I might actually convert them over to Sass.

But if it’s a module that doesn’t get touched by other stuff, then it will just go through a concatenation process. So, that’s a “meh” answer, but it kind of depends on how they’re being used and whether or not I’m going to mess with them too much.

Lyza: Yeah, on our team it often comes down to the decision of whether the code is ours or not from this point going forward. If it’s something that we’re using that is a plugin to something that we’re doing, that’s maintained or written by a third party or another vendor, typically we try not to make any changes, because as you do that it becomes yours, right?

If it’s something that we manifestly want to change, or manipulate, or work with, or integrate, then we’ll take the step of doing that conversion.

Rachel: So, Travis Lehman says: “How do you find a balance between ‘modularity’ and code bloat? So, if two people are coding two different elements with similar sub-elements, how do you make sure they're shared, and not rewritten each time?”

Susan: Well, I like style guides, so I like actually writing your elements into a style guide first, if you can. That way people can see what’s already existing and they can then use that to extend the module for their needs. Or they could realize they just need to put some classes in some markup and they already have their module. So, that would be my preference for how to make sure people aren’t writing the same thing at the same time.

If you have the time upfront—which, it does take a bit of time to kind of document a lot of the things you’re seeing in the design—then you kind of avoid that problem. But I will admit that if you’re moving fast and design is happening while code is being written, the style guide can’t always be done. But hopefully you can somehow communicate with each other about what’s happening.

[50:00]

Rachel: So, Jay Sitter says: “What do you use for documentation? And specifically, any thoughts on SassDoc?” And I think I’ve seen other questions generally about “Do you comment your mixins?” And so perhaps we could talk just a little bit about sharing documentation and comments.

Lyza: One of the approaches we take to documentation is in line with what Susan was talking about with style guides. We tend to build pattern libraries when we’re decomposing sites and creating design systems for them, so part of that pattern library is implementation of little examples of the use of those components in HTML, and part of our system that we have allows us to have metadata in those examples where we can document pretty thoroughly what it does, link to any external libraries it’s using, link to any JavaScript that may be needed to provide behavior for that.

So, we’re able to write it in prose or markdown form within the places that we’re implementing the examples. And then that is presented—it could be used by any level of technical person because you could just see it on the website that it generates. Or you could take that and use that code as you’re implementing your production site. So, that’s one way we approach documentation and usage examples.

Rachel: So, Chris Clapp asks: “What are your thoughts on how to compile?” So, he’s using CodeKit. Are people using the command line? Which tools are people using?

Susan: So, I think we might have touched on this a little bit, but I think there’s a lot of tools and I think you should use what suits you best. If you’re not comfortable in the command line, CodeKit’s great and I don’t see anything wrong with that.

A lot of teams are using Grunt or Gulp, and what’s nice about that is maybe a new team member comes down—they clone the repo and they’re good to go. Like, they just have to run maybe Grunt, or Gulp, or whatever in their terminal and boom, everything is happening for them.

But I think there’s a lot of choice out there, which means it can be a little overwhelming. But it just depends on what your comfort level is with various things.

Rachel: There’s a question here from Ivan Wilson, which says: “Isn’t this discussion, in a way, a reflection of the not-so-great state of front-end development?” [Laughs]

We’ve got a few minutes to go before we need to wrap up. It might be quite nice just to hear from the panelists as to whether you think front-end development is in a terrible state, and that’s why we’ve got all these tools and why we’re worrying about this stuff rather than looking at the core tools, and just really what your thoughts are around the ecosystem and maybe where things are going with all of this.

Jeff: So, that might be a little bit cynical. [Laughs] We have a plethora of tools to try to help people, and people will come across problems because front-end development is hard—like any kind of development, front-end development is hard, and sometimes it gets kind of pushed to the side like it’s not. But it’s difficult to do a lot of the things we need to do because we have to support so many possible ways that somebody could access our content that we’re delivering, or the modules we’re building out for people.

And so a lot of these tools that come along the way… There’s a reason why when somebody says, “What’s the best…” It becomes very, very dependent upon the project that you’re in, because there’s so many people who have built so many tools for so many reasons that a lot of them have gained steam in different ways. And I don’t know that that’s necessarily a reflection of how terrible everything is as much as how different all of the problems that we seem to come across are, because we have so many different little pieces that we need to do. And, you know, how incredibly different each project comes, from one to the next.

[55:00]

Lyza: So, I think I would maybe substitute “bad” or “broken” with “complicated,” and I think what we do is very complicated. And I think in some ways we got what we asked for. Because if you think about it, think about how fast things are making it into the technology now. We figure out things that we wish CSS did, or that we wish HTML did, or browsers did, and then people work really fast to make that happen. Meanwhile, we have so many different kinds of clients and browsers accessing the web, as Jeff alluded to, that that piece of complexity is also branching very fast, and every one of those clients has to implement these standards as they’re constantly shifting and churning underneath us.

So, what we end up with is really a large, big pile of complexity, and that’s reality, and we kind of wanted that in a way because we’re asking for all of these features in the web as a platform. And so what we’re dealing with now is a little bit of churn and transition as we try to figure out how to manage that complexity, and where the line is between managing that complexity or actually introducing new processes or new concepts. That’s why I like to try to look for that line that gives us the right kinds of tools to iron down that complexity just a bit for us so that we can spend our focus addressing and working toward those features and those things that we want to express in our end products or sites.

So, I think that’s the way I’d put it: I think it can be frustrating, it can be very detailed, it’s hard, and it requires a lot of energy to keep up with everything that’s going on. But I wouldn’t necessarily say that it’s on a negative trajectory.

Susan: I think the only thing I would add to that is you can still make a really cool thing with straight HTML, straight CSS, and vanilla JavaScript. You don’t have to use all this stuff. You don’t have to make it—if you don’t want to. I mean, you should be using tools that are helpful to you, that make your life easier, and that help you get your job done.

But the web is still the web. I mean, I think of Jeremy Keith a lot, and he talks a lot about “You can make stuff just using the plain old-fashioned tools that have been around for a long time.” And we use the tools that we’re using because they do make our life easier in some way, and they make it easier to get something out to users. But, again, you know, you don’t have to make it so complex if that’s not your thing. If you don’t want to use all this stuff, you don’t have to. It’s just one possibility in how to build for the web.

Rachel: I think that’s a really nice way to be wrapping up today. Thank you so much everyone for joining us. It’s been great to see all the questions. I think we’ve had a really good discussion on this stuff.

There will be more A List Apart events, and they will be announced on the website and in social media soon. Event #3 is already in the works, so watch out for updates. We’ll add the video of today’s panel to the site in the next couple of days, and there will also be a transcript and that will be posted early next week, so take a look out for that.

Thanks again to Pantheon for being our sponsor, and check them out at Pantheon.io.

And thank you to our panelists. Thank you Jeff, and Lyza, and Susan. And goodbye from me, Rachel Andrew. Thank you.