Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the dog pound--Rupert. [Barking] With me is Chris--in the office--Coyier.

Chris Coyier: Your god-dang right, Dave! It's time to do another episode of the ShopTalk Show. We should start out with a little follow-up.

Dave: Sure.

Chris: That's the responsible thing to do, right?

Dave: Sure. Yeah, we can do that.

Chris: It's like when newspapers publish corrections. They always put it inside page one, right? They're not trying to bury the correction.

Dave: Or page 5,000. Yeah, sure. We can do that.

Chris: [Laughter] Just kidding. Yeah.

Um... We talked about Robin's Vibe Driven Development one last week, two weeks ago - whatever it was. Then he blog replied. It's cool. A little ping-ponging of some podcast blog post stuff. Kind of love it. There's some good stuff in there.

Here's a quote from it because Robin is kind of saying, "Well, I wasn't trying to say that absolutely every product choice should just be winging in. Does it feel good, you know?" Obviously, some stuff is. But there are the classics that shouldn't be.

So, he writes, "Do we really need data to tell us that adding this giant modal that pops up and interrupts the workflow of work is bad? Sure, the data says it makes a point in a spreadsheet go up by 0.1%. But how do you feel about that? Is it disrespectful? Does it suck? Is it good for us in the long run for people to be annoyed by our product? Would you be okay making that thing for your family or loved ones? Then why is it okay to show this kind of junk to a customer? Trust your vibes, man."

Yeah, it's that kind of thing. It's like not every decision can be or should be data-driven, right? That's the point. Unfortunately, the data does kind of lie to you sometimes. It is possible to see a number go up by doing something super obnoxious in your product. Then if that's the only data point you're looking at, it's the only way that you're making a decision, well, that sucks then. You've used zero vibes to make that choice and that's not good. Fair enough. There's nuance.

Dave: Yeah. I like Robin's post, and kind of getting into another post that had a blog post, Miriam wrote a blog post, replied to that blog post, and then he wrote a blog post about design systems are not a democracy (I think was kind of the vibe there).

Chris: Right. Robin was kind of like, "To make really nice stuff, you kind of--" He literally wrote you need a dictator and then felt bad about that because he's like, "Well, I'm not trying to argue for a fascist society. I'm not trying to say the best governments are run by fascists."

Miriam's counterpoint was like, "It is possible to have the kind of benefits that you're talking out here without a single ruler of the universe kind of thing." Robin's first post ended with a dictator is kind of the way to go there, and I kind of take his point. Then there are a lot of good products that come from somebody who just wasn't red-taped all to heck.

Dave: Yeah.

Chris: And that they just know what's good and are doing what's good and don't have to sit in committee meetings and all that. But yeah, it's possible to get those benefits other ways.

00:03:38

Dave: I was going to say you listen to or you read about the Apple iPhone, right? The Project Purple, Inside Apple, Ken Kocienda's book. Tony Fadell's Build book, which is actually really great. So, those are just kind of really good inside looks at behind how Apple made the iPhone.

It's very clear one role that Steve Jobs, who we think is the best CEO that ever lived - or whatever, that Steve Jobs played was editor, which is just this idea of, like, "That's not good enough, or "This is good. I want to do this."

He just was sort of calling shots. For lack of a better term, this is the dictator in Robin's kind of announcement or his blog post, his sort of theory, right? And I think, in my brain, just like a Pixar movie gets made, there's kind of a director. There's somebody directing. There's somebody calling shots and making decisions.

Miriam kind of made the point, like, any creative effort... She does a lot of theater and a lot of communal theater where it's kind of... Everybody is writing the script and everybody is kind of making the music and everybody is piecing it together. A lot of that kind of theater is really organic. It's not--

It's a democracy, but it's maybe more anarchy. It's more collective. You don't have a leader or a boss. You just have a process that you're all kind of agreeing to. I think even--

I think this idea that, hey, there's going to be - I don't know - a person... I think having a person who calls the shots is one way of doing it. And I think that's--

Chris: Right. Unfortunately, there are more examples that way, or at least it feels like there were. It's like, if community theater works that way, cool. But do you get Hamilton that way - or whatever? I don't know. I'm not trying to shoot down Miriam's point here. I'd much rather work in that kind of environment than under a dictator - or whatever.

00:05:51

Dave: Well, I heard an anecdote about Hamilton--

Chris: Yeah?

Dave: --in a book I was reading recently, and you know Hamilton was not an overnight success. He wrote a very bad script for a previous play, and then somebody was like, "Hey, I think we can make that better," and I think it was in the heights, or whatever.

Reworked the entire thing, but there was something there that was good. And the same kind of with Hamilton. It was kind of like there's something here that's good, but we've got to workshop it and kind of get it better. So, I do think there is--

Chris: Oh, that's funny. So, it seems like it's this dictator-created thing, but in the end, the good product came from lots of sources working a long period of time.

Dave: Yeah, multiple sort of sources, and that's where I would even go into the Pixar brain trust model is actually pretty fricken' sweet.

Chris: Yeah, that's my favorite thing. I love that. Thinking about movies that were made and that every scene is perfect because every scene was scrutinized, not by the team that created it but by these meetings they'd have with all kinds of people who would raise their finger and say, "Oh, I don't think they would say that. I don't think they would react in that way. That's weird how they came into the scene." They'd have all this valuable stuff. Then they polish, polish, polish, polish, polish.

Now, once we know that about Pixar movies, when you watch any other movie, you're like, "Ooh... That scene needed a little scrub through the old Pixar meeting machine."

