Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about frontend Web design and development. I'm Dave Rupert. With me is Chris Coyier.

Chris Coyier: Yeah! Yeah! Heck, yes! That's where we're at in this world. You know we're right in the middle of a series about modern JavaScript, in a way. We talked to Henry about Babel, and we talked to @seldo -- [Laughter] -- about--

Dave: Yeah, Laurie.

Chris: Laurie about NPM stuff. In a way, they were maintainer episodes because these people are responsible for big JavaScript ecosystem things. That's what we plan to talk to more of. We had a little scheduling snafu, and it's just Dave and I this week, but don't worry; there's going to be many more names coming at you from the modern JavaScript ecosystem.

Dave: It turns out it's hard to do a podcast when your guest loses their voice.

Chris: Yes.

Dave: [Laughter] And so, you have to reschedule.

Chris: This was for you, dear audience, because we--

Dave: Yeah.

Chris: A high audio quality show has been shown to be ten times more listen-to-able and just a more pleasant experience.

Dave: 10x engagement, yeah.

Chris: 10x engagement, I'd say.

Dave: [Laughter]

Chris: But we'll have people from major JavaScript libraries like, oh, React, View, Next, Svelte, Lit, and all kinds of people coming on. Not necessarily promises there because there can be more scheduling snafus, but there is a little preview for you of people that we're planning to talk to about this world.

In a way [laughter], that JavaScript half of the divide. I've started to not regret calling my post, I posted recently, called The Great Divide because I feel like some people are kind of starting to point to it in a way that says, "Chris is saying there's a divide in front-end development, and he's drawing a line in the sand and saying you're either on this side or you're on this side." I can see that interpretation if you just look surface level and just say, "Oh, what's the title of that post?"

Dave: If you read the first paragraph, yes.

Chris: Yeah, because the first paragraph really draws a line on half, but I drew that because of our experience on this show and lots of different experiences, really, of people that feel that way, not necessarily that I'm declaring that it should be that way. You know what I mean?

Dave: No. I mean I think what I found -- the criticism, I want to take in criticism. I think there were some valid things about it. But your post is basically [laughter] 10 or 12 people saying, "It feels like there's a huge divide. It feels like there's a huge divide." And so, it's weird to claim a fallacy that people are saying there's a huge divide. [Laughter] That's sort of the thesis of your whole post.

Chris: Well, now it's starting to get funny in the post because there are 100 comments on the post that are saying, "Thank you for validating how it feels to me at this workplace," or, "I'm hiring and this is the situation," or this fellow at Google that's like, "This is how we think of it at Google, and we have different career paths for them that have the same pay rate."

Dave: Yeah, Google literally has--

Chris: You're like, "Well, that's interesting."

Dave: Yeah. Google literally divides it.

Chris: Yeah, there is evidence that this is out here that isn't just me trying to sever these community. I hope that's not the case.

I try not to take it too personally because of one person that points as, "Oh, you're stirring up fake controversy." There's 99 that say, "No, this is helpful and accurate and it's stirring up conversations at my work, in my Slack, in my friend groups, and stuff like that." That's what I'm happy about.

Anyway, we wanted to be like, well, if anything, this show, in the 300-and-some episodes that it existed, it probably talks more about the non-JavaScript side. I don't know if that's quite fair, but maybe just because we're old.

Dave: This was something I think kind of made the series. I think we kind of realized, or I did at least, I think, if I were to err on one side of this divide.

Well, let me back it up. I think, as we are recording this series, Think Like a Front-end Developer series, and you were putting together your talk, I think we kind of had a conversation here, like, you know, what's wild is I'm starting to see this divided skillset. I think Brad Frost summed it up very perfectly. There's a front of the front-end a back of the front-end.

That was unprompted, [laughter] and Brad just gave us that line. I definitely liked that, and I started thinking about our show. I was thinking, like, oh, if we err on one side it's probably that front of the front-end, the more design.

Chris: It probably is, and maybe there's a good niche to that, in a way. I feel like maybe if all you care about or your interest in front-end is that JavaScript-focused side but, even podcast-wide, you're probably listening to more Wes Voss than you are Dave Rupert, or you're listening to JS Jabber, JS Party, Front-End Happy Hour, or whatever. There are plenty of more podcasts that seem to be more firmly rooted in that world. Not that they don't talk about the whole spectrum, but it's just like--I don't know--just kind of the way it is.

Dave: No, I think they err on that side of things. I think that's fair to say.

Chris: But we wanted to make sure that we address it because it's not that we don't live in that world, too. I mean I literally write React code with a react router and CSS and JS and trying to figure out SSR. I could live in that world, too, probably just as much as any other world. I feel kind of well suited to cross the divide because sometimes I'll be like, "I'm going to work on CSS-Tricks, which is an old school WordPress site with Sass and jQuery."

I don't know. Not that I don't bring anything modern to the party, but it feels like an old-school-ish stack at this point. Then I move over to another code base that's a super new cool stack. Then I'm sitting here spinning up this 11ty site because I have a little idea that I'm trying to come to fruition there, so I'm working on this JavaScript powered static site generator thing that might end up on Netlify or something. I have feet in all these different places, and it's like, I feel like I live all the way across this divide.

Dave: Yeah.

Chris: Hopefully, I can be a bridge across this divide, you know.

Dave: Well, and that's why I felt like, you know, I guess our interests, need, and what we do aren't fully represented on the podcast. Like you're saying, you work on a React app every day. Last year, I worked on a React app, an Angular app, and a View app all in the same year, and a legacy Java app and--I don't even know--a static site generator, Jekyll. I do all that, like, you know, Craft, CMS, which is awesome.

Chris: We ain't trying to brag here. We're just saying that we get the whole spectrum and hopefully can bring some of that, you know, when it's necessary, a kind of old guard approach to things when necessary, right?

[Laughter]

Dave: Yeah, I do declare.

[Laughter]

Dave: Hey. You guys have been putting me on the sidelines. I do declare that is a crime against humanity. I do have opinions on this subject.

Chris: Anyway, we're going to dig way more into that in future episodes of just getting way more into the JavaScript stuff, because we enjoy that too, before we move on to another series.

Dave: Yeah. I wanted to do this JavaScript thing. Let's balance the force, you know. Let's see. Let's go deep and just see what's happening in JavaScript-landia, JS-landia, and explore that space because it's a huge, huge space.

Just like what Laurie was saying last week. This is huge; 11 million--whatever--NPM users, 800,000 packages, almost 900,000. That's wild. That's a huge ecosystem.

