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 front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris. How are you today?

Chris Coyier: Good. Good. Good. Let's see. We have so many things to do. Maybe we can get to some user questions, but we wrote down a few things as we--

Dave: Actual people questions. [Laughter] Don't be ridiculous.

Chris: I don't know.

Dave: Yeah.

Chris: I see you have a tweet in here, though, from one Tim McNamara. I don't know Tim, but his tweet got pretty darn popular (from just a couple of days ago).

"Why is it harder to make a website in 2021 than it was in 1996?" [Laughter]

Dave: Yeah! So... What do we think about that? This was a very popular tweet this week, and I saw some sub-tweets about it. I saw some back and forth. Even this Web 3 thing is getting mixed into it, like crypto and all this, sort of like, "I hated..."

Chris: What the hell does this have to do with Web 3?

Dave: I know, but it's this idea, like, "I hated making sites in React and stuff, and now I'm just loving Web 3. I have so many ideas." I've seen posts like that, and so I don't know.

First, factually, is it harder to make a website in 2021 than it was in 1996?

Chris: I mean now I'm almost scared to have an opinion because apparently everybody in the world has had an opinion about this.

Dave: Okay. Okay.

Chris: But I have one, I guess. I mean it's that that's just super not true.

Dave: Mm-hmm. Okay.

Chris: It's just not true. I think there are lots more really complicated websites and having a reaction to the extreme levels of tooling and complication that a lot of people experience because that's their job these days, that comes from the Web being way, way, way bigger and more capable and just a bigger part of our life and world than it was in 1996. That's not the same. You know?

Dave: Mm-hmm.

00:02:24

Chris: You know the first follow-up tweet from Tim was, I mean, you know, he says, "I mean, writing your own HTML in notepad and uploading it via FTP was a chore, but it was understandable and easy."

Yeah, sure. That website is just super different than anything that people are working on today. You know what? You can still do that. There's literally no reason you can't do that.

Dave: Mm-hmm. Mm-hmm.

Chris: So, that's a thing. And that if you want it to be even easier than that, now there are a million other options. You can drop that thing on Netlify drop and it's - boop - it's live then, so that wins. That's way easier.

Dave: Yep. Yeah.

Chris: I don't get it. What has happened between 1996 that you can't do anymore?

Dave: Yeah. Nothing, right? But for me, it's the number of people involved has gone up, and so you're hitting literal Brooks' Law of connections.

Chris: It's probably multiple orders of magnitude.

Chris: Yeah. The money went there, and so more people got involved, right? [Laughter] So, you had to be like, "Okay, so now we have to talk to a content person and an editor." We can't just put stuff on the Internet anymore. Oh, they want to edit that. Now we can't just sling FTPs. Well, we can, I guess, but we need a database for the content. Gone are the days where I could have a pearl script sitting on my server that would--

Chris: Right.

Dave: The CGI bin that would literally write a single file. You know? Can't do that anymore. Guess what. That's a major security problem. [Laughter]

Chris: Mm-hmm.

Dave: So, you can't do that. So, we're using databases and PHP. Now you've got to put a user-friendly admin into there.

I feel like the concerns, number of concerns, has gone up. And then it gets more complicated because - guess what - a competitor's site had this really cool animation. Boss wants a really cool animation. Got to do that.

A competitor B has a video on the homepage. You've got to do a video on the homepage.

Competitor C, they switched to React. Oh, you've got to switch to React.

I'm definitely in the camp I think our tooling has gotten too complicated or it creates big barriers, and I'm into more simple tooling, and I think we're getting there. I think it's a very exciting time for that. But I don't know. I have a hard time saying -- I wonder if this is just glory days nostalgia stuff, too.

Chris: Like you emphasize a little bit here. It is harder now.

Dave: I think it can be.

Chris: Yeah.

Dave: I think there's some lived trauma when you open the old file. You open the old project and you try to run it, and Gulp or whatever doesn't work anymore; Webpack doesn't work anymore. You're like, "Man, I can't just make the website. I have to fix the Gulp or the Webpack." You know?

Chris: Yeah.

Dave: I think there's some lived trauma there, and it's a deal. You know? But I don't think--

00:05:44

Chris: That's the beauty. If you can set up a project and avoid all that in some way, you might be giving up a little DX here and there and then gaining it back so big. I mean a website that's not built with nothing fragile in it like that that you can just come back and just get to work on, that is real satisfying - I'll say.

Dave: It's really satisfying.

Chris: I think that anything that complicates -- not all of it, but a lot of it, like it's a test or something that maybe that adds to the fragility of the thing. Or if it's that, if it's there are human processes involved and you can't just ship a new paragraph. It has to be copy-edited or something. For the most part, those things, the net result is better websites.

Dave: Mm-hmm. Yeah.

Chris: It's like less breakable websites, websites that are more ready to be ready to make money and to stay online. Once they're on production, they're actually more stable, not less stable. Less mistakes can be made. Somebody can't just FTP over some change you made and have it be broke.

Dave: Mm-hmm.

Chris: That's unacceptable in a money-making website kind of environment.

Dave: Yeah.

Chris: The things that are complicated are complicated for a reason. Maybe there's too much of it, maybe some of it just kind of snowballed away from us, and we haven't stepped back in a while, looked at it, and reevaluated that stuff as often as we should. But for the most part, things that are complicated, they exist for a reason.

Nobody is like, "You know what I want to do? I just want to complicate things just for the sake of complication."

Dave: I just want to make it all complicated. Yeah. No. Yeah, it's usually complication is born out of a desire to produce an effect of some kind. You know?

I'm in the process of moving a whole - whatever - Netlify serverless - whatever - fully suite app - or whatever - over to a literal monolith on Docker. It's all this complication getting into Docker, but the tradeoff was getting something set up with its own S3 bucket, its own -- all these different buckets and all these different sort of servers, database, and stuff. That was kind of tedious and serverless and stuff like that.

