536: Functional Programming, npm Dependency Hell, and the Patchability of the Web

Download MP3

Should you care about functional programming? What if cloud functions weren't node or deno, but built into the browser? Why do we accept npm dependency hell? Follow up on design matching the web question. And Dave blogged about the patchability of the open web.



Chris Coyier and Dave Rupert in silly sunglasses and a sign that says Shawp Tawlkk Shough DOT COM

Chris Coyier and Dave Rupert

This episode is with just Chris & Dave, ShopTalk Show's hosts. Chris is the co-founder of CodePen and creator of CSS-Tricks, and Dave is lead developer at Paravel.

Time Jump Links

  • 01:11 Dave read a book
  • 04:46 How far down the functional programming rabbit hole should we go with JS/TS?
  • 15:20 What if cloud functions weren’t node/deno/bun/go/etc. but a web browser?
  • 20:23 Why do we all accept npm dependency hell as the price of doing business?
  • 31:49 Sponsor: Split Software
  • 32:35 Advice to help match designs follow up
  • 36:55 The Patchability of the Open Web


[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. Today is a Tuesday hard-stop edition. I'm Dave, and with me is Chris. Hey, Chris. How are you?

Chris Coyier: I'm doing fantastic really.

Dave: Give a little behind the scenes, right? A little, "Hey, guess what. This is a Tuesday hard stop. We both have to go pick up kids."


Chris: That's right.

Dave: We care about you, and that's why we're recording it on a Tuesday.

Chris: Yeah. What you don't know is Dave isn't just having a jokey title about hard stops. [Laughter] It usually means we really do have a hard stop.


Dave: Really, like a meeting with a lawyer or a child is waiting on my presence. Yeah.

Chris: Yeah.

Dave: Yeah.

Chris: Absolutely. You ever forget to pick up your kid? Have you crossed that boundary yet?

Dave: Uh... Like almost yesterday, yeah, yeah.


Dave: Did my kids start walking home from school? Yeah, they did. [Laughter] But it was--

Cam I tell you about my brain? Here's what I'm learning about my brain. I read a book on productivity by a guy with ADHD, this month.

Chris: Mm-hmm.

Dave: It was kind of interesting because I think I'm learning I have a little bit of it. Undiagnosed. I can maybe medicate with caffeine is the situation I'm in.

This guy is Peter Shankman. Faster Than Normal is the book. His is a little more on the extreme, obsessive-compulsive angle of the thing that I don't super identify with. But it was a good read, nonetheless.

But what I'm realizing about my brain is, five minutes before a meeting is the worst time for me because if I have to do something in five minutes, my brain says, "You've got time to do something."

Chris: Oh...

Dave: So, I start doing it. Then I look up and, what? Like today, it's five minutes late now. Whoops. Now I've got to hustle to school or show up to the meeting late.

There's a danger zone five or ten minutes before a meeting or something I have to do where I shouldn't. My brain just gets--

Chris: No, you should do jumping jacks or review the meeting notes, but no.

Dave: Right. No. No, I'm like, "Let me just cut a branch. Let's see." You know?

Chris: It's usually blogging that gets me, like, "Oh, that's a little side task. Let me just write down some words." Then my brain goes into a special time ignoring mode where the words are flowing.

Dave: Yeah.

Chris: You're like, "Oh, cripes." Interesting. That's a good one. The five-minute meeting theorem.

Dave: Oh, my God. Yeah, five or ten minutes. The other day I just was like, "I know myself. If I start doing something, I'm going to do it," and so I just started pacing around my house for, like, ten minutes because I just was like, "I don't want to get behind."

Anyway, it's like a dead zone for me. If I pick up any sort of task five minutes, ten minutes before a meeting, I am late for the meeting. It's just the worst. It's just how my life goes.

I'm learning about unique brain chemistries. They are all fascinating. Everyone's is unique. It's wonderful.

Chris: Mine is perfect. That's all I know.

Dave: That's great. That's good.

Chris: I'm good at everything.

Dave: Just like your code.

Chris: Yeah.


Dave: It's all perfect. You have a few good tweet storms about your perfect.... occasionally, Twitter surfaces those to me, and they are always a joy.

Chris: [Laughter] Yeah. There are just so many braggadocios M'er F'ers on Twitter that it's just easy to get in that mode once in a while. You're like, "I forgot to tell you how great I am lately."

Dave: [Laughter]

Chris: Do it.

Dave: Take a knee, kids.

Chris: [Laughter]

Dave: I'm going to tell you about how rad I am at programming.

I tuned into this one guy's stream. I can't even remember who it is because I blocked him not only from Twitch, Twitter, but also my brain.

Chris: [Laughter]

Dave: He just was like, "I make so much money." And I just was like - delete. [Laughter] Yeah. Good for you, buddy. Deleted.

Chris: I don't think we'll hang out.

Dave: Yeah.


Chris: You know who has got a question about programming?

Dave: Hey!

Chris: Mohamad Talha. He's curious specifically about a kind of programming called functional programming.

Dave: Hmm...

Chris: He's wondering, "How far down the functional programming rabbit hole should we go with JavaScript/TypeScript? After going into it, it's a super deep hole. There's good ol' pure functions and immutability. But then--"

That's where I stop, personally. [Laughter]

Dave: Yeah. Yeah, yeah.

Chris: "But then there's semi-groups, monoids, functors, monads. I'm very slowly starting to grasp the concepts but still feel lost in functional programming conversations. I never know what 90% of the words even mean. I get the thinking, though. Is it even practical to do all this stuff in JavaScript/TypeScript when the language is not 100% functional? I feel like I'm starting-- I'm using this stuff. I lose the ability to work with a lot of developers, as they're mostly foreign concepts."

Even if you did go deep, now you're not lost anymore, but you've lost everybody else that works with you. [Laughter] I could see that happening.

Dave: Yeah. Yeah. Um... Man, I don't know. I pay not much attention to it. It sort of is like this theoretical perfect form of programming. You know.

Chris: Is that what it is? I don't even know that.

Dave: It's just the vibe you get from people. It's like functions are better than any. You know?

I think it's just like immutable - I don't know. State factors in, right? Stateless sort of stuff.

Chris: It is if somebody, some guru, a functional programmer could roll into your codebase, would they be like, "Dave, you see here where this function that you've wrote on line 76 is depending on something on the window, and that makes it an external oddity, and you should never do that? You should pass that parameter in. And by passing that parameter in, now this function has become pure and will only output what you've input into it 1:1 perfectly. And you're welcome. I'm a functional programming genius, and your life is better for it now"?


Dave: Yeah. That's good. [Laughter] Okay. It's good.

A pure function returns the same answer given data. Right? Is that kind of the idea? That's the agreed-upon?

Chris: I think that's one. We even biffed the name on it a few show back, but yeah. Yeah, I get the point. I think sometimes React people get into that because your componentry is functions, so your componentry often is a pure function and is encouraged to be - or whatever.

Dave: Mm-hmm.

Chris: That's your toe dip into the water of all this. Then you're like, "I'm going to write all my functions that way--"

Dave: Yeah.

Chris: "Because my framework is good that way." Then it got extra hairy there for a little while because Redux was super into it, right? They encouraged the use of immutableness with Redux, too.

Dave: Mm-hmm.

Chris: Then everybody got really into it for a minute. But I don't know. I haven't heard about it too much lately. I'm sure there are plenty of functional programming heads still around. But yeah, ask me what a monoid or a monad is and I'm going to tell you. I'm going to step away slowly and run away.

But I'm not encouraging you to be like me. Maybe you should get into this stuff. In fact, I'd say, Mohamad, if you're really attracted to the idea of all, if you're brain is like, "Man, this stuff is so cool. I really like it. This is interesting to me in a way that is making my brain tingle," then my advice is chase that tingle, man. Learn it.

It doesn't make my brain tingle. It makes me confused. It makes me - whatever. I immediately start looking for the tangible benefit. If I'm going to learn -- what am I going to get out of it [laughter] if I learn this?

If you can convince me of that, then I'll join you down the rabbit hole. But I'm not reading computer science papers on this stuff just because I want to know it. That's where I'm coming from.

Dave: Yeah, I would agree. I think you're asking a good question. I think if you like it, you should do it, and you should write the blog post called "Functional Programming for Dave and Chris."

Chris: [Laughter] Yeah.

Dave: Or for people who don't care about functional programming. That's a great title. Boom. Clickbait. Boom! You're on Hacker News, baby.

Chris: Yeah, that is pretty good. Yeah, he wouldn't even have to be very good with that title.

Dave: No.


Dave: Just a video of you passing gas on there. That would be it.

Chris: Somebody should just put that right into GTP3 and just publish what it says.

Dave: Just straight out.

Chris: Yeah.

Dave: Just go. Yeah.

Chris: I'm going to try it real quick. Go on.

Dave: Yeah. Go ahead. Go ahead.

Chris: [Laughter]

Dave: Let's just see what we got. We'll do an audio reading here on the ShopTalk Show.

Chris: Yeah. Yeah, why not?


Dave: But I just think you're interested, so grasp it and break it down and provide some examples of how it looks, specifically in JavaScript. I mean I've learned Haskell and Scheme and stuff like that. That is all functional but, to be honest, I don't care. I am on the "I don't care."

Chris: [Laughter]

Dave: You ask me what programming is. It's moving the header from one page to the next page. It's moving buttons from the header to the footer. That's what programming is to me (in a lot of situations), and I don't know how monads affects my workflow in that situation.

That said, I do like the idea of pure functions. Here's where I am currently having trouble with it. If you take the idea of UI as a function of state, that idea, I agree. Yes, but it's often multiple states. It's the browser state. It's the device state. It's the Redux or local component state. It's the global application state. It's "Is it nighttime in their area?" state.

There are all these different states, is what I want to say. That to me makes programming or makes UI work a smidge different than computer science theoretical correctness. Does that make sense to you, Chris?

Chris: Yes, it does. It does.

Dave: Our work is less like "add two numbers" and it's more like "make a pizza." You know? It's like, how do I make a pizza? What do you mean? Oh, there are 70 different things that can happen in the course of this pizza's 12-minute bake time, or preparation and bake time?

That's where I am a little bit like, this stuff doesn't benefit me on a day-to-day basis. I'm staring at 15 years of making websites and stuff like that. The times I've needed to know about monads is like one. So, there you go. That's how I feel.

Chris: Wow. The results are in, Dave.

Dave: Let's have a dramatic reading. Can we get some masterpiece theater music, Chris Enns? Here we go.

Chris: Mm-hmm.


[piano music starts]

Chris: Functional programming for people who don't care about functional programming. You've probably heard of functional programming and may even have heard that it's a powerful tool for solving certain types of problems. But what it is it really, and why should you care?

In a nutshell, functional programming is a programming paradigm that emphasizes the evaluation of functions rather than the execution of commands. That may not sound like much, but it can make a big difference in the way you approach problem-solving.

Functional programming is all about breaking down a problem into small, self-contained pieces that can be easily combined to produce a solution. This is in contrast to the more traditional approach of writing a program as a series of commands to be executed in sequence.

Functional programming has a number of advantages. First, it can make more modular and easier to understand. Second, it can make it easier to parallelize code, which can lead to better performance. Finally, it can make it easier to reason about code, which can lead to more reliable code.

Why should you care about functional programming? Because it can make your life as a programmer easier and more enjoyable. And that's reason enough.

[piano music stops]

Dave: Damn. I'm convinced. [Laughter]

Chris: That was excellent.

Dave: Wow!

Chris: [Laughter] Wow! That was just a generated blog post. You could just copy and paste that, chuck it on Medium, put an unsplasher at the top.

Dave: Yeah.

Chris: And you'll get 200 claps.

Dave: Golly.

Chris: That's a 200 clapper.

Dave: That sort of did it better than I ever could have. That was amazing.

When you put it that way, robot, computer, I do like functional programming.

Chris: I like it.

Dave: I mean breaking up--

Chris: [Laughter]

Dave: --stuff into smaller functions, that single-use--

Chris: Yeah, smaller functions. Yeah.

Dave: I guess I 100% agree, and that's what I try to do. I just am not, like, I don't put on my computer science academy letterman's jacket, sweater vest, or pocket protector and make a big deal out of it. I don't know. That's just me.

Chris: Yeah, I still can't tell you what a functor is. All right. That was good, Mohamad. Good job. Keep going. Keep going. Do you have any hot topics?


Dave: Hmm... Hot topics. Well, there is--

Chris: Dave, not really?

Dave: I feel like there was something going around. I need to check the Discord.

Chris: Well, there was higher than normal Tailwind drama. Don't care.

I have one that I wonder. I kind of want to -- maybe I want to float this out to Twitter to see if anything comes of it. I won't dwell on it, but 2019, Richard Young -- I have no idea who Richard is. Never met him -- worked at IBM research, published an article and then a repo at the IBM level called browser functions, which back then I felt, "Oh, this is interesting." Now I feel like is almost starting to come true.

What's the runtime for a serverless or cloud function, usually?

Dave: Yeah. Deno as well?

Chris: Node, sometime Deno. Bun, powered by Zig - maybe. You can also -- Vercel surely helps you if you want to write one in PHP or whatever. I'm sure you could. Even Netlify offers Go.

Dave: Mm-hmm.

Chris: But they tend to be -- they're backend-y, right? They're just back-end kind of languages, which makes sense because they're running and there's no screen or anything. There's no user where those things are executing. But the idea of browser functions is like what if that runtime was exactly a browser. Kind of like not just Puppeteer, but all of it. You know? I guess that's kind of what Puppeteer is.

Let's say you needed a UUID. You wouldn't pull the UUID library from NPM. You would just ask for window.crypto because it's built into browsers, so you'd have that.

Let's say you wanted to blur an image. You wouldn't install Sharp - or whatever - in the cloud function and blur it. You'd draw it to a canvas.

Dave: CSS and blur...

Dave: Or not even. You'd just display it as an IMG tag, CSS blur it, and pull the screenshot off of the image.

Dave: Okay.

Chris: Wow. Let's say you want to run all your tests, your NDN tests that are designed to run in browsers. Well, you can now. That's just a no-brainer because you have the entire browser sitting there in the cloud function. Kind of neat, I think.

You know you could use local storage and cookies for session stuff. I'm just wondering if Richard is going to be right in his 2019 article about browser functions. Is that going to be one of the offered cloud runtimes by the big player?


Dave: You know... Yeah, I don't know. l wonder. I'd be curious. That's kind of interesting to think about. I hadn't thought about it because we kind of have it, right?

Node is basically they ripped V8 out of Chrome. We were like, "Hey, look. We got this to run as a server." You know? Deno is sort of a riff on that where it's like--

Chris: It is, and Cloudflare workers aren't either of them.

Dave: V8.

Dave: Did you already say this? They just ripped V8 out of a browser and said that's the runtime.

Dave: I like this idea of, like -- I'm looking at this article now, and he's talking about Web RTC and stuff. I don't need to set up a Web RTC server. I just set up a server that has a browser in it that has Web RTC. That's a browser-to-browser communication.

Chris: Yeah.

Dave: Not even a browser to server to browser communication. That's weird. Interesting. I'm interested. I don't know.

I know how to script a browser, so I think it's cool. I do a lot of Puppeteer stuff, so I think the future is already there. We use Puppeteer to make screenshots, crawl pages, get page titles. I don't know, man. It seems like it's possible, right?

It seems like it's something you would want to do, but I don't know. The overhead of a whole browser is pretty huge. That's maybe my--

Chris: Yeah, that's why it would be Google or something. They would do it. You know? Because they have Google Cloud or whatever who are always fighting. One percent of that market is like $100 billion or something. Don't quote me on that.

Dave: Yeah.

Chris: But I'm always shocked at how big the numbers are.

Dave: Mm-hmm. Yeah. Yeah.

Chris: For providers. You know?

Dave: It'd be interesting. I'd be curious what the limits of it are, too.

Chris: Yeah.

Dave: Some browser stuff, you need permissions too, right? The permissions model is pretty different.

Chris: Yeah, a lot of it wouldn't matter. It's not like you can capture a webcam in a cloud function or anything.

Dave: But what if you could, and then I'm staring at the server room.

Chris: [Laughter]

Dave: Boom!

Chris: Sure.

Dave: You know?

Chris: It's giving me the GPS coordinates of where that server room is.

Dave: See.

Chris: That's weird.

Dave: No one thinks about that.

Chris: Yeah.

Dave: Now we're thinking.

Chris: Think about that, buddy.

Dave: [Laughter]


Chris: Brian Reich writes in. He wants to know about do we just accept NPM dependency hell as the price of doing business. We've talked about this before on the show.

Brian is like, "Is it just me or is modern Web development just a squirrely pile of JavaScript dependencies? None of us really understand what's going on. Everything breaks if you fart in the wrong direction." [Laughter]

Dave: Yep. Yeah.

Chris: Do we just accept it as the cost of doing business? He goes on to say, you know, he has this kind of, like, all projects start out all clean and then get worse and worse and worse. By the end of it, you're handing it off to somebody being like, "Eh, good luck with this weird glass house." [Laughter]

Dave: Right. Yeah, well, and you know what I've been thinking about lately is how entropy of the universe is against you. You know?

Have you ever watched those, like, "The world after atomic nuclear war"? It's like, "The grass is reclaiming the highways and the buildings."

Chris: [Laughter]

Dave: "This building, the Sears Tower would only be alive for eight weeks." You know? It's before it's overgrown.

Anyway, there's a little building near my house (in Austin, Texas) that's completely overgrown and being eaten, swallowed by vines. My wife pointed it out the other day. She was like, "That's like one of those shows."

I wonder if this happens with computers. And I know it's impossible because I know it's saved to ones and zeros on a disk. But all be, man, if you don't -- I feel like a website, just like a lawn (which my lawn guys are about to show up, so that's great timing) is a constant battle against the entropy that it's just going to fall apart. You know?