Dave: Yeah, how did that one get through? Yeah, how did that one?

Chris: Yeah. [Laughter]

00:07:28

Dave: I think Pixar, like websites -- honestly, features on websites -- every scene, every animator works on three to six seconds of a scene for a year and a half.

Chris: Mm-hmm.

Dave: And maybe they do three scenes, three little clips - or something. You know? I don't know. Maybe I'm under-representing there, but it's like thousands of six-second scenes that show up into one big movie. I just think there's a world where it helps if somebody is the tastemaker, but I even like that idea of a brain trust. You're sort of like, "Hey."

The brain trust doesn't say, "Oh, do this instead." They just say, "Hey, this didn't connect with me," or "I felt like this was weak," or "You need to go make this little... Make this XYZ a little bit better." Anyway, it's an interesting discussion. I would encourage you. We'll link it up in the show notes, Robin's post, Miriam's response, and then Robin's response to Miriam as well.

Anyway, it's all kind of like in the same wheelhouse as Vibe Driven Development. Maybe Robin is secretly confessing he wants to be the [laughter] the manager.

Chris: [Laughter]

Dave: Nah, just kidding.

Chris: There you go.

Dave: But I think it's a... I don't know. I think it's interesting. I think it's worth talking about. I think Dan Maul subscribers to the producer model for a design system. Like they're on the hook to produce this production, which I don't think is far off for a design system. You're not making 100 scenes or 1,000 scenes. You're making 70 components or 30 components that have to build websites, a lot of websites, so it's something to think about.

00:09:24

Chris: It is. We have another kind of response article. This one kind of towards me from my now 5.5-year-old blog post "The Great Divide." It was January 2019 when that was out, and that has to do with this show because that came out of a series we did on this show kind of preparing for it of how to think like a front-end developer and stuff. And as we talked to lots of front-end developers, they were really kind of feeling that at the time.

It was like React was already huge on the scene, and it kind of felt like there was an awful lot of people there were just like on that train. And Vue and stuff, too, and whatever was happening in that market. There were just a lot of people that were like, "This is just how websites are built now," and a lot of developers that didn't get on that bandwagon but still had jobs and were doing just fine felt like, "Man, what is happening to front-end development? I'm either on this bus or I'm not, apparently. But I still care about all kinds of other stuff that's front-end."

I pointed at JavaScript as being that's kind of the point of the divide was that it just felt like there were just a lot of people that were just doing everything in JavaScript. I still think it's kind of true today. It's not that different really.

But Tim was saying it wasn't really JavaScript wasn't the wedge between those two things necessarily. It was kind of like a widening of responsibility and it's just tough. Job titles weren't and aren't helping us describe those things. But the wedge, there are just so many different skill sets out there that people are on different parts of that continuum or 3D world of skills that you can have, and there's just space between what people know about, which I think is fair.

That was a common pushback even then, Tim, because there was an awful lot of people who were on the, like, "I'm going to just get down with this mostly JavaScript way of dealing with front-end Web development," who still cared very much about accessibility and semantic HTML and interaction and illustration and all the interesting things that can happen over there.

It didn't have to be one or the other. There were plenty of people that bridged the gap. But not that many was kind of my point. If you're rocking both sides of that, I was trying to celebrate you, like, "Good job! That's cool. You know lots of stuff. You're going to be fine." [Laughter]

00:12:13

Dave: Yeah. I think you were on the JavaScript side. You were like, "I made a bunch of money. What's the problem?"

[Laughter]

Dave: But I think what is maybe missing from that is there was a very big feeling of disenfranchisement from people who are good and awesome at CSS and JavaScript and HTML. But then were being... The market was shifting hard to these all-in JavaScript frameworks. And a lot of people were like, "I don't... This is not what I signed up for."

Chris: Right. I have to learn some new stuff here that feels very outside of what I learned to get here. That feels weird.

Dave: Yeah. I'm sure you can be like, "Eat shit. That's how it is, kid." But that's also devaluing somebody's skillset. And I think what the market is proving now is if you know JavaScript or know HTML, CSS, and regular JavaScript (non-framework JavaScript), you are once again more valuable because you understand how a line of CSS can replace 10,000 lines of JavaScript - or whatever it is.

Chris: Yeah. Maybe it's coming back just a smidge--

Dave: A smidge.

Chris: --that kind of respecting the fundamental stuff because there's been churn since then, since five years ago. Now it's like these exclusively React developers we hired, how useful are they anymore? Were they a little too limited and fundamental people are knowing more? I don't know. It's hard to say that the job industry is back when it doesn't quite feel that way to me.

Dave: Yeah, yeah. Yeah, who knows. I just think the value in knowing CSS and HTML, good HTML, are up more than they maybe were five years ago.

00:14:13

Chris: I do think that's true. I see that a lot. I just looked at a whole bunch of job postings just for fun to see because I also heard some wild statistics that some 80% of people (in our world looking for jobs right now), they call themselves full-stack developers. It's like that dramatic. That's the term that you use. You don't say front-end developer hardly anymore. You just say full stack.

Just say full stack. Every job says full stack, so say you're full stack - full stack, full stack, full stack. A little cheesy, I think. But if that's just the term du jour, my general advice is then fricken' use the term du jour. Who cares? Just say it. Just do the tap dance. Whatever.

I do think there's a distinction. I think the word "front-end developer" is meaningful and is still extremely broad and probably too broad. So, to go even broader than that isn't the direction I like to see it heading. But you know. It's meaningful in a sense that it's the browser. When you say front end, what you're saying is the browser (and understanding what happens there), whereas a back-end developer.