We just wrote it with simplify and then we'll go back to complex again. We'll go down to a monolith and then we'll kind of branch out again. It sounds kind of like I just rebuilt the whole thing and sort of did, but it's helping the end goal. I don't know.

It's just interesting. I've just seen the sentiment more times. [Laughter] I was just like, "Maybe we should talk about it."

Chris: It definitely is worth talking about. We even have a sponsor this week, HubSpot, that makes a tool that adds some complication, then removes a lot of complication, and brings a bunch of power with it. Let's run that spot.

00:08:50

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by HubSpot. HubSpot makes a CMS called CMS Hub. Maybe you've heard about it on this show before. It integrates with their CRM product. It's a pretty super-capable, fancy CMS.

They're launching a context, a virtual themes contest. The idea is you make a theme for CMS Hub and it goes into HubSpot's asset marketplace, so literally, a theme that other people can use and buy. When you make that theme, you're entering for a chance to win, and these are big deal prizes like a Tesla Model Y and over $100,000 in cash prizes across different categories.

You make the theme. You put it up for sale. All the participants (you) retain ownership of the themes that you create, and you're eligible to receive revenue from generating and selling these themes in the marketplace. So, it's a perfect opportunity for you to learn HubSpot and CMS Hub, learn how to build themes for it, make money by selling the theme, and potentially win money from this contest.

The final deadline -- It's October now, so this is coming up. You have some months to work on this, but not forever. January 13th, 2022, is the deadline. Learn more, register, and get involved today at hubspot.devpost.com.

[Banjo music stops]

00:10:24

Chris: And there are all kinds of other CMSs as well that, like, maybe CMS isn't even the right word, but site-building tools. The Web is loaded with them where you can go (I would say, without exaggerating) in 15 minutes you can have a decently satisfying website that communicates what you need to communicate with it.

Dave: Yeah. I mean Shopify, you can have a whole store, like your own baby Amazon just going.

Chris: Totally. I had kind of a local-ish artist that I wanted to help out because her site had gone offline. I'm like, "You know what? We can make a better site. We can do it quicker. We can make it so you can update it. We can make it so you can sell your stuff on there. I just want to help you just because I think your work is great and you need somebody to hold your hand, essentially, through what (if you're not in this world) might feel complicated even though the tooling has got so simple."

I was just like, let's do this. I'll use the way back machine. Grab some of your old content. Right-click, download photo. Right-click, download photo. Right-click, download photo. Okay. Let's see. Let's use this, drag a little image slider on there, publish a couple of pages, and then, a half an hour later, I'm like, "Yeah, that looks fine." [Laughter]

Dave: Yeah. Good. You did it.

Chris: You know. Eh... done. Yeah, and then because it's on a hosted service, which I think is part of the story here (an unignorable part of the story) that that has really helped. That can make things faster. Then you're not worrying about security. You're not worrying about performance. You're not worried about getting hacked into and things like that.

Dave: Mm-hmm.

Chris: I think that's incredible, and the Web is better for it. And we're past that area where we were really sad about it. We were like, "Oh, no. What about the $1,000 freelancer, their jobs?"

Well, maybe that was sad, but now that's in the past and those people found new jobs or something. It's not like there are less tech workers than there were. There are certainly more.

Dave: No, I think you get -- you know it has changed the world. These simple things, that market has been cut out - almost - and the five-pager or whatever. That's almost gone. Now you're using something like Webflow or something. It's complicated.

Jumping into Webflow, we've used Webflow experts before just because we're like, "Hey, you're going to go a lot faster in this because you know how to do it." But it lets them mess with their content and, you know, it maybe works.

Chris: Yeah.

Dave: Yeah, everything has gotten more complex, and WordPress has gotten more complex. But I think the goal is that it makes something easier, so you have to find those paths. What are my tradeoffs? Complex--

Chris: I can see why this clicked with people, though, because if you don't have a podcast where you get to sound off about it and think through all the details, it's easy to just be like, "Yeah, man!"

Dave: Yeah.

Chris: [Laughter] Yeah.

Dave: Yeah.

Chris: It's harder now.

Dave: It's harder. It is. It can be. But why? But why?

00:13:33

Chris: All right, well you know one thing that can complicate a website is when you just slap on additional things in your build tool and all that. I'm curious. You do a lot of Vue. Perhaps it's your most -- your favorite and most authored framework, JavaScript framework, right?

Dave: Yes. Correct.

Chris: Are you -- when you need styles, do you lean into the--? Let's say you're not using PetiteVue or just client-side only Vue. You're using Vue components because Vue components, the SFCs (single file components) have a style block within them.

Dave: Mm-hmm.

Chris: Do you tend to utilize the scoped nature of them or you avoid it?

Dave: What I've been trying to do, it's hard to do it consistently because sometimes you're just like, "I'll just write the style here," and then I'll forget to move it. You know? [Laughter]

But I've started saying styles in my components are going to always be scoped, and styles in pages, they should just never be there. Although, some page template layouts may need a set of styles. But I've always said styles and components should always be scoped. Otherwise, I should have a global style sheet.

Chris: Yeah. I agree with that, and I would say that it's almost a weird default that they're not. The styles should just be auto-scoped. Then if you wanted them global, you'd have to put a global attribute on it or something.

Dave: Yeah. Right. Wouldn't that be--? Yeah.

Chris: I almost prefer that. That's kind of the CSS Modules approach, but it seems like if you're writing styles in a component, it's a big mistake to write something like "body background red" or something that's going to apply globally. It's like, where are you going to find that?

Dave: Yeah.

Chris: That's a mistake that you've gone so global with that. It should be way scoped.

So, anyway, I was just curious if you lean into the scoped styles and the per component styles a lot. It seems like, in Vue land, you would never reach for any other tool to do that. It's built right in Vue.

Dave: Yeah.

Chris: It's built right into Svelte. It's built right into Angular in some kind of way. I'm less familiar with that world but, last I looked, that was the case. Literally, every framework has a styling solution that they go for and not React. But did you have a thought first?

