532: Mobile Browser Injections, CascadiaJS + Enhance, CSS Methodologies
An update on the spoon theory talked about in the previous episode, thoughts on the mobile browser injection going on in apps, Chris spoke at CascadiaJS, Enhance.dev released, 4 new CSS methodologies, and quantity vs quality in your work output.
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 the ShopTalk Show. [Beat-boxing]
New Intro. What do you think, Chris? I'm just... [Laughter]
Chris Coyier: Yeah.
Dave: I was inspired by the Super Mario Bros Super Show a little bit. Maybe Enns can put on a nice little A-Bit track.
[Super Mario Bros music]
Dave: Hey there, Shop-o-maniacs. You're listening to the ShopTalk Show.
[Theme music ends]
Chris: Sounds good. Sounds good. Thanks for keeping it fresh - always.
Dave: Just trying. Trying to bring energy on this, the 500 and nunjuda-nunjada episode of the ShopTalk Show. [Laughter]
Chris: Yeah, 532. Pretty cool.... We did mention that in the great Discord chatter we always get.
Dave: D-d-d-d-discord.
Chris: We had mentioned the Spoons Theory, and I was kind of laughing about or almost dunking on the idea. I was like, how did that become a metaphor for energy?
Dave: Right.
Chris: Of all the things in the world, how did that particular noun become the object?
Dave: We started talking about it a little bit last time, but it was like how did that happen, and there is some background. It was written by a disability advocate or just somebody with disabilities, I should say. I don't know if they're an advocate.
Chris: They were talking to their friend at a restaurant.
Dave: Yeah.
Chris: And they finally had this epiphany of how to explain it. We're talking about Christine Miserandino.
Dave: Miserandino, yeah. j
Chris: Yeah.
Dave: Yeah.
Chris: And it's like the essay is great. It's a PDF, which is great, but that's, you know, it was written in like 2003, and I kind of don't blame them, I guess. You know? They wanted a fancy layout for the essay.
The essay is easy to find, and it was kind of like they had this epiphany and they're grabbing spoons from the table at the restaurant and then explaining that each little action they take, you know, one spoon goes away.
Dave: Mm-hmm.
Chris: Then when you're out of spoons, you're out of spoons.
Dave: Yeah.
Chris: Was the point, so it was funny because I feel like -- and this isn't unique to developers. I'm sure scientists, all kinds of people, do this. You're at a restaurant, and you've to explain something, and you just grab anything around you.
Dave: Yeah. The sugar packet is the house.
Chris: Yeah. [Laughter] Yeah.
Dave: The blue whatever fake sugar is the car. Yeah, totally. Yeah.
Chris: Right, but those tend to be actually really bad analogies, and you can barely get through what you're explaining. Whereas just the spoons was the perfect thing, so it has a very specific history. It has a person you can credit.
Dave: Yeah.
Chris: It's all very trace-back-able to the disability kind of community.
Dave: Yeah, and then I think it was such a decent metaphor because metaphors tend to just crap out and be bad - just in general. But I think it was a decent enough metaphor. Mental health communities picked it up.
Chris: Yeah.
Dave: It's just this general parlance for "I'm out of spoons," I'm out of mental, physical energy to deal with this. Yeah.
Chris: It ends up kind of working for everybody because everybody does have a limit of how much stuff they can take on, whether you have chronic illness or not.
Dave: Mm-hmm.
Chris: Maybe. It's more apt if you do, but even if you don't, there's only so much of yourself that can go around. Spoons it is.
Dave: I've been hitting that very much. This summer, we did a big push on Luro. It's super close to -- not everybody -- super close to a first round of (what we call them) design partners. We don't call them beta users anymore, Chris. Just want to update you on the startup lifestyle.
Chris: Oh, really. Okay.
Dave: They're called design partners now because that's better. You have design partners, so the first round--
Chris: Unpaid. [Laughter]
Dave: Yeah. Unpaid design partner. Anyway, we were trying to nail that down, but we're really close, and the environments are mostly all set up. We're just kind of doing preflight kind of stuff right now. But anyway, it's exciting, but it's also somewhat terrifying. But all of this energy has gone into that for me, and I've had to quit a podcast. I quit my DND group. Kind of stepping back from all this stuff. I quit, just gave up on a bunch of books. I was like, "I'm not reading that garbage." [Laughter] Just a whole bunch of stuff is just flying out the window for me because I'm out of spoons. I feel like that's the best way to put it.
Chris: Right. Right. Right. I feel like you've got to be protective of it, too. You know I've had moments in the past where I've had to step away from something only to have the people involved be like, "Yeah, I totally understand, but why do you have to officially step away? Can't you just, in practice, step away but your name is still on the board?" Or whatever.
Dave: Right. Right.
Chris: Just come when you have time.
Dave: You're still a board member. Yeah.
Chris: And sometimes I'd be like, that doesn't work. You have to make it official. You have to pull your name off the board. Otherwise, it's still there. Otherwise, it's taking a quarter spoon or something.
Dave: You can't bend a spoon in half. It becomes very useless if you bend a spoon in half, either long ways or down the middle, which would be super difficult. You can't really crunch up a spoon and give just half a spoon to something. I feel like when it's something you're doing, it's a whole spoon.
A thread, if we want to get into computer talk, it's a worker thread that runs in your brain, and your brain has a certain amount of CPU (central processing unit) power. You have a certain amount of power. Spinning up a new job, a new side project, a new something, hustle, family stuff, injuries, body injuries, backs going out, et cetera. All of that is a thread. That's something that occupies a part of your brain. Boom.
Chris: Yeah. Yep.
Dave: I was going to start -- really, a part of me wants to do Twitch, right? Like stream on Twitch. And I did three of them this summer, and I was like, "I don't know. What am I doing? This is too much stuff." Even though I had just finished something, it was just like this is just one too many spoons.
Chris: Yeah, it might be part of your personality that if anything falls off that it's like, "Ooh, and opening. I shall fill it."
Dave: That is my personality, and I'm trying to reject all.
[Laughter]
Dave: All gains I've made. But it's hard, though. When you feel like -- when you thrive on feeling productive, that's a hard place to be.
I read -- Brad Frost recommended a book to me called Do Nothing, which is different than the book How to Do Nothing, which is kind of like an interesting, anti-capitalist book. But this is more just kind of like, hey, there are downsides to being productive all the time, and it's usually your mental health. And so, just do nothing. Enjoy boredom. Enjoy having nothing to do on your calendar. Just enjoy that.
It was a very good book. I'll probably read it ten times, and I don't re-read books, so that says a lot.
Chris: Yeah. This is just industry news that's not particularly new, but I wanted to talk about it a little bit. Let's say you're on a phone, and I think we're specifically talking about iOS, but I think it happens -- it just is a little bit of a different story on Android, but I think there are some similarities.
You're in an app, like Instagram or Facebook or TikTok or something that we all spend a lot of time in. And you click a link. And something like Instagram, there are not a ton of links, but there are if they're in a profile or something. You know the whole story.
But it tends not to, by default, kick you out to your browser of choice on that platform. But on iOS, famously, we talk about there's only Safari anyway, right?
Dave: Mm-hmm.
Chris: But you can't. There's a distinction between Safari as an app, just the raw app on iOS, and that is the same as if you open Chrome on iOS, it's really just Safari. It has a little different UI and stuff. I mean it is a little bit different, but the rendering engine and all that stuff is still Safari.
There's a distinction even between that and the browser that opens within an app. I think when you're building an iOS app, there's a way that you can call upon a browser to open up without leaving the app. You're not booted out of the app. You stay in TikTok or whatever, but you're browsing the Web all of a sudden.
It's different because you don't have to show, for example, the URL bar. It could just not be there.
Dave: Mm-hmm. Yep.
Chris: It's just showing you the website or whatever. And it turns out these are a lot different. [Laughter] I think we've known this in the past. There's even little bugs that can show up in those browsers and not the default browsers, which are really tricky to track down, of course, which is just the loudest sigh I can possibly sigh.
But the story gets worse from there. The problem is that many of these apps--which include TikTok, Instagram, Facebook Messenger, Facebook itself, and the list goes on a little bit--will have in-app browsers, and those in-app browsers inject stuff onto the websites they visit, like analytic scripts. They literally jack a script onto the page. Like if you were to visit daverupert.com, here comes Facebook jacking a script in there.
Dave: Wow!
Chris: And these scripts are provably tracking what you click on, what you type, all kinds of stuff.
Dave: That's intense. Wow!
Chris: What the hell?! Right? And it's happening right on an Apple device who is very busy telling us how secure and amazing they are at preventing this type of thing. Not very, though. That's pretty bad, I think.
Dave: Yeah. I mean it's kind of disgusting.
Chris: And it's not just Apple's fault. It's the other companies that are actually doing it. But it's like everybody is at fault here and nobody is saying anything. It's so strange. It's like this needs to stop.
Dave: Yeah. This is a man-in-the-middle attack.
Chris: Very. Yes, it is.
Dave: It is the fitting definition of somebody injecting arbitrary JavaScript into your application. How do we get here?
Chris: Yeah. Your Internet provider, they can do that too. Like you're on hotel wi-fi, and they jack in some JavaScript. That's so uncool.
Dave: AT&T would do that. Southwest Airlines does that when you get on Go-Go Inflight or whatever. It sucks. I've seen what used to be Roadrunner, Time Warner Roadrunner, or whatever.
I am thinking a lot of those have caught flack and changed, you know, stepped it back a bit, but who knows what they're doing. You know? It's just disgusting. That's kind of wild that they--
Chris: And you know it's on the heels of Facebook being all mad that AT&T, or whatever it is, like Apple forcing apps to say, "Hey, you have to grant permission to be tracked," and of course, everybody says, "No. I don't want to be tracked." Then that harms Facebook's business, which we have no actual information about how badly it does, but it probably does to some degree.
They're like, "Well, we can't get information that way, huh? Why don't we jack in some JavaScript and get some information this way instead?" That's what it feels like to me, although they've probably been doing it for forever.
But just third-party people, don't put JavaScript on my website. If you want to run it on your website, fine I guess. I don't know. Nobody loves that either, but when you're the man in the middle injecting your crap onto my website, it feels so uncool. And it feels like A) they should stop doing it and B) Apple should prevent it entirely.
Maybe even in-app browsers just shouldn't exist. If you click on a link, go to the browser.
Dave: Yeah. Hey, playing big tech advocate here--
Chris: Yeah.
Dave: We're trying to make people's lives better, right? They don't want to leave the app. They want to be in the app, right?
Is this a situation where these are actually -- I saw things that were like, "Oh, we're doing that? Oopsie-doopsie. We're not doing anything with that data." Kind of like, "Yeah, bud. Sure."
But is this maybe a situation where it's just a standard click tracker to see how many people use the in-app browser or load a page? How many pages get loaded in the in-app browser?
Chris: Yep.
Dave: Track that metric, telemetry it, and it just so happens that now that it's been discovered, security researchers obviously are concerned for very good reason, but is it a situation where because we don't know exactly what they're doing with it, that's what's the problem? Or is it because they're doing it at all? Or is it because--? I guess, what's the motivation? Why are those scripts on the page, and then why--?
Chris: Yeah. If they came out with a big post that says, "Yeah, we are doing this. You caught us. But the reason we're doing it is X," and have X somehow be benign or okay, I just can't see that world.
Dave: Yeah.
Chris: The reason is building profile information about you for the classic--
Dave: 100%, probably. Right?
Chris: Yeah. Yeah, I mean what could it be? "Oh, we just felt like console.logging something." No, you didn't.
Dave: We just paid--
Chris: I don't know. Why is there a code then that tracks clicks? That's provable. You can see the code doing it.
Dave: We just paid this guy like seven figures a year to just put it in there. We're doing nothing with it. But we pay this whole team of engineers seven figures each, and we're just doing nothing.
[Laughter]
Chris: Not to mention that when you link to a script like that, it's dynamic. It could change every 30 minutes.
Dave: Oh, yeah. It's an external--
Chris: One percent of them could. Yeah. They have complete control over what gets loaded and when. It's not some static piece of code.
Dave: I would love to know how many suddenly changed super quick after this article came out from Felix Krause, or whatever.
Chris: Hmm. Yeah.
Dave: How many blog posts suddenly were like -- or how many of those in-app scripts were suddenly nerfed big time?
Chris: Yeah, perhaps.
Dave: I'd be mega curious. Anyway, what a weird world. I wonder, too. Has anyone fired up Chrome, iOS Chrome, to see what Chrome is doing? It's got some kind of Web view and Web key controller in there.
Chris: Yeah. Oh, I'm sure people have. There's a website, inappbrowser.com. You can go there, and it looks pretty well constructed. For example, I have Apollo DevTools installed. And so, when it runs, it's like, "Ooh, I see that it's doing some kind of watching stuff," because extensions look like they're doing JavaScript injection too.
Dave: Yeah.
Chris: I'm like, "Oh, good catch." You know? It makes me feel like this thing knows what it's doing. I did not analyze every piece of code that this browser does, but it looks like it's doing a pretty good job of sniffing out things that are being injected that shouldn't be.
Dave: Yeah. Vue DevTools apparently is looking for iFrames every second. Anyway, that's putting Vue DevTools on blast here.
Chris: Yeah.
Dave: What's going on, buddies?
Chris: I spoke at CascadiaJS just down the street from me in Sunriver, Oregon, the other day.
Dave: Yeah. Nice.
Chris: It was pretty cool.
Dave: Back in the conferences. How did that feel?
Chris: It was good. I got to kind of open the show and kind of set the stage. I gave my little "The Web is Good Now," but I really spent a lot of time updating it and making it kind of a fresh experience. It was pretty fun.
Dave: Nice.
Chris: It turned out that the second talk was Brian Leroux, who has been on the show before, from begin.com, and the Internet and such.
He DM'd me a few weeks before and was like, "Hey, I wonder if our talks back-to-back are going to make sense," because we're going to be releasing this new framework, new thing.
Dave: Ooh... dun-dun-dun.
Chris: And it kind of did because one of the ways that I was able to kind of shorten my talk there -- short, 25-minute talks -- was normally, I talk about Web platform things and then I talk about tooling things and how they've both gotten a lot better.
Dave: Mm-hmm.
Chris: Then their powers combined makes the Web a lot better. I'm like, "Ah... I have so little time. I'm going to kill all the tooling stuff."
Dave: Yeah.
Chris: Just talk about Web platform stuff. Then I was like, "Well, that works out nicely because I'll be like, "Well, Brian is going to talk about a new tool that's just one example of Web tooling and infrastructure and stuff." Getting better that makes the Web better.
What that was, it turns out, was this thing that really did cause some stir.
Dave: Mm-hmm.
Chris: It's called Enhance, enhance.dev.
Dave: Yeah. It's a new HTML first meta-framework, almost like a Nuxt or a Next or a SvelteKit or something. But it's like HTML plus Web components, which they're kind of doing in their own little way, but it's still Web components.
Chris: Right.
Dave: Then there's state, and then I think they're using utility classes with styling, almost like Tailwind sort of thing.
Chris: That seems like a little bit of an add-on.
Dave: That would be the thing I'd want to rip out, but that's just me. I guess nothing is making me write Tailwind in here or fake Tailwind.
Chris: No, and I saw it in the talk. He's like, "Do you want to use Sass or whatever, just go ahead." It just seem like a ride-along that I don't love either. But, hey, whatever.
I think the point is if you do too little, there'll be less excitement about what's going on here. Although, I'd question that a little bit because this looks really actually pretty cool.
Dave: It's HTML pages, right? You just have a pages folder. You have an elements folder, which is your components, your Web components.
Chris: Yep.
Dave: The custom elements. Then you have an API folder, which is your API routes. If you name the API and the pages the same, almost like an Astro front matter, it will run that script before it runs the page - or whatever - when it builds the page.
Chris: Yeah, so there's a bit of a clever structure to your project. It really is just those three: pages, elements, API.
Dave: But you could also have whatever function, or you could have something like "follow user" or something if you wanted, I think, as part of your API that as long as the page isn't attached to it, or I think even if a page is attached to it, it could go get the page.
Chris: Yeah. That part of it reminds me of Cloudflare pages. I think it was how you can put a Cloudflare worker in a folder. If you name it the same thing, the worker runs at that route in addition to serving the page.
Dave: Hmm. Maybe that's what's going on behind the scenes. I don't know. Brian has a lot of -- through Begin, they have a lot of dev ops.
Chris: Cloud infrastructure knowledge, yeah.
Dave: Cloud infra-tech and know-how. I think to the point that I don't know that any other framework can compete with them on that level of integration, except for maybe Next, which is the whole platform is around the framework - or sort of.
Chris: Yeah. Yeah.
Dave: You know, but--
Chris: A couple of other interesting things here. They didn't say, "Bring your own componentry," like Astro did. They're not like, "Oh, use JSX or our own Astro components or Vue components or whatever." They said, "No, use Web components," but not really because they have their own opinionated way about how you construct a function.
They call them - whatever - custom element pure functions. They look very simple. Nobody is going to be confused by them, I don't think.
But then the way that you use them looks exactly like a custom element, like dave-rupert.
Dave: Right. Right.
Chris: Or my-tabs or something, so something is converting them into a Web component and instantiating them automatically for you, which looks pretty cool I guess.
Dave: Well, and I mean we kind of did, on our YouTube. Remember YouTube? We did it, on our YouTube, a little Hello, World of like three or four different ways to write Web components right. I feel like we were using -- we used Lit, but we used a couple of other ones that are kind of around. I'm blanking on which ones those were.
Building off of that video, which we'll link to in the show notes, Chris, but then this seems like a cool, different way to write Web components that's very natural. It's very, yeah, just functional component-y. It seems cool. I'm really curious what people are going to build with it.
Chris: Right.
Dave: Every framework needs a big show.
Chris: You could use this in that world of where, like, "Oh, obviously, I need HTML includes." That's a classic thing that's been on my mind for a couple of decades now. If I'm building a website, I need a way to include a header and a footer.
Dave: Yeah.
Chris: That's the very basics of it. Then it keeps going from there. You start eventually building your entire website from these reusable components.
I need to pass data in to them. The more that they style themselves and have their own state and stuff the better. This solves of that. It's that.
Dave: Yeah.
Chris: Interestingly, another interesting approach to this is it's not a static site generator at all. It only runs on the server. Interesting.
Dave: Yeah
Chris: You know?
Dave: Yeah.
Chris: It looks like it easily -- not easily. I hate to say that, but it could prebuild into HTML, I would think. But it just chooses not to. Perhaps that's because Begin, they're trying to be opinionated here. They're trying to say, "I think it's actually a better approach to let a server respond to these request," and I think that's interesting. I think we are starting to get to that level where that might be kind of nice.
Imagine if you have to pre-build, all of a sudden that used to be like, "Oh, it's so cool. Once it's done building, I just deploy these flat files," and think how fast that is, and cacheable that is, and all that.
Dave: Mm-hmm.
Chris: But that build has to NPM install the universe every single deploy. You know? it's starting to be like, "Oh, that's slow and wasteful." [Laughter]
Dave: I'll tell you.
Chris: The deploy of this is just -- whoop -- just a few little--
Dave: Yeah, just like whatever files you had on your local host now just shoot up. There's probably some kind of build, but it's very minimal. Yeah. No, this is--
I was thinking I have a half-written blog post about the stuff I want from a meta-framework, and this has a lot of it. I think Web components support is kind of up there. I think the page-based routes, I think the built-in API server is there.
To the extent even some of my feelings on Jamstack are sort of changing. I love that Jamstack is like, "Hey, it's just static files." You know? But man, Jamstack plus a Node server that's running your API, and I don't have to spin up a whole new website or a whole new ecosystem just to get a little Node API server going, I kind of -- I don't know.
I feel like Jamstack needs to evolve to where you can have a Node option or a ... option.
Chris: When it's just a given, it's just sitting there waiting to be used? Yeah.
Dave: Yeah, it's a button, a one-click button to get up and be like, "Okay. Deploy this actually on Node." You know? It's Jamstack, but it's also just on Node. You know?
Chris: I don't think this is even just a little idea. I think that's kind of where things are headed. People are starting to get into their head, like, "Oh, when I deploy, so many of these infrastructure tools have a runtime available to use at the time the file is requested." It's true of Cloudflare. It's true of Netlify. It's true of Vercel. It's true of all these things, places where people actually use.
Dave: Mm-hmm.
Chris: And then along comes Bun powered by Zig that says, "We're another runtime. We're designed to be cloud-first," and people are like, "Hmm... Interesting.
Dave: Hmm...
Chris: There's going to be more and more of this, like, "Oh, there's a little runtime available to me always.
Dave: Yeah.
Chris: Hmm... What could I do with that? Well, a lot.
Dave: Cheap runtimes, yeah. Right? Like maybe the future is these little -- you know. I can do my--
I think, like the serverless stuff, Jamstack has pushed us into this idea pretty hard of like serverless. Like you just have these functions that execute once. A lot of these API routes could just also be serverless functions, but then you need the dance of making them run on almost like Edge functions or something. Anyway--
I think serverless is awesome, but I think just maybe these little micro runtimes would be awesome. Micro runtimes, that's the term we use now. Link to me.
[Laughter]
Chris: I like it. I think it's cool. It's one of those. It's almost to be expected. It's like, "Ooh, we swung away from servers," and then people started sensing the swing back to servers, but it's not the same when it swings back. It's a little different. It doesn't mean spin up an EC2, an entire server. It means little, tiny, lightweight things that do just the jobs that we need them to do. And we know what jobs because we're maturing as an industry. We're understanding what we actually need from these servers.
Dave: We're maturing, even in the lifespan of Luro. It was on Netlify, and then we had some beefy Node things. It was like, "Okay, let's go. Let's spin up a Node server. We're going to spin up more than one, so let's put it on Docker."
We put it on Docker. Well, guess what. My Docker build times are like 12, 13 minutes, and it's driving me nuts. And it takes 30 minutes to deploy a tiny fix.
I'm looking at different environments. I started playing with render.com, which is kind of a new host platform thing.
Chris: Yeah.
Dave: What's neat about Render is it gives you an environment, but then it's like -- or it says, "Okay, what do you want? A Node server. Great. I'll do a Node server. You want a database? Great. I'll give you a database."
Then it gives you the option to create these render.yaml files, which are probably based on the same stuff that Begin uses (Arch or something like that). But basically creates you a YAML file of your environment, so if you ever need to spin up a dev environment or whatever environment, you're one click away. How cool is that? You're just in a world where you have a customer who is like, "We want to pay you a bajillion dollars, but we don't want to be on the server that everyone else is on because we are Bajilla Corp."
Chris: Yeah. Money.
Dave: You're like, "Man, it'd be cool if I could just one click a button and get a new environment for them, like a clean room." You know?
Then they're like, "It has to be hosted on our internal servers." Now you're like, "Uh, I wish I had a Docker." [Laughter] Anyway, that's life, but you know.
Chris: They do data. Very cool. I wonder if that's still the kind of the secret sauce to money.
Dave: I think once you have customer live data on there, on a server somewhere, you're sort of stuck. Right? The more customer data you have--
Chris: Even if you're not stuck, it feels like the analytics data shows that you won't churn as much, like those customers are going to stay with you.
Dave: Right. Right, you probably have customers.
Chris: There's something like feels about it, too. I don't know. Because they have my data, I'm okay with spending more money, or I think of them as fancier or trust them more or something. I'm thinking of it in the context of Shawn Wang stuff talking about how front-end-only tools just don't--
The potential for them to make money and the potential for them to have a return for VC and things like that are so low because it's like, meh, it's not valued as much. It's just easier to move away from them. There's lots of details to this, but I wouldn't -- if somebody is going to do something cloudy these days, do data because there's always money there.
Dave: Yeah, well, but I wonder if we're on the cusp. I think we talked about it before, snaplet.dev is a cool little project. But it's basically a way to -- it's almost like WP DB Migrate Pro or something, but for a PostgreSQL server from the command line. Maybe we're at a heyday for data with Supabase and all these other tools where it's like, "Oh, you know what? I'm going to just move this over to Supabase," my weird [laughter] custom, homebrewed PostgreSQL server. I'm going to just chuck it over on Supabase now.
Then, "Oh, you know what? Supabase is going out of business." They're not, but I'm just pretending. "I’m going to move it over to here."
Maybe we're on the cusp of that being a potential reality.
Chris: Of data being--? That would be nice, actually. Yeah. What does that mean, though? Does it mean PostgreSQL? Doesn't there need to be a format that is portable, too, that everybody kind of agrees is good?
Dave: Right. Right. Yeah, I guess there needs to be some kind of standard.
Chris: It's nontrivial to go from schema-less to MySQL or whatever. They're not the same.
Dave: Yeah. PostgreSQL to MySQL or Mongo to MySQL is different. Anyway, I just wonder. I wonder if there's a future here where you're able to kind of just fluidly sort of just - whatever - send your data. I don't know because I feel like, right now, it's--
Chris: Yeah, become monetization of these ideas is great.
Dave: Yeah. Because I feel like, with servers and hosting and stuff like that, it's like, if I have a Next site, I can deploy it in about ten different places pretty easily.
Chris: You can.
Dave: You know? If I have a Jekyll or an 11ty site, the same deal, ten different places. Pretty easy options to get up and going. So, as a consumer, that's really great for me. I feel like these tools need to start inventing really good--
Chris: It's starting to be that way with a little piece of Node code that you expect a cloud runtime to handle for you. There might be a little bit of differences here and there, but for the most part are starting to become monetized.
Dave: Well, and I can't wait to be on Nuxt 3 because I could maybe be back on Netlify again because they'll just spin up little Edge functions for me for my API. Like if I write the API in Nuxt 3, then Netlify can just spin up the Edge function API server. It's got all the routes for my file-based API.
We're in a cool era is what I want to say. [Laughter] I feel like we meandered a lot to get here, but I feel like we're in a very cool era for JavaScript, for CSS. I mean I guess this is your talk, huh? [Laughter] We're in a cool situation compared to yesteryears.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Split. That's split.io, split.io/shoptalk, actually.
A very clever name for a product because it has to do with splitting, actually, like the users that use your website. Imagine a basic use case of that being something like A/B testing, like I want to show some percentage of people this version of the website because I want to test the effectiveness of it without necessarily rolling it out to everybody. Test the effectiveness meaning literally measure the impact that it has and see if it's kind of good or bad.
But that same kind of technology then can be used for feature flags. That's essentially what you're doing. You use their product to set up these feature flags, like these 100 people or these 25% of the user base have this feature flag, which you use their dashboard to do. Then it allows you to write if-else statements, essentially, right in your own code base that says if this flag is turned on, deliver this piece of JavaScript or backend code or whatever it is. Otherwise, do this.
It gives you that ability in your code, but it separates the ability. You don't have to deploy in order to change the 100 people or the 25%. You manage that elsewhere, which ends up being a pretty nice experience.
Then again, it helps. It's for rolling things out. You have a brand new feature. You don't want to roll it out to everybody. You want to roll it out to a subset and get feedback from them. That's the whole point of feature flags. Split helps you do that.
Split is the feature delivery platform you need to help execute these modern expectations and continuous and progressive delivery because if you're not delivering, you're falling behind. You and a team of ten can create your first feature flags at split.io/shoptalk. Create your first feature flags with a team of ten. Thanks for the support.
[Banjo music stops]
Chris: Well, we were just talking about all this infrastructure and framework stuff, but it's a very similar story when you get to Web platform. Yeah, we had Jen on talking about all that stuff, and it was really great. One of those things was layers, which is interesting.
Dave: Mm-hmm.
Chris: I didn't realize. They seem so new in this. They seem newer in my brain than even container queries.
Dave: Right.
Chris: I don't know. We've been talking about container queries for so long, but it's actually not the case. Layers is actually everywhere, like @layer.
Dave: Like since... [Laughter]
Chris: Yeah, which is very surprising to me.
Dave: Yeah.
Chris: Everywhere meaning the Chromium stuff, the Safari stuff, and the Firefox stuff. That's amazing. [Laughter]
Dave: Yeah.
Chris: You could actually just start using @layer, and that changes some stuff. You have a blog post, "Modern Alternatives to BEM," and you go off and it has some classic kind of Dave humor of inventing a bunch of funky acronyms, but they're all -- [laughter] They all actually kind of make sense, including some layer-based ones because it's like, "Do you need BEM as much?" or anything like it when you have layers.
Dave: Yeah, that was the thing that stood out to me from the Jen episode, and I've been thinking about it since. It was just like, "Oh, layers is like a folder and now CSS can put the styles in that folder, but I organize the folders." I can say, "Okay, this folder goes first. This one second. That one is the last one. But I'm going to write my styles however I want. You just chuck them in this folder. I'm tagging this to put in a folder."
That's a terrible way to describe it on an audio podcast, but it's interesting because you get control of when the styles apply. We've done all this backflipping to control specificity and application. But now you can just kind of make -- you could make a layer for every component in your design system and control the order in which they apply and it's always going to win.
Yeah, I don't know. Anyway, that's different than scope, but scope is cool too. So, I came up with the--
Do you want to hear my four modern methodologies?
Chris: Yeah, this is perfect for podcasting.
Dave: Okay. Yeah.
Chris: What are the new four CSS acronyms that are in the category of BEM but not BEM?
Dave: Okay. And I should say we want to keep some good things, right? We want to author in components. We want low specificity to avoid some collisions. And we want a bucket probably of utility classes or a very big bucket if you use Tailwind. Right?
Chris: Mm-hmm.
Dave: You have Cube (which is Andy Bell's thing), composition, utilities, blocks, components, and exceptions to those rules - like any kind of weird one-offs. I like this. This is kind of how I write code now.
But let's say you wanted to go in on components. You're just like, "All I care about is components." Well, if you use Web components, you have auto-scoping built into that. It's actually way too good, in my opinion. But you have basically the host element, like Dave's button. You have elements inside the button: ULs, LIs, Ps, divs, classes (just like HTML classes), state. Inside your Web component, you can just write as specific as you want because you know it's not going to bleed out everywhere.
You're the boss in that component. You can write like it's the year 2000, and you're touching CSS for the first time.
Chris: Yeah. If you want to style an LI, you just go right ahead.
Dave: Just fricken' do it. Why not? How many LIs are there going to be? One?
Chris: Yeah.
Dave: Great. Just do it. Yeah. I call that HECS (host element class state). The host component, the element inside of there, the class, and the state.
Chris: Mm-hmm.
Dave: Then if you want to reduce specificity entirely, which is what all those tools did, you do WILS (where is layer and scope). WILS is pretty powerful. Scope is not out yet, I should say.
Chris: Right. Right. Right. You use the where trick to nuke out the specificity of things. That's a new trick, right? Even something like BEM was trying to, specifically trying to lower specificity. And now it's like, yeah, but we have this new trick now, so we don't really need it.
Dave: Yeah. Yeah, exactly. Right. Now we can just say where whatever component or my component where LI - or something - and it's very low specificity. I don't know.
Chris: Yeah.
Dave: That's a bad example off the cuff, but anyway, so you're able to basically reduce specificity and control now when styles apply. Then Scope is control where it starts and stops applying. When Scope hits, that's going to be a big thing.
Then the last one I had was GPC, which is based on a post you wrote in 2012 called "One, Two, Three."
Chris: What? [Laughter] Yeah.
Dave: It was how many style sheets should you have, basically, was the question. You said, what, like global, page, and section.
Chris: Yeah. I mean it's so fun to think that that had any longevity at all.
Dave: Oh...
Chris: But it was basically Wufoo days. That's how we did it. We had global styles and then if you're in the form builder, the form builder of course has its own styles which are very different than if you're in the rule builder or something. Those don't need to share any of those page-specific styles.
Dave: Yeah.
Chris: But there's also a tree, right? If you need a third one, the third one could be a very specific page.
Dave: Yeah, totally. Yeah, you could just be as specific as you want. In layer land, you can have global page component folders. The global one is always the first one. Page comes after that, and component, section, or whatever you want to call it is the last one.
Chris: Yeah. You're controlling your specificity. It's actually even better because in the one, two, or three scenario, sure, there are three style sheets, but none of them have any enforced strength.
Dave: Right. Right.
Chris: Whereas this does.
Dave: Yeah, and you can also author this however you want. [Laughter] On the about page, you could actually change a global style if you wanted. Just chuck it in there and there's sort of no consequence because it's only happening on that page. Or you just author. You edit. You're saying I'm in this page, so make the body background pink on this page always. I know what I'm doing, so that's this--
Chris: Yeah. I wonder if it encourages almost because the idea of just not loading a CSS file on a page that doesn't use it felt good at the time because you were like - I don't know. Then there's no risk of any bleeding over because I'm not even loading that other style sheet. But it meant that you'd be breaking up actual style sheets into smaller chunks. I think that has not shaken out yet.
With layer, it might mean that encouraging everything being in one smashed-together giant style sheet is good because you still have lots of control over what's being applied where. Then you get the benefit of one file being cached between all pages. But unfortunately, the technology has almost worked the opposite direction. They're like, who cares how many CSS files you load? Load 30 of them. Who cares?
Dave: Yeah. Yeah. No, I mean we kind of went through an era where we're optimizing the heck out of CSS, just critical CSS, all this. I wanted to call out a post this week from Harry over on CSS Wizardry. It was basically like, "Critical CSS, not so fast."
Chris: I just read that. Yeah.
Dave: It's really interesting because he's basically like it's an issue, but make sure this is your bottleneck. Don't worry about critical CSS until it's your bottleneck. I thought that was really amazing advice because it's heaps of technical debt. [Laughter]
Chris: Yeah.
Dave: Solve your other stuff first before you try to get all the styles just for that page to render in the head. I really enjoyed this post.
Chris: It's rife with footguns, I think. I've just never been the world's biggest fan of it. I was always like, if it can be really automated, then okay, do it.
Dave: Yeah.
Chris: Then even in those situations, I could find little problems with it, or you'd go to some page where it thought it had the right critical CSS but it didn't, which actually led to more jank rather than less.
Dave: Mm-hmm
Chris: That's a pretty bad footgun. It's not like, oops, I didn't get the critical CSS right. I tried to do critical CSS and made it worse. [Laughter]
Chris: Yeah. Nah.
Chris: It's just like, ugh, screw it. Of course, but performance tools all day are dinging you for not doing it.
Dave: For sure. Yeah. Lighthouse is super pissed you didn't do this. But it's really hard to do, especially across a whole entire site.
For me, it's like an N+1 problem, basically, or ON. I'm not even sure how the N notation works. But it's the idea of, like, your critical CSS needs to be your header plus the next thing on the page - more or less - and maybe a sidebar if you have a sidebar layout. That can change radically based on anything that shows for how many templates you have in your website.
Is it the product template? Okay. You need all the product crap and selectors and form crap up in the top on the product template.
Oh, you have a checkout form? You need to make the lists and the products and the forms and the coupon code up there.
Chris: Yeah.
Dave: But you could also just do the header, and maybe that's a great first step. But now you still need a block somewhere to get the rest of the page rendered. What do you do?
Chris: Yeah.
Dave: I guess I block the page. Maybe I should have just blocked the page the whole time.
Anyway, it's a really good article. It's really thought-provoking. I think there's still super value in critical CSS, but the idea of, like, don't worry about it until it's your bottleneck. [Laughter]
Chris: Yeah, it's pretty sensible advice, really. I mean think of 99.9% of websites on the Internet do not do this. They let the CSS be a blocking resource, and I don't think it's all that night and day when a website decides to implement this.
I think probably more sites implement it to their detriment than it solves. There's probably a very small amount of websites in the world that would feel slow but then they did critical CSS and now are fast.
Dave: Yeah. Right.
Chris: I don't want to talk you out of it, but implementing it is very difficult. A real-world example is on CSS-Tricks. The Jetpack boost plugin offered critical CSS. And it was in the typical fashion of Jetpack. It was a switch. You just turn it on.
There's no configuration whatsoever, which to me actually is really cool. That sounds amazing. That's how easy I want critical CSS to be because me hand-managing it in my brain, what's critical and what's not or having some special CSS syntax or some automation tool that's trying to figure it out by analyzing the DOM, all those are a major turn off to me. The fact that it used magic somehow to figure out what it needed to do was appealing to me. So, I'd turn it on, and it really did a 95% good job.
Dave: Okay. Yeah.
Chris: I was like, oh, that's good. Good for you. Now my Lighthouse scores are now higher because I flipped the switch on.
But there would be some pages that you could go to, like a sub-page that had pretty different CSS, like what would be the second of my one, two, three thing.
Dave: Yeah.
Chris: It didn't differentiate. It didn't make different critical CSS for the middle pages to the higher.
Dave: Tis-tis-tis.
Chris: Yeah, right, so then you've visit that page and it would be missing some critical CSS that was above the fold and it would cause that jankiness because now the rest of the CSS is essentially lazy loaded, right? When the lazy loaded CSS hit, it would change some stuff above the fold and be like, "Whoa! What happened?" It all happened pretty fast, but it was anti the goal.
Dave: Now you have CLS (cumulative layout shift) because that happened.
Chris: Right.
Dave: And that's a ding in Lighthouse too.
Chris: Yeah.
Dave: Unless you threaded that needle perfectly, man, you didn't win.
Chris: Right.
Dave: Clowns to the left of me, jokers to the right. You know what I'm saying?
Chris: [Laughter] Yeah. Maybe there'd be a solution to be like, oh, I don't know. Create unique critical CSS on these eight kinds of templates and anything that they're responsible for - or something. Sure.
Dave: Well, and I wonder if you could, too. It's all probably fine until, what, you do the special Christmas episode or the Christmas theme. You know? You put a little Christmas tree in the navigation. Guess what. It didn't work. Critical CSS did not pick up on that, and now--
Chris: Exactly. You have to remember to regenerate it, which maybe that's part of your build process but probably not.
Dave: I wonder if maybe this is an Edge function kind of thing, too. Maybe it could run a critical CSS test on it, but I don't think it's going to do that fast enough. Does that make sense? I don't think it's going to -- a critical CSS tool can't return in under two milliseconds in order to -- or let's say 200 milliseconds to get the page back fast enough.
Chris: Yeah.
Dave: Now you're putting the blocking on the server, which is good. But you're going to slow down your TTFB (time to first byte), which you also get dinged for. Ah... anyway. Good thought-provoking post.
Chris: This aint going to get solved anywhere soon.
Dave: Yeah.
Chris: Yeah. Thanks, Harry. Good job. Good job. Let's see. Do we have time for one or two?
Dave: We should do one question.
Chris: Okay.
Dave: It is, after all, a question-and-answer podcast. Clyde Ward Cron writes in, "Given time restraints of being a full-time employee, husband, father, am I better off focusing in on one project and adding a lot of bells and whistles to it or should I spend my time making many smaller projects as I can?"
Chris: Interesting.
Dave: "Quantity versus quality situation. Which way do I go?"
Chris: Oh, my God. Both. [Laughter]
Dave: Do both. [Laughter]
Chris: [Laughter]
Dave: You know this is tough. I think, strategically, the quantity is the play. Does that make sense? I feel like you have to--
it's kind of like the investment thing where it's like one out of ten startups fail - or something like that. One out of ten of your ideas are going to fail.
Chris: Okay. I can see it. Yeah.
Dave: Does that make sense? You've got to make ten side projects and maybe one is cool. but when I say make side projects, I don't mean work your fingers until they're bleeding. I mean just kind of etch out the idea and get it up there and see if somebody says, "That's cool enough I'd use it." You know?
Chris: I like that. The reason I said both is because if you only ever did first-crack little projects and you never got to round two on any of them, you're still going to get a breadth of experience and that's going to be great because you can choose different technologies and all this stuff. There's probably more benefit there.
But it also means that because you haven't spent time maintaining it, you just don't get that feel, which is a very different mode of work. You'll probably never write a migration. [Laughter]
Dave: Yeah. Yeah.
Chris: You know? Oh, you just never had that because you've just never had to maintain a project for a while. Your concept of what technical debt is will be limited because you'll be like, "I don't know. I just move. I just delete that GitHub repo. That's how I deal with technical debt." You know? [Laughter]
Dave: Yeah. Yeah. Yeah. I think, too, applying your hand to one thing, I think there's a lot of value in that, so I'll undercut what I said before. There's mental energy too, talking about spoons. How many spoons do you got? Do you got ten spoons free or one spoon?
If it's something you just want to do just to get this idea out of your head or see if it works and you know you've got to put a lot of work into it, there can be something relaxing about, "You know what? I know this is my side project. I'm not going to come up with any other side projects."
Chris: Yeah. Yeah. Yeah.
Dave: "I'm doing one at a time. This is my thing. I've got one spoon, and I'm putting that spoon--"
Chris: Yeah. It depends on how strongly you feel about it, right? If you know that that's your thing, you feel very strongly that this is a good idea, that's easier.
Dave: Yeah.
Chris: But if you're like, "You know what? I'm going to make a CRUD app for cat litter boxes or something," just because it's some idea that you got. Hey, maybe, you know. Build it and move on.
Dave: It was somebody in our Discord. I want to say it's one of the Andys. There are 15 Andys. [Laughter] Is it Andy Ford? Has a Lego, like a brick builder website. It's basically like share your Lego creation, kind of like Instagram for Legos.
Chris: Yeah.
Dave: Awesome niche. Very cool. He's passionate about it, likes those. Do that. Just do that. That's your idea. Do it. That's a really great idea because it parlays into another hobby you kind of like or whatever. Maybe turning your hobbies into work is actually a bad thing, too, so maybe think about that.
You're at least able to be like, this is an idea I have. Every time you sit down at the computer, you can make one idea better. That's kind of cool. Then you're not under ten backlogs. You're under just one backlog that you created. That's what I'd say.
Chris: Pretty cool. Yeah. Good luck, Clyde. You probably can't do wrong at all just spending a little time plucking away at projects, whether it's either direction, really. But yeah, I like Dave's analysis better. Err on the quantity while they're babies.
Dave: Yeah. Do some quantity. Find out which one is good. Then go quality. Maybe that's it.
All right. We should wrap it up. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.
Follow us on Twitter, @ShopTalkShow, for tens of tweets a month. And join us in the D-d-d-d-discord, patreon.com/shoptalkshow.
Chris, do you got anything else you'd like to say?
Chris: Hmm... ShopTalkShow.com.
[Super Mario Bros music]