It's not like any of these jobs are totally bubbled out, but you deal with servers more. That's what the back end is. And it does have somewhat different concerns and things and different skill sets. So, I think the distinction is still pretty useful there. But you know. It's true that front-end developers, a lot of them are like, your job... At some point, it just became obvious and normal that you're the person fetching all the data. You get all the data now. So, if that has shifted, if that has come out of the server-side skillset bucket, like maybe they make the API and you use it - or whatever - but that is kind of... No wonder that people are saying "full stack." Like, I just wrote a fetch for data and put it in a cache and then populated all of my components. That feels pretty full stack-y.

Dave: Yeah.

Chris: You know?

Dave: Yeah. I mean you're like, but that's $.ajax sort of started that. You could always--

Chris: Right. That's true.

Dave: --build your own XHTML HTTP request - or whatever. I think we have been kind of fetching data, but I think things like GraphQL sort of shifted this thing or added to the front-end stack where it's like, "Okay, well now you, front-end developer, are actually in charge of the data query and what data you're getting back from the API. You're shaping the API," even though you're not on the back-end server. It created this bigger surface area for front end.

Chris: Right. And if you got really good at that, it kind of makes sense that you didn't then also have extreme CSS skills, too, because, like it or not, the human brain is only so big, or there are so many hours in the day. There are physical constraints against knowing every darn thing in the world, especially when you're early in your career.

Dave: Oh, I mean I feel very good at CSS. But you know when I watch Kevin Powell, I'm like, "Golly, man. He's good. He's good at it." So, your skills naturally kind of atrophy, or you are only so good at something because you operate on this code base that has these problems. If you have different problems, you have different solutions. I wish that was always in the forefront of advice blogs and things like that, like, "I am a developer on a B2B commerce product," or whatever. "This is why," whatever "Vue works for us."

Chris: Right. Ah, wonderful. So, we have a couple of back-to-back ones on design stuff in Web components, or do you want to do something else?

00:18:07

Dave: Well, I was saying, speaking of Vue, somebody wrote a Vue app--

Chris: Yeah.

Dave: --for my Austin Independent School District where you get kids' report cards and stuff like that.

Chris: Oh, yeah?

Dave: It's just crap in the bed, and that affects my wife who works at the school.

Chris: Oh...

Dave: Because to get football, to get into football, you have to prove you're a student of the school by getting a report card. Well, every summer, the report card is broken as the school year transitions - or whatever. And my wife was like, "Maybe it's broken intentionally because they put the kids'--"

Chris: They want summer off?

Dave: They already have the kids' slotted into the next teacher - or whatever - and so if they show that to parents, parents will be PO'd, like if they can get that information. So, it just gray screens. It just blanks out, but it's an error in the code with even down to some marketing code. Anyway, I just noticed that the other day. I'm debugging my school portal, but whatever. It's stupid.

Chris: [Laughter]

Dave: Stupid things I can do, but it's--

Chris: Yeah.

Dave: But I do think they intentionally take it down so parents--

Chris: They don't leak information? Yeah.

Dave: Yeah, but then it creates this whole thing where my wife has to now get everyone who is enrolled in football, like all 800 kids, or however many kids are in football, she has to go and take a phone call, do a report card, do this thing, and it's just this... I think about systems a lot, Chris, and how this--

Chris: Yeah.

Dave: Pop Warner has to get the football thing, nonprofit needs a report card so that they can go to the city and say, "We had ten kids, so give us money," and then they... But the school, the city spent money on making my wife print out that report card and send it to somebody. [Laughter]

Chris: Mm-hmm.

Dave: It's just like there could be a better system.

Chris: Yeah.

Dave: Yeah.

Chris: I could never do something 800 times. I don't think my brain would allow it. I'd be like, I will invent anything I need to, to not do something 800 times.

Dave: [Laughter] What can I do?

Chris: Anything.

Dave: Yeah.

00:20:21

Chris: I was doing some QA. I'm literally working on it right now. You know it's like a table in Notion, and we set it up that says, "Here are all these 15 things, and we want to test these 10 things on these 15 things." It's got to do task A, B, C, D, whatever. Then you check it. At the end, you say, "It was last checked by this person on this date," just to be like this is a good smoke test thing that says these features are working and they need to stay working because it's just important. As we're touching a lot of stuff and things are moving around, make sure that all this stuff works.

I just couldn't. I went through it twice over the last - whatever - few months manually. Now I'm like, "Nope! I'm not doing it again." So, I wrote up Cypress tests that do it all, and they're a little janky. They're like, "Click on this," in the selector to get the thing to click on is just a weird mess. Sometimes I'd clean it up or add one of those. I'm a big fan of... I use the attribute test ID, and it's a way to give a unique ID to something but have it clearly say what it's for. So, you know it's for this particular task.

It's always kind of been one of my problems with classes is that they serve multiple masters, so you never know if a class is because JavaScript is going to use it for something. Is it a styling hook specifically? What is it for exactly? Whereas there's something so clear about the data test idea, it's for this one job.

Dave: Do your components not have--? Because you're using CSS Modules, you're just getting robo barf out the end.

Chris: Yeah.

Dave: But does it prefix - whatever - header dash--?

Chris: It is prefix. Once in a while, I'll do that.

Dave: Okay.

Chris: Because it's prefix with a name of the component that it is.

Dave: Mm-hmm.

Chris: Sometimes I'll do a star selector attribute selector.