Dave: I saw a discussion in our D-d-d-d-discord, CSS Modules versus styled-components or what are the tradeoffs and stuff. It's funny because I almost checked out of the conversation because Vue solves this for me. I didn't have to pick. [Laughter] Vue has exactly what I want inside of it.

Chris: Right.

Dave: And so, I didn't have to home row. I didn't have to bake something else. I just have a global style sheet with some utilities, and I don't even use Tailwind. I know people use Tailwind for this sort of stuff, too. But I just have a global style sheet with the utilities I want and then some maybe just standard classes - or whatever - global component kind of things.

You know you have table styles or something that you want to be global. You don't want to have repeated table styles for every single little -- or you don't even want 50 table components. You just want to apply a class to a table whenever you want.

Chris: Right, and some people might be like, "Well, then make a table component and scope the styles to that."

Dave: I don't want it. I just don't want the file.

Chris: But you don't necessarily always want to do that.

Dave: I don't want the file, so yeah.

Chris: Yeah. Yeah, it's just HTML. Why make a component?

Dave: No.

00:17:01

Chris: Fair enough. Fair enough. Fair enough. Okay, so React doesn't, which is weird, but everybody knows that already, right? There have been a million. CSS and JS exists because of React, pretty much.

Dave: Mm-hmm. Mm-hmm.

Chris: People want some kind of solution, and they've been battling it out forever. It seemed like there was a wide landscape of it - to me. This is just my impression. Then it kind of narrowed down, and styled-components has long been kind of like the winner - maybe.

Dave: Mm-hmm.

Chris: CSS Modules being cool, and I like them, but they don't do very much. That's just for scoping and co-location of styles, and I like that light touch. But if you're talking about actual JavaScript syntax and - I don't know - being able to do stuff like take the props from a component and use them to do styling, conditionals, JavaScript math, or whatever, then you're picking one of these libraries. Then there's emotion, which came a little later, but I feel like is similar and also has a lot of superfans.

Dave: Mm-hmm.

Chris: That was as narrow as it got for a minute. Now there are all these new players like stitches and vanilla extract.

Dave: Mm-hmm. Mm-hmm.

Chris: And style JSX. It feels like it's widening again - for whatever reason. Perhaps part of the reason is some of them have variant API, knowing that, okay, you're going to author styles and then you're going to author variations of those styles, which feels like, "Yes, we probably are going to do that."

Then a leaning more heavily into design tokens and setting up a design system like Tailwind encourages. I'd say proper usage of Tailwind -- maybe that's extreme, but I would go there -- is to configure it and say, "These are my colors. These are my spacings. These are my fonts. This is my design system. Then you use those.

Dave: Mm-hmm.

Chris: That I think the CSS and JS world is starting to be like, "Well, what if we did that too? You have to configure the CSS and JS library first."

Dave: Yeah.

Chris: And with your variations and then lean into that in a way that styled-components would be like, "I don't know. Just make a bunch of variables then or something."

Dave: Mm-hmm.

Chris: Whereas these other libraries are taking it more seriously but, in the end, it's more verbose and complicated. Anyway, that was a lot of words to say -- I don't know. I'm just watching to see what's up. I don't know if you're following this as much either, but I wonder if it appeals to you. Do you wish Vue would help you with design system like styling more?

00:19:30

Dave: Yeah. I looked at vanilla extract. Is it Mark Dalgleish? Am I saying his last name right? I don't know.

Chris: Right, but I think it's kind of like a whole team behind it.

Dave: A whole team. He asked me what are my thoughts about it. I don't use React, so I'm kind of already out. Right? I guess I should say I use Vue, so I already have a thing. [Laughter] I don't need a new thing.

Chris: Yeah, and this would say, like, "Oh, this is framework agnostic," but you're like, "Yeah, but not Vue."

Dave: Technically, yeah. Technically, I think it could work anywhere, but I have Vue, so I'm good to go.

What I liked about it was it creates tokens. It's very design token friendly, I guess you'd say. It leverages CSS variables pretty heavily, and I thought that was really cool about it because it is kind of more of this sort of what we've been talking about in the ShopTalk videos on YouTube and stuff like that, this system that you just kind of use variables to program and create new ones or create variations.

Chris: Yeah.

Dave: I liked that about it, and it would be something I'd look at if I was in a React world.

Chris: It's funny that that's what it compiles to because then it's like you could just write vanilla CSS, make a bunch of custom properties, and just use them. But I guess it doesn't give you the guardrails.

Dave: Right. Right.

Chris: I think that's starting to be not an expectation necessarily, but a bonus of this next-gen CSS and JS stuff is that they're like, "Oh, they're in TypeScript," so that way, as you're typing, it's giving you type ahead for this design system you've set up.

Dave: Mm-hmm.

Chris: It's warning you if you try to use a variation that doesn't exist and that kind of thing.

00:21:32

Dave: I think that's cool. I was working on a design system for a company, and I always thought it'd be really cool to not only just figure out the auto-complete, set up auto-completes in a plugin or something, but also make an extension for Chrome that you type "my hero" and it gives you, "Hero 1, Hero 2, or Hero 3. Which one did you want?" It would just auto-complete or give you all the options. I guess you could probably set up TypeScript and write all the types and everything to get that, I guess.

Chris: Mm-hmm. Mm-hmm.

Dave: I'm not taking it that far. I was going to say Vue 3 introduced this new v-bind in your CSS. Have you seen that?

Chris: V-bind in CSS? Oh, is it--?

Dave: Yeah, so in your little style block you say, "v-bind my prop, my value, or something," and it basically creates a CSS variable based on that property and does the bridge.

Chris: Nice! I was watching that a year or more ago, I thought. Is it every piece? You have to be a little bit more explicit about it. I think the last time I looked at it, it was like every piece of state, like every property of state in a component gets automatically turned into a custom property (whether you want it or not). It's just like, well, because then you can react to that state in a custom property (if you want to), like if there's a styling that changes for that state. But this is more like, okay, you--