Chris: Here's one that we started almost pre-show. We were just jabbing on while I was trying to find a power plug or something. It was kind of about, like, maybe it would be fun for me and you to talk about CSS and JS or what's happening to styling in the world today because it crosses the divide and it's part of the JavaScript world. It's part of the CSS world. It's very much a part of this landscape. Maybe let's just dig into it a little bit.

Dave: Yeah. What's weird is how -- I mean we're kind of peak-CSS and JS drama right now. Hopefully, it tapers off but, every Monday, something different happens. [Laughter] Usually, it's Saturday. I think people get bored and tweet.

[Laughter]

Chris: What is it with weekends and drama? Yeah, it's something.

Dave: Just trying to be funny on the weekend and then you just--I don't know--threw a match on some gasoline and, whoops.

Chris: Whoops.

Dave: Yeah, so I think right now it's a big debate. We were talking, and maybe we need to set the stage. I think there are a few. There are always some snark on both sides of the fence.

Chris: Well, what's hard is if you say the words CSS and JS and then just start the conversation there. The conversation, I feel like it's screwed from the beginning because it kind of means something, but it kind of doesn't. There's so much nuance in that world of, "Oh, yeah? Which tool? How are you using that tool? What are you using that tool for? that is necessary to lay out before you can say that this is good or bad. When I say good or bad, I mean good for the Web bad, bad for the Web bad, good for your project bad, good for performance bad, or good for browsers bad?

Dave: There's a lot of mischaracterizations and misunderstandings, willful misunderstandings on both side. But what's interesting is that your post, The Great Divide, was nothing about CSS and JS, I don't think. [Laughter] Maybe one part of it was. It's very emblematic of the issue, isn't it? It's very connected at the root.

Chris: It does. That's why I'm happy that we can talk about it now a little bit.

I think I did mention it, only in the case of, like, I was looking at what happened in front-end development articles, some of which were extremely good, well researched, and I felt right at home reading them and being like, "Wow, they're right. These were the big moments in front-end design," but were all JavaScript-focused. It wasn't like, "Oh and, in the world of Web design, these were patterns that we saw emerge," or, "These were what the hot conversations in accessibility were about this year because this landscape changed."

It just wasn't any of that stuff at all, and that's fine. It's not the fault of that article. CSS would make the list, but an actual new CSS property or something would not.

Dave: Yeah. Yeah, no, I mean it's like GitConnected, the post by Trey Huffine. It's a recap of front-end development in 2018. It's 100% JavaScript. I don't even think it mentions CSS Grid coming to Ubiquity. [Laughter]

It's not even prescribing this is what's going to be hot in 2019, but it's just kind of like CSS and JS took off, and stuff like that. It's at that point for me when these things are saying they're taking off, I'm kind of like, okay, well, maybe now is the time I check it out.

Back when we had Jed on in 2015, I maybe dismissed it or was not fully onboard with the CSS and JS train. But maybe now is the time to relook at it and just see what its advantages and disadvantages are.

Chris: Yeah. Well, okay. That's one place we could start is advantages and disadvantages. Here's another place to start that's closer to just the modern JavaScript ecosystem. I feel like when it's talked about, it's talked about in the context of React only because there are other major libraries like View and Angular who both, you don't decide. It's just kind of like, if you want to do it there are built in methods for doing it. Because that's true, that's what everybody uses.

Dave: Yeah.

Chris: I don't think you use Emotion and View together, for example. You don't. You just use a view file and you use style. You use style scope, probably, if you want the scoping in View, and that's that. It's like a solved thing for you, in a way.

Dave: It goes into your template. Yeah. No, I mean I did see you tweet that. [Laughter] It was just like, View doesn't have this problem. [Laughter] Basically, because it's like they just made a decision, an architecture decision, and you don't choose which library you want. It's just handled by View, you know.

Chris: Yep. Yep, and so, okay, well, let's talk React then for a moment. Then the landscape opens wide open because I think that's part of the reason of React's success is that they didn't mandate what other tools you use. It's just a small library for components. Then the stack that you build around it is on new.

If you need state management, you pick from this slew of state management tools. Do you need routing? You pick from this slew of routing tools? Do you need a styling solution? You can pick from this ecosystem of styling solutions.

There were fights and ups and downs. Which one is better than the other one? That still hasn't shaken out yet, I've so learned. I did this video with Dustin Schau. He was giving a me a tour of all this stuff, and I've looked it into it because we were having these conversations at CodePen. The big winner, it feels like, or if you look at stats and stuff, the highest used one, the one that's probably talked about the most is one called Styled Components.

Dave: Yeah. Yeah.

Chris: That one is kind of a big deal. What's interesting about it, and what piqued my interested at one point was the fact that it uses this thing called Tagged Template Literals.

Dave: Mm-hmm.

Chris: Or it can, optionally, use Tag Template Literals as the style, which is kind of like backticks are template literals where it's nice. It's almost like a pre-tag or something in JavaScript.

Dave: Yeah. It's like a native JavaScript feature.

Chris: Yeah.

Dave: Where you use the backtick, which is connected to….

Chris: Wonderful for templating, you know.

Dave: Yeah, and then you do dollar sign, curly brace, whatever variable, and it echoes….

Chris: Yeah, I prefer to use quotes in there. It's very nice. I'm sure a lot of people understand the beauty and power of template literals. There is this weird sub-feature of them where you can put a word or something before the template.

Dave: Yeah, almost like a class and so it behaves.

Chris: It calls it a function.

Dave: Yeah.

Chris: Then it takes that template literal and it passes the value of it to that function and returns something. Styled Components makes use of that with their styled function. What you put in the template literal is quite literally just CSS. You're like, "Oh, nice!" because I think in the early days of styling libraries, you think, "Well, now I've got to do all my styling as camel cased weirdness."

That feels weird. That feels extraordinarily -- like if you're trying to point at something and say, "That's exclusionary," to people that are already comfortable in this CSS land to have to say, "Not only do you have to write your styles over here in JavaScript, but you have to write them in this totally different way that's JSON-like, not CSS-like," so This template literal thing is kind of cool that they did that.

Now, I've heard that some people don't like that on purpose because, the second you're in template literal land, you've kind of lost some of the other power of CSS and JS. Some people quite literally pick a CSS and JSS library because you have this power of JavaScript within your styles. You can write ternary operators and little functions that do stuff. You can harness the language of JavaScript to process and return values and stuff.

Dave: Yeah.

Chris: That's easier to do.