Dave: Yeah.

Chris: Like class star equals, and I use star equals because sometimes the order of them changes if there are multiple classes on there.

Dave: Mm-hmm.

Chris: So, I don't use the start swift one. Then the name of the component because that's pretty... That should be pretty consistent. I just think that is so gross-looking. I don't know why.

Dave: Hmm... hmm... Yeah, yeah, yeah.

Chris: And it's not quite as perfect. I don't know. Whatever. I do a little of both. But these Cypress scripts, Dave, I'll just throw them in the garbage. I don't care. I'm not trying to make them necessarily like go in the code base and run as a commit hook and run in our CI and all that stuff. Maybe someday if they grow up and they're really stable, we could run them in CI. But probably not.

Dave: Yeah.

Chris: They're a little too flaky. End-to-end tests are flaky city, and they are annoying to me.

Dave: Yeah.

Chris: But right now, they're helping me cruise through essentially a spreadsheet of testing 50 times faster than I can do it by hand.

Dave: Yeah. That's the trick, right? The manual tests are way too inefficient, and a Cypress setup can be super-killer.

My dogs managed to open my door with their noses and break in.

Chris: Yeah.

Dave: So, I have to close the door now so my air conditioning doesn't go off.

Chris: Okay. [Laughter]

Dave: Love new animals. Be right back. Love new animals. Stop! Now you guys know how to work doors. They're getting smarter. They're like the velociraptors from Jurassic Park

[Laughter]

Chris: Hell yeah.

Dave: They can't open doors, can they?

00:23:57

[banjo music starts]

Chris: Hey, you should check out this browser extension. It's really cool. It's about making much better bug reports when working on websites, and I'll tell you how to do it. Anyway, go to jam.dev -- a nice URL, right? -- jam.dev. Sign up. Get the browser extension. It's all free.

Then it's a cute little strawberry icon as a browser extension. And when you see a bug, you just click on the little strawberry, and then you either just click and get the whole screen or you click and drag and get a piece of the screen that you're trying to show somebody.

It has nice annotation tools in there, so if you need to type something or draw an arrow to something or boxes around it - whatever - that's nice because you're trying to point out what the bug is. You can write with words about the bug - or whatever. And that's it, so it's really no harder than just taking a screenshot.

But what you get then is a URL that you can share of the problem. That's nice. Or you can have a team account. It's automatically part of the team and all that. But here's the greatest part is that it's full of all this metadata that you wouldn't have gotten normally with a screenshot, like the entire browser console.

Here's a story that happened on our team. We were debugging this problem and somebody left a tab and came back. There was just an error sitting there. And another user -- we're sitting on a Zoom call or whatever -- was like, "Ooh, make sure you take a screenshot of that, but do it with the console open because we need to see if there are errors in there." They're like, "Oh, okay. I guess I'll do that."

If you were to use Jam to do that, it takes all of the thinking out of it. The console is automatically captured, and it can't be on the wrong tab or you didn't capture all of it or the important thing has already scrolled past. None of that can happen. You're going to have the whole console as part of the metadata around this little screenshot/bug report that you've automatically created just by clicking and dragging really quickly.

It's got network information. You can connect it up to integrations if you want to later send it to Jira or send it to Notion or something. There are tons of integrations. You can hook it up to Sentry so you know if it was a bug that triggered in Sentry. You can connect the two up together. There's AI stuff built into it for diagnosing what's wrong. That's all the juicy stuff on top of the Jam.

But the best part is when you're just working with your team, all you do is be like, "Oh, yeah," muscle memory. Screenshot. Take screenshot. There's the screenshot of the bug and, automatically, without having to do any extra work, has all this useful debugging information along with it. So, it makes bug reports way easier with no additional work. Jam.dev, a super-cool tool.

[banjo music stops]

00:26:29

Chris: Well, let's take the opportunity to do a couple of incoming questions/topics here. We have one from Andy Schooner writing in. His brain was captivated, of course, by Brad's global design system thing that he threw out there. I think that it captured everybody's attention a little bit because they were like me, saw lots of problems with it. But then it sticks in your head. You're like, "What if?" You know?

To me, Web components are the only way. The only way this could ever be done is that. If you don't pick that, I'd just like to hear any argument otherwise. What could it possibly be if it's not that? [Laughter] Because the second is, you're like, "Well, we'll do it in Vue." Then you've lost 90% of websites at least - or whatever. That's not going to work. The point of this thing is to get as close to 100% of websites that can use it. Web components get you there. Pretty cool.

One of the things was shipping with as little styling as possible (right) because again if you're aiming for as close to 100% of websites as possible, shipping with none or very limited and easily overwritable styling is going to get you there. If you roll in with really heavily influenced styling, you're going to lose people that just don't want that particular style. It doesn't work with their brand. Although, that's kind of how Bootstrap rolled, and it was pretty highly adopted. But if you're trying to beat Bootstrap-level adoption, that's one thing.

So, Andy writes, "Does it seem--"

Dave: He... Oh... Yeah.

Chris: Yeah, go.

00:28:06

Dave: Well, I think that's exactly right. I think Bootstrap... Part of the reason it was great was because, hey, it kind of looks like my internal app anyway, so I'm just going to copy-paste this table, and blam-o, I got the--

Chris: Right.

Dave: But I agree with the idea it should be very vanilla and then let people ship themes for it, like CSS Zen Garden style.

Chris: There you go.

Dave: This is extreme app feel.

Chris: Right.

Dave: Or this is - you know.

