On YouTube
206 JSJ PostCSS with Ben Briggs

02:30 - Ben Briggs

03:03 - PostCSS

07:16 - What problems was PostCSS designed to solve for developers?

09:46 - Using PostCSS vs Sass

14:02 - Using Future Features

16:28 - Tool Fatigue

23:39 - When should people start thinking about using PostCSS?

31:24 - Postprocessing

33:43 - Shipping Apps with Emojis?

36:21 - Where does PostCSS end and where does css-modules begin?

Picks

Chet Corcos: Functional Programming for JavaScript People (Aimee)
Operation Code Scholarship (Aimee)
Web Platform Daily Digest (Ben)
Cadbury Caramel Eggs (Joe)
Hello World Podcast (Joe)
React Rally (Dave)

Special Guest: Ben Briggs.

 DAVE:

[Clears throat] mi-mi-mi-mi-mi-mi

Hey everybody and welcome to episode 206 of the JavaScript Jabber Show. Today on our panel we have Aimee Knight.

Hello.

Jamison Dance.

Hello, friends.

Joe Eames.

Hey everybody.

And I'm your host, Dave Smith. We have with us today a special guest named Ben Briggs.

[Inaudible] hi, Dave. Ah…

Ben…

I just realized it's a podcast. [Laughs]

Welcome, Ben. Would you like to tell us a little bit about yourself?

Yeah. So, I'm a freelance JavaScript developer. I've been developing for the web for about 10 years and I do client-side and server-side development. I'm probably best known for the open source work that I do. So, I wrote cssnano which is a modular CSS minifier. I also authored postcss-use which is how you can use PostCSS on CodePen and lots of other modules. You can find them on my GitHub or npm.

So, we're here today to talk a little bit about PostCSS. Can you just give us an overview of what that is?

Yeah. PostCSS is really like a toolbox of tools that you have to modify some CSS. So, we basically give you all you need to transform or analyze some CSS. But we don't actually give you any sort of opinion on how that should be done. We leave that up to you.

So, the tools that PostCSS has, it has a parser. So, the parser takes a string of CSS and basically turns it into an abstract syntax tree. And then that tree is basically a JavaScript object that has child objects inside of it. So, a very simple example if you have a CSS rule say heading one and you have a declaration inside, color blue, then PostCSS represents it as a root node which is like an invisible wrapper which is the file and then you have a rule node with the selector. Inside that rule we have the declaration. So, it has this parser for this tree.

And also with the parser you get some methods on top. So, if you need to iterate over all of the rules you can use methods like 'walk rules' which goes through all of the nodes in the actual file. And we have helper methods like append and prepend and clone and 'replace with'. So, it's like a DOM API in terms of actually being able to manipulate CSS. You have all of these methods that you can use. So, that's the syntax tree. We also have source maps support built into PostCSS. So, many CSS tools obviously you want the source maps so that the compiled CSS maps back to your development file. And then we have the stringifier. So, the stringifier takes this syntax tree and turns it back into a CSS string.

Now, the thing, what makes PostCSS really good, is the actual plugin system. So, the thing with PostCSS is that you are doing your own plugins. So, the most popular of which is autoprefixer. So, autoprefixer obviously goes into your CSS file and prefixes all of the rules that need vendor prefixes. And right now we have something like 200 plugins that you can use. And you can just load them in via the require function. And this way is quite a nice way of working with CSS because you have these plugins and you get to choose which ones you want to use in your build process. You don't have to use all of them. In fact, [chuckles] I encourage against it because there's a lot of modules that will do similar things. And it's really on the developer who wants to work out what modules are right for their project. And obviously it's going to be different depending on what your project is.

To solve some of this we have plugin packs. So, there's a plugin pack for future CSS syntax called cssnext. There's also the precss which is like a plugin pack for doing preprocessor-like tasks. And there's also lots of other plugins. So, there's a website for this, PostCSS.parts that you can go in and just have a look and just browse a list, search for plugins that you want to use. And yeah, that's PostCSS. It's quite a big thing because obviously you have this plugin system.

And it's just important to note that PostCSS doesn't actually do anything. So, in its default state if you load PostCSS via Gulp or Grunt it doesn't actually transform. Because PostCSS was meant to work with old CSS files. So, it saves as much of the whitespace and the comments and the selector hacks as it needed to, to work for autoprefixer. So, the basic goal is that we provide a oneto-one input to output. And so, PostCSS does nothing until you fill it with plugins. And that's cool.