Dave: Yeah, so I'd say like background color v-bind color, and color is a prop you pass in or a computed value or something.

Chris: Yeah. That's awesome.

Dave: Then it'll create a variable called --color. Vue is tracking all of it, so it'll say, "Okay, I'm going to update color now because it needs to update," or it got updated in the DOM, the prop got updated manually, reactively, or whatever. So, I'm going to send that and update it.

Chris: Mm-hmm.

Dave: I thought that was a pretty elegant, low-touch solution. It does create a custom syntax inside CSS, like v-bind. I don't think working groups are going to go after the v-bind keyword there [laughter] but you know.

00:23:59

Chris: No, a little weird, but then it's 100% runtime is another thing I think of, which is maybe light touch. I don't know. I don't know how Vue extracts this stuff, but that's starting to get popular. That's one of the reasons vanilla extract is called extract is that they really lean into this zero runtime idea, meaning that your styles are not in your JavaScript. During the build process, actual .css files are produced and you use those. Meaning that's as good of performance as regular CSS is, and it even tries to--

And it's not just this one. There are other ones. Even Linaria - or whatever - was one of the early ones that tried to be zero runtime. I scoff a little bit at runtime only because it's like CSS is a runtime too. It's running in the browser.

Dave: Yeah.

Chris: Why can't it just say, "Compiles to CSS"? Then it's like, "Oh, I get it. Okay. Cool."

It does matter, though, because people -- when you say CSS and JS, I think in a lot of people's minds you're like, "I don't want to put my CSS in my JavaScript," but really you're only authoring it there, the performance of, assuming you're using one of these libraries that supports it. The end result is just some CSS.

Dave: Yeah. Zero runtime CSS means a CSS file, but it has all the benefits of a runtime CSS, like robo-classes and whatever.

Chris: But if something has got to react to some state and change a custom property or something, some JavaScript is doing some manipulation.

Dave: Is going in there. Yeah, right.

Chris: Yeah.

Dave: Yeah, some runtime is happening. Yeah. I don't know. Do you ever--? [Laughter] Do you ever feel like you were gaslit by the entire JavaScript community for a few years about the benefits of a certain approach? [Laughter] Yeah, I don't know. It's kind of funny to see it all come back to, like, "Let's just make CSS files." [Laughter] Anyway--

Chris: Yeah. You know I just published an article today-ish - or something - with a cheesy title like "CSS is Going Gosh-Darned Hog Wild, I Tell Ya What." [Laughter] It was just kind of like, let me just point to some of the -- just some of the really bold stuff CSS is doing lately: the container queries, the units, the nesting, the layers, the when, the scoping, and all that. That's not to mention -- I don't know -- color changes.

Dave: Mm-hmm.

Chris: And logical properties. It's just a million things that are happening to CSS that's really cool. Once they're all out, I would think that it almost is going to usher in yet another one of these rollercoaster moments where we're at the low point of the rollercoaster where people are like, "I don't need tooling."

Dave: Mm-hmm.

Chris: "I don't want tooling. I want to trust CSS to this because it's the most performant thing and it can do these somewhat amazing things without the tooling."

00:27:00

Dave: Yeah. I should not discount. I'm dismissive. I apologize. There are some major benefits about a single file authoring experience, which you get with CSS and JS. Until literally Chrome 93, you couldn't import CSS into JS. Now you can.

And it's not in every browser. And the ability to use variables to trigger different styles, that is very cool. So, I don't want to discount all of CSS and JS, but I think there are some major benefits to it that you can write. You can stay in a JavaScript file. You didn't have to go out, and you're not hunting down 20 different Sass files in your entire build. You're co-located. Your CSS is right in the same folder as your component. I think that's good.

Chris: Wow. Yeah. Me too, man. Then if you don't need that component anymore or you just don't load it on a particular page, your build process is probably ignoring it, not bundling it together, and not loading those styles.

If you throw away that component, it all goes away. There are not orphaned CSS in some other file that you totally forget about. Those things are real to me. [Laughter]

Dave: Yeah. No, I mean that's a huge benefit, especially if you were building in components.

Chris: Yes.

Dave: There are people who don't, and I don't understand it, but it happens.

Chris: Ha-ha! Yeah. It depends on how baby the site is or whatever, but it's starting to seem like it'll get easier and easier over time.

Dave: Yeah.

Chris: I'm curious. We were just talking to (or I overheard, I guess) Brad Frost talking about it. He's moved host. He's over on Flywheel now. High-five. That's where we keep ShopTalk Show's site and stuff, too. Not a sponsor of this show but has been for a long time.

He's like, "I'm just going to build my new WordPress site, my vanilla PHP not exotic WordPress site." He's going to do it all in Web components. [Laughter] Sorry to break the news. Maybe Brad will never do this.

Dave: Oh, yeah.

Chris: Sorry, Brad. You're not beholden to this idea, but that was his idea at the moment. Fascinating! You know? I think once you've designed a couple of design systems for big clients in them that I think Brad has broken the seal.

Dave: Yeah.

Chris: He's like, "Oh, I get it. This is how you work now." I've seen more and more, including some articles on CSS-Tricks about people going down this road. Instantiate Web components using PHP data and crap at first from your WordPress output, but ultimately then have the client take over.

00:29:49

Dave: Mm-hmm. Yeah. It's a pretty good model. I mean there's a small server-side rendering story with Web components where it's not that great. You ship a Web component; JavaScript still has to run to mount the Web component or register the Web component. Then it can spit it out on the page.

But there's a new thing called-- [Laughter] What's it called? Something Shadow DOM. Descriptive Shadow DOM? DSD? You write the Shadow DOM inside the DOM. You basically ship a template inside your Web component, which is actually pretty fine. The browser can actually read that template and start doing stuff before the Web component even shows up.