Dave: --response to state, you know.

Chris: Right.

Dave: I mean, you know. I don't know. If something is new, you want to make it green or something. The impact is not a big deal.

Chris: Yeah, or active or not active is the common state related thing.

Dave: Yeah.

Chris: That stuff is kind of cool, but I don't know. I feel like maybe I'm in my early days of this, but kind of less attracted to that because you can just do that with classes anyway. It's not that big of a deal.

Dave: Yeah. Yeah, I mean I see the appeal. But, yeah, it's also kind of a solved thing. [Laughter] You can just do class.active or something.

Chris: Yeah, so Styled Components, and then one big desire is that not always do you want to declare this big block of styles for this component and that's that. That's just what this component is styled as. Sometimes you want to have the option of doing a little bit of inline styling really quickly on one little sub-element. I think that's one of the things that Emotion did really well, but then Styled Components picked it up. Now, it seems like kind of a little war for the top between Styled Components and Emotion in React land.

Dave: Mm-hmm.

Chris: But while I was looking at this, I'm like, this is so neat because -- okay, let me take this on another tangent. Another thing that I really want as a CSS author, and I can even look back on CSS-Tricks and point to this article many, many years ago where I think I called it Style Injection is for Winners, or something.

[Laughter]

Chris: I just saw a tweet by Una the other day who said, like, "Remember when live reload was so hot? It was like the hottest thing."

Dave: [Laughter] So hot.

Chris: You'd turn on live reload and it would watch your CSS files and then, as you edit them, the styles would just kind of appear in the browser.

Dave: You had install a separate app on your machine.

[Laughter]

Chris: Yeah. That's kind of how CodePen works, right? You just type styles and they just appear in your document. That was such a strong concept to me. I'm like, "I need this. This is no longer optional for me. I feel like it doubles my effectiveness as a developer to have these kind of like, as soon as you type styles being reflected as I'm authoring. Every time I have to work without that, I'm just like, this is unacceptable.

I'll spend half the day. I feel like Abe Lincoln or whatever. Doesn't he have a quote that's like, "I'd spend half my day sharpening my ax," or whatever, "before I cut down a tree." Don't use a dull ax. I don't know. That was a terrible slaughtering of that quote, I'm sure.

Dave: No. I think it was Abe Lincoln or Ben Franklin who said that.

Chris: One of the two.

Dave: [Laughter]

Chris: I would sit there and figure out how to get my style injection situation going. These days, a lot of times people use Browsersync. That's a pretty good one for that that has that kind of ability. I find that I have one particular stack on my machine that when I spin up Gulp, which spins up BrowserStack and stuff, it's slowsville. It was probably just the stack. It's not just that those tools are inherently slow, but I was very much looking forward to getting rid of that.

Now, oh, man, I'm in React land, React and Webpack, and they have this newfangled thing, the new version of Style Injection, which is this Hot Module Reloading. I'm sure you've used that.

Dave: Yeah, and that's where, if I change my whatever, my product card--

Chris: Yeah.

Dave: --React component, it will automatically reinject that module, like that JavaScript.

Chris: It's incredible. It's like HTML injection and JavaScript injection because you can change your TWIC handlers and all that stuff.

Dave: I didn't even know how you do that. [Laughter] I don't understand how you do that.

Chris: It's like anything you change.

Dave: How do you inject something and then unbind everything else and then….

Chris: It's incredible. I have no idea how it works. It's just amazing. It's like everything on your page is a little iFrame that just gets a command-R on it, but it's even cleaner and faster than that. Anyway, there is some cool voodoo going on there to do that.

Once you've worked with HMR, as they called it, you can't go back. It's amazing! To bring your styles into that, I know this is 100% developer convenience, but I can see that being a hook, a fishhook, you know, like, "I need this."

These libraries work great with HMR. Now I'm back to that level where I'm changing padding 0.5 REM to 1.25 REM and it's just there. You know it's that great styling experience brought to you by Hot Module Reloading. That's not good enough of a reason to just ship it out to a whole product, I think, because that's what makes me think about this Jeremey Keith framing of, like, when you choose technology, sometimes it has a user-facing issue and sometimes it doesn't.

Dave: Cost, right? Yeah.

Chris: Sass was always a great example of that because it's kind of like, to some degree, you can screw up your Sass. You can extend something that you shouldn't have extended and it creates this crazy style sheet that you didn't intend. But, for the most part, people use Sass just as a developer convenience to author style sheets that are largely like they would have written it themselves, but just with variable conveniences, nesting, important, and just kind of simple stuff that CSS developers really, really like.

What gets shipped to these is just a CSS file. It's not really user-facing, really. But when you pick a library like React or something, maybe that's great for speed or whatever, but that's a choice that very much goes to the browser. Your users are going to be affected by that technology choice.

Dave: Yeah. That's, I think, an attempt to diffuse the conversation, right? People try to be like, "Oh, whatever, man. Just use whatever makes you happy. Git 'er done." You know? Which I think I have a tweet from yesterday that said that. [Laughter]

I understand the need to diffuse it because everyone is at each other's throats--

Chris: Yeah.

Dave: --about like, "Oh, you're doing it the wrong way. You sinned," you know. [Laughter] You're like, "Whoa!"

Chris: Yeah. Unfortunately, because this type of quote can be misconstrued in this day and age, but there really are problems on both sides. If you're too, like, "Nothing matters. Do whatever," that's not helpful either.

Dave: Yeah, I don't think that. I don't. I think that's a misrepresentation of it. I think Jeremy's line of, like, "Does that artifact impact the user?" is pretty good. What did Mina Markham say…?

Chris: Yeah, but I don't want to set this up to say that just because you've picked React, that's bad. That could be very good. React is extremely fast at doing the things that it does, in a way, but you have to be smart about what you do and stuff.

Dave: Yeah.

Chris: To bring this back to CSS and JS, it means that the way that styles are injected onto the page is different now. Way back when we did our panel ages ago, [laughter] we used to just kind of almost just straight up call them inline styles.

Dave: Yeah, yeah.

Chris: At the time, it was kind of like that's how they made their way into the DOM was literally inline styles. That hasn't been true for a while. None of the libraries do that anymore, like just actually put a style attribute on the thing. That's not how it's done.

Dave: I wonder how much that has impacted the perception of it. Does that make sense? Like the first draft of it. I even went back, and I listened to that episode because I was like, "How did I feel about it back then?"

I maybe even said it in an episode, but my general feeling is I want it to blow up in somebody else's face before it blows up in mine. [Laughter] I think we're past that point now. We now know more about it. You know what I mean?