It just seems like we're constantly at war with the tech. Even if you set something up today, in three weeks, something is going to break down, even if you didn't touch it. That's how I feel about it. Right?

I feel like NPM being kind of a house of cards, plays a part in it. But it's hard to point fingers and blame them.

Yeah, what is it? Why does the Gulp task not work? Why does it stop working? You know what I mean?

Chris: We were having this funny conversation about it the other day Bend.js here in town about the same kind of frickle thing, and it was like, "Why was X broken?" In this case, it was -- I don't know.

Somebody was defending it, but then I was like, "Do you realize that just today you asked me why this thing was broken?" I don't think that's how it went down, but I think it was a Create React App from three years ago.

Dave: Uh-huh. Yeah.

Chris: Nobody had spun it up in three years, and nobody touched it. It worked just fine before. Now everybody's machine who pulled it, it was dead. You just couldn't run it.

Dave: What? How?

Chris: Well, in this case it was Sass, the project assumed Sass, and Node Sass has C-bindings. The C-bindings wanted Python. I think everybody -- I think, at the time three years ago, everybody's MacBooks had the right Python on it. In those three years, OSX or MacOS shipped with a different Python or something.

It's not like you couldn't get it to go. It didn't just go. Node Sass was killing it because of all the internal binding crap. That's just a guess. I don't even know.