That was a really awesome explanation of a huge thing. Can you take a step back a little bit and tell us, for someone who's not familiar with PostCSS, what problems it was designed to solve for developers?

Yeah, sure. So, PostCSS really came off the back of autoprefixer. But to understand that, we have to understand some of the context of why PostCSS was born. So, I don't know if you've ever heard of rework.

No, I haven't.

The book?

No. It was actually a Node module created by TJ Holowaychuk.

Well, that narrows it down to only half of the node modules. [Laughter]

Yeah. Right, basically so TJ created this module which is similar to PostCSS. And Andrey Sitnik the guy who actually wrote autoprefixer and PostCSS, he was using rework for a time. But he noticed that there were parts of rework that he wasn't satisfied with, one of them being that people were coming to him with CSS that was malformed. And he wanted the autoprefix that just works. So, you put in some CSS, it doesn't matter if it's missing a semicolon here or there, and that's in PostCSS is postcss-safe-parser. But for a long time it was bundled as PostCSS.

And so, Andrey really, he took the base of rework which was this components-based system for managing CSS and then made it into PostCSS. He sort of… maybe he did fork it out. I wasn't… at this point I wasn't even in the project. I've been working with PostCSS for coming up to a year now but it's been two or three years old now. So, I'm not really sure of that history behind it. But I know that it was a transition from rework to PostCSS. And PostCSS fixes a lot of the problems that rework had when we were working with autoprefixer.

So, for a time PostCSS was used by autoprefixer internally. So, instead of autoprefixer using rework as the tool behind what it was doing to add vendor prefixes, they [obviously] switched it over to PostCSS. And then it was extracted out of autoprefixer and then PostCSS was born. And it was made as a pluggable alternative to rework. I hope that answers the question

I think so.

I have maybe two questions also before we get into too much detail. So, the first question, I have two, but the first question is you sent us some great stuff to read ahead of time. And so, some people you talk about are in this article that talks about using PostCSS along with Sass. But then in one article it talks about using PostCSS as a replacement for Sass. So, you also talked about a little bit earlier how you can do some logic with it. So, why would someone still want to use Sass and why would someone maybe just want to use PostCSS?

That's quite a hard question.

Because basically Sass is a different way of solving the same problem that PostCSS tries to solve. It just tackles it in a different way. So, if you think about when Sass was first coming out and people had this vendor prefix issue, they would get some mixin library or they'd write a mixin library to handle vendor prefixes. So, to have the autoprefixer functionality you would write a mixin to do it. PostCSS doesn't have this syntax on top of it. It just parsers structures that are like CSS. So, the interface for autoprefixer is that it just operates on a declaration. Because CSS is a declarative language, autoprefixer just works on that. And you can do the same in Sass. But with Sass you're using their own scripting language called SassScript. So, it's just a really different way of solving the same problem, I think. Because you can do a lot with Sass.

I was looking… actually even today, I came across this module called Sassdash and it's basically Lodash but in Sass. And there's some really cool things that you can do with SassScript. And for those people who have that use case of they want to have functional concepts in their style sheets then I think Sass is still the best tool for that. PostCSS takes it in a different direction because we say that we don't want these structures in our CSS. A lot of popular PostCSS don't have this kind of syntax. Autoprefixer is a good example. But there's also a grid system called Lost. Now the Lost Grid system basically, it defines some extra CSS properties. They all start with Lost. The getting started example on their readme is just a diff with a lost colon property and lost colon one-third. And then that compiles into five div [inaudible] which are basically how you would implement a grid system in CSS. But obviously you don't have to write that because the grid system generates that for you. And that's just using existing declarative CSS to output. So, it's a different way of thinking about it.

So, Sass likes to keep logic inside your style sheets. Whereas PostCSS plugins like to take logic out of your style sheet and instead you have JavaScript manipulating the CSS behind the scenes to get the desired output. So, I think there's still a place where people can use both Sass and PostCSS together. Maybe if you use stuff like the syntax sugar if you use something like… I know there are some people that write PostCSS plugins actually trying to emulate stuff from Sass. But I don't really think it's the best way forward, because obviously Sass has got its own variable state machine. And when you have that across plugins it doesn't really make sense [inaudible]. So, I think Sass is still the best tool for that. But who's to say that that possibility might come to PostCSS in the future? We don't know. I just know that me personally, I prefer that [inaudible] structures.