Chris: Yeah.

Dave: Than we did.

Chris: Even still, it hasn't shaken out entirely yet. For example, one way that these libraries can work is that it looks at the styles that it needs. They're ones that you've authored. It figures out what is needed based on the components that are being used and stuff. It grabs all those styles, and it just drops them into the head of your document in a style tag.

Dave: Style tag.

Chris: Yep.

Dave: Injected into the top.

Chris: Right.

Dave: At run time, so you're using CPU on the device.

Chris: You are, yeah.

Dave: Or I guess you could statically generate it like, whatever, a React DOM string or whatever, so Gatsby or something would do that for you.

Chris: Mm-hmm.

Dave: You could just print out a style tag. I think that's fair. If it's done on the server, I think that's fair.

Chris: It's done on the server, it's usually not. I think you have to kind of -- if you want it to work totally SSR, you need to--

Dave: Quite a bit of work….

Chris: Now I have to admit that my knowledge here has plenty of gaps here, but you can use this thing called the Extract Text plugin. I'm not sure which versions of this works or not, but it's like a Webpack thing, I think, that gets it ready; gets all those styles ready so that you can use it with SSR. But I would think a lot of people don't. They just ship it with their bundle. When that component renders on the screen, it dynamically injects those styles into the head as that component is being rendered.

Dave: Unless I'm being paid Facebook bucks, I'm not going to refactor my app just to support the server side render. [Laughter] Developers are lazy.

Chris: Yeah. Hopefully that stuff gets easier, and I think it has in some ways. I don't think it's totally an insurmountable task to get SSR rendering with this stuff.

Dave: Sure.

Chris: But you give up some of it, too, because, with SSR, it doesn't always know exactly what's on the screen because you have to teach it or something, or you just dump all your styles there, which then gives up the idea that this is efficient, in a way. Imagine if all your styles in your whole app -- this part, I admit, appeals to me highly -- all the styles are really tightly coupled to their components so that, if that component isn't being used anymore, those styles aren't being used anymore either. There's no dead CSS because it's all tightly matched.

I kind of like that because you hear problems all the time of people being, you know, "Our CSS just grows and grows and grows, and people are afraid of it. They don't know what to change. They're afraid if they do change something, they knock a stool over in another bar," all that stuff.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by Ride Home. The Techmeme Ride Home podcast, actually. If you search in your podcast app for Ride Home, you'll find it right at the top of the list.

You're probably aware of Techmeme.com. It's a great place for returning to several times a day to find out what you've missed in the world of tech. What they're doing on the podcast is just taking what Techmeme is good at and distilling it into podcast form; the same news headlines, context, and conversation around what happened today in the world of tech.

They've got daily shows Monday through Friday posting around 5:00 p.m. eastern each afternoon. Each episode is 15 to 20 minutes long and it's got the top stories from Techmeme.com.

Like I said at the start, please search your podcast app for Ride Home and subscribe to the Techmeme Ride Home podcast. Our thanks to them for sponsoring this episode of ShopTalk Show.

[Banjo music]

Dave: Could we talk about this? I think this is the scope styles portion. [Laughter]

Chris: Maybe, yeah.

Dave: Or the critical CSS. I think this is great. I think it very much was the trend, you know, like, "Inline styles are bad." That's the Web standards mantra. I think that was a reaction to how we used to have to style with font attributes and BG color attributes, which is kind of weird.

Chris: Yeah, they were mad because they weren't reusable in any way. There was no abstraction to them whatsoever.

Dave: There was no abstraction and so, I think, your first pass, you probably pulled all those out and you put them in a little style tag. Then it was like, no, you've got to pull all the style tags throughout your whole site and put them into a style sheet.

I think that's still good. It can be reused, cached, and everything for the next subsequent pages and things like that. I think that's good, but I also found myself, if I'm writing a one-off module like the Download Our App component or something on a page, I'll just do inline style block because why not, right? I don't have Sass. That's maybe the downside.

Chris: Yeah….

Dave: But you can write a style tag inline and it's fine. HTML is like, "Yeah, do that. I'll figure it out." It maybe block render as the page goes down and maybe now it has to recalc a paint or something if you change something.

Chris: Yeah, but it's two properties on a thing. It's not that big of a deal.

Dave: Right. I'm kind of like maybe that is a happy medium there. But these CSS and JS frameworks, that thing where you can have component level styles and they're scoped and isolated, I think that's awesome. That's actually the only thing I care about [laughter], taking all of the CSS and JS….

Chris: It feels like they're going to last longer too. You make this little component where the styles are really isolated into itself. You know that there's not a lot of other global CSS happening on the page anywhere either because you're moving towards this having less global styles.

Not none either. I think that's a distinction too is that you still can have and probably should have some global helper type of stuff available to you like, I want to set font family. I don't want it in my 35 or 200 components on the site. I don't want to set font family lobster or whatever because I want that being used all over my site. There's still stuff that can cascade through, but it's like little sizing stuff and internal component stuff that is important. I think those two concepts can live together okay.

Dave: I worked on an Angular project this summer. Bootstrap, I think, is what they were using before we came in, and so we melted that down. [Laughter] Then they were also doing things in the component level, too, and that was frustrating because I had to go into the component. Then I had to go to the global. It was a little frustrating. Eventually, I got things into the component and it felt really good, but then another component kind of needed the same treatment, you know?

Chris: Mm-hmm.

Dave: It was like, oh, now I can class reuse, and so I pulled it back out into the global. It feels like there's a song and dance, right?

Chris: There's an interesting question there, right? How do you deal with that kind of shared thing without totally giving up and going -- giving up maybe not the right word, but going global with that style? I would think that some really heavy CSS and JS users would be like, "Well, that's where you start leveraging the power of JavaScript. You can literally write a function. That function returns a little chunk of styling information. Then you call that function in two places. Now you have….

Dave: …mix in kind of thing.

Chris: Yeah, but it doesn't even need a language abstraction. It's just JavaScript, as they say.

Dave: Yeah, well, that gets me to, I think, Ben Frain said it, "You kind of have two choices: total isolation or total abstraction," I think was his kind of point of view.

Chris: Mm-hmm.

Dave: Which stinks because I want this middle ground. But, in some ways, he's probably right. You probably save. You take a consequence, like you have no abstraction if you do all isolated, but you eliminate all those other headaches, you know? I think that's also, too, the whole entire kind of debate, I think, is around, oh, the C in CSS has messed up the cascade, or whatever. [Laughter]