Dave: Yeah.

Chris: All I did was I pulled out Node Sass and put in Dart Sass, and it ran fine for everybody. It was like a five-minute fix. But it was just an example of this, like, "Oop. That's the way it is."

Dave: Yeah.


Chris: Another story. You want one? [Laughter]

Dave: Give me. Yeah. Tell me. Tell me. Yeah.

Chris: This happened at work. I tried to get somebody at CodePen to podcast it with me, and people were like, "No," only because they were just so turned off by having to do this work at all.

Dave: Yeah.

Chris: The work was we wanted to upgrade a Node dependency of a thing. We have a bunch of carrots in our package.json, which is like upgrade even minor versions. But we don't do it all the time. It's not like there's a calendar appointment to NPM update all - or whatever it is. You know?

A good number of them were a little out of date, and the person updating this particular dependency just decided to do them all kind of thing, which is fine. Right? But then the PR becomes like it's not just updating this one dependency. It ended up a pretty dramatic change to the lock file and all that. It was a lot of dependencies are breaking.

We stopped for a minute, and they wrote up this little thing that was like, "Coding philosophy question. Let's all talk about this as a group before this PR goes in."

This PR has nothing to do with these 15, say, other dependency upgrades in this lock file. So, if I put it in, everything will probably be okay, but maybe not. You know? I don't know what 15 dependency changes is going to do to our final output. Usually, it's fine.