Chris: Oh, I see. You might have to repeat yourself an awful lot, right? But who cares.

Dave: Yeah. If you had it in 20 LIs, you had your card. You'd have 20 Shadow DOMs repeated and your Light DOMs, which stinks. But the idea, the tradeoff there is you get this. You get the free, I guess, render pass before the component even mounts.

Chris: Right. Literally, if JavaScript doesn't run at all, it still maybe works.

Dave: Yeah, and so that's kind of cool.

Chris: Yeah.

Dave: Kind of the idea that these components can start mounting or start doing stuff before--

Chris: I guess it can be a template tag, right? But there's--

Dave: No, it is template. It's like my Web component on the outside. My component.

Chris: Yeah.

Dave: Then inside, you have template, ShadowRoot open, so you're just saying this talks to the whole thing. Then you have your Shadow DOM code.

Chris: Yeah.

Dave: Div div button button button.

Chris: That attribute, does it make--? I always thought in the user agent style sheet template was display none. But I guess if you put an attribute on it or something, maybe the user agent style sheet updated to be like, "Oh, but if it has this, then display block."

Dave: Yeah, I think it's that ShadowRoot keyword where it's like, "Oh, you're going to put a shadow in here, so I'll just go ahead and create the shadow. It won't be interactive or anything, but I can slot -- take that Light DOM content and now throw it wherever you said slot or whatever." There's a way. It's just kind of--

Chris: Yeah.

Dave: Anyway, it seems like-- I want to say-- Let me find-- I'm in the Web component community group Slack here, and I'll try to figure out what it's actually called here.

Chris: I think it's kind of good. It's repeat yourself heavy, but anything would have to.

00:32:39

Dave: Declarative Shadow DOM, that's the word. You declare your Shadow DOM.

Chris: I see.

Dave: That is what creates it.

Chris: Then when you mount it, does it--? I guess it doesn't have to match, right? It doesn't care that much, or does it hydrate somehow?

Dave: Yeah, it would.

Chris: What if it's all wrong? [Laughter]

Dave: You could hydrate. Yeah, what if you're--? I don't know what the resolution is if your declarative Shadow DOM and the Shadow DOM you wrote inside your template (the render function), if those are different, how it reconciles. I would assume it upgrades to the JavaScript version.

Chris: JavaScript-powered one. Right.

Dave: I think it would probably prefer that. But that's an interesting idea there. But all a Web component really does is it looks for a template and chucks your stuff inside that template and spits it out on the page in an invisible iframe kind of thing.

I don't know. I'd be curious to see how far people can take it, but I definitely would agree with Brad. How cool would it be if your website was just a little folder full of components that you take with you everywhere you go? [Laughter] You didn't have to -- like, if you changed hosts or you changed platforms, you don't have to update that, Chris. You have all your little components and now you just do it a little differently.

I think that's a really cool way to build a site. You didn't have to set up your new Webpack chain. I guess you probably still have some kind of rollup Webpack thing going on, but you don't have to do it.

Chris: I mean I would think a build process will help this, so you're not repeating yourself manually as much.

Dave: Right. Yeah. Yeah, that would help.

00:34:27

Chris: I've got a different one for you.

Dave: Oh. All right.

Chris: I'll just throw this at you because I don't have too much. I don't know how long we can go on this, but a year ago, two years ago maybe, I was like, "I would love to write a book about CSS because I have a website called CSS-Tricks and it seems like a decent business move." You know? [Laughter] Because I've never done that before.

But I didn't want to write how to CSS because it's been done a bunch of times. I'm not sure I have anything. I'm starting to come around that maybe I do have something to say about that. But anyway, at the time, I was like, "The world doesn't need an intro to CSS book at the moment."

The site is called CSS-Tricks, so what if I make the book CSS-Tricks? That seems the way to go.

Dave: Mm-hmm.

Chris: I put big ol' quote marks around the word "book" because I never even really considered putting it to paper. To me, a paper means some kind of paper. But I thought, "Oh, at least I'll get it in PDF and crap," right? Then I just never got to it. But I wanted to also write it the way that I write everything else in the world, which is on my own website at URLs, like using that blog post style format. So, that's what I set up.

I made a custom post type for chapters of the book, and I just started writing some chapters. Then when I had 15 of them or something, I'd be like, "All right. That's enough." They're all just literal CSS-Tricks, like my favorite ones, but fresh writing about it and crediting the original authors - blah-blah-blah.

Then I just compiled all those together at a URL and said, "Hey, that's the book." If you want to buy it, you just have to be a supporter of CSS-Tricks. Otherwise, you just see the first paragraph and it says, "Sign up to read the book."

Big quote marks for book. It's just some locked-down blog posts.

Dave: There's a lot of overhead in a physical book. You have to store it. You have to ship it. That costs money. Yeah.

Chris: Yeah. I had some experience with previous books that I did where we wrote and designed them in Adobe InDesign, so it was very exotic what you could do with the layout, and it was very fun to work on, and 100 times the work of a blog post. Just an incredible amount of work, especially when it comes to updating and stuff and how text shifts around where you've got to move stuff.

It's the most fun way to make a book and, I think, the highest quality output, but I was always generous when I'd pick up a tech book and read it. I'd be like, "You wrote this in a single column just totally unapologetically."

Dave: You just riffed. Yeah.

Chris: This is a column of text is the book.

Dave: Yeah.

Chris: Yeah, and it can come out just fine. It's kind of like the blog post format. Just like column - go.

Dave: Mm-hmm.

Chris: I don't mind it. I think, for tech books, I think, because it's so quick, it's kind of the way to go - in a way. I always thought, though, that I would at least get it into PDF and stuff.

Dave: Mm-hmm.

Chris: Being like, how hard can that be? All you've got to do is barf out the content on a blank page, hit command-P, and save as PDF.

Dave: Yeah, and now you've got a PDF. Yeah. That's it, right?

Chris: Yeah. How hard is that?