Hopefully that maybe answered your question.

It did. And I have another question that relates to that. So, one thing that I thought was really, really cool about PostCSS is its ability to allow you to use future features that might be coming out. So, I

was kind of thinking of it like a Babel for my CSS. Do you want to talk about that a little bit?

Yeah. So, that is a module called cssnext. And basically that contains a lot of the future CSS features that are going to appear in CSS. And we're talking about things like the var function. So, you can define a root selector with all of the custom variables in there and then reference them in declarations. Now the thing with this is it has to be scoped to the root because that's how it works. You can't actually emulate some of the behavior using a polyfill because it wouldn't' work for that like a JavaScript runtime. But you can polyfill a lot of the CSS features just statically. There's another one for the calc function. So, if you have simple math which you need to… obviously older browsers don't support the calc function but if you have a simple expression then it can be calculated. And so, there's a lot of CSS or future CSS that can be statically compiled into existing

CSS. And there's a whole load of features on the website CSSNext.io. And cssnext is just a PostCSS plugin. So, if you want this feature in your style sheet you can load it. The idea of cssnext is that it is a module that will lose features over time as browsers add support for all of these new features then they will be removed from cssnext. And also cssnext is both about doing the future features and also compatibility for old browsers. So, cssnext actually includes autoprefixer along with other things. It used to include cssnano for a time. But it's been trimmed back. It's now on GitHub on postcss-cssnext which is a bit of a mouthful. But the general principle is still the same, that you have the plugin that is specifically focused on just future CSS syntax.

So, I have a question that's a bit of a change of direction. It's about how PostCSS fits into the larger JavaScript ecosystem and I'm trying to think of another way besides JavaScript fatigue but that's kind of what it is. [Chuckles] Like the…

Oh, yeah.

You have eight million different choices of different tools and ways to plug things together and you can customize things just infinitely. And that time that you spend customizing things is time you don't spend getting stuff done. And it seems like PostCSS is another tool that is very powerful and can offer you a lot of flexibility. But also is just another thing to setup. How do you offer the power that PostCSS offers without driving people crazy or making them just frustrated with one more tool to set up?

That's a good question. It is quite hard to do this. Going back on that point about cssnext becoming postcss-cssnext, it was just cssnext for a time on GitHub where you could get cssnext as a tool and use it as a standalone tool. So, it had a command line wrapper. It had Gulp, Grunt, Broccoli, all of these wrappers, so that it could integrate into a build system. And for a time that was good. Now, I think what people are realizing is that it's like the Grunt versus Gulp argument. So, the whole reason why Gulp was created was because of this expensive file system write. So, you would run some plugin, you'd write to disk. You'd run some other plugin, write to disk. And then Gulp came along and said, right, well we can get rid of those intermediate disk writes and we can do all of this stuff in memory. And what PostCSS offers is the opportunity to consolidate all of your CSS processing steps into one single plugin.

Now, I can appreciate that obviously we have 200 or so PostCSS plugins now. So, for people that maybe are fatigued then that's probably not going to save you from a whole lot, the fact that you might have to go through the plugin list and pick out plugins that are suitable. But you can start with a couple. You could just start with maybe just autoprefixer. See how it worked for you. The nice thing about PostCSS is once you have it there in your build then you can start adding in plugins that work with that CSS. So, today I might load in autoprefixer. Oh, it works really good. Now I can look on the PostCSS website. Oh, there's another plugin I want to try. And you can sort of build it up that way.

It's like Babel in a way I suppose, because Babel went from version 5 where everything was built-in to version 6 where you had to configure everything. And for a time people thought, “Oh, well I'm going to stick with 5 because it's got everything I need and I don't need Babel 6.” But configuration files came out for Babel 6 and lots of documentation came out. And actually, it wasn't that difficult to upgrade. And they had some [inaudible] problems with Babel but they got all of those ironed out. And we ended up with a much nicer system. I think these pluggable systems are a lot nicer. Once you have them in there doing their stuff, it's very easy to add plugins to them.