But if it's not fine, it was me who broke them, and I don't know. Yes, we have tests. But maybe probably not 100% test coverage on who knows what all these things are going to--

It was the same question here as Brian is asking. Is this just the cost of doing business?

Dave: Yeah. No, I think it unfortunately is.

Chris: It just is. Yeah, that's what we came to the conclusion.

Dave: I mean we're offloading so much code and so much time and effort.


Chris: The story goes on. Are you ready?

Dave: Uh-oh. Oh, boy. Deeper.

Chris: Well, just so you're reacting to the right thing. We were like, "Okay, fine. Be around when it goes out. Have, say, three hours in front of you because it's going to be your deploy, essentially. Sorry. It's on you once in a while."

It wouldn't build, though. [Laughter]

Dave: Oh, no.

Chris: The thing was dead. And it turned out to be -- and I'm not trying to throw stones or whatever, but it was related to Next.js. And at one point, Next.js -- I think it was in their big 14 release, which feels recent-ish to me, but I'm sure it wasn't anymore. But it feels new to me still, like, "Oh, it was a big release."

Dave: Yeah.

Chris: They switched from Webpack by default to some other thing. SWC or some Rust-based Webpack alternative something-something. It was supposed to make it really fast.

At first, we were like, "Oh, we have some weird Webpack stuff we're going to keep. But then we did the work, and we were like, "No. If that's where Next is headed, let's do it. Let's be on their thing."