Chris: Uh--

Dave: There's a strategy around it.

Chris: What's funny is that even when you use these libraries, you could still use cascading within the component, which I've been doing quite a bit of.

Dave: It's true. Yeah, you could set up your type….

Chris: I'd like to enter stage left, as kind of an--I don't know--older one, maybe, but it was very compelling to me and it ended up being a major choice that we've made is to use one called CSS Modules. Have you seen that one?

Dave: Yeah, and I hear it chucked around, but I need a better understanding on what CSS modules is.

Chris: One that was surprising to me that I don't know how you would come across this information other than just being around this ecosystem a lot more than I am, I guess, is that CSS Modules is just baked into Webpack. It's just there.

Dave: Okay.

Chris: It's just a part of it anyway. You don't have to -- it has its own repo and stuff, but you don't have to specially install it for some reason. It just works in Webpack land.

Again, this is pretty unique to React because all these other libraries already have that kind of stuff, but I imagine that then means preact2. You can definitely use CSS Modules outside of any framework at all but imagine a React component because so many people work in that land, as I do.

At the top of a component, you're importing React from React. You're importing whatever else, your GraphQL stuff or who knows, and you're importing your own other components. You need a subcomponent in this component, you import that component. We're familiar with, at the top of a component, just importing all kinds of stuff.

With the way CSS Modules works is you import a style sheet also. It could be Sass, so you could say, "Important styles from card.scss." That card.scss file is sitting right next to card.js kind of Angular style, I think.

Dave: Okay. Yeah, Angular.

Chris: That appeals to me folder structure-wise, immediately. What gets imported then is an object of styles. In that card.scss file, you've written, like, .root or .card, if you want to; .card, and then you can even write Sass in there with mix-ins and all the full scope of Sass if you want to, or it could just be CSS or less or whatever.

In the component then when you want to apply, you have a div class name equals card, right? You want the class name of card because that's what you've written in your style sheet is .card. You're matching the two. That's how CSS and HTML work.

You don't just put card on there. In your curly brackets you say styles.card because it's this object of styles that you've written in your style sheet. And so, now you're importing your styles and you're referencing the class name through this object. But what happens in the DOM is that that class name gets obfuscated to gibberish, but it doesn't have to be total gibberish. It can be a string that you configure, so it can tell you what file name it came from, what component it's a part of, and then maybe some gibberish characters just for good measure, kind of thing.

Even if you're in the dev tools and you're looking at it, one, it's source maps compatible so it'll tell you source maps where that style was and exactly what file it is, so that's cool, with line numbers and all that. But also, just the class name itself will tell you where that style is. It's not totally indecipherable, which is kind of cool.

Now, you've got the isolation down. Now you have this component which has this class name that's been intentionally obfuscated so, while I'm authoring just this component, I can use class names that feel very natural just to the component. I can use .header and it's fine. It's not going to conflict with some other component's .header.

If I don't even want to come up with a name, I'll call it .root because I just don't want to even think of a name for it, so it's .root. That's what the component is at the top and the div that wraps this component has styles.root on it, or whatever.

It works great with hot modular reloading also, and it naturally works. The encouraged use of it is just to tell it to then figure out, through Webpack or whatever, extra all those styles and actually make a .css file out of it that you link up on the page. What you ship to the user is much like with Sass or whatever. It's just a style sheet. It's just a regular old style sheet.

If Jeremey Keith were looking at this, he might say, "Well, I see you get the scope style of it. It doesn't really impact the user because it's just a style sheet like any other style sheet."

Dave: Right.

Chris: Some people might be like, "Well, I can't. I still can't look at those styles. They're indecipherable to me. They're computer-generated gibberish. It ruins view source." There are all kinds of other conversations to have here.

To me, that checked all the boxes. I was like, "Wow, this is really powerful. I can still keep in Sass. I can couple my components and my styles. I get hot module reloading. I get all the stuff that I want. It doesn't seem like it's exclusionary or bad for the Web or anything.

Dave: Do you get source maps?

Chris: Yeah, yeah, yeah.

Dave: Is this source mappable?

Chris: I mentioned that a little earlier, but yeah, it's absolutely source mappable, so you're looking in dev tools, and the class names themselves will tell you good stuff but, also, it'll just have the line number in the file and jump you right there.

Dave: Okay, but the output is like robo classes.

Chris: Yeah, but remember the robo classes that are configurable, in a way. You can say, what do I want in those robo classes that's useful to me?

Dave: Okay. Okay. Okay. Okay. I mean, yeah, I think this would check a lot of boxes for me too.

Chris: That felt like a pitch for CSS Modules. It did work for me, but I don't -- you know.

Dave: What are the downsides? Why is this not the thing or why is it coupled with something else?

Chris: Well, part of it is that it's not really like CSS and JS. I can harness none of the powers of JavaScript with this, really.

Dave: Oh, okay. Okay.

Chris: Because it's just a .css file that I'm authoring, I can't do my ternary operator stuff or my state management stuff in there, really.

Dave: Okay. Okay.

Chris: It's just obfuscating class names.

Dave: CSS has been run through the same machine as your JavaScript. Can I use this on my legacy Java app, or does it only work in my React or my front-end?

Chris: I think its APIs are pretty abstract. You can do this with just a .js file sitting there that you don't even use Webpack on or anything. I think its APIs are that generic, you know.

There's a post. Robin Rendle wrote about it on CSS-Tricks way back when, when I totally kind of didn't get it. I looked at his demo and was like, you have to then -- because what you need is to put that obfuscated class name both in your CSS and in your HTML. You need a developer-y convenient way to do that.

In his demo, he would template all the HTML in JavaScript, but just raw JavaScript, not JSX or anything. I was like, I'm not going to do that. That's not enough. I can't just all of a sudden start templating all my HTML in just vanilla JavaScript. It's just not going to happen.

Dave: Right. Yeah, I guess that would be the thing. Right, you can't. You'd have to -- your DOM would have to be generated by JavaScript and probably some framework, right?

Chris: I don't know the whole ecosystem. There's probably a Gulp plugin that processes your HTML to have those classes in it. There are probably multiple ways you can use this. It's probably not entirely scoped to React. But, as we learned from Laurie's episode, React is absolutely massive and dominates these discussions, in a way.

Anyway, I think CSS Modules is pretty darn cool in that way. It feels like if the conversation is like, well, there are all these CSS people out there, and it's a little dangerous to rip that tool away from them and say, "All styling is now done in this totally other file and this other format, and you've got to spin up this different system to use it and stuff," some of that is true, but some of that sticks with, well, it's just CSS. There is literally no difference.

