482: Asset Pipeline Issues, Google ZX, Crazy CSS, and a New CSS Reset
Join us on YouTube 3x a week for more ShopTalk fun. This episode: How would you build with maximum user growth in mind? Asset pipeline issues, self provisioning runtime, Google ZX, and crazy new CSS.
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--under pressure--Rupert, and with me is Chris -- I forget another - whatever - David what's-his-face's songs. Oh, man. I'm not here today. Hey, Chris. How's it going? [Laughter]
Chris Coyier: Yeah, a lot on your mind, Dave. That's okay. That's okay. I'm just going to throw stuff at you, like complicated questions, and then you just have to pontificate on them.
Dave: That's cool. Just jam me.
Chris: The harder it is the better.
Dave: Just DDoS my whole entire brain.
Chris: Yes, but this will be -- at least you won't have to solve logic puzzles. You'll just have to think generally. Okay?
Dave: I've got a whiteboard. I thought -- so, we're doing YouTubes now. We should say we're doing YouTubes over on the YouTubes.
Chris: That's true.
Dave: Over on CSS-Tricks YouTube.
Chris: Yeah.
Dave: I thought it would be really funny if I bought a whiteboard, sort of like Katie Porter, the awesomest congresswoman ever, and did whiteboard exams or something. We could do actual whiteboard exams.
Chris: That would be fun. Yeah, we're trying to play with the format as much as we can. You know?
Dave: Yeah, so anyway.
Chris: Oh, yeah. Whiteboards are hitting hip, you know?
Dave: Oh, Ben -- what's Ben's last name?
Chris: Holmes?
Dave: Ben Holmes? Yeah, he has Slinkity, and he's doing a badass job of promoting Slinkity using a whiteboard, and I'm eternally jealous. It's so good.
Chris: That's nice. I remember seeing this. It reminds me of this book website. I think it was an author and they were trying to release a book, but they didn't know how to make websites, but they had a camera, right? And they could figure out, basically, how anchor links work. You'd go to the website, and it would just be marker on a whiteboard. You're looking at it, and it was like, "Hi. I'm Katie," or something, and you'd click it. And it would just go to the next jpeg. And it'd be like, "I wrote a book called Cool Book. You'd click it, and it would go to the next jpeg. It was just a slideshow of clicking jpegs.
Then they were like, "I don't know how to make a website, so I just used this." Then it turned out it wasn't a whiteboard but they just cleaned all the crap off the top of their refrigerator and pointed the camera at the top of the refrigerator and were drawing. They had one zoomed out one and be like, "Not kidding." [Laughter]
Dave: [Laughter]
Chris: And at the end was just a link to Amazon or something. It's kind of an experience, and it felt very honest, like they actually didn't know how to make a website.
Dave: Yeah.
Chris: But got it done to the point where it was probably better than your average website. You know, assuming it had the proper ALT tags and stuff.
Dave: Yeah.
Chris: But it was funny.
Dave: Awesome.
Chris: Here's one. So, let's say you want to make something really popular, but for developers, a framework, right? You want to help. You want to give developers a platform, a framework, or something to help them build websites.
Dave: Mm-hmm.
Chris: Dave's framework.
Dave: DaveJS, yep.
Chris: Yep, and it doesn't have to do everything, but it could. Okay?
Dave: All right. Okay.
Chris: You get to choose, Dave, how much opinions the Dave framework has. So, we looked -- on our YouTube show, we looked at petite-vue.
Dave: Mm-hmm.
Chris: We even talked about it a little bit on this show. It's, in my opinion, very light on the opinions. It doesn't care about build tools. It's just a little sprinkle-on kind of thing, so it's helpful. But as far as opinionatedness goes, it's not very high on the scale.
Dave: Right.
Chris: Pretty, pretty light, but it does have some because it expects some particular HTML attributes and stuff. You might even argue jQuery is even less opinionated because it didn't impose anything on your HTML. It was like, do your HTML exactly as HTML is, and I'm just a little library over here doing nothing. Pretty lightweight.
You bump up the scale, and let's imagine a totally other side of the scale, which would be like Rails, a classic thing put in the opinionated bucket because you've got to do your templates like this. Your controller has got to be in your controllers folder. You've got to pick a database that's compatible with one of the ones they work with for open record or whatever it is.
Dave: Mm-hmm. Yeah.
Chris: Pretty opinionated, but it wasn't all the way over because at least you had some choice in - I don't know - how you style things.
Dave: Yeah.
Chris: If you wanted to just write CSS, you can. And there are only some databases. You know you have a choice of some databases. It's not just one.
Dave: Right.
Chris: Then you look at -- you know we've talked about RedwoodJS on the show. It might even put it even more opinionated because it has just about as many opinions as Rails did but then said, "Well, this is the database storage you're going to use, you're going to use GraphQL, and you're going to write your components like this. It's going to be React. You have to write things in this way." Probably even more opinionated.
Dave: Yeah.
Chris: I think of Meteor, too, which was a full-stack framework, meaning it really cared about the database you were using, too.
Dave: Mm-hmm.
Chris: It wanted -- everything was media. Then there's like React, which is somewhere in the middle, and maybe old-school Vue, like going to have a build process and stuff, but I don't give a crap about your database. I have no opinion whatsoever about that.
Quite a spectrum of opinionated versus not opinionated as far as frameworks, libraries, and stuff. But your goal in life is success, and we're going to measure success by one metric, which is how many people use it.
Dave: Mm-hmm.
Chris: What would you do? It seems like it would have to be open-source, right? Because you're never going to get mad usership with closed-source, right?
Dave: Oh, yeah. You've got Flickity.
Chris: That's true, but is it wildly successful or is it just a tiny bit successful?
Dave: Yeah, and maybe that's still open-source.
Chris: Yeah. I mean if there's Microsoft Word or whatever, I know that's not website, but it's not like closed-source can't be huge - because it can.
Dave: Right. Yeah. Okay.
Chris: As far as website frameworks.
Dave: Open-source, for websites, because we were, before the show, talking about trust. You need a trust bucket.
Chris: Ooh.
Dave: Open-source says, "Hey, you can browse all my code." Right? So, I think open-source is kind of critical.
Chris: I love the trust angle because it's like that's why if Google drops a new framework, like it or not, a lot of people trust the big name behind stuff.
Dave: People use it.
Chris: That's why when you're just some solo developer and you try to drop a framework, even if it's certifiably genius, you don't have -- you've earned zero trust points.
Dave: Right.
Chris: Nobody trusts you.
Dave: You've got to build it, and so you have to have trust coming into it. That's Facebook - very popular.
Chris: Mm-hmm.
Dave: They offer a lot of tools: React, Jest. These are all Facebook projects. GraphQL, I think it's moved on or something.
Chris: Yeah.
Dave: But it originally was a Facebook thing. People jumped on it because they were just like, "Oh, Facebook uses it. Facebook is big. I'm going to use this." Now, maybe that trust is kind of kicking them because the governance of React and stuff like that is kind of tied to Facebook, et cetera, et cetera - long story.
One way to get trust is to just be open-source and say, "I know I'm writing code. You're installing it. Here it is. It's all open."
Chris: Yeah.
Dave: "Check it out if you need to."
Chris: Right, and I think open-source means that you can put a license on it such that people who really need to care about that (which is most people, I'd say) that you can put that license on it such that they can use it and not have the red tape of, "Are we paying for it? Is this okay?"
Dave: No, I mean yeah.
Chris: But on the opinionated scale, where would you go? Would you try to pull it light or would you go heavy, heavy, heavy?
Dave: I think if I'm going for mass adoption, I would be pretty light in the opinions. And if I was going for utility, I would probably be heavy in the opinions, if that makes sense.
Chris: Hmm.
Dave: But sometimes, like you said, that can be a foot gun. That can come back and bite you. I like Redwood. I don't use React, but that would be a tool I would reach for. It's sort of like Next with more rules, sort of [laughter], is how I'd put it. I would consider using it just because I like that sell part of Redwood where it's sort of like, "Hey, all your components, they're going to have a loading state. They're going to have a success state."
Chris: Yeah.
Dave: "And an indeterminant state and an error state," I think. But I think, for me, that's very forward-thinking, and I would like to have that constraint or that convention in place. I like conventions. I'm generally somebody who likes conventions.
I like Rails. Rails was awesome. It had some memory problems and gem breakages were brutal, but there was a lot to like from a developer perspective about Rails. I did not have to worry about authentication or user system. You just gem-installed devise and it's there, right?
Chris: Mm-hmm.
Dave: The whole entire user system.
Chris: You can't argue that that was successful, right?
Dave: Right.
Chris: That was great to have those opinions.
Dave: Hugely successful. Twitter.
Chris: Even things like Bootstrap or whatever. Even Tailwind. They were helping you make choices. There's a lot of evidence that developers like being told what to do.
Dave: I think it eliminates so many micro-choices you have to make along the way. I'm using Nuxt, which is pretty high on the convention, high on the pre-made decisions level.
Chris: Sure. Yeah.
Dave: Such that, at Nuxt Nation, which is a conference that just happened, a lot of questions were like, "Why should I use Nuxt instead of Vue 3 or with Vite?" It's a good question because they seem to do a similar thing. They do static compilation of things. But Nuxt is just sort of a group of conventions and stuff around programming patterns and so, in Vue, Vue programming patterns.
Chris: Is there some nuance to this? If Newt -- Next-- Newt. Wow. Maybe they should--
Dave: Newt Gingrich? No. No. [Laughter]
Chris: Yeah. [Laughter]
Dave: Newt. Newt could be the next Nuxt form.
Chris: Yeah, Next 4.
Dave: No one has Newt.
Chris: No. I don't think so.
Dave: Yeah. The logo makes itself. But there are always kind of ways to break out, right? It's like you can do routing this way. But if you want to do your own routing, go ahead. Is that the escape hatch here is that opinionated is good but you can always not use the opinion? Yeah.
Dave: Yeah, I think that's probably it. But that's just like I, Dave Rupert, don't want to write a router. I don't even want to figure out how to put Vue router inside a very big Vue project. I want somebody to do that for me if I'm going to go into a framework. If I'm not going to go into a framework or have deemed I don't need to, then I'm just going to - whatever - file system route.
Chris: Mm-hmm. Mm-hmm. Okay. So, opinionated is good, but you'd go light.
Dave: I think ejecting is--
Chris: Even though you like opinionated.
Dave: Yeah, I would go light for mass adoption just because I feel like that there's this thing.
Chris: Yeah.
Dave: Did you ever read Scott McCloud's "Understanding Comics"? Did you ever?
Chris: Absolutely.
Dave: Remember when he was talking about the level of detail and how people -- you have a Charlie Brown face or a smiley face on the left and then you have a Charlie Brown face. Then you have--
Chris: Calvin and Hobbs or something.
Dave: Calvin and Hobbs. Then you have full-on Superman from the 1930s, ultra-detailed, grizzled face.
Chris: Yeah.
Dave: There's this weird projection thing that our brains do where you see the Superman, the fully detailed picture, and you're like, "I don't know that guy," or "I know that guy. That guy is Brent. Brent was in my college dorm room. We know each other. He's weird."
Chris: Okay.
Dave: I already have a feeling. But when it's the Charlie Brown face or even just whatever circle with two dots and a smile--
Chris: Yeah.
Dave: --you're able to project yourself onto that face. You can say, "Hey, that's kind of me."
Chris: Mm-hmm.
Dave: I think, when you're vague is the point I'm trying to make. When you're vague, I think you can get a lot of people to project or see what they can do with that, and that vagueness works for you.
Chris: Interesting. Can you draw one parallel to a technology with the vagueness?
Dave: I think about Vue right now. Over in the D-d-d-d-discord, we've been having discussions about, like, "Hey, this petite-vue is a lot like Alpine. Hey, this other Vue has a new static compilation thing that's a lot like Astro." You know? [Laughter] And so, Evan You is doing a lot of stuff with Vue that we're kind of like, "Hey, this looks like this other project." I think that's cool. I think it's A) this big flex that Vue is doing, like, hey, Vue is set up and built in such a way now with Vue 3 and all its component system, reactivity systems all broken out, that it can actually take different shapes. It can become different things. I think Vue is doing a pretty good job of, hey, this does different things. It's a tool, but it kind of does different things.
Chris: Yeah. Does that speak to extensibility, too? I guess that's similar to ejecting is that you could go. It's almost like a different spectrum because you could go light or heavy but still have it be very extensible or not extensible at all.
Dave: Yeah. Yeah. I could kind of make my own Vue project, Newt, and [laughter] I'm going to make Newt with the Vue reactivity system, and then I don't even know - whatever.
Chris: Yeah. I've definitely seen products that promise pluggability where nobody cares, also. So, that's yet another spectrum is, like, "Cool. You made it extensible, but did you do a good job of making it extensible? Is it attractively extensible?"
Dave: Yeah. Yeah.
Chris: Or is it not so much?
Dave: Do you want to build on it? That's the thing is when you show this, do people's brains kind of get working? Like, "Oh, I could use this." I think that's like Svelte. The compiler does too much maybe for me. It's on the, like, "Oh, it's doing too much," side of things.
Chris: Okay.
Dave: But when you look at a Svelte component, it is so simple to read. It is so easy to understand what's going on because it's like, let counter, and then counter plus plus.
Chris: Right.
Dave: That's how you make an incrementor.
Chris: I almost seem to unlearn that stuff because I saw you being very excited about that the other day, especially in comparison to how even really simple state in React is handled where you have to use state, and you have to use the function and stuff.
Dave: Use effect and.... Yeah.
Chris: Which is so embedded into my brain that I'm like, "I like it."
Dave: Mm-hmm.
Chris: It makes a certain amount of sense to me, especially because when you are that explicit about it, and let's say I have a counter and a set counter, and then I pass set counter to a child, and I use set counter in the child, what I'm also saying is when that change re-render anywhere that needs that state that I'm also passing around, I like that where I'm like, now that I have counter and I update counter, how do I pass that around and know what's going to happen when I do pass it around?
Dave: Mm-hmm. Yeah.
Chris: Because there's no ceremony at all, it makes me understand it less.
Dave: Yeah. No, and I think that's the critique is too much auto-magic. That was one of Rails' critiques. It kind of does too much.
Chris: Right.
Dave: Because you could gem install Responsive Web Design.
Chris: It comes up weekly at CodePen, still, ten years later. We're like, "Ooh, a little too magical there, Rails." [Laughter]
Dave: Isn't that weird?
Chris: Yeah.
Dave: You're like, "You made my job too easy.
Chris: But you change as a company.
Dave: Yeah.
Chris: It's not that Rails changed necessarily. It's that our needs and demands have altered as well. Sometimes you want the magic because you're two people and you don't have fricken' time to screw around with everything under the sun. You know?
Dave: Yeah, and I think Rails has kind of increased its opinions, you know. It's, ask that pipeline how we're going to do this. We're using Webpack. Then I think they just said, "We're not using Webpack."
Chris: Hmm.
Dave: Then a lot of people -- and they were using Spring for a while. I don't even know if that's still going, but there are a lot of posts about how to undo every Rails default. [Laughter] Set this config to no, no, no.
Chris: Yeah, so it seems weird. Yeah, I think they're headed towards Tailwind, and you're like, "Well, that's going to get really weird then."
Dave: See, and that would be a situation. Not beefing with Tailwind, but it's not my flavor. That would be like, "Oh, man. That's not fun for me." This is a lot to undo now if everything is using Tailwind.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by HubSpot. Whether you're launching your business or ready to take things to the next level, building a seamless digital experience for your customers is a great place to start. Picking a CMS that integrates to your website and the marketing tools can be tricky. Cobbling together potentially unreliable plugins often isn't ideal.
At HubSpot, they are thrilled to introduce CMS Hub Starter, a simple but scalable content management system built on top of their CRM platform for businesses that want to generate leads through their website. At $25 a month, CMS Hub Starter comes out of the box with all of the standard features needed for a fast, secure, reliable site. Plus, they handle platform management so you can spend more time developing remarkable experiences. Learn more at hubspotdev.co/cmshub.
[Banjo music stops]
Chris: I had a weird one. We use their asset pipeline, still. This is just interesting because it's a spotlight into how things get weird sometimes. The asset pipeline can help you run Sass, right? But it's old Ruby Sass.
I think there's discussion (and it hasn't gone anywhere) of Rails moving up to Dart Sass then Canonical Sass. It's not there yet.
Dave: Mm-hmm.
Chris: Eventually, that becomes untenable. It's too old. Ruby Sass is ancient - already.
Dave: Yeah. Yeah.
Chris: What's going to happen? I don't know. But fine. Okay. Whatever. It's built into the asset pipeline. That didn't turn out to be a big problem for us, but then asset pipeline can also decide to compress your CSS, too. Not just process the Sass, but then also minify it, remove the comments, remove the white space, and all that stuff.
It turns out, asset pipeline just uses Sass to do that also, which makes sense because that's one of the output modes for Sass is a compressed mode. But it doesn't just run your Sass in compressed mode, which would make logical sense to me. It runs your Sass and then (later in the asset pipeline), it runs Sass again to minify it. It's usually fine because the output of Sass is Sass compatible, so it just runs twice.
Dave: Yeah. Yeah.
Chris: Maybe not as efficient as it could be, but it seems okay.
Dave: Right.
Chris: But Sass has an HSL function in it that it takes over your HSL and does something. Hence, you know--
Dave: Oh, okay. Yeah. Yeah.
Chris: Obnoxious, so we're like, "Okay, don't do that because we're going to pass this custom property to HSL, which is not what it expects. So, we'll just do the thing where we wrap it in an octothorp, curly brace, HSL, "leave me the hell alone," escape hatch. But then it would bug out when we push to production, and it would say, "HSL is not a function," or "It doesn't have the correct parameters." IT's because it was running Sass twice! So, it would rip off the escaping and then run again. And it was just a very insidiously weird bug to figure out.
Dave: Mm-hmm.
Chris: And we had to just tell it, "Okay, Rails. Don't use Sass to compress. Just do nothing, actually, because our Cloudflare already compresses CSS on the way out."
Dave: Yeah.
Chris: "So, just leave it alone," which sped up our build process a little. That's the kind of crap you have to fight with.
Dave: Yeah. Now you've got a Cloudflare dependency, which you probably already had for other reasons, but now you have--
Chris: No, I almost prefer it. That's acceptable to me. Even shipping non-compressed CSS is almost acceptable to me. It's not amazing, but it's Brotli anyway.
Dave: Mm-hmm.
Chris: So, the savings that you get from Brotli are 10x the tiny amount you get from not compressing before you Brotli. It's still better to compress, so you might as well do it. But in the grand scheme of things, it's really not that big of a deal.
Dave: Mm-hmm. I don't know.
Chris: Okay. That was a lot. Sorry.
Dave: Well, so I was going to say another example would be 11ty.
Chris: Yeah.
Dave: Love 11ty. I'm a $16 million investor. It's fine. You know. Just giving them money. $5 a month over the next 300 years.
Chris: Yep.
Dave: It is not opinionated on your templating language, which was very strong, the strongest power. It says, "Whatever you want to do. Write a little adapter and spit it through."
Chris: Mm-hmm.
Dave: But it's also not opinionated on Sass, JS compilation, asset bundling, and stuff like that, and that's a feature I could use. So, it's like I love the unopinionatedness, but then there's also a feature I could use. I think they're all working on it. I don't want to--
Chris: I don't know. Yeah, it seems like there's -- I'm also on 11ty lever, and probably wouldn't. If I was the new CEO of 11ty, [laughter] I wouldn't say, "We're changing course. Opinions are going to get thicker on here." I'd probably leave it the way it is, but I think I would ship blessed solutions for all popular crap that people want to do.
Dave: Right.
Chris: Like all of them.
Dave: Yeah.
Chris: I don't know if that's a good use of resources or not, but I think it's too light and it's not great to me that you have to BYO all the time with every other thing you what to do with your website.
Dave: Nah, and that's, I think, just sort of the thing. That's Astro is kind of attractive because it does all the compilation, the Vite style, esbuild thing, and stuff like that.
Chris: But you only get what they offer. Let's say you want to use stylus or something. Too bad.
Dave: Yeah.
Chris: Then you can't.
Dave: You have to use--
Chris: That's the bummer.
Dave: --the weird Astro dotfiles or whatever.
Chris: Yeah.
Dave: Dot Astro file, which again are great. It's like a single file component kind of thing. But, yeah, where do you fall? Where's your sweet spot on opinionated versus not opinionated?
Chris: I don't even know. I think I lean more towards opinionated because I think it's easier to build opinions.
Dave: Mm-hmm.
Chris: It's like taking a bolder swing at things to be like, "This is good, I think, and you should try to do it like this. And if you don't like it, that's okay because the Web is a big place and you can just use something else."
Dave: Right.
Chris: But these are my opinions, so maybe you'll like them too.
Dave: I like to solve people's problems. You think about React itself. It came out with some big opinions, like, "We're going to do everything in JavaScript." You know?
Chris: You could argue the exact opposite, though, that they don't help you. They just help you with this slim layer of stuff.
Dave: Yeah.
Chris: But it's at the core, so you want it to do more. That's the thing with 11ty, too. It's like, "Hey, you're moving my files around, so you can't not be opinionated about processing of some stuff. You say you're not, but you are, in a way." I'm not accusing it of lying, but I'm like--
Dave: Right. Right.
Chris: --I have to tell you what files are okay to move over to my dist file, so you matter in my pipeline.
Dave: Right.
Chris: Everything has to play nice with you. React is sort of similar. It's like, "I need a build process. You're saying you're light, you're not opinionated, but everything needs to play nice with you."
Dave: Yeah.
Chris: So, you do matter. Yeah. Then how I structure my site and components and build everything up and pass props up and down. All that is impacted by the technology choice. Yeah. Okay. Well, that's very interesting.
Chris: Well, let's stay heady and weird for a moment.
Dave: Yeah.
Chris: If you will.
Dave: Stay weird.
Chris: This is a Sean Wang thing. We end up talking about Sean a lot. He's a good thinker out there in the world of website stuff.
He had a blog post a couple of weeks ago called "The Self-Provisioning Run-Time," which seemed very logical to me that was like, maybe the literal code that we write is going to say what it needs to run. Maybe that's too big of a simplification of what he's trying to say here, but that's what it seems like to me because we've been moving towards code as infrastructure, right? You don't just log into your host provider and click some buttons and now you have hosting. Then all your code depends on that hosting.
It's more like you write code that tells the host what to do, deploy it, and the host provisions what it does. Right? We're already there. At least some bigger companies are doing that, us included, and I think it's cool - code as infrastructure.
Dave: Mm-hmm.
Chris: But the code as infrastructure is separate. It's like a configuration file that says what you need. Maybe the code itself has that, like on top of each file or something. [Laughter] It's like, "I'm a Lambda."
Dave: Just like....
Chris: [Laughter]
Dave: Yeah. [Laughter]
Chris: Run quickly, please - or whatever. It doesn't say anything because it's just assumed that this is going to work. It's going to provision its own infrastructure. He makes a lot of points that things are already pointed in that direction anyway, so it's not much of a stretch of the imagination to keep going.
Dave: No, that's interesting. Back in the day, if you wrote a Bash file, you had to say, "This uses Bash," or whatever, or pearl file. You had to be like, "Exclamation user bin pearl," or something. You know? So, you had to kind of say, "This uses this," so that'd be kind of interesting to think about because I'm in a situation. [Laughter]
I'm in a situation. I made an app and built some functions and deploying via Netlify. It's great. I love it. But we had to build a whole backend service, and so now it's like, "Maybe we need to flatten this a little bit and pull all these functions into the backend because now we're kind of maintaining code in ten different places. It's kind of weird. It might be good to flatten it."
But I'm sitting there like, "Okay, cool. I can do that, but how many gigawatts of server am I going to need?" It would be cool if I could just say, "Hey, Digital Ocean, this has functions in it. Deploy these guys. Deploy this like this." It would be cool if you could tell any hosting platform that, Netlify included. Like, "Hey, this has a backend server. If you have to spin me out to a third-party that does servers, Heroku or whatever, that's fine. Just tell me what it costs."
Chris: Yeah, or you tell them what it costs. Be like, "I'm willing to spend $5 a month on this."
Dave: Yeah.
Chris: If it goes above that, either cut it off or tell me it's going to happen, or something.
Dave: Yeah.
Chris: And I'm willing to wait 500 milliseconds for a response. The faster the better, but that's the bar for this. So, if you can put it on something cheaper because that's fairly slow, I don't care. However, this needs to run for eight minutes. I don't really care where you put it. It just has to be able to run that long. You just express that, and then they deal with the provisioning or whatever. It just seems pretty logical.
Dave: No, I'd be kind of curious because it would be kind of cool. I'm just thinking. It'd be cool to describe in human terms what you need.
Chris: Yeah.
Dave: Like, "I need this to never fall down. [Laughter] I need this load-balanced. I need this," you know, almost like a cucumber sort of test or something.
Chris: Yeah.
Dave: Just like, "I need--"
Chris: I wrote a link post about Sean's post and that's what I put. I put some pseudo-code at the top that was human language bullet points describing exactly those things.
Dave: Yeah. I need Ruby. I need Node. I need Node V14.
Chris: Right.
Dave: That stuff would be super cool because you could just be like, "Hey, this is what I need."
Chris: And it's right next to the code that's living there, so they make some kind of logical sense. Like I said, we're already kind of headed in that direction, and some of it is because we're dumb. People are writing this code that don't have extensive dev-ops experience, and I like that because I'm just one person on a Sunday. I don't have a team, but I have big dreams. I think that's legit and that code auto-compile stuff can help you accomplish your dreams without needing to know so much stuff because it's a tall order, man.
Dave: Oh, I'm burnt down by it. Yeah. I don't know how many gigaflurps I need. You tell me, dude. [Laughter]
Chris: Yeah.
Dave: You know? I don't know.
Chris: [Laughter] Exactly.
Dave: But I think that's the -- what is it called? The tension is that hardware nerds are like, "Cool. We've got double Lambdas now. They never expire. They just run forever. Double Lambdas, they're amazing." You're like, "Well, I want to use double Lambdas, so I'm going to have to figure out how to make that happen in my toolchain pipeline," because they didn't offer a "just use double Lambdas function" or whatever descriptor. So, you have to come up with your own tooling to do that or use somebody else's tooling. It's not easy.
Chris: Yeah. No. I hope some people see this coming so far ahead that they come up with some standards. That it's not just like--
Dave: Because if I could be like, "I need a Postgres. I need a Mongo. I need a Node server, and I need functions."
Chris: Yeah.
Dave: Then I need an HTTP server on a CDN that distributes my Nuxt app. I would be golden.
Chris: Yeah.
Dave: That would solve 100 problems right now.
Chris: Remember Perch? I think Perch is still around, but it was that Rachel Andrew and Drew McLellan's thing. You could do this thing with the CMS where you didn't pre-design the fields that you needed. You just used what you thought would be available in the templates.
Dave: Mm-hmm.
Chris: Then it's like, "I see what you're trying to do. I will make the input fields for this type of content just available." You never had to say, "I need an image field." You just would use an image field in the template and it would put one there, which was clever.
You could go a step further and be like, "It will even make the data model, too." It would make your Postgres schema or whatever the hell.
Dave: Like image one, two, three.
Chris: It seems crazy, but maybe.
Dave: No. See, that's -- I mean I'm using Prisma. Prisma, it's like an ORM (object-relational mapper). So, I feed it JSON. It converts it to SQL using a little rest app, rest client, and then it makes efficient Rust queries to my actual database - secure everything.
Chris: Yeah.
Dave: I like it, but one of its features is you can do Prisma introspect, and it'll go hit a database that already exists and write out the whole schema for it. That's a thing databases can do - or whatever.
I'm actually in the process of decommissioning an old Rails app, and I was like, "Hey, this would be really cool if I could just introspect and get the database. Now I have all the data for when--"
You know? And so, I just hooked it up. It took about five minutes, and I have the whole schema. Then my JavaScript now knew what was going on. Anyway, it's cool. It's cool.
Chris: Prisma has its own little language.
Dave: Yeah.
Chris: But it works with GraphQL, too?
Dave: It does. It does.
Chris: I saw a demo on Hasura the other day. Are they really similar? It seems like they kind of are.
Dave: Hasura, I think, is more the GraphQL face on a Prisma or on a Postgres. Does that make sense?
Chris: Yeah, it does.
Dave: You have your database and, in front of it, you have Hasura, which creates a GraphQL explore API endpoint kind of thing.
Chris: If you were going to use that, why would you need Prisma? You just don't, really?
Dave: Prisma works from the other end. Prisma would be like, in your Node app, Prisma just hits your database straight.
Chris: Yeah.
Dave: It's not GraphQL, technically, but you could set it up to use GraphQL.
Chris: Man. They still seem similarish, but I guess I kind of get it. It just depends on what flavor of code you like to write, I guess.
Dave: Yeah. Sort of. Yeah. I like it because it's a little bit more like Active Record and it does migrations, which is kind of a cool feature.
Chris: Oh, right.
Dave: So, if I have app 1 and app 2 - whatever - instance 1 or instance 2 and I need to upgrade them, I can just run the migrate tool and it'll add the right columns or rename columns or whatever.
Chris: That seems like a smarter move long-term that the tool actually helps you make choices like that.
Dave: Yeah, and that sort of like was my thing, but then there's also Supabase, which is cool. It's just like JavaScript that connects. Anyway, I just need to maybe use it.
Chris: Yeah, but then what if you need a migration on your Supabase? You've just got to make it a little more calls to the wall?
Dave: You've got to click some buttons. You get a GUI, at least, to go make those migrations. [Laughter]
Chris: Yeah. [Laughter]
Dave: That's cool.
Chris: So many tools these days, you know. I'm not sure. I'm still old school enough that I'd be like, "I don't care what you want me to do. I'm going to make my database. It's my schema. Then I'll layer tools on top of that, but I'm not going to trust anybody else for my actual data store."
Dave: Yeah. I think there's -- yeah, I think that's why people like Mongo and stuff like that because you can just chuck JSON at it, and it's like, "Cool. I'll take JSON. I store that." You know? It doesn't care. You could change the name of your title field 100 times.
Chris: This stuff makes me sweat, though. There are so many choices to make.
Dave: No, and I think the tooling around databases needs to get better. We made 22 jumps on the front-end of your website but the database (even the back-end in just Node, Go, and whatever), but the back-end or the database layer is still very, like, "I hope you know SQL." [Laughter] I think we're close to having a better system. I don't know.
Chris: It seems like both Hasura and Prisma are capable of that. I actually don't know SQL. So, at some layer, it actually produces the SQL for you with cleaner syntax.
Dave: Yeah. Yeah, and I think it does. You just basically have - whatever - a DSL. Is that what they're called? Domain-Specific Language.
Chris: Mm-hmm.
Dave: You have a way to ask the database for things that feels very JavaScript-y, at least in Prisma.
Chris: Yeah, that's got to be it, right? It always comes down to that. "Oh, it's JavaScript, so I'll use it." [Laughter] You know? That's why we use cloud functions because it opens up the door to this cloud stuff that you don't have to write cloud functions in JavaScript. I'm sure lots of y'all smart people write them in Go and crap, but I write them in JavaScript because it's just natural and easy to me, and now I don't have to provision anything. It's opened all these doors for me. That's why I'm like, "Well, fine. Keep opening doors for me. Thank you very much."
Dave: No, I mean--
Chris: I want to learn anything. I just want to write simple configuration.
Dave: No, it's so -- it's that JavaScript is taking over the world kind of thing, or always put on JavaScript, or whatever. But it ends up being this, "Oh, I can do that, so now I'm getting myself into trouble writing database services." [Laughter] I don't know.
Chris: It reminds me. I just saw this the other day. I don't know how new it is, but Google has got this project called ZX.
Dave: Okay.
Chris: It's like a way to write Bash or whatever, scripts like CLI stuff, but you just write it in Node.
Dave: Oh, weird. Okay.
Chris: Which means that you can use await, so you're constantly doing await$ template literal (write the stuff that you want to happen at the CLI) and then it'll wait for that to finish. Then run your next command - or whatever. I think it's for me.
Dave: Yeah.
Chris: It's like, you want to write a little script, but I don't want to learn Bash. I'd rather just write it in JavaScript.
Dave: No. Yeah.
Chris: So, I don't write it in Bash.
Dave: Now you can just - whatever - do whatever weird kind of stuff you want to do.
Chris: Doesn't that look good? It looks fricken' popular.
Dave: Yeah. It's already like 22,000 stars, 23,000 stars.
Chris: Yeah, so if I can be written in JavaScript, it will, right? Don't they say that?
Dave: Isn't that weird? It's weird. As much as we complain about JavaScript, you're like, "You can write Bash in JavaScript now," or whatever. [Laughter] You can write Bash apps in JavaScript, and we're like, "Whoa!" 23,000 people come out of the woodwork to be like, "That's cool."
Chris: [Laughter]
Dave: You know?
Chris: Yeah, it opens doors that were closed before.
Dave: Yeah.
Chris: It doesn't mean, "Don't learn anything new," because I'm a little nervous about that, like, "I'm not going to learn anything. I'm just going to wait for JavaScript."
Dave: Don't learn anything new. Typescripts is totally overrated. Don't learn anything.
[Zelda & Chill - Song of Storms - Mikel Lofi Remix starts playing]
Dahn: Hi, friends! If you are looking for gaming hot takes and standouts from a team of filthy casuals, then you should be listening to Aside Quest.
Dave: Every month, me (Dave), Dahn, and Zach deliver updates on our time-starved, favorite hobby through the magic of the Internet.
Zach: And with our combined 80 years of video gaming experience, we provide some soul balm for that weary gamer heart.
Dahn: So, check us out on your favorite podcast listening app of choice and follow us on Twitter, @aside_quest.
[Zelda & Chill - Song of Storms - Mikel Lofi Remix stops playing]
Chris: All right. Let me do some rapid-fire CSS because this is on my brain, right?
Dave: All right. Hit me. Hit me. Hit me. Hit me.
Chris: Like how crazy CSS has gotten.
Dave: Oh, yeah.
Chris: Crazy CSS time. All of a sudden, W3, they announced news. There's a draft for nesting.
Dave: Mm-hmm.
Chris: Do you want it?
Dave: Yes.
Chris: Do you love it? Nesting.
Dave: Put it in.
Chris: Yeah. Hell, yeah. So, you have to use the ampersand in the spec that exists today.
Dave: Mm-hmm.
Chris: like Sass has an ampersand, so it works exactly the same way that Sass does, except for that, in Sass, you don't have to use it if it's implied that it starts with it. You know? Which is pretty nice.
Dave: Right.
Chris: But you know any time, like if you want to use it later in Sass, then you use the ampersand if you want to sprinkle it in at the end of the selector, in the middle of the selector or something.
Dave: Yep.
Chris: If you want to do that in CSS, you have to put @nest at the beginning of the line. Then you can put the ampersand wherever you want. But otherwise, the ampersand has to be first and you have to use it. Although, I did hear some little rumors that maybe just maybe @nest would go away and that, in order to do nesting, you use double curly braces. So, .l{{, and that says, "I'm doing nesting now," and then you don't have to use the ampersand at the beginning anymore, which I like because the ampersand isn't my favorite.
Dave: Yeah.
Chris: Then you don't need nest anymore. You can use the ampersand wherever you want.
Dave: Interesting.
Chris: I don't know. I don't know if that'll last. I don't know if people are excited about that. That's just a murmuring. I don't think that's actually in the spec yet.
Dave: Okay.
Chris: But cool.
Dave: Yeah.
Chris: Okay, so we're both plus one on nesting. Big deal, especially if they get media queries in there, which I think they have.
Dave: Yeah. I am so used to -- like, it's the one part of Sass I love and will never give up. That is the ability to make a clean, little component, a little three of three nested things. It's beautiful.
Chris: Yep.
Dave: So--
Chris: Yep, so let's jump to scoping then because that's related (in a way) in that sometimes just putting a selector on something is the same as scoping anyway. You're just saying--
Dave: Right, right.
Chris: --anything under the selector is scoped, so there's that. But this is scoping with an @scope rule, which has a couple of interesting aspects to it, one of them being the donut scoping. You can say, "Don't just scope this selector, but only scope it down to when you see this other selector, and then stop scoping."
Dave: Right.
Chris: Which has its own little interesting use cases. I think of stuff like, will you have typography inside of a card or something? You want it to not mess with that. The typography is just global only. Leave it alone. Don't let the color cascade down into it - and crap like that.
Dave: Yep.
Chris: That's pretty good, although I'm not 1000% excited about that. But there's this aspect of having the scope apply to the nearest selector that matches it, which is really good for dark mode and light mode. A little hard to explain, but we could do a video on that some time.
Dave: Specificity jump, sort of. Yeah, we could do a video on it.
Chris: Pretty neat. Yeah. Yeah, but one jump or something.
Dave: Yeah.
Chris: Anyway, it's neat, but are people foaming at the mouth for it? I don't know, but it's big and weird for CSS. As far as like, "Wow! That's new crap for CSS," for sure. It feels similar as big of a deal. Maybe not as big of a deal but is similar in complexity and wow factor as container queries, to me.
Dave: Another thumbs up.
Chris: We had a little round of talking about like crazy because wow.
Dave: Yeah.
Chris: That's amazing that you can do that. It's in Canary, so you'd flip on the flag and you can play with it. All good.
But then all of a sudden, the other day, the same Canary, but you cannot do this with a flag. You have to go to the command line, find the little binary inside of Canary, and then open it at the command line with a flag.
Dave: Mm-hmm.
Chris: Have you ever done that?
Dave: I've done that, yeah. I mean it's whatever. It feels weird.
Chris: If you do that and pass it the proper flag, you can get container units to work too.
Dave: Uh-oh.
Chris: There's a build of Chrome with container units and they're QI, QX. There are like six of them. There's one with, like, you know how viewport units have V-min and V-max? There are versions of that for container queries, too.
Now, for the first time, you can say, "I want to set the font size" -- or the gap or the margin or the padding or anything -- to a percentage of the width of the container.
Dave: Love it.
Chris: Which is just fricken' nuts.
Dave: That's exactly how fit text worked was a percentage of the parent width.
Chris: Width.
Dave: Was what the thing, the text font size would size as.
Chris: Yep.
Dave: It's going to be -- we're talking - I don't know - edge to edge type blowouts. This is it. This is it. We're here.
Chris: Truly great, and it really makes container queries all the bit more useful.
Dave: Oh, yeah.
Chris: I don't really care which one we're going to drop first, but it seems like they're both there now and neither of them have made it any further just yet.
Dave: Yep.
Chris: But it seems likely to me that they'll drop similarly timed.
Dave: Yeah.
Chris: Why not? Beautiful, though. Really, really cool. They're the correct way to do responsive typography because it should be -- well, not always but generally, probably related to the card. Okay, container units. We did scoping, nesting, container queries, container units.
Chris: Now there's cascade layers. This is probably the most mind-blowing thing coming up in CSS where you write @layer curly braces. That gives it this new superpower.
If you have CSS outside of a layer and CSS in a layer, anything in the layer is going to win regardless, Dave, of specificity. You could have a baby little P-tag selector beat a selector outside of a layer with five IDs on it.
Dave: Mm-hmm.
Chris: It's infinitely more specific. That little baby P-selector inside the layer is just going to win. That's wild! Wild!
Dave: I think this is awesome for 100 reasons. You know I've had a lot of clients, like, "We're going to build this on Bootstrap." I can do @layer Bootstrap CSS. Boom. Now all my stuff goes above that.
Chris: Kind of. It's pending if you can link tag Bootstrap with a layer.
Dave: Oh...
Chris: They're saying they want to do that but, for now, this is within the CSS context only.
Dave: Well, I will go edit the Bootstrap CSS [laughter] and wrap it all in @layer.
Chris: You've got to have a layer on it.
Dave: Yeah, 100%.
Chris: Hell, yeah, you will.
Dave: I mean I don't know.
Chris: Yeah.
Dave: There may be some compatibility issues there, but this would be huge. Even just good citizenship or something, like @layer ads or something. I don't know.
Chris: Yeah.
Dave: There are a lot of positives that can happen here.
Chris: It seems like it'll clean up CSS. If I can have a layer that's called overrides that's the last layer and then I don't need to go and have little specificity wars.
Dave: Important ... town. Yeah.
Chris: Yeah. It's pretty good.
Dave: I think it's @layer important town would be the correct way.
Chris: Important town? Yeah.
Dave: Important town, and then--
Chris: Because I do think important still wins, right? Inline style still beat layers.
Dave: Interesting. Yeah.
Chris: So, there are still some -- you know what I mean?
Dave: Because that's the ultimate layer. We're just creating layers in our CSS layer.
Chris: And you know important is, in a way, even more powerful than inline styles is, but it doesn't have anything to do with specificity. It's just how one particular property resolves.
Dave: Mm-hmm.
Chris: You know what I mean? So, it's not really specificity-based, but I think important will still beat layers. Although, I'd have to look into that. That's weird.
Dave: Oh, see that would be deal-breaker for me. I don't know because you get into all of these, man. You open the hood on Bootstrap CSS or something; it's all importance. So, I would kind of need that to not win, but I don't know. Maybe. I don't know.
Chris: I don't know. We'd have to play with it. It's brand new. You can't even play with it yet.
Dave: You can't even play with it.
Chris: There's no implementation. Actually, there is an implementation of this one.
Dave: Okay.
Chris: Yeah, you can play with this one.
Dave: Cool.
Chris: But I don't know how final it is - or whatever.
Chris: Then the last one, @when, which is the same thing as @media. You could write @when max width 500 pixels and then put braces around it. It's the same as @media except for that with @when, it's a little different. You have to go @whenmedia and whatever.
Dave: Yeah.
Chris: The idea is that it can be multiple things, not just media queries. You could use @supports queries and stuff in there. But the whole point is that it's like a conditional statement that then also supports else statements, even a waterfall of them. So, it makes the syntax cleaner when you have to, you know, "This media query, otherwise this," which is otherwise a little hard to write in CSS.
Dave: No--
Chris: So, it's just a cleanup of that syntax, I think.
Dave: Like an if/else, yeah because I've had to do min/max or min-width 800 pix and then max width 800 pix to make mutually exclusive things, and it'd be cool if you could when-else. You know? That might be a better fit.
Chris: Yeah. It's cleaner to read, for sure. There was a little drama about maybe it should be called @if because if makes some kind of logical sense, but that's ... Sass. Oh, I don't care about Sass. Well, if is more of a -- when is more of a declarative syntax. There are some darts throwing back and forth, but I don't think there's any actual progress to move it away from when. I think when is going to win.
Dave: Yeah. Yeah, I would be curious, but again, I care 1% what it's called, or 10% maybe. You know?
Chris: Yeah.
Dave: I care 90% about when I can use it.
Chris: What it does.
Dave: And what it does.
Chris: Right. Now we think about all the stuff together. Wow. That's a lot of change in CSS. I have a feeling we got a little used to CSS moving together better.
Dave: Mm-hmm.
Chris: Like Grid and Flexbox shipped so close to each other and all that. A lot of these things we can use. You end up looking at "Can I Use" and you're like, "Wow! That's pretty - Wow! Good job, Gap. I can use you now."
Dave: Yeah. Yeah. Yeah.
Chris: Things moved pretty quickly together. I have a feeling those days -- I don't know if they're going to last.
Dave: Yeah. We might be heading into a weird zone.
Chris: These things are big and weird. I think, yeah, we're going to get to a thing where not everybody is dropping all this stuff together anymore. There's just too much of it.
Dave: Well, and that could hurt it. That could hurt CSS's reputation because a lot of these are non-polyfillable, like container, @container. I know Jonathan Neal has something that you can kind of shoehorn a Polyfill in. It works pretty good, but it's not quite the same - at least if I'm remembering it right. But @scope, you can maybe Polyfill or PostCSS or @nest you could maybe PostCSS. We're going to be in a weirdo state for a bit until all these features mature.
Chris: I think so, too.
Dave: There are always going to be one guy on Twitter who says, "Well, I still have to support IE 11."
Chris: Yeah, I mean I was at a meet-up and did cascade layers. People were like, "This is stupid and bad, and it's going to make it harder to reason about how selectors are applied." I was like, "Wow! I wasn't expecting that." You know?
Dave: [Laughter]
Chris: I'm usually surrounded by people that are like, applaud changes to CSS.
Dave: Like Jeb Bush, "Please clap." [Laughter]
Chris: Yeah. [Laughter]
Dave: Please clap.
Chris: I mean they had a point because I do think it's -- specificity has been in my brain for so long. To see a selector that's a weaker selector beat something that's a stronger selector is going to be like, "What?!"
Dave: No, that'll be weird. Yeah.
Chris: So, dev tools is going to need to make that real clear on day one why a weaker-looking selector is winning.
Dave: I'm already, like, "I don't understand," to be honest because I copied the selector from dev tools. I put it in my CSS. For whatever reason, my thing is not winning. Sometimes, even I'm like, "I don't get it, dude."
Chris: I know. It happened to me just this morning, I think. I saw a selector in dev tools and my thing was winning even though the one in the style sheet had an important on it. I'm like, "Why is mine winning?"
Dave: Why is it winning?
Chris: It was the exact opposite problem. [Laughter]
Dave: Yeah. No, there's - I don't know. It's already complex enough. But I think, again, we're maybe in a symptom solution or symptom and cause sort of problem, causation and correlation situation.
Chris: Yeah.
Dave: Because the reason I have 15 selectors all glarbed together is because I don't have scope. But if I have proper scope, I can just say, "@scope foo A tag, B tag, H1."
Chris: Yeah.
Dave: I don't have to do these five, six level selectors. I can just do really targeted selection.
Chris: Yeah, it's going to change the math. The math, for a long time, for me, was make it flat. Make it class-level selectors only. That way you just don't have to think about it that much.
Dave: Mm-hmm.
Chris: I wonder if that's going to matter less because you're like, "I don't know. Use really light. Use really heavy selector. Who cares? Overriding it is easy."
Dave: As long as it's scoped, it's fine. Yeah, I don't know.
Chris: Yeah.
Dave: I think we're just going to call this our prediction. Cube CSS really strongly positioned here.
Chris: Yeah.
Dave: Just that it focuses on component level styles, which you can do with scope.
Chris: Yeah. Once it's all together, then it's really going to rewire our brains a little, but I cannot pretend to understand exactly how I'm going to write CSS in the presence of native nesting, native container queries, native container units, cascade layers, @when queries that are nestable, scoping. It's like once all that stuff is in, CSS is just different.
Dave: I'm struggling with is and where.
Chris: Yeah, sure.
Dave: Even those are just like, "Wait a minute. I love that you used it. I don't know what's going on." Sometimes.
Chris: I saw a new proposal for a post on CSS-Tricks that I'm probably going to accept. I just need to figure out the best way to present it. It's that Elad guy. He's a pretty good writer about CSS. He's got an idea for a new reset.
Dave: Okay.
Chris: Which is fine. Everybody wants to be Eric Meyer [laughter] in a way.
Dave: [Laughter] I will become Eric Meyer.
Chris: But his reset, it's significantly weird.
Dave: Okay.
Chris: You know?
Dave: Good. Good.
Chris: It's weird enough that I was like, "Hmm..." So, it's making heavy use of all reset. Have you seen that in CSS? It's literally all properties.
Dave: Like all unset or -- yeah, yeah, yeah, yeah. I have a story about that, but finish. Finish.
Chris: Yeah, all unset, but he picks one of the keyword values. But then he's like, "But I don't want it on every, every, every, everything because there are some things that are bad to pull everything off of." I think he makes the case for, like, it's weird to pull it off iframes because iframes have that default size, and you can do stuff you don't want to do to an iframe.
Dave: Yeah. Yeah.
Chris: So, the reset is like :where:not iframe, SVG, and a bunch of stuff, and then all onset, so it's a way to target the things but also apply no specificity to it either because it's a reset style sheet, so you don't want to be fighting your reset style sheet.
Dave: Yeah.
Chris: So, it's like a zero specificity reset. It's pretty cool.
Dave: That's cool. I like that. No, I did all unset on something, like a button or something.
Chris: Yeah.
Dave: In a Vue component, and it trans -- in inline style on a Vue component, and it transpiled (with PostCSS) all that CSS. They all unset into like 500 properties - or whatever.
Chris: Yeah.
Dave: I was looking in my code, and I was like, "What the hell is going on? Who pasted 500 properties?" It was just all unset getting transpiled. Anyway, you've got to be careful.
Chris: Oh, crazy! I get it.
Dave: Yeah.
Chris: Oh, my god. That blows my mind.
Dave: Yeah.
Chris: Yeah, you should probably leave that one to the browser, if you can.
Dave: Yeah.
Chris: All right, so we have some questions from people we're not going to have time for today, but they've been coming in good, so we'll do a user questions show next week, let's say.
I'd also like to throw a shoutout to BuySellAds, we've worked with for ages. They do, you know, if you end up booking an advertising spot on this show, we generally go through BuySellAds because they help book it and get the content ready and make sure everybody is happy and most effective and everything is tracked and all that stuff. They do a great job, but I work with them on everything anyway.
It's a great company, I think. Successful and does advertising in really tasteful ways. They're one of the few ad networks that even if you have Ad Block Plus on your fricken' machine, BuySellAds ads come through because they do everything so responsibly that they're whitelisted on an adblocking plugin.
Dave: That's wild.
Chris: Which is wild, too. Anyway, this has nothing to do with that. They're hiring.
Dave: Oh! Okay.
Chris: A developer community manager is one of the roles they pointed out that they're hiring. They do Carbon ads. That's that really tasteful little, small ad that's once on websites on lots of different sites like Dribbble and Bootstrap.
Dave: DaveRupert.com.
Chris: And Feedly. DaveRupert.com, sure. They want to have somebody work on that but be, I think, partially the face of it that's working with those sites to help them make more money and just be with them, but also maybe grow that network and to be the community manager for BuySellAds Carbon and the native ad network, which is pretty cool. They have this JSON endpoint you can hit with a zone and get back a bunch of JSON data and craft an ad yourself.
Dave: Hmm.
Chris: That's what we do on CodePen a lot, so you can make ads look really integrated into your site and have them make money similarly to how Carbon does.
Dave: Nice. All right.
Chris: Pretty cool.
Dave: Yeah.
Chris: BuySellAds, they're hiring. Cheers.
Dave: All right, well thanks, 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 check out our YouTube, of course. We have a brand new YouTube over on the CSS-Tricks YouTube channel.
Chris: Yeah.
Dave: We've been posting about three-ish videos a week. Be sure to like and subscribe over there. And join us on 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.