Dave: Mm-hmm.

Chris: Our build of our Next.js parts of our app are using the new thing, not Webpack. The new thing just so happens to be a little more bitchy and not build-y about circular dependencies.

In Webpack, Webpack was like they just solved it somehow. It's probably one of those many things that, as much as people like to bitch about Webpack, they have kind of solved it.

Dave: Yeah.

Chris: And newer stuff hasn't solved it yet, so it was just like -- I mean I hesitate to get into the intricacies of what a circular dependency is (particularly because of my own ignorance) but you can kind of picture it. A imports B. B imports C. C imports A. Whoops.

Dave: Yeah.

Chris: How does that get resolved?

Dave: Yeah.

Chris: I don't know how, but Webpack kind of just figures it out - or something. I think the deal is usually there was some way out of that loop. It was just kind of ... yeah.

Dave: I think they stash the version. They're like, "Okay, there's a conflict, so now I have A.1 and A.2 - or whatever."

Chris: Right. But it wouldn't build because of it, right? Then we were like, "You know what? Instead of sweeping this under the rug somehow, we'll just do the computer programming necessary to un-circular dependency every single circular dependency in our app."

Dave: Shoot. Yeah.

Chris: It was three, four days' worth of work in the end, which just kind of sucks, but it was the way it is. We ended up using some cool open source. Mar-something. I'll look it up if I can find it - or if anybody cares. But it was just a circular dependency checker. Now it's part of our commit hook that it checks in our little functions that run on PRs and stuff to make sure there's no circular dependencies in your app.

Dave: Really?

Chris: But that was also the cost of doing business was we updated a bunch of NPM dependencies, don't totally know what the fallout is, don't totally know what the security implications are, and broke stuff. It was just like, "God, it's a lot." The cost is high sometimes.


Dave: There are so many things. I do think, if I could add one criticism, not to throw certain one-line package authors under the bus, I think we over-relied on--

This sort of is tied to the functional programming question. But there are a lot of functions like left pad or whatever that were just one use function. Lodash is a collection of functions, right? I think when NPM came out, we overoptimized on this, "I'm just going to ship one line code all the time," you know? One line.