Dave: Was it not that?

00:37:34

Chris: Well, no, it's not that, sadly. It turned out -- I think you can, but meh. It's not the best look.

Dave: You get automated quality, right? You get--

Chris: Well, you don't even get page numbers, and you don't get little headers and footers on the pages that say what chapter you're in. I don't know. I wanted to do it a little bit better, but I didn't even want--

I cared a little bit less about PDF because, yes, you basically can do that for PDF, even if it's not the best quality. But what about e-pub? E-pub is what like Apple Books uses, and a variety of other things. It's kind of a standard format. That you need a build process for. You need something to digest. E-pub is just trickery.

Dave: Yeah. Yeah.

Chris: I wanted to go there, and I finally have gotten it done, like a year later.

Dave: Oh, wow.

Chris: I had to hire someone to help, and they did a great job. I'll talk about that in the blog post and all that.

Dave: Yeah.

Chris: I just can't remember all the specifics. I want to make sure I get it all right. But, ultimately, the wrote a make file. [Laughter] You know?

Dave: Interesting.

Chris: That's like, "Take this HTML," which that was a lot of work to get that HTML really perfectly clean and ready for this.

Dave: Mm-hmm.

Chris: Then it ran, and it ran two different PDF makers because there are two different kind of command-line-based PDF tools that will take HTML and turn it into PDF. But respect your print level rules. There are a bunch of CSS that's just for print media.

Dave: Yeah. Page break, for example. [Laughter]

Chris: Yeah. But even @page.

Dave: Yeah.

Chris: There are at-rules that do specific stuff. Pretty interesting. It created those, and they were both really different in levels of what they support and how good of a job they did and stuff. I'm glad he put them both in there because I went back and forth over and over about which one I wanted to ultimately use and ship.

Dave: Yeah.

00:39:35

Chris: Then it made a PDF, and then it made a MOBI, too. MOBI is unique because that's the Amazon one.

Dave: Like Kindle format. Yeah. Yeah.

Chris: Right, and that one is a pain in the butt.

Dave: Is it really? I thought it was very e-book, like e-pub-like. But it's different, huh?

Chris: It's very different because it accepts very little styling. You can imagine what Apple Books is like. It's with the white background and the page-turning things.

Dave: Yeah.

Chris: It'll animate a GIF in there.

Dave: Whoa! Whoa, whoa, whoa, whoa. Slow down. Yeah. [Laughter]

Chris: [Laughter] But it won't run JavaScript, really.

Dave: Yeah.

Chris: You can't put a CodePen embed in there. And that was tricky, too, because my book has a lot of--

At one point, because I thought -- I was like, "Oh, screw it. I'll just give up. It'll just be online only." I put a bunch of CodePen embeds and stuff in there. Then as I started to turn the table, I was like, "Well, but that's not going to work in e-pub and stuff."

I have two Guttenberg blocks in WordPress, and one of them is print-only content and online-only content. Then they just display blocker display none each other depending on the output format.

Dave: Yeah.

Chris: Yeah, just pretty simple. And so, any time there's a CodePen embed, there's some alternate something for this format.

But here's another trick. You know that classic where you do your anchor links and then you put a pseudo-element after it? Then the content of the pseudo-element is the href of the link?

Dave: Mm-hmm. Mm-hmm. Mm-hmm.

Chris: I just didn't have to do that because these formats are headed to a digital place where the link is blue.

Dave: You get a click. Yeah.

Chris: You can click it.

Dave: Yeah.

Chris: It's like, there's the link. You get to do slightly different stuff for the e-book world, but it was pretty satisfying, and it was complicated. I ended up writing a lot of CSS really massaging the HTML. It took me a long time to get it really just right.

Now it's kind of done. Now, if I basically do the same thing for another book, I just run this thing again and now I'll have the digital format.

Dave: The e-pubs? Wow! Well, congratulations! That's awesome. I think we've all written books before. [Laughter]

Chris: [Laughter]

Dave: No. That's awesome to hear because--

Chris: I haven't open-sourced it. It was given to me as a private repo and I just left it private.

Dave: Yeah.

Chris: But I might talk to him and see what's worth open-sourcing here because it's pretty complicated. The first time you make, it has to install all kinds of crap.

Dave: Mm-hmm. Yeah.

Chris: [Laughter] To get it to work at all.

Dave: All of - whatever - Linux.

Chris: Yeah. [Laughter]

Dave: Like every single package that Linux has ever made. Yeah.

00:42:12

Chris: Yeah. Definitely some old-school packages in software and stuff. Then you know what you don't get, which I think is changing a little bit but really needs to get better, is the feedback loop. There's not a JavaScript library you can load up on the page that simulates what these tools do, then you write CSS to get the output right, and then you run it once to get the final output.

The feedback loop is like, "Change a little bit of CSS. Run make file for two minutes."

Dave: Mm-hmm. And pray it shows up.

Chris: "See the output."

Dave: Yeah.

Chris: "Oops. That doesn't look good." I probably did it a thousand times.

Dave: How do you QA the MOBI and everything?

Chris: The e-pub, you just drag onto iBooks and look. But then you've got to delete it, because otherwise, you have a thousand copies of the book in there.

Dave: Do you test font resizing and stuff just to see if that explodes it or whatever?

Chris: Yep.

Dave: Yeah. Okay.

Chris: You've got to play around, and that has left and right pages on a PDF.

Dave: Uh-huh. Uh-huh.

Chris: A PDF, you almost don't want the pages to have that vibe. You just want a column up and down.

Dave: A column, yeah. Yep.

Chris: But on e-pub, you don't really have a choice. You've got to have left and right styling, which means then you're using @page left and @page right in your CSS to control the gutters a little differently.

Dave: Add indents. Yeah. Yeah. Wider outer gutters or whatever. Yeah.

Chris: Then MOBI, I just got the taste from the guy I was working with that MOBI just sucks kind of and, generally, people that buy their own books and stuff and have a Kindle workflow, they tend to have their own little workflow. If you give them a pretty good PDF, that's all they want anyway.

