552: Do You Want to Build a JS Framework? ☃️ CSS Wishlist for 2023
Austin power updates, what do you need if you want to build a new JavaScript framework, and what do we hope CSS brings in 2023?
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--prepper--Rupert and with me is Chris--comfy in the office--Coyier. Hey, Chris. How are you doing today?
Chris Coyier: Yeah. We had a tiny little leak in the ceiling the other day. That's about as bad as it gets around here. But the electricity (for the last five days), I'll tell, has been extraordinarily consistent.
Dave: Really? Okay. Good.
Chris: Yeah.
Dave: You've got all 120 amps, or whatever it is? [Laughter] Or 15 amps.
Chris: All the juice we need.
Dave: 120 volts, yeah, that's good. Yeah.
Not so much down here in Texas. [Laughter] We had to kind of cancel a guest, sadly. But anyway, we're back in action.
Chris: Yeah. Yeah. It was interesting. I could do nothing but follow what was happening there. But was that just one neighborhood of Austin? Is this a national emergency?
Dave: It was all over Austin. That was the weird part. We had a big ice storm come through, and at first it was like... So, when it rains, ice in Texas, when it gets icy, like below 30, they cancel school because Texas--
Chris: Uh-huh.
Dave: ...are stupid, and we drive too fast on the ice, and we crash, and it's not safe for schools and buses, blah-blah-blah. I don't like that... You know every other state up north of the Mason-Dixon is like, "Yeah, we're fine with cold. We drive on ice. That's fine." Austin, or Texas in particular, just does not handle it very well, so you'll just see videos of people careening sideways at 90 miles an hour on the interstate.
Chris: Eh...
Dave: It's not good, right? So anyway, it iced. They said school was canceled. Pretty uneventful. Then, boom, that night we work up to hear the sounds of popping, like tree branches falling.
Chris: Yeah, your transformers.
Dave: And transformers just going out. Like a tree branch came and karate chopped a patio chair that we had, an outdoor dining table chair, just karate chopped it in half, and also took out my fiber Internet.
Then we thought we were okay, like, "Oh, that was the worst of it," and then, boom, the lights go out at like 8:30 in the morning. And so, five whole days of no power, and it was brutal. We survived, though. Sent the kids over to a friend's house who had power. They lost power, but then they have a generator, so.
Chris: Oh, my gosh.
Dave: Anyway, it was a brutal situation.
Chris: Yeah. It reminds you how precarious all this is. You know? Just that one thing, you know? And how many other of those one things are there? You know, Internet and your water and whatever.
Dave: Well, yeah. I had thought about getting a generator after the freeze in 2021. A lot of people did. My friend John did.
Chris: Mm-hmm.
Dave: That's awesome. Cool. My neighbor did too, behind me. But we're not generator experts. The chance I turn the generator on next time and it works is probably pretty low. [Laughter]
Chris: Oh, yeah. Ask my snowblower. It's a journey every year to get that thing to work right.
Dave: Exactly. Right? So, I'm just like, in panic, and my generator is broke. I don't want to be in that situation, but whatever. But anyway, we could have got a generator, but then my Internet wouldn't have worked.
I don't know how your life is structured, but we are very Internet-dependent, I think. We have Netflix. The kids have iPads, Roblox. I do work on the Internet, so do I need a backup Starlink? How stupid do you get?
Chris: Hmm... Just because you have power doesn't mean you have Internet?
Dave: Right.
Chris: Is that the case?
Dave: Right.
Chris: Right.
Dave: We have overhead lines here in Austin. We don't have buried lines. That's not a feature of Austin, Texas.
Chris: Oh, yeah. They're pretty tied at the hip. Yeah, that's interesting. I don't know.
I mean, yeah, you're going to have to have... If your power and your Internet are 100% combined like that, I don't know.
Dave: I think most of the world has (or most of the United States, I should say) buried lines and stuff like that, so it's probably a lot less brittle than Austin. But yeah, we just had the ice storm hit us in the wrong place.
Chris: Yeah. I have a generator tucked away somewhere, but it's not a home generator. That's a different classification. I have one that you get it going, which I think I could get it going because it's designed to be really simple. You pour some gas in it. You pull the lever. You know?
Dave: Mm-hmm.
Chris: But it's only got a couple of 220s on it or whatever, a couple of outlets, and it's just for absolute emergencies like - I don't know - running a hot plate or something.
Dave: Right.
Chris: It certainly isn't going to make the outlets in your house work again.
Dave: Yeah. There are little things you can wire up to make that work. Yeah, and then you need to turn everything off and go to critical systems or whatever. I don't know. Yeah, it's a lot to think about. We may bite the bullet and get a generator just because that was uncomfortable.
Chris: Mm-hmm.
Dave: And if it's going to happen, if I only have power 50 weeks a year, maybe I'll just get... [laughter] I'll just have a generator. I don't know?
But then it's like all this stuff is happening because of global warming. Weather extremes. Hundred-year events every year, right? Is me running on a natural gas generator helping the situation? Absolutely not. [Laughter] It is actually probably making the situation worse, so I don't know. Anyway--
Chris: That's interesting.
Dave: Then what happens when my natural gas goes out? Boom. Clog the pipe or explosion.
Chris: I wonder what we would have done as a family. I feel like we would have been, like, "And we're going on vacation!" [Laughter]
Dave: Well, that's the other issue. If they would have said, "Hey, we're not going to have power for five days," boom, me and my family Ted Cruzing it out of here. We're going to Cancun. You know what I mean?
Chris: [Laughter] Yeah.
Dave: We're out. But in stinking this realm, they're all like, "Oh, it's coming on, guys. We're working on it," you know, and Friday. You know? And it's like, "No, Monday is more accurate." You know?
Chris: Oh, gnarly you had to go through a whole weekend.
Dave: Yeah. Anyway, I don't know. I need a vacation from my forced vacation now, so that's my life here. Anyway.
Chris: [Laughter]
Dave: All struggles.
Chris: You wrote (maybe three weeks ago or so)... You made this just great little list of things that you'd have to do to make a new JavaScript framework, which was really funny but also true. By JavaScript framework, I think you mean let's say you want to be Solid.js or something. What does Solid have to do? Not necessarily. You know mean like a big one that has big ambitions, I think, was kind of the--
Dave: I mean I could tell you exactly. Here's what you've got to do. Ready?
Chris: Mm-hmm.
Dave: You need a library, but it has to be different from React. It can't be React because people just use... But it has to be similar enough that people who use React are like, "Yeah, this is cool. It's just like React."
Chris: You might even say you use JSX with our library too.
Dave: Might have to have JSX just to appease just popular demand, right? By popular demand.
Chris: Uh-huh.
Dave: You have to say it's fast. Solid does that. [Laughter] I'm not picking on Solid. You need ten influencers to get hyped up about it being fast. Right?
You're going to need a CLI. You're going to need a Linter, a formatter. You're going to need a build process, some kind of like... Vite is probably the cool thing, but you need a custom Vite extension, you know, whatever, like Vite plugin my framework - or whatever.
Chris: Mm-hmm.
Dave: You need a custom file extension. You can't just have JS. It's got to be cooler than that, right? It's got to be LJS or whatever your thing is, right?
Then you need a component model, right? That's pretty standard, right?
Chris: Yeah.
Dave: You need types because everyone is using TypeScript now.
Chris: I'm starting TypeScript, yeah.
Dave: You need local and global state management, obviously. You know?
Chris: Yeah. That's funny, too, and you can't use it... It would be tricky to use an existing one. Ah, maybe I shouldn't say that. But you either need your own or it needs to work really well with an existing one.
Dave: Yeah, you need a concept of it, right?
Chris: Mm-hmm.
Dave: Right, and then you need a marketing site. You've got to build a marketing site. You need a doc site. You're going to have dark mode because that's really important.
Chris: On those two sites, yeah.
Dave: Yeah, you're going to have a plugin module system, right? You're going to have to have something like that.
Chris: Extensible. Sure.
Dave: Yep, and then you're going to need a dark mode module so that everyone can have dark mode on their sites that use your project. You're going to need a router. You're going to need an auth module, like somehow to connect to OAuth or something. You're going to need an image module to make it fast, like Nuxt Image, Gatsby Image.
Chris: Astro has got one, yeah.
Dave: Astro has got an image. Everyone has an image.
Chris: I suppose. Yeah, if it makes HTML, it's got to do something for images.
Dave: And then you need a meta framework on top. People are building apps, man. You've got to have a meta-framework, but you're building a meta framework just to build your doc site, but that's fine. We're making serious apps, but we're just building a doc site, right?
Chris: I see. Like you could not... Your core thing maybe doesn't need a router, but your meta framework better.
Dave: Yeah. Your core thing is really hotty about... really hot to trot about how it's unopinionated or whatever. [Laughter]
Chris: Mm-hmm.
Dave: But then you have a whole opinionated meta-framework that goes along with it.
Chris: You sweep your opinions to the meta framework?
Dave: Oh, yeah. Kick them down the road. You know? That's these jerks' problem.
Chris: [Laughter]
Dave: These are the opinionated ones. I'm cool, guys. [Laughter]
Chris: [Laughter]
Dave: What drugs is this? Yeah, I'm cool, guys. [Laughter]
Then you need the special doc site generator that competes with the meta-framework, like the DocuSource specific. I think 11ty just got one of these recently, right? It's actually pretty cool.
Chris: Yeah because there's, of course, a difference in an app-like framework or something that's generic enough to fit any Web application. But those are too generic for a documentation-specific generator.
Dave: Exactly.
Chris: Those. Yeah.
Dave: Because that one needs code highlighting.
Chris: That's right.
Dave: It's 11ty Notes from Sandroroth. It's pretty good, but you need that one.
Chris: It's got to have the sidebar as the main thing. It's got to auto-generate the sidebar.
Dave: Auto-sidebar, probably something like sidebar.yaml. It's got to be like previous-next buttons.
Chris: Sure. Right.
Dave: Move to GitHub.
Chris: The idea is you promise everybody. All you've got to do is dump your Markdown files in a folder and you get a doc site.
Dave: Yep, yep, but hey, we're a serious JavaScript app framework.
Chris: Hmm...
Dave: But anyway, we're building a static blog, a completely static documentation site. But whatever. We are a serious app framework, and so you need that, and then your meta-framework.
Your meta framework says, "Whoa! We need something special. We have to have islands," so you need island architecture. You've got to lazy load some components. But your meta framework can't just have islands. It needs to do server-side generation, SSR (server-side rendering), client-side rendering, universal where you split the dif, incremental static rendering or on-demand builders, kind of like on-demand generation, CDN-backed delivery, and edge functions. You've got to have all that stuff - boom - in your meta-framework.
Then all that stuff is really expensive, so you need VC funding to do that. Then you're going to achieve your goal of becoming a cloud hosting provider like Gatsby and then get acquired by Netlify.
Chris: [Laughter]
Dave: There you go. That's how you build a JavaScript framework in the year 2023.
Chris: Yeah, because you do all that work, which is not the work of one person anymore. It's a team. Let's say ten to start.
Dave: I think ten, minimum. Yep.
Chris: Yeah. That money doesn't grow on trees, let's say.
Dave: Ten developers who make $100,000 is a $1 million a year burn rate.
Chris: Yeah. Yeah.
Dave: Yeah.
Chris: We're starting to get to this weird thing where $100,000 for a developer is starting to be... I don't know. Maybe all these layoffs have brought it back down a little bit. But that's some pretty beginner-level stuff.
Dave: That would be, yeah. Yeah, that would be pretty low unless they live in a market where that is a good amount.
Chris: Mm-hmm. Yeah, but the ironic part is you almost have to bring your own fame, too, because not only do you have to be this great developer but, ideally, you're part of the marketing too.
Dave: Mm-hmm.
Chris: You have your own people you're bringing to this framework because you need the influencers, but maybe a little double duty doesn't hurt once in a while that your developers themselves are the influencers.
Dave: Yeah, I think we've seen that with very popular frameworks that got acquired by Shopify. We have seen that just happening time and time again.
Chris: You'd say there's some behind-the-scenes stuff, too, in that the influencers can work publicly, but they have to work behind the scenes, too. If you sense some criticism bubbling up on the framework, you've kind of got to reach out, quell, quell any rebellion against the nay-sayers here. Make them feel bad about their public criticism.
Dave: "Hey, guys. Real people work on this!" That's like auto-complete. You've got to have that in your text expander.
Chris: [Laughter]
Dave: You know? "I don't think it's fair because, like, real people are spending their heard earned venture capital-backed time on this, so like be nice." You've got to have that in the text expander. [Laughter]
I'm just digging a hole. I'm just burning bridges, aren't I? Yeah. I'm doing a good job.
Chris: [Laughter]
Dave: Hey. Again, tongue in cheek, but I do think this is what it takes to have a framework or all frameworks kind of evolve into this point.
Chris: There's some appeal to it, isn't it? It feels like, "Oh, wow! You did it. You made it." But there's also this irony that these are largely front-end technologies and the end state for these things is usually not that great. It's hard to play VC in this world.
What are you going to do? That's what one of your last bullet points is you've got to become a cloud hosting provider because now you're doing something that people are used to and okay with paying for. Whereas I better be able to NPM install X to use your thing. It better be free. The full framework better be free.
Dave: It's free forever, free for life, and I get to yell at you in GitHub. Yep.
Chris: Right, so you need something else, and we're all very certain that your Lemonade or your Patreon or whatever GitHub sponsors is absolutely not going to pay those ten developers. It's just absolutely not happening.
Dave: Yeah, that's $60 max.
[Laughter]
Chris: Yeah. So, there's advertising. That's not going to work.
Dave: No. No.
Chris: For developers, no. So, membership sometimes works. The early Remix days, they were selling, and I don't hate that. That's cool.
CraftCMS charges $100 - or whatever. They're still doing just fine. Saw those fellows at the PT the other day. Turns out we use the same [laughter] physical therapist.
Dave: Oh, good.
Chris: [Laughter] Yeah.
Dave: Making friends on the electro chair or whatever, right? You're getting electrocuted in the chair. Yeah.
Chris: Oh, you've got sacrifice your back. You should have put that as a bullet point in here.
Dave: Oh, yeah. Yeah. Yeah.
[Laughter]
Dave: Just fucking destroy your body.
[Laughter]
Chris: But I wanted to home in on one of them, aside from that was fun to dig into for a minute. But the fastness is fun to think about to me because usually they're not lying. These people are serious about what they mean, and you kind of have to say it. You certainly can't say nothing, and you can't say it's slow.
If you're going to do all this work, usually the underlying spirit of it is "I think I can do this faster," because there's been changes in technology that I can leverage, whether it's ESM or import maps or browser changes or not having to support older browsers. Something has changed that the way you can do it is faster.
Dave: At a fundamental level, if you use ESM versus not ESM, it's faster. Having script-type modules chucks you to a whole other browser JavaScript machine in Chrome. Just having module support and only modules, boom, you're faster.
Chris: Yeah, but we've already gone down a path. Now we're talking about browser fastness.
Dave: Right.
Chris: That's not always what they mean.
Dave: True. True.
Chris: Here are some examples of this is that Astro means that. They say, "Build faster websites." It's not 100% clear. It's got to be a tagline. It's got to be digestible and usable, so no shame in any of this. But I know what they mean is that they ship less JavaScript to the browser. Thus, the website itself is faster. They're saying build faster websites for users.
Dave: Mm-hmm. Mm-hmm.
Chris: But I don't think that's always what the goal of the framework and what they mean when they say fast is the same.
For example, Next is slightly more clear about it. They say... One of the sentences on their homepage that uses the word "fast" says, "An integrated, powerful, Rust-based JavaScript tooling for the fastest builds." That is probably, I think, more common that frameworks and meta frameworks use the word fast in conjunction with DX instead of UX.
They're saying it's fast in how fast it compiles and gets ready. It's fast in how you can preview it. How fast is it for you, the developer?
I've always defended that in a small way in that I do think that stuff matters, too. I'm not saying it's more important than what users experience. I'm never going to say that. But I'm just not going to poo-poo DX, too, because I like it.
Dave: I mean just straight up; I'm not going to use it unless it's fast. You know? I didn't use 11ty because it was 0.05 milliseconds slower than my Jekyll. I stopped transferring my blog over to it.
It's fine now. It's probably even faster. But that fastness, that's about feedback loops, right? When I hit save, I want it to - boom - be saved as fast as possible.
Chris: Right. Yep.
Dave: I think that's killed some things.
Chris: We have choices. I can do other things with my time and my life and stuff. I like the fast feedback loop. It does make me feel more productive. I agree that some of the criticism that says, well, it doesn't automatically translate.
The saying that good DX leads to good UX is largely debunked, and that's fine. But I still get to make choices about what tools I get to use, and I choose the fast ones.
It could mean faster websites. Although, it's hard to say that. You can provide a foundation for how fast the user experience is on a website. You can deliver a template that gets 100 on Lighthouse or whatever. But you can't promise that as a framework.
It's easy to screw up websites, and people do it all the time. Tricky, but you can say it.
If you're a project like Vite, you're also in that build category because you're not really a framework-framework. You're part of all these tools, so when you say speed, you are talking about builds, and you can say that. But you're also talking about not just the build process but then what happens after the build. In the case of Vite, they say lightening fast HMR, and they're talking about hot module reloading, which is the end of the feedback loop after a build.
Dave: Yep.
Chris: It's that tremendously satisfying experience where you don't have to refresh the browser. Not only CSS changes in there, but your JavaScript and, ultimately, HTML and DOM changes are put in there, too, without the refresh of the browser.
Nobody craps on this because it's just a developer concern only. But it is a little bit like client-side rendering for the developer. You know? [Laughter]
Dave: Yeah. Yeah, it's--
Chris: CSR for that world.
Dave: Yeah, and it's kind of - for lack of a better term - tweaker-y. It's like, "I'm going to save 1,000 times, and it better show up." You know? Whereas ancient days, I remember clicking a button in Visual Studio and compiling the website to see the change I just made.
Chris: Right.
Dave: There are very old ways. Anyway, but it's just this, like, "I'm going to hit save a billion times and I want to see it show up." You know?
Chris: That's right. I looked at the homepage for Nuxt just because that comes up in our Discord quite a bit, patreon.com/shoptalkshow.
Dave: Does it say it's fast? [Laughter]
Chris: Well, it brings up... The only time it uses the word fast on the homepage is because of how good the SEO strategy stuff is in Nuxt and that what you get is fast time to content for great indexing, meaning it's fast for Google to get updates to the content of the website. It's an interesting claim to make.
Dave: Mm-hmm. Mm-hmm.
Chris: Then I was listening to a podcast the other day with the main guy, perhaps, from Qwik.
Dave: Yeah.
Chris: Quick is right in the name. They put fast...
Dave: Oh, they bought in. They really... Okay. If they don't deliver, they don't deliver. Yeah.
Chris: Yeah. Interesting, and they're talking about ... in every way. But it is interesting that you've got to throw out the word fast, and it's rarely particularly well-defined.
You can kind of just say fast and developers just buy it even though what it means is all over the map, which is interesting, I think.
Dave: Are you collecting these, because this would be a really awesome--? [Laughter] It would be a really awesome - I don't know.
You did a recent blog post where you went through all the announcement blog posts for Interop 2023, and you were like, "What code do they use to announce it?" like for the timestamp, you know? Anyway, it was brilliant. It was peak content for me.
Chris: [Laughter]
Dave: Let's just look at this HTML for these browsers. Anyway, I love it. But it would be interesting when people talk about fast, what do they mean by it, and then what is their...
Chris: Yeah. That's kind of why I brought it up because it's on my "to blog" list, potentially.
Dave: In your drafts. I love it. Yeah because Nuxt has a second homepage. I don't know if you know that.
Chris: Hmm.
Dave: Surprise! I believe it's... I'm sorry. I'm in this new browser, but it doesn't have URLs. Nuxt.com.
They use it for, "Fast and furious, optimized with code splitting, tree shaking, fast by default so you can focus on building." That's developer-fast. But then they also have, "Ship faster with Nuxt modules."
Chris: Ship faster? See, that's a good one. I didn't bring that one up. Yeah.
Ship faster. Yeah, that's interesting. It reminds me of something. I can't remember what it is. But yeah, still it's another abstract usage of fast.
Does it make your team faster? Is the website faster for users? Or is the build faster? Which I think is kind of the most common one at the moment.
Dave: Yeah.
Chris: How fast does the library or do the processing that it needs to do is generally the most common one.
Dave: They use euphemisms like super-charge and performant is another one, too. That's what I saw on the Solid's headline. "Simple and performance reactivity for building user interfaces."
But yeah, there's a few euphemisms, right? But it's funny. That ship faster, I know DX gets a bad rap right now. It's under fire currently.
What I care about is that community module system. I don't want to go reinvent auth. I don't want to go reinvent Vuex. I don't want to go reinvent. I don't want to do that stuff or internationalization.
I want a community module that does that. Dave Rupert likes to code, but I do not want to reinvent whole big systems like that. I want to benefit from the commons. That part of shipping faster is actually kind of important to me, that ship faster aspect.
Chris: Interesting. I would have almost poo-pooed that because it seems so arbitrary to me. The speed in which you ship stuff has 100% to do with your team.
Dave: Well, and it's not always linear, like, "Oh, I'm going to NPM install this and solve my problems." That's what you think, and then you spend seven years figuring out what options this thing takes to make it do the thing you want to do. I feel like everyone has that story where I installed it, but it took five days to hook up. Now I wonder if I should have even installed it.
Chris: [Laughter]
Dave: That's a common thing, you know.
[Banjo music played]
Chris: You got another post. I did one of these, too. I was like, I'm going to think about the stuff in CSS that I still want, and it came over the year of, you know, I was on the Snowtacular - or whatever - the front-end horse thing.
Dave: Oh, yeah.
Chris: I don't know how I even decided that this was going to be what I talk about during that thing, but I started making something. I was going to show somebody. I was going to show off a particular feature that I thought was neat.
Here's the thing on CodePen. We have all these panels that you can slide around, and we're working on a new editor, too. There are arguably even more of that kind of thing going on.
It's surprising to me how complex the JavaScript libraries are for "I want to grab a thing and drag it."
Dave: Mm-hmm.
Chris: While it's influencing other panels, too. It's not so hard to just drag things around or make them resizable but make them resizable while influencing the size of multiple other things starts to get more complicated - yadda-yadda-yadda.
I started there and just there. Through that, it just went forever on, like, "Oh, that's hard," and it's a little bit doable, but I don't have choices in how it looks. I don't have any choices of how it's styled or how I can grab it. If there's text in there, I have even less options. How can I flow content from one to the other while I'm changing it?
It just cracked open this door of all this stuff that's still very hard to do in CSS, almost surprisingly. I put that into a post about what I want to see in CSS in 2023.
I'm not saying I started this because everybody blogs about their CSS stuff. You did it. Eric Meyer published his just yesterday. Tyler Sitcka did it from Cloud Four.
There are starting to be lots of these lists to reference of what people want, so maybe we can talk about that a little bit.
Dave: Nah. Yeah. Okay, I found... "Things CSS could still use heading into 2023." It's funny, man. There are so many.
2022 was a very good year for CSS. I think we should celebrate. Interop 2022 worked. That's where all the browsers were like, "Let's all work on the same things kind of generally, and we'll land them in a similar-ish timeframe." Firefox has kind of dropped the ball, [laughter] but I think all that stuff is coming March-ish or something (is kind of what I read last).
But anyway, it's very exciting, and so I just was thinking about 2023. I think we talked in our Discord, too. It was just kind of like, "Oh, man. You know what I want?" And a lot of my stuff was literally just stuff I want from working on Luro.
I needed a select menu, a styleable select. A user dropdown or a status dropdown is what we just rolled out. It's like, "Gosh, if I could just style this or put a user icon in this dropdown, my life would be fricken's sweet." You know?
Chris: Yeah. Right.
Dave: But styling a select, as hopefully all Shop-o-maniacs know, sucks. [Laughter] It's not there yet, but the select menu lets you kind of do that. Then related to that--
Chris: What always gets me is because developers want to do this, in a way because of frameworks that we're just talking about how easy it is to do the absolute basics.
I'm not sure where to place the blame because CSS helps make this easy. But let's say you have a div, right? The div can toggle back and forth between display block and display none. Inside that div, you put some more divs. In those divs, you put the emoji that you want to display or something that you couldn't otherwise display in a select menu, or you couldn't apply the CSS that you wanted to like colorize each menu item.
Then you put on-click handlers on each one of those divs inside the parent div. Now all of a sudden, you've built a select menu out of divs that does exactly what you want for people that don't use their keyboard, that are only on a desktop computer, that have no--
You know what I mean? It's so easy these days to build the wrong thing. What select menu does is it keeps it easy and does the 1,000 other things that are necessary to do to make it semantic and performant and accessible and all those things.
Dave: Yeah. I don't know. if I could get that, A) I would reduce code. You should see the code for our custom user dropdown. It's 400 lines of code or something like that, and a component we pulled off the shelf. It'd be cool if it just was easy.
Chris: Mm-hmm.
Dave: Then related to that, CSS anchoring was a thing that was talked about. I really don't know where that's at, but popovers. We have these little meatball menus, the little three dots that you click, and they give you other stuff you can do all over the app.
Chris: Mm-hmm.
Dave: We're using popper.js, I think, to do that.
Chris: Ah, yeah. Yeah.
Dave: Position that and show that. It's cool. It's fine. But man, we're doing it a lot. It would be cool if it was just as easy as detailed summary or something like that. Boom, arbitrary DOM On the top layer.
I even had the top layer problem. We wanted to use a meatball in a dialog, which is kind of terrible, but whatever. That's where we're at in life. Then we had where the dialog was on the top layer, and then that was overflow hitting and stuff like that.
Chris: Oh, no.
Dave: I just was like, "Oh, wouldn't it be better if that was on the top-top layer?" You know?
Chris: Is that a thing now with the new dialog thing? It just automatically is on top regardless of how deep it is?
Dave: Yeah. Yeah.
Chris: Woo...
Dave: Adam Ardell was telling me yesterday he had an issue. You know like when you write a bad code, and your React, Next, or whatever will give you an error on line 52, or whatever?
Chris: Mm-hmm.
Dave: Like a big overlay. Well, that's CSS. Even if they put it at CSS one million - or whatever - or Z index one million, your top layer will actually be above that.
If you're working on modal and you trigger an error, your modal will actually still be the boss. That's great, you know?
Chris: Yeah. It happened. I was working on a modal the other day that the way that we do modals at the moment (in some parts of CodePen) is because it uses React. There's this thing called portals in React. The whole point is you can put the modal kind of anywhere where we need to or where it makes sense (because you never know how fricken's deep you are in nested component land). But if it's a modal, it gets portalled out to basically a child of the body.
Dave: Mm-hmm.
Chris: Because modals can't be that deep in there. One little overflow hidden, who knows what it's going to chop off. You know?
Dave: Mm-hmm.
Chris: You just have to move it out. That's really super cool that the native one absolves that problem. That's fricken' great.
Dave: Isn't it weird? Using the platform, we solve a problem. If you trigger a modal from a modal, it'll go over it. It's smart. It knows what's happening.
Chris: Mm-hmm.
Dave: That's one. Letting trim, which I hear the name might be changing, but that's the idea where you know when you make the background of text pink, and there's extra space above your text that you didn't code in there.
Chris: Mm-hmm.
Dave: Letting trim tries to solve that, so it's like you can set the line height basically to the top of the T and the bottom of the T (of a capital T - or something like that).
Chris: Yeah. It chops off right at the edge. For alignment, it's especially nice, right? It really depends on what font you're using.
Let's say you're building a documentation website with a sidebar on the left. You kind of want the first item in that sidebar to line up perfectly with the header that's on the right. It's just not going to. [Laughter]
Dave: It just won't. It won't. It won't.
Chris: Yeah.
Dave: The current workaround for this is this tool called Capsize. You can put it in Sass. But you've got to upload your font and scroll of line to the top of your thing to count a metric.
Where we're seeing it a lot is in buttons, like a button element where you do pattern 0.5M.
Chris: Yes!
Dave: It's got extra padding on top. It sucks. And so, you end up with all these magic numbers, and I am starting to hate magic numbers.
But what you do with Capsize is you use magic numbers, and you display table it, or before-after display table, and then I have content null or empty string, margin-bottom -0.1189M, and then margin-top 0.0479M in display table.
It works but it's kludgy, and I had to go measure my font. I had to go eyeball it. That sucks. Let's not. I don't want that anymore.
Chris: It's probably driven people to frameworks in the past. They're like, "Look at my fricken' buttons. I can never get them to look just right. Screw it! I'm using Bootstrap," or whatever.
Dave: Oh, man, absolutely because I've certainly been in that position. It's just like, "I just want a button, but now I'm being told by design it looks bad and I have no idea how to fix it." Well, this will fix it.
I just found out it's in Safari. It's on by default. Safari technical preview 163, so that's maybe in the next version, big version, of Safari.
But I heard there's some spec drama. I think they changed the name of it or something like that. It's weird it got turned on. But anyway, ideally, it will be available soon in some browsers because that would just eliminate troughs of code.
One of my coworkers, who I don't want to throw under the bus (Trend Walton) just put a thing where he did top three pixels to fix a vertical alignment thing.
Chris: Hmm.
Dave: Which you usually shouldn't have to do, but I think it was 100% one of these letting-trim situations.
Chris: Hmm. Yeah.
Dave: Where the font had extra whitespace, so when you did a vertical-align, it wasn't correct.
Chris: Yeah. I think it subtly affects design choices that people make. This isn't wildly common but imagine you're in that left sidebar or right sidebar kind of situation and there's some letting trim issues that are a problem. Rather than even trying to align the text perfectly, you might use - I don't know - border-top one pixel - or something - because that will align.
Dave: Mm-hmm.
Chris: Now all of a sudden, you've made this choice to use lines in your design because you can trust them more layout-wise.
Dave: Yeah.
Chris: If you can start to trust text more, that will change design subtly, I think.
Dave: Yeah. No, I think it'll change a lot of stuff just because it happens inside your buttons. It happens at the card level. It happens at the layout level. We might have a chance at actual vertical rhythm if this shows up, so that's kind of exciting.
Chris: Mm-hmm.
Dave: Where ascenders and descenders in the font don't impact. I don't know. To me, it's like line height equals actual line height, too, at that point because you're just like, "No, I'm slicing this, but I want the letting in between to actually be three pixels or ten pixels or whatever." It's cool.
I had a couple of other but we don't have to read my blog post. The two things were relative color syntax because light and darken in Sass, I need that almost daily. I don't want to spin up a whole new variable. I don't want to do the HSL lightness variable splitter thing. I just want a little darker gray so it's a little more noticeable.
Chris: That one is a big deal. I see you put color contrast in there, too, which is cool. I have lower hopes that people are going to really lean into that one so much because it's kind of like - I don't know - "I'll just pick the color," rather than--
Dave: Yeah. Yeah.
Chris: I don't think it saves all that much, but the relative color syntax is flipping amazing. I just love that one.
You can start with anything. Start with anything. A hex color, HSL, a new color format. You can start with any base color and then just be like, "Oh, smoosh it up a little bit."
Yes, there are helper functions like lighten and darken, but you can do anything you want. The general color function will say "from" and then you put the original one that could be in anything else, and then say, "What do you want to output it as?" What if you want to switch it over to the okay CLH model? Well, you can do that and then have access to those outgoing channels and then use calc to mess with the channels on the way out, which sounds a little heady, but that's what you can use then to adjust the hue too.
If you're just lightening it, it doesn't do too much because it's too saturated or something, you can squoosh the hue just a little bit, too, to get right. That stuff just trips my trigger. I love it.
Dave: You go to the design system, and they have 70 pinks and 70 oranges, and 70 greens. You could build that with literally one color. You pick a hue, and then you just have a math-based -whatever - tetrachromatic. You could do the math to get to the complementary colors or the five complementary colors. Then you can do the lightness values by tens - or whatever - or hundreds, from zero to one hundred - or whatever - by tens.
You can have ten pinks, ten grays, or whatever, but it's all programmatic.
Chris: Mm-hmm.
Dave: Man, it just feels so good. [Laughter]
Chris: It's the way to go.
Dave: You just know you're always adjusting lightness by ten - or something like that. Man, it's so easy to be like, gray lightness channel minus 100 or minus 70 is always going to be in your design system. That's incredible. Right?
Chris: Yeah. Yeah, it's interesting. If we compare your list to Eric Meyer's list, it sounds like he's got Subgrid at the top. Interesting. He shares that one with Tyler's list. I'm also a big fan, but it's already on the Interop 2023 list, so I feel like I don't really have to wish for it because it's just going to happen.
Dave: Mm-hmm.
Chris: Eric wanted masonry. You're going to get that, too. It just dropped in Safari. Interesting.
A little pushback on it from the Chrome people because they feel like it's underspecified and maybe shouldn't be in Grid at all. It feels like a little too late since Firefox is shipping it and Safari is shipping it. It's kind of like, "I don't know. Just ship it."
I actually quite like it and think it's fine in Grid.
Dave: I think it's fine. I don't know. For me, it felt right in Houdini because it's like, "I'm going to do a weird thing," but not everything has Houdini.
I do wonder if it should have just been display masonry, but anyway.
Chris: Well, then how do you tell it what columns to use?
Dave: Well, grid template column. Yeah. Maybe... It's fine. [Laughter]
Chris: See. I convinced you. I already won.
Dave: See, you won. Yeah because all your grid, template, rows, masonry is how you do it, and that's all you're messing up is the rows, right?
Chris: Yep.
Dave: Yeah. That makes sense.
Chris: Tyler agrees with you about relative color syntax. I agree, too. I believe it is also on Interop 2023, so you're just going to get that.
It's starting to drop all over the place. I think Chrome is next, and it's really soon that it goes to stable, which is fricken' huge.
Dave: Is it? Nice.
Chris: Yep. Let's see. You listed the view transitions API. Eric does mention that, too. And it's number one on Tyler's. I'm telling you right now that's the coolest. That's the coolest thing that's going to happen in the next couple of years in CSS land, and you're going to start--
There's no way I'm wrong about it. It's amazing! It's amazing.
Dave: It seems like... I mean there's been three or four attempts at it already, but it just seems sorely missing. The idea, I can just make... Sarah Drasner's quintessential demo in Vue that was on CSS-Tricks.
Chris: Yeah. Yeah, and she overdid it on purpose to be like, "Everything is whooshing around as you click." It was so beautiful and so Sarah and so awesome.
But the point of it, really, I think was just to say this stuff is possible. Chances are, in your app, you're not going to be so whooshy-whooshy about every header goes into a new thing. I think it's more like that apps will be able to have that feel that native apps do.
Just open up any native app and start poking around your Spotify or whatever. The views are going to slide around. They're just going to. That's just all native apps. They just do that for whatever reason.
Usually, for good reason, that it's like, "Oh, I see. I'm getting deeper into the hierarchy," or whatever.
Dave: Yeah.
Chris: It kind of makes sense. We'll be able to do that pretty trivially with this. It's very cleverly specified. Certainly. [Laughter]
I was at a meetup, and I was just going to get up for five minutes really quick and show how it works, and I just couldn't get it. I did it from scratch, and I just made a Pen really quick to do it.
There are little things that make it, I feel like, harder than it should be, but that's half my fault - whatever.
Dave: Well, but that's also market opportunity for stuff like GSAP to come in and be like--
Chris: It is. Yeah.
Dave: "Awesome. We make it easier to do this." And it probably saves GSAP bajillions of lines of code to tween between two elements.
Chris: Ah, yeah. I see.
Dave: You know what I mean?
Chris: I see what you mean. Yeah. Yeah because you get that flip. It does it with, believe it or not, a screenshot, like an image of what is moving.
Dave: Yeah, a rastered--
Chris: A rastered, yeah, which is not quite GreenSock territory. But I'm sure they can use it in some way.
Dave: Yeah, I guess they want more. They do better work. But this idea of, yeah, you just want to kind of basically show per object permanence, basically.
Chris: Mm-hmm.
Dave: You know if you've had a kid, you play peekaboo with your kid. When you hide your eyes, they think you disappeared. [Laughter] Then you reveal yourself again, and they're like, "Whoa, boy! That's exciting."
Chris: Yeah.
Dave: We can have object permanence with our websites.
Chris: Yeah. It's just tremendous, and the nail is already in the coffin of client-side rendering of everybody now admitting that that was stupid and bad.
Dave: Well...
Chris: For performance reasons and SEO reasons and all those things, for the most part. Now, with this saying, "Oh, and you don't have to lose transitions either," oh, my gosh.
Dave: Interesting. That's what I'm trying to wrap my head around in 2023 here is what is life like with that, with the acknowledgment that CSR is kind of bad news and with the acknowledgment that hydrating is kind of bad news and expensive and with the acknowledgment that we can now transition elements. How do we build websites? Container queries might fit in there too.
I feel like we're kind of at a big point where how you build websites going forward is going to be pretty different.
Chris: We're back to inline click handlers. I'll tell you that. They used to be so uncool. But yeah, put the JavaScript right on that button element.
Dave: If you're using a PHP or Rails stack still, you're actually probably in a much better position than most of the other people to adapt to the new Web stack.
Chris: Yeah! I think Astro is well positioned as well, too, that they strip out all the JavaScript stuff and get you. The point is, you want to be shipping HTML, and then really tastefully--
I think they still have some challenges, too. For example, let's say you want to ultimately use React. You have a little React component that you want to use in there. They don't do anything. They'll strip it out for first render, but then if you do client visible - or whatever - it's still going to load the entirety of React to power that one element.
Dave: Mm-hmm.
Chris: That's the thing that's also starting to be questioned, I think, like, "Do we really need that at all? Can we not hydrate it?" [Laughter] Still use JavaScript, but not load an entire framework to do it.
Dave: Well, and that's where islands - yeah - kind of come into play. Yeah, don't hydrate it. But this one, you do.
Yeah, I feel like Nuxt is in an okay position for it too, especially if they land the server and client. Then I heard Evan You talking about this new thing called Vapor, which is kind of not what you name your mythical JavaScript product.
Chris: [Laughter]
Dave: But Vapor is a new way. Basically, it's an alternate rendering engine where, if you know the component not quite like functional but if you know the component is mostly static or whatever and doesn't need to be rehydrated, you could use this and just fast path. Again, fast.
Chris: Yeah.
Dave: It's faster building and faster or less JavaScript at all.
Chris: Yeah. Yeah. It reminds me of my new framework Fool's Gold.
Dave: Oh, yeah? Yeah?
Chris: It's coming out really soon.
Dave: Really?
Chris: When I was listening to the Qwik guy talk about Qwik, it was interesting in that when he was doing his best to call out React problems, it was kind of that it's not so much that React is 40 kilobytes and that, at some point, you've got to load React, and the 40 kilobytes is heavy or whatever, because it's easy then to have somebody just be like, "Look. See, 40 kilobytes. That's bad," and have other people like, "Forty kilobytes is like my favicon." You know? Who cares.
Dave: Mm-hmm.
Chris: But it's not so much that. It's that a React app tens to be hundreds of kilobytes and more. That it grows. That an actual app in it is not 40 kilobytes. It's many hundreds of kilobytes. And I think he's right about that.
How do you stop that proliferation too? Can a framework hydrate itself without being like, "Okay. I'm at zero, and to hydrate is all hundreds of kilobytes of that."
Dave: Yeah. I feel like my dream state is a framework that knows that, like, this needs to be hydrated. You actually, Dave, don't have to worry about it. I'll figure out if it needs to be hydrated.
But in addition to that, it's like, "Okay, cool. I have an API. Actually, I know this endpoint takes a long time," or "Everything is going in a serverless function unless I know it can't go in a serverless function," like it's too big or it's too something, "and so I'll just put that on a Node server somewhere, and I'll figure out the bridge between those two." That's what I want.
Chris: Yeah. God, there are a lot of moving parts to all this. Whoosh!
Dave: Yeah.
Chris: We have not figured it out. Let's say that.
Dave: We're far. There's still stuff to discover.
Chris: Mm-hmm.
Dave: UX may be a solved problem, [laughter] but serving your website is not. Anyway--
Chris: Yeah, yeah. Well, back to the CSS stuff a little bit.
Dave: Yeah, what's your big...?
Chris: Well, you know I'm interested in your list and all these other lists, but almost like, can everybody also do another one where instead of looking at what is already coming and that you just want sooner - or something - and think about stuff that is not on any list.
Dave: Ah, the big pie in the sky, big brain. You want big brain.
Chris: Yeah. Yeah, kind of. Even if it's you can tell that it would never ship because it's too esoteric or too fraught with problems - or who knows what.
Dave: Never ship without a tabs element. Got it. Yep. [Laughter]
Chris: [Laughter]
Dave: What's next?
Chris: That's too bad. Yeah. That one is HTML, too, so tricky - or whatever.
The full SVG syntax in CSS or something like that.
Dave: Hmm. Yeah.
Chris: I could use that. Whenever SVG makes its way into CSS at all, it's the unit lists syntax, which always freaks me out because CSS doesn't really do unit lists very good.
I know we have it for something like line height, but all it means is a multiple, so that's fine. You put the numbers of SVG in there for something like clip-path or offset path. There are a couple of other places where SVG syntax has made its way into CSS. What it ultimately means then is pixels.
Dave: Mm-hmm.
Chris: It's like, "Well, that sucks," because offset path, as it exists now, uses that syntax and is only pixels, which means that the offset path is not responsive or resizable in any way.
Dave: Mm-hmm.
Chris: Which is like, "Ah... Boo! [Laughter]
Dave: Right.
Chris: You know?
Dave: Huh.
Chris: It's little stuff like that. Let's see. What else does Eric say? We'll just finish these lists off and call it the end.
He wants nesting. Tyler says he doesn't care if we ever get nesting. How interesting.
Dave: Oh, wow.
Chris: I like nesting. [Laughter]
Dave: You'd disagree. Yeah, that was on your must-haves for--
Chris: Yeah.
Dave: "I will use Sass because of nesting, and I have to have it or I will die."
[Laughter]
Dave: That I believe is a quote from your blog or something.
Chris: I just can't write the same selector over just to then say :hover, :focus.
Dave: Oh, that's good.
Chris: Get out of here.
Dave: "Or I will die." Yeah.
[Laughter]
Dave: It is so good. Oh, God.
Chris: Anything... Lots of stuff does nesting, including... Interestingly, I think nesting even made its way into the PostCSS version of babel/preset-env.
Dave: Mm-hmm.
Chris: PostCSS has this, like, something preset-env. They use the same name of it, and they're like, "This is stuff that's Polyfillable through syntax that's coming in CSS." [Laughter]
I think the nesting one is in there. Wrong!
Dave: Hmm.
Chris: Which has always made me so skeptical of stuff like that.
Dave: Yeah. Yeah.
Chris: You know? You better be really right that this is coming. Otherwise, you're encouraging this wrong syntax that's supposed to be all future compatible but just isn't.
Dave: They decided on three, option three for that, right?
Chris: Yeah.
Dave: Yeah. Yeah.
Chris: Not my favorite.
Dave: Really?
Chris: Because it's the one that has this... You can't pick it up and copy and paste it into somewhere else that might need nesting because it depends on which one comes first.
Dave: Something. You had to use is, I thought - or something. But anyway--
Chris: It's the one where you can't use a letter. I can't write article, and then nest within it a div or figure and fig caption.
Dave: Sure. Sure.
Chris: I can't just nest those two, just the way that it is, because the F of fig caption screws up the look ahead. And it's not that big of a deal.
Dave: Mm-hmm.
Chris: You can just put the ampersand first.
Dave: Mm-hmm.
Chris: Then you're good. It does the same thing. But the fact is you don't need to put the ampersand in some situations. If I go figure.figcaption (making it the class fig caption), that's fine.
What I don't like is all those little nuanced rules of what's okay and what's not because it makes it hard to teach. It makes it hard to copy and paste around. It just seems strange to have all these little esoteric rules about what you can and can't do.
It seems better to me -- and I know I lost, I lost really badly in this, so I'm probably wrong and you probably disagree -- that forcing the use of the ampersand or something like it was cleaner.
Dave: Right. Right. Yeah. Yeah, it was interesting. They gave some background, but I was really trying to figure out why those options were all pitched the way they were. That was kind of like the context I was missing.
It's easy to look at something and be like, "I like that one," but it's like, "How did you get to this one?" was a question. Or, like, what's the technical limitation?
Chris: The one where we voted on Chrome's blog, and there were five options.
Dave: Mm-hmm.
Chris: Then all of a sudden, that one just didn't matter anymore, and we were voting again but on the WebKit blog. It was confusing to me. There wasn't enough background as to why I had to throw away all my previous thinking about it and think about it again.
Dave: Kind of a mom and dad are fighting situation.
Chris: Yeah. It kind of felt like that a little bit.
Dave: Uh... I should say the right thing because I want it, but I just want which--
You know Eric Meyer, kind of at the end, he had a bonus, but this gets into the unspent stuff. But CSS regions, which got canceled, but just the idea you could have a bucket to flow stuff into.
Chris: I fricken' love it. Yes, please.
Dave: I would love it. It kind of went away, but he makes the point, like, try to create all this page maker in CSS. I don't know if people have used those publishing things, but it's basically like you drag a box and it chucks it to the next column pretty efficiently. If you're in Word, it'll chuck it to the next page.
Chris: Hmm.
Dave: It's the same tech. We could have maybe some really cool experiences if we had that.
Chris: To me, it's all about Grid. The fact that you can define these really rigid regions with, you know, the content goes here, and it's very easy for content to expand out of that thing, to just say, "Oh, if it does, then go over here." That just seems great.
Dave: Right. Something to think about.
All right, well, send us your lists if you come up with some big-brain stuff.
Chris: [Laughter]
Dave: Thank you for downloading this in your podcatcher of choice. That was the biggest brain thing you did in 2023. Good job. We really appreciate that.
Follow us on -- I think we still have a Twitter -- @ShopTalkShow. You can--
Chris: What instance should we be on?
Dave: I don't know.
Chris: I'm not going to spin one up.
Dave: I'm not going to spin one up, but maybe--
Chris: Is there a podcasting one or something?
Dave: There's a dev tools one, like a dev tools one we could maybe get on.
Chris: Oh, that's cool.
Dave: Front-End Social, maybe, I don't know. But anyway, maybe we need a new Mastodon instance.
Then head over... Join us in the Patreon, patreon.com/shoptalkshow for the D-d-d-d-discord, which is fun.
Chris: Nice.
Chris: All right.
Chris: Sure is. See ya.
Dave: Well, Chris, do you got anything else you'd like to say?
Chris: Oh... I forgot. ShopTalkShow.com definitely still exists. Websites are hanging on.
Dave: Dude.