Now you have a lot of dependencies by default, which is not where you want to be from a security standpoint. Lots of dependencies. That's lots of things to check. Now you are at--

Semantically, that's a very thin line. You'd have lots of things to check in one big file versus 100 small files.

Chris: Yeah. Yeah.

Dave: But the fixes all come together, and you don't end up with -- you end up with less cross-dependency like, I guess, lockups. You know? I don't know.

I guess I'm with you, Brian. There's just too much stuff and it's hard. I think there is a maintenance task, and I think we're all just kind of prioritizing short-term gain over long-term satisfaction. Does that make sense?

Chris: Ah, yes. There you go.

Dave: We're saying I'm getting a short gain by NPM installing some fix, and the turmoil is some fix may fall apart in six weeks because I don't know why.

My yard guys just showed up, so this may be some kind of place where either you talk or we cut this out.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Split, the feature management and experimentation platform.

What if a release was exactly how it sounds? A moment of relief, an escape from slow, painful deployments that hold back product engineers. Free for your teams and your features with Split.

By attaching insightful data to feature flags, Split helps you quickly deploy, measure, and learn the impact of every feature you release, which means you can turn up what works, turn off what doesn't, and give software innovation the room to run wild. Now you can deliver features up to 50 times faster and exhale. [Laughter]

Split feature management and experimentation, what a release. Reimagine software delivery. Start your free trial and create your first feature flag at

[Banjo music stops]


Chris: All right. I'll move on for a little bit here. I'll avoid the one where I'm going to ask you a bunch of questions (just for a moment here) and read one instead from Brian Steet who says, "A couple of episodes back, chapter four." That's cool. Thanks, Chris Enns, for chunking our shows into chapters to show on people's podcasting listeners of choice.

Chapter four was advice to help match designs. I remember talking about that. We kind of said, "Yeah, matching designs is different than perfection."

Anyway, Brian's reaction was, "My reaction was that I thought we accepted that pixel-perfect design is kind of a deprecated approach. So many design tools don't allow you to specify all the breakpoints, states, et cetera. Do I have the wrong impression? My experience is that receiving designs, even in Figma (that don't actually follow a design system), each page has kind of accidental and intentional snowflakes that frustrate me. What has been your experience? What advice do you have for the design side and for the development side?"

That kind of classic mismatch between what the design comps are and what the output is. I remember thinking about this, and maybe I even tweeted about it, not that it matters what I tweeted and didn't. But that it was like there are lots of people that say you don't have to be pixel perfect. That that is an antiquated concept. It never should have been a concept. Things don't have to look the same in every single browser.

Little differences are fine, but that message shouldn't be conflated with "Don't even try to match the mox. Just let it be fast and loose and sloppy." Those are not the same. There's still a spirit and a level of quality work that you should be striving for.


Dave: I saw this question came in, and I thought about it. I think there is a difference between my developer cannot reproduce a design and my designer does not understand fluid stuff on the Web. There's a difference there, right? The locus of the problem is different.

My developer literally can't replicate a design, and then my designer does not understand fluid stuff. I think you're right. The Web is not a static object. But I think if you can't even ballpark it, that's a problem. If you can't even come close, that's an issue.

Chris: Yeah. Right, right, right. Anyway, interesting. I don't think you're wrong, Brian. Pixel-perfect design is kind of an antiquated approach, but it depends.

We'd have to look at stuff together. It kind of goes both ways. If you get some Figma comp that's just a huge mess too, it's like you having to attempt to replicate that faithfully more like requires conversation. You know?

You can be like, "Hmm... You see how you did this, and you totally ignored everything else that's happening on other pages? That's not great either."

Dave: I do feel like it's antiquated. I do, but I think it's also sort of just like do you know what you're doing. You know what I mean?

Then I think there is a challenge, too. Design tools -- Jason Grigsby has kind of been on this for a while.

Chris: Mm-hmm.

Dave: It's just like design tools are still static. In Figma, you can't be like, "This is one M REM 8VW." You know? Some of the problem starts there, right?

Chris: Yeah.

Dave: Expectations get built there, and we need to break some of those expectations.

Chris: That's a very good point. What you might use as a unit in CSS later (because it's the right answer) is unavailable in design software.

Well, you wrote about the patchability of the open Web just the other week, huh? What was the story there?


Dave: Yeah. I've been into anime, watching some anime in my downtime while I build some Gundams. I was thinking about, like, I'm watching Crunchyroll, right?

Chris: Yeah.

Dave: Crunchyroll has this problem where it's either on or off. It's either running a video. But if you swipe up, it doesn't play in the background and it doesn't go to picture-in-picture. It just stops. Right?

I was just like, "This sucks." [Laughter] I was thinking about the Web. I've been in a Web versus native thing since the Figma acquisition.