As I say there's literally no difference, there are a few extra little, tiny, little, weird things that CSS Modules adds to your CSS. You have this colon global thing that you can do if you want to say, "Hey, I want this. I specifically don't want you to mess with the classes in this block. Just leave them alone, please," you can use that global block or whatever.

Dave: Okay.

Chris: It's also worth noting it only messes with class names. If you write this .root block or something that ultimately gets obfuscated, you could write within that block in your Sass. You could say, oh, right pointy arrow header, so I'm selecting the header within this root. It's not going to obfuscate header. That just stays alone. You know? That's what I mean. You're still kind of using the cascade within the block.

Dave: Mm-hmm.

Chris: It only messes with class names, not IDs.

Dave: I think this is what Angular does.

Chris: Hmm?

Dave: I think this is what Angular does behind the scenes.

Chris: Maybe it just uses CSS Modules. It could.

Dave: Yeah, I think it would because you can do a Sass file and stuff like that, and that's all kind of bundled in the component. I guess for some things, like my legacy Java app or whatever, how do I get this in there? I don't see the pathway.

Chris: Oh, yeah, I can't. I have no idea.

Dave: It seems like so far and so foreign. I wonder if, even like a WordPress site. I'm not adding a whole front-end JS framework to run my WordPress. It seems like overkill, you know.

Chris: As much as I like this, I can't bring this idea to my WordPress site. It's not going to happen unless Timber supported it or some kind of view layer abstraction to it because you need that. You need to bring an abstraction.

Dave: That's what some of the framing and the bigger discussion at large is where I get a little uncomfortable or a little frustrated with. People are like, "Duh, Chris. We're not all making WordPress, you [explicit] dinosaur."

It's like, well, I make my money making WordPress. [Laughter] What can I do? I can't just drop my moneymaker and switch to some framework. That's where it gets uncomfortable to me.

Chris: Yeah.

Dave: I think somebody -- Rachel Andrew had a really good post. A couple of people have some really good threads and posts, but Rachel Andrew had a post about CSS being an entry point, which I really liked. Some people have pointed out, like, to some degree there is a lot of privilege in this, like, "Ooh, you work on a modern framework. That's awesome. That's a cool piece of privilege."

Not to say that but, at some point, it becomes, "Oh, you don't see the light on this? You're a dummy." Maybe I'm projecting or something here, but that's sort of what I feel like it is, or, "You don't have this so, therefore, you're a dinosaur." It's like, well, no.

Chris: These conversations are so hard, right? I don't think you can read Rachel's post and disagree with most of it in there. She's saying it's very powerful to sit down with somebody who has no idea how to make websites and, with it, with two files, an HTML file and a CSS file, show them how they can make a totally legit little website for something, their turtle hobby or whatever. That's extremely empowering and it's going to stay that way for a long time.

Where do you change that "Hello, World" of Web design? You can't throw that baby out with the bathwater, or whatever. I don't think I would sit down with someone for the first day and be like, "All right. Spin up your text editor and type NPM and NIT. We're going to pull in React. We're going to pull in your CSS loader and your SCSS loader because CSS Modules needs the SCSS loader before the CSS loader. Anyway, don't worry about that. We'll talk about it later. And we need to configure a Webpack to be hot module reloader ready."

All that stuff is cool. In fact, I have a folder on my desktop right here, Dave, that I did that on because I was so into this little idea of CSS Modules, but I was doing it in the context of a super large application that I was like, what does it look like to install just a "Hello, World" of this stuff? I struggled my way through it, and I got it. Maybe I'll do a screencast on it because it was kind of fun to do.

Dave: How big is that folder? Please tell me. [Laughter]

Chris: Well, I'll tell you.

Dave: Right click and tell me how big this thing is. [Laughter]

Chris: Actually, maybe I could do that. Let me find it quick. Here we go.

[Banjo music]

Chris Enns: Hey, Shop-o-maniacs. Chris, the editor, here, not Chris Coyier in Andre the Giant mode. Just wanted to let you know this episode has been sponsored by WordPress.com. if you're a regular listener of the podcast, you're well aware of what WordPress is, the CMS. What you may not be as familiar with is WordPress.com hosting. With it, you can create a robust website, blog, or combination of both, your personal blog, your portfolio, a business site, sell stuff even. It's all up to you.

They've got plans for any budget. You start it free and you can upgrade for advanced customization, security, and SEO tools and, of course, custom domains to carve out your own space on the Web and manage it right from WordPress.com.

They're mobile friendly, of course, and you get fast, friendly support from their team of happiness engineers that are standing by. Those happiness engineers are available 24/7 via email and the community forums. For anyone with a paid plan, happiness engineers are available via live chat for real-time assistance.

With WordPress.com, you can get a site built in minutes. They host your site, register your domain, offer built-in plugins including automated software updates and security. You can choose from hundreds of beautiful designs and customize them for your business site, blog, or portfolio. If you purchased a WordPress theme elsewhere, that's not a problem either. On the WordPress.com business plan, you can install any theme you'd like.

If you're not ready to register your own domain for your site yet, they have a whole bunch of free subdomains with a .blog address like mollys.food.blog or advice.tech.blog. You get those for free with your WordPress.com site. Then, of course, at any time, you can register a domain and assign that to your website and you'll have that as well.

You can check out all the details that I've mentioned here and more over at WordPress.com. Pricing starts at $4 a month if you're going with a paid plan, $4 American and $6 Canadian for the Canadian folks out there. The rest of the world, of course, if you can visit WordPress.com/pricing, you'll see where your pricing lies.

Thanks to WordPress.com for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: You know Mr. Flavio Copes had an article about this where he was kind of--

Dave: Poo-poo-ing this behavior, this form of shaming. [Laughter]

Chris: He was because it's going to be a couple hundred megabytes, Dave, and then we're all going to have a good laugh, you know.

Dave: Ooh!

[Laughter]

Chris: But it's not like that goes to production. Why is it say, "Folder zero bytes"? There are six items in here, including a whole node modules folder. It's not zero bytes, you stupid computer.

Dave: Hmm. You optimized it. Well done.

Chris: Oh, here, it's calculating the size on just the node modules. It's going to be very big, but it's like -- oh, it's only 95 megabytes. That's still a lot of megabytes.

Dave: Okay for "Hello, World." [Laughter] It gets me every time. It's a good joke every time.