And I always found, I sort of started with Grunt, Grunt 0.4 when it came out. And I just liked going to the Grunt plugin website and just doing a search for CSS. What tools can I use to use on my CSS? How can I make it smaller? How can I do various things with it? And that organic discovery is something that I really like about a plugin ecosystem. And I think it's worked well for Babel. It's worked well for Grunt. It's worked well for Gulp. And I think it's working well for PostCSS. We hit something like one and a half million downloads the other month. So, we must be doing something right.

So, I want to ask a related question here.

Sure.

Since we're already on the topic of tool fatigue, what's your overall opinion of the entire tool fatigue topic and where PostCSS fits within this? I know it's really related to what you've already answered but I'm just interested in your holistic opinion as well.

Sure. Well, I think people are fatigued by the amount of configuration. And I tend to think of this as a documentation problem and not a code probably. I think that this modular way of developing tools for working with CSS is a lot stronger than what we were doing before. So, before we had a pluggable system like PostCSS you would have a Gulp plugin for every transform that you'd want to do. And then you would have this thing where you would be parsing and stringifying and parsing and stringifying each time you loaded a plugin. So, in terms of it being modular I think that that's actually a good thing.

In terms of where it sits in configuration PostCSS is more like a Babel type deal than something that you can easily drop into something and it just works. Tools where you just drop in a module into your build process and then it just works and it has a nice default configuration and you don't have to worry about all of these extra modules that you put in, I think it is worth the extra effort. But PostCSS is definitely on the side of you need to go and get a configuration. And we're working on adjusting that.

Recently we released PostCSS.org. PostCSS.org is going to be one place where you can get information on PostCSS, PostCSS plugins, and at the moment it's just a landing page. But we've gone for so long just having a GitHub repository that having a website, a proper website, was a really exciting thing for us. And I think, I really do think that this problem is a documentation problem. And that people that are fatigued should be able to go to a website or at least ask in the chat room. We have a chat room so anyone can come over and say, “Hey, I'm completely lost. I don't understand what PostCSS is. I don't know how to configure it.” They can go in the chat and say these things and we'll help them. But failing that, I think having a website with all of this documentation, initial setup, recipes, would be really good.

So, we're working on that. That's a pipeline thing. You know what developers are like for documentation. It takes a backseat a lot of the time. Because they like [chuckles]… we like writing code. But I do think it's a really important consideration to make.

Another somewhat related question here. Let's say that you're a developer and you're building a project, where on the scale of how much care, attention you're going to pay to your CSS, does PostCSS start offering enough value? Like if I'm just building a simple project then I'm just going to maybe drop in Bootstrap.

Mmhmm.

Maybe PostCSS doesn't make sense for me. So, where on that scale does PostCSS start making sense for people? When should they be thinking to themselves, “Hey, for this project I should probably start looking at this if I haven't looked at this before”?

Right. So, I don't know because I've not used Bootstrap for a while. But does Bootstrap still provide vendor prefixes in the compiled files that you know of?

I'm not sure, but I believe it does.

Right. Well, if it doesn't then that is a number one reason to use PostCSS anyway. But even if it does, let's just say you're using a version of Bootstrap that's very old. Autoprefixer can actually remove vendor prefixes from files too. So, it is very much a developer convenience that you have this tool that is there for managing prefixes. I think it's one of those… it's like an organic tool. Autoprefixer has a little time capsule in it which basically at some point, it will detect that there's no need for vendor prefixes in your file and it will tell you to remove it from your build. And maybe a few years down the line, we don't need to use vendor prefixes anymore and autoprefixer is not necessary. I think transforming CSS really does depend on what use cases you have for it. So, vendor prefixes is a big one. But PostCSS has lots more use cases than that.

One of the things that people maybe don't talk about so much with PostCSS because primarily it seems like it's a transform tool is analysis plugins. And there's a really fantastic linter tool call stylelint. And stylelint is like ESLint for your CSS. And if you're using PostCSS with stylelint then why not chuck in some extra plugins that are going to improve your CSS workflow? I've already talked about the Lost Grid which I think is really good. It means that you don't have to maintain a

grid system. Even in a small application you're going to want things like grid systems. You've already talked about Bootstrap but you can think about maybe adding in your own and trying it out. But I think yeah, so stylelint is a very big value add that allows you to lint pretty much everything now. There are about a hundred rules, stylelint.io. And it's another…

Is it customizable?