But I was just thinking about how, on the Web, that's not a problem because if they didn't code a picture-in-picture button, I don't really care. I can open up my console and type "document query selector video request picture-in-picture." All of a sudden, I have picture-in-picture on YouTube, which doesn't have that button.

Chris: Yeah. Even if your dev team didn't build that in.

Dave: Yeah.

Chris: Yeah.

Dave: And I could probably do it in this app we're using here, Riverside, which has your video and my video. I could probably request picture-in-picture and yoink out one of these videos.

Chris: Pluck it out, yeah.

Dave: Not that I really need to, but if we were doing something. I could see myself doing that. Maybe if I was on a video call or something and I just needed to - whatever - work on something at the same time.

Anyway, I realize I just underappreciate just how we can do this on the Web. I do video document query selector video or audio playback rate two all the time. I add 2x controls to any audio I can find. Right?

Chris: [Laughter] Right.

Dave: I don't know. This is...

Chris: But that's your workflow. What about the many other people with different little things that they do?

Dave: Right.

Chris: Imagine accessibility is something that you got used to jacking onto the Web. It does remind me of the conversation about mobile browsers. The entire platform is so, like, unhackable.

Dave: Right. Right. No, and I mean that's sort of a bit of, like, you can't do it, really. But you know I installed a bunch of extensions recently to block Twitter trending topics.

Chris: Hmm.

Dave: Again, back to the ADHD stuff, that has been a massive productivity booster for me because now I'm not elbows deep into British politics or Indian politics. [Laughter] Actually, not even American politics. I'm just able to use Twitter in the way that it was originally intended. I'm not sucked into these basically tarpits for my brain. You know for normal people--

Chris: Right. Oh, God. I'm installing it right now. [Laughter] Because I'm always like, "Oh, God." I don't know. It's something. I don't even want to say one out loud because they're so horrible.

Dave: Oh, what celebrity name is this? Oh, okay. Cool. Dolly Parton. Oh, great. Now I've got "What's up with Dolly Parton? Oh, thank God she's not dead. Okay. Oh, she's just cool. Oh, here's a picture of her with Willy Nelson. Oh, okay."

You know? It's that over and over and over and over. It's just such an attention hoard that I don't need it.

Chris: Yeah. You're zero percent better at the end of reading any of that. You know?

Dave: No, and it's like I can opt into it. I can URL hack and get back to the explore tab if I need to, but I make it difficult to get there and that's good for me. It's good for my brain.

Chris: Yeah, you can still get there. It doesn't mean that you're turning your back on the news or whatever. That's what it wants you to think. I need lots of news breaks. But then all of a sudden, I'll feel bad. I'll be like, "Yeah, but there's important stuff happening in the world. Me burying my head in the sand isn't the way either." You know? But that doesn't mean you've got to open the firehose into your brain.

Dave: You don't have to. Twitter is already an open firehose, and I kind of believe -- like, I found out the Queen died. That wasn't hard to suss out. You know?

Chris: Yeah. [Laughter]

Dave: There are enough people talking about it. It's big enough news. You know? Then I've got my own rabbit holes of news I follow obsessively, like the Ukraine war and stuff like that. I spend an hour at night, at least, tracking what's going on in Ukraine. My brain is fully occupied doing that. I do not need to know about -- I can't even think of an example -- what celebrity said what. I do not need to care about that. Literally, zero impact into my life.

Chris: Yeah. Sorry, Pete Davidson. We don't care. Not that he cares, but--

Dave: I'm super broken up about your relationship with Kim Kardashian. I mean it is just tearing me to pieces, bud, and I just -- but for the sake of my attention, anyway--

I think it's cool that the Web is this, right? You can just basically go through and say, like, "Hey, I don't like that." That's the design of the Web. It's built-in. It's users over authors over implementers.


Chris: Yeah.

Dave: That's such a foundational principle.

Chris: What gets me is it's kind of built-in. It is built in because we have dev tools. But it's not built into, like, the APIs or anything. It just happens to be that browsers want you to be able to do that via those particular tools. That doesn't seem to be going anywhere, but it's attached to a history where it was more encouraged.

Dave: Mm-hmm.

Chris: In the world of CSS, forever, part of conversations would end up being about user style sheets, which I always used to kind of, I don't know, be annoyed with because I'm like, "Where? Who is running one of these things?"

Not that it's not used. It's just like, I don't see that function in browsers anymore. I think they're all dead at this point. I think none of the browsers allow a user style sheet anymore. They used to be extra interesting because they had a special specificity layer, so the conversations about them surfaced a little bit when @layer was being talked about.

Dave: Mm-hmm.

Chris: But it's like those are dead. You can't do that anymore, which it's not an absolutely no way because, of course, you could write your own browser extension or you could use an existing browser extension, like the one that you have that's hiding Twitter trending topics. That's probably jacking in a style sheet.

Dave: Yeah.

Chris: That's kind of like a user style sheet. That's a patchable Web thing. But it's through the graces of the browser extension marketplace existing. It's almost unfortunate.