Dave: Okay. Interesting.

Chris: That was just his vibe. I was like, "Eh, I don't care," but there is an app called Calibre on Mac, I believe, that opens your MOBIs, so that's what I used.

Dave: Oh, okay. Yeah, I was going to say I've sent them to my stinking Kindle before, or whatever. Just files I download from Kickstarter or whatever.

Chris: Mm-hmm.

00:44:14

Dave: I was going to say, too, A Book Apart, they do good. No shade. But I have noticed when I read those on my Kindle, like code samples and stuff are really hard to see, even. There's contrast. But then the formatting is kind of hard. To the extent, I've started buying the physical books, the A Book Apart books again, just to have the intended version of it. Yeah, that's all fascinating how it all comes together.

Chris: Yeah, it is. The way that you get them -- if anybody cares to get them -- it's the same way as the book. You can't read the book online unless you're a supporter. If you are a supporter of CSS-Tricks, there's just a product in the store or the little PDF and the e-pub.

Dave: Yeah.

Chris: I don't even know that I put a MOBI in there because I was so lackluster about it, and I heard people have their own kind of workflow anyway. I could put it in there. If anybody asks, I'll give it to you. But I just was like, "Eh..."

Dave: Yeah.

Chris: I wasn't thrilled with the output, so I just didn't even put it in there. It's the same way with the posters. You can buy physical posters from the CSS-Tricks store, and we'll ship them to you for money. But if you're an MVP supporter, you get the posters for free.

Dave: Digitally.

Chris: I mean for free, you know, like you have to be a paid supporter. Yeah, the digital copies of the posters. If it's a digital thing on CSS-Tricks, we'll give it to you as part of the membership (for free).

Now I'm stoked because now I've got the system. Now I can work on Volume 2.

Dave: I love it.

Chris: And work on other crap I want to do. Yeah.

Dave: I love it! That's great. You're a publishing house now. You have the thing.

Chris: [Snickers]

00:45:55

Dave: I might do my-- How much time have we got? We've got time. Okay. I might do my first workshop, Chris.

Chris: Oh, yeah?

Dave: I've done one before, but I might do one for a very popular front-end mastery series.

[Laughter]

Dave: Thinking about doing it on Web components because I'm in the Web components community group. I'm just a literal pawn in that group, but whatever. The advice there was put all your course materials in a GitBook so people can follow along - or whatever like that. I just was like, "If I'm going through all the effort to make a GitBook or something like that, maybe I just make a book, like write a book or self-publish a book, or whatever on Web components."

Chris: Yeah.

Dave: Because I'm that far down the rabbit hole. I might as well--

Chris: Right.