Chris: Right. It's so easy to bring your own if you'd prefer. Yeah, I think that's the way to go.

Dave: Yeah.

Chris: For something that you're going to call quite literally a global design system, it almost doesn't even feel optional to me. That is how it has to go.

Dave: Yeah. Yeah.

[Laughter]

Chris: So, there's that. Andy even brings up Open UI. That's this thing that you could ship. You could be like, "Here. Here are a ton of variables that you can use that bring some consistency and stuff." Maybe that's a way. That's kind of an interesting option. But then it's still pretty DIY then. You're having to apply them in pretty specific ways.

Okay, but then he says... He brings up the idea of HTML Web components. That kind of became a key. That's not a real thing. That's not... There's no specific technical thing that says that. It's just come to mean the idea of generally mostly non-Shadow DOM Web components, meaning you have this piece of HTML that would work anyway (if it's in a Web component or not). But you wrap a little custom HTML element around it and then say, "Hey, that's a Web component," and then apply (through JavaScript) some extra bonus stuff to it.

A classic one is the image comparison slider. You put two images in there. Wow. Great. You're already comparing two images. You're looking at them both. But if the Web component runs, then it layers them on top of each other. It puts a little slider in there and good to go.

There are a million examples of this. It's pretty much like any JavaScript that you would apply to a little piece of HTML qualifies as something that could be an HTML Web component. But not the problem but the implication here is that it's like bring your own HTML and that there is a lot of opportunity to get that wrong. We even talked with Brad about this.

Part of the reason in his thinking around the global design system is to take away the mistake-making. Take away your ability to incorrectly apply a label to an input. You should get that stuff for free. You use the component. You get the correct, accessible, good HTML output.

To me, that means Shadow DOM - probably. It's abstracted away in that way, unless it's just really good copy and paste - or something - or some kind of tool that puts this stuff out there. But if you say, "Oh, this whole thing is just HTML Web components, and here's some documentation that say what that HTML could and should be," I don't think you've succeeded in the goal of making no-brainer design system components. If you're just on your own to write all the HTML anyway and there's no styling, it's like what did you get here? There are not a lot of point.

00:31:33

Dave: I think the biggest problem for the design system is everybody is a cowboy and we're all doing it our way. I think that no one is willing to be like, "Oh, this is actually a great way to do it." I think that's the biggest attitude.

We'll talk to Brad this weekend over at Frostapalooza, so we'll be able to maybe get some updates.

Chris: Yeah, we'll see if he's in the mood to talk about design systems or not. Maybe.

Dave: Yeah, I bet he's got a lot on his plate. [Laughter]

Chris: Yeah.

Dave: Like 40 musicians and 30 songs. But it would be--

Chris: Yeah, he's doing a great job, though. The last couple of weeks, he's like, "Hey, what if we had people make CodePens that will play in the background?"

Dave: Yeah, that's fun.

Chris: At Frostapalooza. I was like, "Oh, that's amazing." Unfortunately, I didn't have time to make it a super-official CodePen thing. But you know he did a blog post on it, and so did I. Then we have a hashtag for it and stuff. It's not like we need a zillion of them.

Dave: Yeah. Yeah.

Chris: The idea is just to make them. Then we'll make movies of them. Then he's got a cousin, a friend, or something that makes this app that's literally for the visualizations at concerts.

Dave: Yeah.

Chris: What was impressive to me is this is cool it's coming together, but he was so thoughtful and all over this last-minute idea to make his concert even cooler. I think it's really... He's just doing a tremendous job of pulling it all together.

Dave: Yeah. Yeah, you know there's been... I would say there've been some updates on the global design system. It is being talked about in Open UI, so that's, I guess, a point to that if you want to get involved. But Hidde de Vries, I believe.

Chris: Oh, yeah.

Dave: It's Dutch, so I'm going to not do a good job. Pardon me, Hidde.

Chris: Classic great blogger. One of those must-subscribe blogs.

Dave: Must subscribe blog. Big into accessibility.

Chris: Yep.

Dave: But I think everyone wants this accessibility angle, like, "Is it accessible? Are these components accessible?" Maybe Open UI doesn't do... I think the idea was maybe Open UI doesn't do the, like, "We're going to make components," but maybe they just can give a thumbs up to existing systems, like, "Hey, this one is good enough." But I think there's this idea of, like, "What is accessible?"

If you're asking, "Is it accessible?" you've kind of asked the wrong question, which is kind of a sad state of things. Again, ruthlessly eliminate nuance. But I think the idea is in what way is this accessible or where does it not fit the bill?

I think he says, "Instead, we could deem multiple implementations of tabs okay. We don't have just one golden tabs. And the org X tab is cool. The org Y is wildly different but also cool. But the org Z tab is not great because it lacks A, B, and C."

If we could get to a point where we can say that rather than this whole, like, kind of myth (I think is what he calls it), a myth of the accessible component, the perfectly accessible component.

Chris: Hmm...

Dave: Maybe we can actually make some headway into sharing some common ground or building off of common patterns. I think that was the idea of Open UI was to provide blueprints, like, how do we provide blueprints for components? But then that quickly... Once you provide the blueprint, people are like, "I want to make that. I want to put that in HTML." It becomes a challenge.

00:35:22

Chris: We have this very related question from Mark Root-Wiley. We were just talking about HTML Web components and this idea that you'd drop a bunch of HTML inside of the custom element and then apply JavaScript that way. Mark is like, "What about PHP? Why can't you have daves-component? Then in the middle of that, PHP echo blah," echo the response of some function that barfs out the Light DOM based on parameters that you're giving it, which I think is, in another world, maybe would have been... If you're hardcore rocking a WordPress site or something, maybe that is the way to go.

I think people aren't thinking about this because so many websites live in not PHP-land. They live on Netlify and that type of thing. You're thinking of build processes and things that you don't have this server that's just sitting there on hand to do this. When you do have a server that can just handcraft HTML and stick it out, then sort of the need for this is less, I fee like. [Laughter] So, I don't know. It's not a bad idea, but it makes sense to me that you don't see this that often.

Dave: Yeah. I always come down to the idea. I have another half-written blog post on this. If your components go one place, just the WordPress site, probably don't need Web components. PHP is doing just great.

Chris: Hmm...

Dave: But if that component is also on the random Drupal blog, uh-oh. Okay, maybe now you have code mirroring problems. But where a Web component really shines is you have--

Chris: Yep.

Dave: --you just give me a few props and I'll render the same thing on two different websites. Every framework templating computer language should be able to make a big string and make an element that has props with certain strings. That should be something every programming language can do okay.

Chris: Yeah, good point.

Dave: So, I think that's the issue is if you have distribution or the components need to go to more than one place.

Chris: I really like that. Even two places, it's like, "Then do it."

Dave: Yeah.

Chris: I always think there's a lot of value in that.

Dave: Yeah. Then even just if you have problems with your coworkers, even on the same website, like making the cards look the same or the buttons. Sometimes a website can be big enough or have enough people working on it that two people working on the same website feels a lot like two different products, so that helps to make it feel the same.

You also have old code and new code. What if you could just have that thin layer of abstraction on top of that to where now when you update the buttons, they all update? That's helpful. It's helpful.

00:38:44

Chris: Mm-hmm. I like it. Simey de Klerk writes in with a view transitions question. They're kind of just around the corner. They kind of are. I think they're pretty much out in Chrome and only Chrome, right? The rest of the browsers will... Maybe it'll be an interop 2025. It kind of has that kind of vibe.

Simey is asking, "Do you think it almost makes it too easy to add page transitions? Does that mean that there's a lot of very average sites that are just going to be littered with whatever," as he writes, "the lowest effort view transition is? Leaving us all a little nauseous from everything moving around all the time. Or am I spanning the cart before the horse?"

Dave: Hmm... I think it has the potential to go bad. But I think that's where taste will come in, and people will say, "Oh, yeah. I hate that."

I also think it's probably going to be better than your whole... [Laughter] I'm thinking of a makeup site or something where it's a full page wipe slash transition to the next whatever, to the product page, the PDP. Is that what they call them, product detail page?

I think it's going to be better in that regard, too. Then I think we talked on a previous show; they're going to die sometimes. The transition is not going to happen, and that's great. That means the computer has negotiated the situation and said, "I don't have enough juice to get loose. I'm going to stop." Whereas if you're doing this all in JavaScript, the JavaScript is going to execute and it's going to use up all the juice to try to get loose.

Chris: Right.

Dave: And it will not have enough juice to get loose. What do you think? What's your thought there?

00:40:37

Chris: Well, I think the lowest effort one is just putting that new piece of CSS into your style sheet, the @view-transition thing. That's the lowest effort thing you can do. Just by doing that, you get the fading transitions. If you're going to start seeing a lot of something, it's going to be that. It's going to be the fady-fady.

Dave: I think it'll be the fady, but you know what's cool is if your navigation is in the same place. That's going to feel like a single-page transition because that's going to stay the same. That's going to have some level of permanence. Yeah.

Chris: It should. Yeah because I don't think they opacity fade. Do you think it's smart enough to have that not fade out and fade in (even if it doesn't have the same view transition name)?

Dave: Yeah. I think it should cross-fade. Yeah, yeah. I think. I don't know.

Chris: Well, that's nice. Yeah, I think you're right. I think it has to do with essentially how they wrote the filter, how they apply to each other. If it's the same element, it doesn't look like it's changed at all. It's not like it darkens or something. It's a clever color combination thing. Why is that name eluding me?

Dave: Like mixed blend mode?

Chris: Lighten, darken.

Dave: Yeah.

Chris: Yeah.

Dave: Color burned. [Laughter]

Chris: I think it really does use blend modes on the raster versions that it's moving around.

Dave: Yeah, yeah.

Chris: Interesting. Yeah, they'll be fady out-y in-y. We did spend time talking about the individual elements that sometimes will run and sometimes will bail out - kind of thing. I wasn't, at the time, really thinking about what the full-page transitions are like. Will those bail out, too? Probably not, right? Maybe. I'm not sure. What is that--?

It seems to me they will either almost always run or they'll be the earliest thing to bail out because in order for them to run, the whole page needs to be rendered in order to do it. It feels like one or the other, but I don't have any testing or evidence to support this kind of thing.

But yeah, you can certainly write CSS to go with a view transition that says, "Yeah, see this entire document? On its way out, it should - I don't know - translate X 100%, and the incoming page should start at translate X 100% and animate to translate X zero," so it's just this big, obnoxious, heavily moving page thing. Should you scope that to mobile? Probably.

Dave: Mm-hmm.

00:43:05

Chris: We've talked about this a little before that watching 320 pixels make a full page swipe isn't nearly as gut-wrenching as 2,500 pixels of width on a browser window doing it.

Dave: Yeah.

Chris: There's going to be some taste that happens there. The other thing this makes me think of, though, is it probably has come up with just countless CSS features over time because they're all a matter of taste in design. So, when background color was coming around, do you think there was somebody being like, "But what if they pick brown?"

Dave: [Laughter]

Chris: "That would look bad." People were like, "Well, we can't just have them not have brown." I don't know.

Dave: Yeah.

Chris: I have seen this over and over, like, "Oh, now that animations are too easy in CSS, will there just be too many low-quality animations?" is definitely an era I remember. It usually doesn't hold up. It's usually not strong enough of a reason to not do a technology. Humans aren't very good at, "But what if it's misused?"

Dave: Yeah.

Chris: We don't tend to be like, "Oh, good point. Let's not do it then."

Dave: [Laughter]

Chris: We tend to be like, "Full speed ahead, baby."

Dave: It could be misused. I like that. Tell me more.

Chris: Yeah! [Laughter]

Dave: I'd like to invest some money into that.

Chris: Right.

Dave: Oh... There's an opportunity for misuse?

Chris: Oh, let me put my monocle on.

Dave: Yeah.

[Laughter]

Dave: I'm in. Say no more.

Chris: Right.

[Laughter]

Dave: Sad. Um... Now I'm sad.

Chris: [Laughter]

00:44:39

Dave: I think, if we're going to pick enemies, man, scroll timeline is probably your enemy here.

Chris: [Laughter] Yeah, that's true.

Dave: Throwing up over paragraphs flying in and, you know what, not a day goes by a paragraph doesn't fricken' fly in and try to hit me in the face. Yeah. I have some feelings.

I think talks, like from Val Head, Sarah Drasner, and animation pioneers there, Web animation pioneers there, Mandy Michael, are going to come back into vogue just because if we have all these tools, I think there's going to have to be a tastemaker in the mix who says, "Here's what is good. Here's where it kind of goes bad." I think you kind of have to get down to the core, like, "Why are we using motion? What are we trying to evoke here? Is it because the page was boring and we're trying to make it interesting? Bad. Don't do that."

I think motion can be a crutch. This may be hot drama, but for design I think, "Oh, it's a boring page. But guess what? Everything flies, so that's cool. Now it's cool, huh? Now you want it?" You know?

Chris: Yeah.

Dave: It's like, "Well, I don't know, man." I tried to use--

Chris: It's lipstick on a pig. Is that what you're saying?

Dave: Lipstick on a pig or just kind of like what's the point. What's the point of this? Let's get down to the brass-tacks of why are we adding motion here and what is it actually doing. I think you'll have some good conversations, or you'll just not have conversations and quietly write in your journal, "I told them so." You know? [Laughter] Always keep a dev journal in your Obsidian or Notion.

00:46:44

Chris: Sheila Brennan has a question that ends up circling around design systems, too, if you want to take it.

Dave: Yeah. Sheila writes in a topic idea to compare and contrast the roles of a front-end engineer versus design systems engineer. "I just had a chat with somebody about this after he found a blog post I wrote a while ago, "Front-end Engineer versus Design System Engineer." We'll link it up on sheilab.com. "I think it's not something people talk about much. The roles are pretty different."

Chris: Yeah. Don't you think it's exciting? I think, if you see a job posting for a design system engineer, I'm already pretty happy.

Dave: Mm-hmm.

Chris: I'm already like, "Oh, my god. You used your words to describe what this role is, that you actually know what a design system even is, you know that you're hiring for that specifically, and that it's different from other things? It's such a baby step into that world that I'm already like, "Oh, good job." You know?

Dave: Yeah. I mean I think design systems engineer, to me, is sort of like this almost like design engineer role but maybe a bit different. But a front-end engineer, you know, is slinging UI, doing that. But a design system engineer is going to be a bit more like, "Okay, how are people using this and how can they use this? How am I going to do this? How am I going to roll this out?" Oh, some breaking change. What do I do here? How do I get that fixed out?

The core concerns are kind of way different than just like, "Made page. Ship page. Made page. Ship page." It's like, "Oh, shoot, dude. If I change this, does that mess up all my consumers?" I think, as Sheila highlights, communication skills are important.

Chris: Yeah. It does seem like the scale is a little different. If your job is the system and changes to the system and who changes to that system affect does feel - I don't know - a little unique. There's probably quite a bit of overlap. But I can see that being a different scope.

Dave: You know it's like an open-source project inside your company would be how I'd put it. With open-source comes bug reports, comes customer service, comes you've got to make sure everybody is on... You know things are communicated ahead of time, breaking changes. I've said that ten times, but breaking changes don't break for everybody very big.

Sheila talks about you're going to need a storybook. You're going to have to show how this works. You're going to have to make sure things are accessible. You're on the hook for verifying the accessibility.

A design system person doesn't get to find out after the fact that everything is inaccessible at its core. Or maybe they can. But you're on the hook to fix that and ship it to your consumers.

Chris: Mm-hmm.

Dave: Downstream, you're going to have a bunch of downstream consumers who have different competing needs. I definitely feel that.

00:49:58

Chris: What do you think? Do you see that a lot, like, "We are hiring a design systems engineer"?

Dave: No, I don't think job titles have quite caught up with how we build things. You know it would be very - I don't know. I think you could probably find... It's like a facsimile here. A plumber versus a handyman. [Laughter]

Chris: You're in charge of the city's water system not--

Dave: Yeah.

Chris: Yeah.

Dave: Yeah, you're a city planner, water management versus a plumber. That's a different business, fixing at the end-user level or fixing at the core system level, making sure everything works and is wired up correctly and everyone is happy and nothing is breaking.

Chris: Yeah. I feel like I worry too much about city water. Doesn't it--? It seems so complicated. I'm sure electricity is the same way and trash and sewage and who knows. But is there somebody who definitely knows the whole system of Bend, Oregon's water system? Where does it all come from? How is that going? Do we definitely have enough? How does it get to all the neighborhoods? Where does it go once it's there? Who is monitoring for big problems in it? What can go wrong? That type of thing.

Then if there are, what if they leave or die or something? Is there ever a city, not just Bend, any city where all of a sudden the only person that knew how the water system worked is gone now and, all of a sudden...?

Dave: [Laughter] Is it like every other company?

Chris: Yeah. [Laughter] Yeah, but water is pretty important. Or it gets to this point where the city just turns to each other and shrugs and be like, "I don't know. I don't know. I don't even know how any of this works."

Dave: Where's Jim? Where's Jim?

Chris: Yeah.

Dave: Jim, I can't... I've been texting him all morning. Where's Jim?

Chris: Fell in a well, turns out.

Dave: [Laughter] Well, who is going to... How do we turn the water on?

[Laughter]

Dave: I don't know.

Chris: How resilient is it? My own ignorance makes me very scared of the whole thing.

Dave: Which one of these knobs fixes it?

[Laughter]

Dave: Yeah, I'm sure there are a lot of systems like that that are very manual knowledge. I'm sure it's in some manual, like a book somewhere. But who is going to read that one book, that one binder full of ideas? Yeah, I don't know. Now I'm frightened, Chris. Thank you.

Chris: Yeah. You're welcome. Yeah, or how do those towns work? You're driving through the middle of nowhere and there's a town with ten houses on it, like a "one stop sign" town.

Dave: Yeah.

Chris: You're like, "Where does your water come from?"

Dave: Where does your water? Probably a well, individual wells.

Chris: Yeah. Oh, I suppose. Those people just well it up. Then also have the backyard thing where it just dumps under... What do you call that? They do their own sewage.

Dave: Collection bucket? Yeah. Oh, yeah, they've got a septic going. Yeah, yeah.

Chris: Septic, yeah.

Dave: Oh, I watch enough off-grid houses. I could tell you all about that. I watch enough YouTube about living off-grid in Idaho.

Chris: Do you? Oh, that's amazing.

Dave: Oh...

Chris: I even look at houses around here that are way up on a hill or something, like, "I don't think the city sent them up anything. I don't think they even have electricity, probably." So, they make it their own somehow.

Dave: Well, it's even more wild if they do. Somebody at the city was like, "Yeah, we'll run you a wire up there."

Chris: Yeah, 42 miles out to you. Sure.

Dave: My brother has... Let's see. I don't know. My brother is in Hill City, South Dakota. He's a little bit outside of city proper.

Chris: Mm-hmm.

Dave: Whatever registered boundaries of the city. It's funny. The Internet company is like, "No, we will not run a wire to your house. You are outside the city. If you lived a quarter mile up by the putt-putt golf course, we could do it." [Laughter] "But you're a quarter mile away, so we're not going to do it."

Chris: Got to draw a line, I guess.

Dave: Well, I just wonder. I bet he's on septic. I bet he's... Maybe he's on well water. I don't know about that. But I think he has water. He has electricity. But anyway, I'm just kind of like, what... He's just a quarter mile out, but he has to do all these services himself.

Chris: A quarter mile, yeah. I wonder if it's... Yeah, sometimes the Internet gets involved, too. I cannot get fricken' Dominos at my house. It's really not that far away. But somehow when I put in my address on the Dominos app, it's just like, "Out of range." I'm like, "Are you sure?"

Dave: Yeah. I could see it.

[Laughter]

Chris: I could just barely see it.

Dave: I can just see it. Yeah.

[Laughter]

Dave: We have the opposite problem. Dominos is the one in our neighborhood, like smack dab in the middle of our neighborhood.

Chris: Yeah.

Dave: It's just like you're just like, "Oh, I'm having Dominos again."

Chris: We'll be there in five minutes.

Dave: Yeah, yeah.

[Laughter]

Dave: But to get any other flavor of pizza is a deal because they're like, "Oh, I don't know, man. You're far away. I'm not going to do that."

Chris: Hmm...

Dave: Or you pay $70 for fancy pizza. That gets me. Oh, well.

Chris: Well, we did good, man. We did four.

Dave: Four questions on the question and answer podcast ShopTalk.

Chris: I'll say we mentioned it. We probably did it more at the top of the show. Who knows how many countless people have bailed on this episode? But we mentioned it early before. We got quite a few write-ins. Keep it up, people. We'll take your topics.

Dave: If you listened this far, just send us a tweet, "Looking forward to the Thanksgiving episode." Okay? That's what you say. Okay?

Chris: That's it.

Dave: You say, "Looking forward to the Thanksgiving episode," and that's it. That's it.

Chris: That's it. That would be amazing to know.

Dave: A little wink and a nod, turkey emoji. Right back at you.

Chris: Yep.

Dave: We got this. Yeah.

Chris: Human on human analytics.

Dave: Yeah, this is good.

Chris: Yeah. Cool.

Dave: All right. Well, 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 Mastodon. That's the good one. Then join us in the D-d-d-d-discord, patreon.com/shoptalkshow. A few people have joined, so thank y'all for joining us. It's great to have new faces. Chris, do you got anything else you'd like to say?

Chris: Hmm... [speaking in a whisper with an echo] ShopTalkShow.com.