Dave: Yeah. All extensions basically grift on the fact that you can add stuff to a page because you're the user. You're the final say. That's your page. You can block ads.

Chris: Yeah.

Dave: You can clear out things on your webpage. I think even Firefox tried to kill Grease Monkey, I think, at some point. But they couldn't, and there was just enough backlash. It was just like, "No, we're just part of the Web now."

Chris: Right. That's funky. Yeah, but these browsers, they probably won't. But they could say, "Oh, no. You can't do that anymore. We're going to design a browser that doesn't allow the jacking in of things anymore. I just think it's worth noting that any patch-ability that exists in browsers is because they say it's okay. They give us the APIs to do so.

Dave: Right. Android or iOS -- I'm on iOS, so that's my major gripe. But you can't do it on native unless I hack the binary.

Chris: [Laughter] Right.

Dave: [Laughter] And so, what I got out of it was the Web is cool. It's good. In all this Web versus native, even just the number of websites I visit habitually are probably mostly native apps like Twitter or whatever. Anyway, it's just cool. The fact that we have control on the Web is a cool, unique feature of the Web that I don't know that you can get on native platforms, really.

Chris: Right.

Dave: Unless you code and get provisioned to do that. [Laughter]


Chris: I responded to it thinking that not only do I wish patch-ability was better, but let's say there was a vote for what browsers should do and the vote was up. Should real, true user-authored CSS come back? And, in addition to that, how about user-authored JavaScript too? That's what your post mostly focuses on JavaScript things that you would execute on a particular page.

Dave: Yeah.

Chris: What about user authored JavaScript too? That's kind of what you meant by Grease Monkey, I think. That was the point of Grease Monkey, right?

Dave: Yeah.

Chris: Executing JavaScript on pages of your choice. I said that's what I would vote. I would bring those back.

Right away, Simon Williason -- we talked about him in the context of AI stuff lately, but he's a long-time Web dude, been on the show, and he wrote, "I genuinely worry about how easy it would be for malicious people to convince naïve users to add this script to get X," you know, penguin bucks or whatever.

Dave: Yeah.

Chris: When the script actually just steals their password and cookies for every site they visit. He's right that uneducated hackability is dangerous territory despite -- I don't know.

No doubt, that's why it's harder now than it used to be is security concerns.

Dave: Yeah because I think it already exists. It's like Facebook, I think, in the console, they have a message or something like, "Don't paste stuff you found on the Internet in here," because people would be like, "Make Facebook faster by pasting this." You know? It's some eval script.

Chris: Yeah. Even if it said right in the browser, "Do not paste stuff in here that you got from the Internet!" then the stuff on the Internet would say, "I know it says don't paste stuff in from the Internet, but do you want penguin bucks or not?" You know?

Dave: Right.

Chris: Of course, then you're like, "Yeah."

Dave: Of course I want the damn penguin bucks. Come on.

Chris: [Laughter] Yeah. I'll post that.

Dave: I want the penguin bucks!

Chris: Yeah. You just can't. There's no -- you've got to either disallow it or not. Anyway, great article. It's good to think about that those things are mostly positive for people, but tricky territory.

Dave: Yeah, I mean I think browser extensions are a pretty good example. I've written some of my own. It's like I want a feature on this website and they don't offer it, so here I go. I'm going to mod this website. [Laughter] There are cool things you can do. I don't know. Programming is also--

This is also something I've been thinking about but programming is a really neat, little superpower. And I think somebody in the Discord, D-d-d-d-discord was calling it like casting spells. You know? It's just your ability to sort of just be like, "You know what? I want this website to do this every time I visit. I'm going to write a little extension." That's got to be voodoo to my dad or somebody. You know?

My dad is like, "You can just make a website behave differently? That's wild."

Yeah. I can do that in minutes. That's kind of cool, I would say. It's really cool.

Or how many stories have you heard where somebody is like, "The pre-order system was down, so somebody hacked into dev tools and updated the credit card form - or whatever - and were able to get past some failure of the website"? I totally did that. I think I got my panic playdate by nuking my browser cache. That's how I got into the queue faster than other people because I just went through--

Chris: Wow!

Dave: --cleared application. I killed the application cache. You know?

Chris: Ooh, this is good! People should send these in. I know we've got a hard stop.

Dave: I would love to, yeah.

Chris: The ones where you hack the Web a little bit to your liking. I think of ones where you have to go in and remove the disabled attribute from a form because you filled it out correctly. It's just some JavaScript is not working and you can't submit the stupid form, so you have to go in there and hack it yourself. Or put your own country in the dropdown list or something like that. I love those things.

How do you hack the Web or patch the Web, as Dave would say, to your liking? That would be awesome.

Dave: Love it. Send it in.

All right, well, it is a hard stop edition, Chris, and we're in that dangerous five-minute zone. [Laughter] 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 six tweets a month. And join us in the D-d-d-d-discord,

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