Yes. So, it basically takes a configuration file. It's like ESLint in that way. So, you can actually publish your configuration to npm with ESLint. And I think you can do the same with stylelint. And yeah, so… and if stylelint doesn't provide you with the exact linting setup that you want, then you can actually plug stylelint itself. So, you can create your own rules for stylelint and stylelint will pick them up. You just write a JavaScript function if you have the [inaudible] to do so I suppose.

Right. And I think you've given a really great answer to that question. And maybe my scenario wasn't a great one because probably what's more likely is you're working on a project and you've just been handwriting CSS, the designer's been handwriting CSS, and you've got whatever, you've got a whole bunch of handwritten CSS and you've been thinking to yourself, “Maybe we should look at a preprocessor or maybe we should look at PostCSS or maybe we just haven't quite had the time yet.” That idea of where is it really going to start paying off for me to look at one of these tools, I think is a good question…

Yeah.

A lot of viewers might end up asking themselves after listening to an episode like this. It's, “I've got a project that's kind of like this. Will I really find value in this? Or will I spend a lot of time looking at it and in the end feel like it just doesn't quite have the payoff for me to spend a bunch of time setting it up?”

Yeah. I can get that. It's hard for me to answer that kind of question because if you find that, and PostCSS as I say is a couple of hundred plugins, if you find that there's nothing that PostCSS offers you in that plugin list, then you shouldn't really be using PostCSS. But there are so many things that it offers you to transform CSS in different ways. For example, one of the plugins that I was having a look at the other day and I'm so gutted that I haven't had the opportunity to use this plugin because I just thought it was so cool. It's called RTLCSS. Basically the idea is that you have a website that's left to right. And then for people that don't read from left to right, they read from right to left, obviously they expect the site should be mirrored. And that's what RTLCSS does. It doesn't just convert direction LTR to direction RTL. It has a whole range of properties that it can transform just as background, border, clear, cursor, floats, transform text shadow, and padding and margin. Though it handles a lot of what conversion that you would have to do.

Say your boss said, “Hey, we get you some sales in this country and they don't read from left to right, they read from right to left,” how do you do that? If you're handwriting your CSS you probably have to make an override style sheet and copy all the selectors in and then search and replace float left and replace it with float right. And the advantage of RTLCSS is that you put in your CSS file and it flips it. And it's a PostCSS plugin. And that's just one of the examples of how you can use PostCSS as something that not only can modify things like vendor prefixes but it can also take a whole style sheet and mirror it.

There's also Brian Holt made a module called postcss-colorblind. And basically what this is like is it's running your website through a color blindness filter. How would you do that before PostCSS? Well, what you might do is you might get a screenshot of your website and then get it into Photoshop. And maybe you have overlays but different colorblindness. And this plugin says you don't need to do that. You load the plugin in and it would transform your live website with all of the new colors so that you can see, “Hey, that contrast is really bad for those users.” And quickly, because you can chain all of these modules together, you can be debugging your website for colorblind users that are reading from right to left, right? So, there are lots of different use cases that it enables. But it really depends on you and what you have. I've not had the chance to use RTLCSS. I think it's a really cool project. But I haven't had he users to do that for. I'm just waiting for that opportunity.

One thing I'd like to talk about, I don't know if you've ever heard the term post-processing. But for a time that was what PostCSS was known for. And we sort of changed the meaning from that whole post-processing thing. It's really more than CSS. It's like how we have rock in post-rock. It's like PostCSS is like you can do more with CSS.

[So] like modern and postmodern?

Yeah, sort of, yeah.

Ah.

Beyond CSS.

Yeah. Right. And I wanted to put this out there because I thought people might be interested. I wrote a… basically it's a code block formatter for PostCSS. Because PostCSS can actually pass things that aren't CSS into this AST. And it can output things that aren't CSS. So, basically you can load in custom parsers and custom stringifiers. And so, I wrote this thing. It's called Midas. The link is MidasJS.com. And it basically takes CSS and wraps span text around all the tokens. And I wrote that for basically I wanted some really nice code blocks for the cssnano website. And I was looking at Highlight.js at the time and it doesn't handle minified code very well. That was just an idea of PostCSS can do quite a lot with CSS.