Chris: You know what is funny is when you empty your trash. I don't know what emptying your trash is like on Windows, but it takes a hot minute when you do that thing because it's always like--

Dave: Oh, yeah.

Chris: It's hundreds of thousands of files that get deleted.

Dave: Oh, in Windows, you get the graph of files deleting. [Laughter]

Chris: Oh, cool.

Dave: There's like a runtime graph. It's great. But, yeah, when Rachel talks about the entry point, I'm definitely like, that's what I don't want to lose, like on the view sort, on keeping it simple.

There are some snarky people who would be like, "I just created an index.html file. You can still do it." That's true, but can you get paid to do that? [Laughter]

Chris: Well, remember how education evolved? I feel like curriculum started to be like, you know when Sass got really big it was, "Well, curriculum starts with -- still, we'll start with an index.html file and add a CSS file. We'll work and work and work until there's a point at which the styling just gets a little too much for just a single CSS file. Then, in the curriculum, we'll talk about what the jump to Sass does for us."

There might be curriculum that starts to evolve that says, "We can continue to start simple, but we'll pick that point at which the complication is just too much and we're going to jump away from it and look at other solutions." Like if I was teaching and a blog was supposed to be out output. I'd be like, "Well, we'll still start in HTML and CSS," because, remember, these people know nothing when they walk in the door, and they're coming in the door by the thousands at these boot camps.

You've got to start somewhere. I've seen people start with Git. I've seen people start with node. There are interesting starting points. But if I was doing this literally today, I probably would still start with an HTML file in CSS because I feel like that's so empowering.

But then I'd be like, well, by the time we're writing our second blog post, I'd tell the class, "Oh, my developer alarm bells are already going off here. I feel like we need a little more abstraction to make this more useful for us." This is our excuse to have CMS day at class and we're going to talk about why this is good because we don't then have to create 30 .html files. We can create a template for that HTML file and then a database fills in the blanks with the content. I think people would understand that because it's kind of a natural leap.

With this stuff, too, there comes a point at which there's a natural leap to needing this type of abstraction. You could show a really complicated site where we could be like, "Look. Look. Doesn't this look complicated?" Go to some--I don't know--ESPN.com or something and look at that. They have charts, they have table graphs, they have big article and small articles, and very complicated header pieces that are open or closed, models, and payment methods. It's just complicated, right?

Can you imagine trying to write all that CSS globally? I'm sure that they can do it and maybe they have done it, but it's so nice sometimes to scope down that thinking to just one little component and then piece together those components and feel like it was a better way to go.

I used to know this guy who built components for skyscrapers. Skyscrapers aren't built holistically. They're built in little parts and then they're craned in together and bolted together. That's kind of a metaphor for how websites can kind of be built, in a way. You can kind of make little parts, crane them in, and bolt them together.

There's more conversation. There's cohesivity problems and communication problems that might happen there. Of course, there's going to be. There are always problems. [Laughter]

Dave: Yeah.

Chris: All right.

Dave: Yeah, yeah.

Chris: That was a lot of talking. Sorry. Have you shipped any? Have you looked at these or avoided? Are you a BEM is good enough kind of guy?

Dave: You know, again, I am very comfortable with CSS, and so, to some degree, I don't have the problems that people are describing. I try to understand what's happening in CSS and write the minimal amount that I need to do to fix something or whatever. I don't just copy/paste; change the ID. [Laughter]

I think, in systems, and I guess I get paid to overhaul large companies' systems, so I'm very comfortable doing that. I think I'm not -- I don't know. I hate to be like, it's a flash in the pan. [Laughter] It solves some problems but, I think, when I read these blog posts it's like, I kind of don't have those problems when it's like, "Oh, robo classes because naming stinks." It's like, well, I kind of don't have that problem and I'm kind of fine to keep it readable. Actually, I think we were talking before the show, but that would be a hard thing for me to give up.

Chris: Yeah. How many sites do you think have that problem? That can be a part of this discussion, too, is that sometimes the discussion is dominated by people that work at huge sites that really do have that problem and, thus, it's okay that they talk about it, but they need to scope that conversation down to, "This is how we do it, this is why we do it, and this is what works and what doesn't for us," rather than day one of a boot camp wouldn't be CSS Modules. It's just not -- the scope of the problem is different.

Dave: Well, one of the reasons or one of the common citations about why you use CSS, JS, or anything is because of scale or whatever. Man, I've got to be honest. [Laughter] This is really crass, but you could picture me in the background doing the largest jackoff pantomime in the whole entire world because that means nothing. You know what I mean? People will cite scale and it's like, oh, looking at it, it kind of just looks like a WordPress. They're like, yeah, scale; it's got a database. You're like, um, okay.

Chris: Yeah, I think people cite scale a little too quickly.

Dave: People cite scale a little too quickly. Facebook, 900,000 developers pilfering your data, yeah, maybe it does need some sort of really terse, rigid system.

Maybe you're a startup, let's say, and you're explosive growth-ing or trying to do that, or you just got funding and you're going to hire 30 people in the next and you don't want to reexplain, like do the brown bag for how the CSS works.

Chris: Well, this is a good point, too, that it's not necessarily scale, but it's that anybody can jump into this code base and see there is a 1:1 between the component and the styles. I don't have to spelunk around and worry about global styles. I know that anything I change in the style isn't going to have unintended consequences. I think that can kind of be part of the story too. Even if you don't need the scale, if you're in a high turnover business for example, I think there is a rigidity to the styles when done in this way that can be appealing to know that, if nobody touches this for five years, it's going to be fine.

Dave: Yeah. Yeah, and I think I like that too. I think I understand that concern. Unfortunately, it's just always like, you know, scale. You just don't have scale, so you don't get it, man - or whatever.

It's like, we need to establish what scale means or what you're trying to optimize for. That, to me, and again, back to my whole thing. I kind of only care about this component level scope styling, which, ideally, scope styling would have made it out of Web standards ten years ago.

Chris: Isn't that normal that some people look at Sass and be like, "I only care about these few features of Sass." People can look at these libraries and be like, "You only care about the scoping, in a way."

Dave: Yeah.

Somebody else could not necessarily care about scoping, but care about something else. I found it funny in looking at what people want out of CSS that that was actually pretty low. People aren't asking for scoping from CSS itself.

If you ask the world, "What do you want out of CSS?" you're going to get a million answers and there are going to be some themes that emerge, like container queries and stuff like that. But not scoping.

Dave: Still want it.

Chris: Nobody asked for scoping.