Dave: --see what that's about. I don't know. Then I have another half-written book (for an unnamed publisher that didn't quite go through) about prototypes and stuff like that.

Chris: Yeah.

Dave: I was just like, "Oh, maybe the GitBook for that one, too."

Chris: Yeah, maybe. You can publish it with CSS-Tricks Press, Dave. I'll take 10%.

Dave: What's 10% of $5? What is that?

[Laughter]

Chris: No.

Dave: Yeah, maybe that's an opportunity here for us to do business. No, I just was like, "Man, I have all this." You think about all the stuff you do. You prepare a talk, right? You did an SVG talk for years. You prepare a talk.

Chris: Mm-hmm.

Chris: It is enough work, and if you were to write it out, it's probably getting close to a book-length. You just need to kind of pad it a bit, right? My brain is starting to go there.

Obviously, people who write books are -- sorry. It's not just like writing a talk exactly, but you've done all the research and you cut it down to fit the talk, right? And so, you have all this research, all this knowledge. You might as well parlay that into some kind of book format - I feel like. I don't know.

00:48:16

Chris: I totally agree. Start with a blog post because if you can't even choke out one blog post, then your book is done.

Dave: Yeah. Yeah. Yeah.

Chris: Just don't even bother because you've already admitted failure - in a way. Then turn it into a talk if you can. I think you can because there are a million meetup groups and public-facing things that are starved for content. Again, if you can't find anywhere to give a talk on your passion project, then that's probably not a good sign.

Dave: Right.

Chris: Raise your hand and say you have a talk that you've prepared that you want to give, and you'll find somewhere to give it.

Then the talk really forced you into some format stuff. Between blog posts (probably plural) and a talk, you've got all the fodder you need for a book and you can kick it out. Now that just tends to be how these things go.

Dave: It's cool machinery. I don't know if that's "sell your byproduct" kind of thing from -- I think that was an old Basecamp-ism or 37 Signals-ism or something. Just that you're working so hard; you might as well do a little bit more effort, write it all out, and then you can build a book or something -- or get a different byproduct out of all the other work you just did.

Chris: Right.

Dave: That's something I'm terrible at. I borrow time from myself to make the talk, and then I jump straight back into consultant work. [Laughter] I don't have that month off where I'm just going to work on my novel - or whatever. [Laughter]

Chris: Right. I would say this. That was highly in mind when I was doing this, too. I think the byproducts are even more extreme. Even how the 37 Signal guys do it because mine have URLs to every book. I mean they have URLs for their books, but every chapter. It's like Web first.

Dave: Mm-hmm. Mm-hmm.

Chris: The byproduct of the book is SEO content, at least a little bit.

Dave: Yeah.

Chris: I think that's extra valuable.

Dave: Very cool.

Chris: It also doesn't mean that it can never hit paper with these things. It's possible that it can be done.

Dave: You're doing so much. Then you can also maybe provide extra chapters or extra illustrations or custom artwork or something for the book to make the book special. In theory, you could.

Chris: In theory, yeah.

Dave: If somebody has already read your post on grids or something, you can give them a little something extra, more interesting, or something like that.

Chris: Yeah. In this case, the something extra almost runs the other direction. If you read it online, it's a little more compelling because the live demos and stuff are there. That's kind of what I lean into, in a way.

Dave: People want the book format. Apple Books is actually kind of cool, so you can do a lot in there.

Chris: Yeah.

Dave: Videos.

Chris: Definitely early days for this, but it feels satisfying. Mostly because it's been on my fricken' to-do list forever and now I get to scratch it off.

Dave: Scratch-off. The big scratch-off. That's awesome.

Chris: [Laughter]

Dave: Congratulations on the book launch.

00:51:29

Chris: Maybe we can cap this off with one user question because I think it relates to the first thing we talked about. I'm going to do one from Nick Lansing here real quick. He says, "Hi there. I'm wondering how you would go about building a brochure website. By this, I mean a site that mainly has company information on it that is editable by the stakeholders and has a contact form. What tools, tech would you use to achieve this? I recently took up a project like this, felt overwhelmed by the options, so curious to hear your take."

So, not much info. Not much interactivity stuff except for a contact form. But is editable by, you know, non-techies, presumably. What's your go-to there?

Dave: It's kind of a joke in our company, but we've kind of cut it down to three choices. It's either a Webflow site, a Craft CMS site, or a Jamstack site.

Chris: Yeah.

Dave: Those are your three choices.

Chris: What would you pick here? There's a little bit of overlap.

Dave: A little bit of overlap.

Chris: Webflow has a CMS C-thing in it. Would you do that?

Dave: Yeah. That would be my thing if it's high-touch content, like they want to tweak the paragraphs and the images and whatever. Guess what. They never will. They'll just come back and ask you to do it and invoice you.

Chris: Yeah.

Dave: Just spoiler.

Chris: [Laughter]

Dave: But what they asked for is to be able to update the website, because that was probably a bottleneck with their previous client. They couldn't get updates going whenever they wanted. I think Webflow is a really good option, and we found talented people who do that, so I would do that.

If they were like, "No, just set it and forget it," like "We just need a landing page," or if you can convince them, "Hey, I can go build it this way, but you're actually never going to update it, so it's just cheaper to pay me to host it for zero dollars a month and pay me whatever, $100 when you want it fixed, that's probably the cheapest way." A Jamstack site would be great, 11ty, Astro - strong competitors here. On Netlify because you can do the Netlify forms thing - a really strong competitor.

Chris: Yeah, the forms thing. Yeah. Yeah, that's compelling because you get that for free. My history tells me I know what I'm actually going to do: WordPress and Wufoo.

Dave: WordPress. Wufoo.

Chris: Yeah, because that's just what I do. But my modern brain things, like, "Ooh, have you seen Stack Bit Studio? It looks really cool." I'd probably lean into that because then the editing story for them is really satisfying because you're WYSIWYG in a pretty extreme way, even more so than WordPress.

Dave: Mm-hmm. Yeah.

Chris: WordPress is starting to blur the lines a little bit because if you pick a really well-done theme, they pipe those styles for the pages into the editor itself. Now there's full site editing, so it's really getting really blurry as to what you're looking at. I'm just really comfortable in the WordPress land, so I'd probably do that. It's cool, though. That's your craft.

Dave: Mm-hmm. Yeah, and we just choose Craft because it has another level. We started working with Happycog for Craft integrations. It's pretty great.

Chris: Mm-hmm.

Dave: They're really good at it. But Craft has stuff out of the box. A lot of the multilingual stuff, really robust plugin ecosystem that is supported because you pay people money to support those plugins. [Laughter] It's a little different than WordPress where you found some GPL stuff online. [Laughter] I think Craft is very cool in that regard, and this new Craft cloud thing that they're rolling out with a GraphQL endpoint and all that. That could be really, really cool.

Chris: This is fun for me. I agree with what Nick is saying. There are so many options. Every single one we've talked about is like, "Ooh, that would be fun." [Laughter]

Dave: Yeah. Well, and it's the olive oil aisle at Whole Foods, isn't it? It's just like, "Oh, this is a $4,000 bottle of olive oil. Why? What's it got that the $3 bottle doesn't?" You have to kind of walk through all those options.

For us, it's a total joke that we only work on three things because we actually work on whatever the client has. But having just three wheelhouses that do different things has kind of simplified our whole decision flow, our whole choice matrix. Maybe you do that. Maybe you just kind of have an engineering all-hands, or whatever, and you just say, "What's our stack? What do we want to even do? What do we want to work on, and what do we not want to work on? Let's just pick three." Maybe that's your--

I will say if you're in the -- we talked about the bottom of the market being wiped out. That said, if you're all WordPress developer or all Craft developer, and you're a specialist, I think there's a lot of work there because people need a guy or a gal. They need somebody who does it.

Chris: Yeah, I mean hopefully this one-pager is for Nike or something and not the bakery, because then they just don't have the budget for your work at all.

Dave: Yeah. Well, but you know that's the long tail of it. Maybe you do a few bakeries and then somebody starts working as head of Nike.

Chris: That's true. Don't say no to the bakery. I'm just saying it's hard to turn that into a career these days.

Dave: Yeah. Yeah. That's harder. But I think, like Chris Enns, our wonderful podcast editor, he started out doing websites and stuff and WordPress. But he edited his own podcast, and he started editing podcasts. Now he edits a lot of podcasts. He's got a little empire going, and so it's pretty cool. That's all I'd say. It's just pretty cool.

Chris: Pretty cool. All right. Thanks, everybody.

Dave: Yeah. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Follow us on Twitter, @ShopTalkShow, for 16 tweets a month, and follow us over on the YouTube, on the Real CSS-Tricks YouTube channel. We've got some videos coming out, and a fresh new batch coming out, I think.

And then, yeah, go to CSS-Tricks and get the new book. Be a supporter. Yeah.

Then, yeah -- I'm trying to think -- oh, follow us on or join the D-d-d-d-discord over at patreon.com/shoptalkshow.

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

Chris: Um, ShopTalkShow.com.