We also have a LESS parser and a Sass parser. Now, they don't actually convert. So, it's basically if you wanted to add a PostCSS step to a Sass file before you sent it out. Basically, if you have a theme file and you wanted vendor prefixes but you wanted the variables to be intact, you'd use one of these things. One of the things we get quite a lot is that, does postcss-scss compile SCSS to CSS. The answer is no, it doesn't. So, that's just something to bear in mind. But yeah, so we do offer those custom parsers and custom stringifiers. I think there's a lot of unexplored territory around that. And that was my idea with Midas was to make something that was sort of working with CSS but it's actually working with HTML text.

I saw a nifty demo on the Twitters a month or two back by somebody. And they had set up I think they were using PostCSS for, well the thing it's most frequently used for which is prefixing all of your rules with these randomly generated id's. But instead of id's he had used emojis.

Oh really?

Yeah. So, I wanted to ask you about that. Like is that legit? Can I start shipping apps with emojis in my DOM?

Yes. [Chuckles]

I answer that tentatively because I don't really know. Because basically PostCSS parses CSS-like structures. So, it parses things that maybe aren't specification CSS. But you can also convert those to actual CSS. So, there was an example. Lots of the fun PostCSS plugins, there's a fun category in the plugin list, and lots of people have made postcss-australian-stylesheets and postcsscanadian-stylesheets. So, it's about making those properties, turning them from maybe a Canadian version of a certain property into the actual American spelling.

Oh, so like S instead of Z and things like that? Or do you mean…

Right, yeah.

Adding a suffix of 'eh' to everything? [Laughter]

Alright that was [inaudible] Canadian joke.

[Laughs] Well, they have postcss-spiffing which is basically a reimplementation of the Spiffing module.

What is that?

And basically that's British English properties. You can write color with a U and then it will be translated to color without the U. and things like important becomes please instead. So, you can do things that are…

Oh, that's awesome.

Yeah.

It's not quite CSS, but…

Yeah.

PostCSS can transform that into something that the browser understands. In terms of emoji, I'm not really sure. I think at least the Unicode symbols are valid identifiers…

Yeah.

In JavaScript.

Oh, yeah.

I'm not sure why it wouldn't be in CSS. That's pretty cool. But you wouldn't need PostCSS to do something like that.

But it might be…

[Inaudible] quite cool.

I'm sorry. Go ahead.

I was thinking it might be quite cool if you…

Oh, it looked really cool.

Yeah.

He had a screenshot of the DOM inspector and it was very colorful.

Yeah.

[Laughs] That's awesome.

Yeah, I was impressed. Now I'm wondering if it was fake since you're like, “I don't know about that.” [Laughs] Anyway.

It's not something I've looked into. But I'm sure it's…

Yeah. So, my team is using PostCSS at work and they love it. It's fantastic. But one of the questions that we often find ourselves scratching our heads is where does PostCSS end and CSS modules begin? To us, those are one and the same but I suspect there actually is an interface between them or something. Can you describe that for us?

Yeah. So, PostCSS actually has a plugin for CSS modules. It's called postcss-modules. And basically this takes the output from CSS modules and puts it back into PostCSS. And…

And so, is the CSS modules like a separate project completely?

Yes. So, I think it started off as a PostCSS plugin. But now if you go to the GitHub link cssmodules/css-modules then it defines really a spec for implementing CSS modules. So yeah, so there's a separate PostCSS plugin. And I know that obviously there's ways to do this in React. So, you have a React class which is actually using CSS modules. But there's a lot of overlap between CSS modules and PostCSS. All PostCSS is doing really is transforming class names. So, if you look at the example of postcss-modules, you have input styles and you have the [composer's] rules which are then compiled into actual extending from selectors. And then you have the global selectors which don't have these class names on them. And then you get a JSON object back with all of the class name mappings. So then, you can use those mappings in, say you wanted to use them with Handlebars templates or any, like Jade or anything like that, you could do so. There's obviously more integrated ways, things like React. But I think that's right. Andrey was talking about CSS modules in his dotCSS talk. I don't think he went into it very much in detail. But it is something that is definitely going to be something to look at. It's very important not having CSS applied to everything in a global way, but having…

Yeah.

Yeah.

Would you say that's the number one reason people use PostCSS?

I'm not sure, to be honest. I don't have downloads on postcss-modules. But I'm sure that people use PostCSS for a lot of different use cases. And that must be one of them, because…

Yeah.

Yeah. I think [inaudible]…