Dave: [Laughter] I still want it. I still want it. Yeah.

Chris: All right. I want it too.

Dave: Yeah, I mean this is the whole issue. You have scoping and CSS variables, which I would say they're almost to ubiquity. IE11 is the problem child there. It's like we're really close to having these things native in browsers and stuff like that.

I don't know. I wish blog posts about CSS and JS would at least acknowledge scope styles solves this problem. It's just, unfortunately, not through Web standards yet. Or scope styles without the shadow DOM would be kind of cool, you know, [laughter] because there are some artifacts from that too. It's not just all fun and games. Yeah.

Chris: You know it's a guilty pleasure of mine is to look at people's little projects and see what they did for styles. I was looking at some 11ty sites because I have my little 11ty site I'm working on. I looked up Wilto's food blog. He does this little thing.

I was like, I've got to know how Matt Machey does styles these days, you know. It's just like style.css. [Laughter] It's just a chunk.

I look at Dave's. I look at your accessibility nutrition cards. I'm like, there isn't even a CSS file in here. You just wrote a chunk of styles. It's like 80 lines of generously white spaced regular CSS and it just does this thing.

I know it's just a one-pager, so maybe you'd have to give up on that if it got more complicated, but it's fascinating to go on GitHub, look at somebody's project, and be like, "Where are they styles in this project? What are people doing here?"

I think you see a lot of Sass, still, you know, but you see lots of different options. There are so many ways these days.

Dave: Yeah, I mean Sass is maybe still valuable. I don't want to poo-poo it whatsoever. I think we've talked about it on the show before. I think a lot of its advantages are kind of are disappearing, like variables, even partials. Essentially, this whole CSS Modules thing is kind of the partials feature, right? Things like that are kind of nesting, nesting….

Chris: I wonder what's left for them. Are they out of -- is the question, are they out of ideas or is technology just gotten to the point where they can't? Like just a preprocessing language can't do all the stuff that they want it to?

You'd think that they could look at the post-CSS ecosystem and be like, "What are the most popular things being done here? Can we replicate them in a Sass-y kind of way?" That would be kind of interesting.

I wonder how much enthusiasm they have. It seems like they have some momentum lately, the Sass projects, so I wonder if they're doing that kind of thing or if it's just largely like working on speed, maintenance, and stuff.

I kind of like the idea because there is a big difference between a pre-processor variable and an in-browser variable. They're just kind of different beasts. If you only need what a preprocessor variable can do, which is just a stand-in value that you want to be consistent about, I think that's fine to use a pre-processor variable. It might even be smart to.

Dave: Yeah. It's kind of like const more than var, or whatever. [Laughter]

Chris: Or things like -- yeah, but they have to be so careful, right? That's one of the things I worry about sometimes with certain post-CSS libraries is that they replicate directly a browser feature.

We talked to Henry about Babel, in a way, and Babel does that too, right? Babel doesn't have abstractions that are different from the language that then compile down to the native thing. They do exactly what, hopefully, the language is going to do. That's what post-CSS does too, but then it puts you in that difficult position of, like, when do I remove the preprocessing step?

Have you seen there are a lot of conversations in JavaScript about shipping multiple bundles or at least two bundles, like an old browser bundle and a new browser bundle? It's starting to get ridiculous to compile down to ES5. People are starting to be like, "Man, it's bigger. It's slower. It's just worse in a lot of ways."

Dave: Well, it's like a tenth of the size. I think Jamie builds -- I forget his last name. On Twitter, tweets this every few months or so. [Laughter] Putting a class in the Babel REPL, just class foo extends var or something like that. It's massive amounts of code just to port that over to a previous thing and to, like, the old syntax. But then, even modern browsers get quite -- even if you do modern or whatever, you get tons and tons and tons of cruft for what's supported by all the most, most, most latest browsers.

I definitely understand this desire to polyfill or split this up, but that also -- that introduces a whole bunch of headaches for me. Anyway, I don't know. I don't know if you remember the less than IE9 stylesheet days, but it was always this weird non-responsive style sheet you'd ship to browsers. It was kind of a headache, but there's a lot to be said. It could work.

Chris: Oy, oy, oy.

Dave: We've been talking about ten years, so we should probably wrap it up. What's our general feeling? [Laughter] We hate CSS in JS?

Chris: It depends!

Dave: There you go. No. [Laughter] It depends. No.

I think, just to sum up my whole thing, I think, when it was like, "Oh, it's an inline style attribute inside the element," I was like a no. Then when it was a style block injected into the head, I was like, "Well, maybe, but that still takes a lot of CPU, that runtime."

Chris: Just to note, it also can be that link rel stylesheet with a blob, which is very weird.

Dave: Yeah. Now that it's link rel style sheet, I'm like, "Okay. Now I feel like I can investigate this technology." That's where I'm at, Dave Rupert. Take that as you will. Your favorite Luddite on the Internet, Dave Rupert. [Laughter]

I'm just saying, I think it's a technology I can maybe look at, but there is a lot of concern about like Rachel Andrew's point of view; everything going all JS does sort of eliminate some pathways into our industry. I think that's worth considering.

There you go, Chris.

Chris: I think I'm with you there, man. I almost kind of like it when it's not a style, like the head block is the most appealing to me. While I was the most scared of that because I thought that, in a way, we're telling browsers -- I feel like browsers work so hard on the rendering pipeline and making that fast and good for websites, and that this says, "No, no, I'll take care of injecting stuff into the DOM. I'll take care of injecting styles into the DOM." We're kind of making it work, but the browsers aren't exactly optimized for that. I worry that if we push it to the limits that browsers will be like, "Well, what the hell are you doing, man?"

Dave: Well, I mean, the easiest way to be fast is to be cached, right? The easiest way to be fast is to be cached.

Chris: This has none, zero cache, except for the whole bundle itself, which -- I don't know. Is that fast enough? I don't know.

Dave: Maybe. I don't know, so anyway.

Chris: [Groaning]

Dave: All right, well, thank you, dear listener--

Chris: Yay!

Dave: --for going on this tangent with us. We really appreciate it. We'll be back next week, hopefully continuing our series.

I should also note, a little bit of housekeeping. If you hear somebody different on the advertisements, that's Chris Enns, who mixes down the podcast. It's not Chris Coyier on drugs. [Laughter] Just so you know. We had that confusion come up.

Be sure to follow us on Twitter at @ShopTalkShow for tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris, do you got anything else you'd like to say?

Chris: Hmmm, ShopTalkShow.com.