But my team loves it.

Yeah. That's awesome.

They're huge fans. Because we've been through several iterations over the years of trying to basically solve the same problem of how to scope your CSS so that you don't have too much specificity or hard to refactor styles or leaky styles. And so, we've been through BEM, we've been through csstyle. And finally PostCSS is the one where we're all like, “Okay, this one's going to stick.” [Chuckles]

Yeah.

Really, CSS modules specifically.

If you want to use CSS modules you don't absolutely have to use PostCSS. But it's one of the ways in which you can use PostCSS. If you just think of PostCSS as a way to just transform CSS or analyze it and then you can fill that with whatever you want on top, really.

Yeah, sure.

I hope that covers that.

Alright. Let's go to picks. Aimee, what are your picks this week?

my first pick, if you follow me on Twitter you probably already know this but I found a really good article this weekend. It's called 'Functional Programming for JavaScript People'. And I just thought it was really… I will say, and it says this in the article, it's not a quick read. So, be prepared to learn a lot. But at the same time I felt it was pretty approachable. So, that is my first pick. I'll put a link in.

that if you are a veteran Operation Code which I am helping with has partnered with an online bootcamp called Launch School. So, you can apply. I'll put a link in the show notes. But you can apply to go to this online bootcamp for free. So, [inaudible] for veterans. I would… also, if you are a spouse of a veteran or potentially spouse of active duty, I would say go ahead and apply as well and feel free to reach out to me if for some reason they say anything about that, because I think that that's also very important.

So, those are the two picks for me. And that's it.

Ben, what are your picks?

I just have one pick. So, I visit this website every weekday. It's called Web Platform Daily. It's WebPlatformDaily.org. And it's basically this curated list where you can see all of the daily news from folks in the web community. And it's really, really good. I highly recommend that. And it only takes a couple of minutes just to sort of read it. There's links to Twitter conversations or tools or just lots of cool stuff. So, that's a good one, Web Platform Daily.

Cool. Joe, what are your picks?

Oh, alrighty then. I think I'm going to go with two picks today. Pick number one is Cadbury Caramel Eggs. Not cream eggs.

Ooh.

Caramel.

Ah.

Caramel. In fact, just to show you how much I enjoy this pick, I'm going to let you listen to me…

Oh boy.

Unwrap and eat one.

It's like an unboxing.

Yeah. Can you hear it? Can you hear it? [Wrapper sounds]

I've got to clean up a little bit, maybe.

Mmm.

I'm putting it right next to the mic so you can hear it being unwrapped. It is…

Nice.

So delicious.

This is the tackiest thing we've ever done. [Laughter]

And that's saying a lot. That's really saying a lot. [Laughter]

And my second pick is going to be the Hello World Podcast. Shawn Wildermuth interviews developers and talks about how they got into programming. And last night I attended a live recording.

Cool.

Live recording because it wasn't live broadcasting but was recorded while people were alive. [Laughter]

Just like JavaScript Jabber.

Yeah. Just like this show. [Laughter]

We've never done a dead recording.

We've never, never ever done one. But he had Merrick Christensen, Utah's own Merrick Christensen who has an amazingly awesome story. So, go check out the episode on Merrick Christensen on how he got into programming.

Local celebrity and hero.

Yes, absolutely. And that's my picks.

Great. My pick for you today is one pick. I'd like to pick React Rally coming back to Salt Lake City August 25th and 26th. I just want you to know I'm not affiliated with this conference in any way other than friendship. Jamison Dance, our very own panelist, is one of the co-organizers along with Matt Zabriskie. And I have seen a few of the announcements. And it is looking to be an awesome conference this year. Early bird tickets are going on sale. Let's see here. Soon. [Laughter]

And you better be [inaudible].

Write that date in your calendar, folks.

Yes. Pencil in early bird tickets going on sale soon for React Rally. This is a community-organized conference. They've already announced a couple of speakers. It looks like it's going to be really great. They've learned a lot from last year and I think it's going to be really awesome. So, you are definitely going to want to get your tickets during the early bird. Don't pay full price like a schlub. So, React Rally coming to Salt Lake City August 25th and 26th. That's a great time of year to visit. The grass is brown. The skies are clear. That's a Thursday and a Friday. So, I'm excited. I think it's going to be really slick. That's all I have for you. So, that's it for our show.