Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris.

Chris Coyier: Hey! How ya doin', Dave? Episode #499 here. Pretty exciting. We have a special guest with us, a longtime friend of the show keeping us honest over here at ShopTalk Show, Melanie Sumner. Hey, Melanie. How ya doin'?

Melanie Sumner: Good! I'm glad to be here.

Chris: In your skyscraper in Chicago?

Dave: [Laughter]

Chris: Is that comin' at ya live from--?

Melanie: That's true. Yes, I live in downtown Chicago, on the top floor of a building. It's really fun.

Chris: Once in a while, we get photos from the view from Melanie's. It makes us all jealous.

Melanie: [Laughter]

Chris: Chicago being a very beautiful place and your place having a beautiful view. You can find Melanie online at melanie.codes. I'm looking at your GitHub profile, too, which somehow you have an A+. You get an A+ on GitHub for your stats.

Dave: You get grades on GitHub? What?!

Chris: Melanie does. You've got an A+.

Melanie: Yeah. I was excited to see that.

Dave: What?!

Melanie: Yeah. Cool, right?

Dave: [Laughter]

Chris: PRs, issues, contributions. I probably get a good C-.

Dave: Oh, man.

Chris: But I have no idea.

Dave: I would love -- I want a grade. Okay, well, that's cool. [Laughter]

Melanie: [Laughter]

00:01:36

Chris: I say a long-time friend of the show because, literally, for years, probably since the beginning, Melanie would write in (back before we had a fancy community Discord and all that) with sometimes questions and sometimes just comments and things on topics that came up on the show. But somehow, embarrassingly, have never had her on the show until now, so we're going to change that.

I think of you as -- I'm sure you're a much more complete person than this -- Ember Accessibility and Enterprise. You're the three E's except that accessibility starts with an A. An EAE.

[Laughter]

Chris: But certainly have been heavily involved with Ember also for years and years and years. Tell me about that.

Melanie: Sure. Yeah. I'm a member of the core framework team and also the steering committee, which handles the governance kind of work.

Chris: Mm-hmm.

Melanie: That's pretty cool. My role in the core team is about accessibility and how we can make Ember more accessible by default. So, what you get out of the box enables you, as a developer, to ship an accessible app, or at least we don't get in your way of building an accessible app. You could still ship a terrible app if you want to but some of the defaults we've improved over the last couple of years, so that's been really exciting.

Chris: I bet it is. This is one of those things where it actually lines up. Sometimes you hear really weirdly nonsensical things like, "Is Jamstack good at accessibility?" You're like, "Those two things are unrelated."

Melanie: Yeah. [laughter]

Dave: [Laughter]

Chris: It matters if your Markup good or whatever.

Melanie: Yeah.

Chris: Likewise, I'm sure you can write an Ember component with a div with a click handler on it, right? It's not going to prevent you from doing that. But a JavaScript framework does certainly have accessibility things in mind, like if it's handling routing, then is it helping you with focus management and things like that? Is that what you mean? What other things get tied in there?

00:03:40

Melanie: Yeah, so I actually wrote a library that handles accessible routing for Ember. We've recently started the project to improve the router. We just got some things. Ember just celebrated its tenth birthday and, for a JavaScript framework, that's really old. Right?

Chris: Or a podcast.

Dave: Or a podcast. Yeah.

Melanie: [Laughter] For anything in tech, really, and we're starting to do some improvements around how we handle query parameters and how we handle accessible routing. We sort of just reached that critical mass where we mostly love our routing story, but there are definitely some areas where we can improve and make it better for the modern Web, really. That's really what it is.

A lot of times, Ember is kind of a testing ground for new ideas. Then they'll get adopted into JavaScript through GC39. Then we have to go in underneath and switch out some of the stuff internally in Ember to match what's been widely adopted.

We have to do all of this in a backward compatibility way because banks use Ember. We don't want to break your banking experience. [Laughter]

Chris: Right, because you shipped a version and somebody just clicked the upgrade button - or whatever. Yeah. Yeah.

Dave: That's kind of like one big feature of Ember, right? It works.

Melanie: Yes.

Dave: It's almost like jQuery; kind of rarely broke compat. Ember is like, "We're making sure it works," right?

Melanie: Yeah. It's kind of weird to think that the rendering engine has been rewritten a few times over the years to make it faster. Consumers of Ember didn't have to do a single thing but take in the new version. It didn't change how you use Ember. It just changed how Ember worked for you.

Chris: Yeah, that's awesome, right? That's the good way that a framework can change is if you're like, "Oh, I do nothing and get benefit and just get to feel fuzzy about that? That's great."

Melanie: Yeah.

Chris: But that's probably a little hard to pull off. Once in a while, a framework will say, "Well, we actually have a better way you should be doing this."

Thinking about routing specifically, I don't think there's any doubt that people are the salty about React routers change at one point. It went through a change that said, "Hey, this is better. This is a better way to handle it, but it's totally not compatible." It was - whatever - version 3 to 4 or 4 to 5 or something like that of the famous React router, which is rightfully famous in that React really needed that. They needed to step in and provide that and did and did a good job. But, man, just literally yesterday heard people just beefing about it.

Melanie: Yeah.

Chris: Even though it was years ago at this point, and that's not something you hear really from the Ember community, probably on purpose, because it's like, "Well, you're not going to do that to people. That's your namesake. You're not going to just roll out a routing change that's just going to absolutely destroy the past."

00:06:56

Melanie: Yeah, and we have a really strong RFC process. If somebody wants to propose a change, they can. They can do a request for consideration, and it really gives us the chance, as a community, to talk about the idea all the way through.

What is a detailed design? How do we teach this? What effect will this have on users?

We do deprecate some things, but very slowly, and we give you lots of deprecation warnings, code mods if possible, so you just run a code mod and it changes the code that needs to change.

Chris: Fancy.

Melanie: Yeah, pretty nice.

Dave: Yeah, that's cool.

Melanie: Major versions in Ember don't release new features. They only remove deprecated features.

Dave: Hmm. Interesting.

Melanie: Yeah. This is very non-standard for the rest of, I think, the other JavaScript frameworks. But we think it gives a little bit more stability.

Dave: Mm-hmm.

Melanie: If you're on the last LTS of the 3.0 -- we just recently had 4.0. If you're on last version of the 3.0 series, well, you have confidence that you can go to 4.0. What you're going to get is smaller -- less JavaScript, basically, because we're going to remove a lot of this for you, and that's the major version bump.

When we want to do something like conceptual changes, we do what's called editions. These are more of what you would call a major version in another library or framework, but we want to walk you through a holistic picture of what the shift is and what this means for you. Because Ember is fully featured, lots of stuff out of the box for you, we usually have to tell multiple parts of the story in an edition, which is why we try to do that a little bit differently, I think.

Chris: Okay. Just so I have that clear. If you're on 3.2.6 and you move to 3.2.7, there will be nothing new. It will only remove things. But if you move from 3.2.8 to 4.0, then you get new things?

Melanie: No.

Dave: The opposite.

Melanie: The opposite.

Dave: The opposite. Yeah. Features go under the major/minor patch, right? Features go under minor.

Chris: Point release, you get new stuff.

Dave: Then majors take stuff out.

Chris: Version bump, you take stuff out. I think that does make sense. It's dangerous to go from 3 to 4 because something in your app that you used might be gone now.

00:09:50

Melanie: Yeah, and we have a tool, Ember CLI Upgrade. Somebody in the community wrote it. It will walk you through upgrading you step-by-step for new versions. It's pretty useful.

Chris: It looks at your code, so it's like, "Look. In your file dave.js on line 32, you're using an API that's gone now." Is that the kind of vibe?

Melanie: It's more about incrementally updating your dependencies and running tests. We have what's called Ember Try, so we'll run the codebase against different versions (that we call scenarios) to make sure not only are you--

We can give you kind of like an overall status. The last LTS version of Ember, the current version of Ember, the beta version of Ember. We're developing a new build tool, so we'll test against that now. And just kind of give you an overall picture of, "Hey, these are the things that are coming, and you can start thinking about those now."

I work on some apps where I'll disable some of those scenarios just so CI will pass, but it gives me a backlog, "Hey, I need to look into why that scenario is failing. Is it just some dependencies that need to be upgraded, or is there something I need to think about differently and maybe refactor a little?"

You get tons of warning, which I think is really great for enterprise teams who have to do planning, like a year in advance. You know? [Laughter]

Chris: Right. Is LTS long-term support or is it something else?

Melanie: LTS is considered stable. We are fairly certain that if you use this, you shouldn't run into any major issues. We've ironed them out by the time it gets to LTS.

Chris: Okay.

Melanie: That's kind of like every four minors, I think, that's the next LTS. Yeah.

Chris: Cool. You use the enterprise word, so let's go there. Where does that come from (an example) because I think that's a blind spot, perhaps, for Dave and me? Although, Dave, you work with enterprises where I don't. I just don't think about what's different for people that work in that world. Tell me about my blind spot. [Laughter]

00:12:11

Melanie: [Laughter] Well, maybe all the folks who have to work in enterprise are jealous that you get to have that blind spot.

You have to think about things at scale and you end up having a lot more constraints than just "What am I doing on my website?" For example, I worked for a global banking firm, and we had to wait to roll out some accessibility updates to some components because, in Europe, they were adopting some new legislation and they didn't want to roll out a new dashboard at the same time that these new regulations were rolling out. To have to think about all those things, it adds this extra level of complexity that you just don't anticipate or don't even think about because - oh, my god - as a Web developer, how many millions of things do we already have to know? To add, "Oh, there's some new legislation around finance coming out in Europe," that's a whole--

Dave: Yeah, it's kind of like enterprise is Web development with lawyers involved [laughter] in the process at some point. I've seen like we couldn't use certain versions of jQuery - or whatever - because it wasn't approved yet.

Melanie: Right.

Dave: Even some of that stuff, you have to guarantee it happens or you have SLAs, so you can have zero downtime in any kind of upgrade.

I'm trying to think of a weird one I had recently. I can't even think of it. That's how memorable it was, but I'm sure it was just like, you know, "We can't do this because--"

Oh, it's that classic thing where it's like if you take any kind of payment, the person who hits publish cannot be the same person who committed code. It's like the person who deploys it cannot be the same person that writes the code (if you handle money, PPI, or anything like that).

Melanie: Mm-hmm.

Dave: It's weird. It just affects the process, right? And so now the people chain is weirder.

Melanie: Right.

Dave: Or not as linear, and then you have to talk to whoever - Greg's boss - to kind of nudge Greg to release that, but Greg is like, "Is it in the ticket queue?"

Melanie: Then maybe Greg goes on vacation.

Dave: For two weeks.

Melanie: Yep.

Dave: And puppet and chef are broke for two weeks because some guy went to Burning Man. Been there. [Laughter]

00:15:02

Melanie: [Laughter] It's such a weird balance, too, between enterprise engineers and contractors. So many times, I will say things for months, I'll show demos, I'll do white papers, and I'll make Jira tickets. But until I bring a contractor in to say the exact same thing that I've been saying for months, there's not general consensus that it should get done.

I used to think it was just me, so even still on my desk, I have, like, "How to articulate design decisions," and "How to make it clear," and all these different books that are helping me figure out where I was going wrong. But in the end, it's really that they just want to hear it from someone else.

Dave: No, I mean I think Chris and I were talking. It's almost even like pay scales, too, affect that.

I remember one company I worked for -- got an audit from Google, like Google came in, you know. They were like, "We're going to help you." They were like, "Make the website faster."

Then all of a sudden, it was really important to make the website faster. [Laughter]

Melanie: [Laughter]

Dave: It was like, "Yeah, that's why you hired us," and I was a consultant. But sometimes it just takes a certain consultant to--

Anyway, it's weird.

Melanie: Yeah. [Laughter]

Chris: Well, so a lot of these things, they just sound all bad. It takes a long time to ship anything. The people chain is really weird. The requirements are harder. The constraints are thicker. It just seems like--

And so, I can understand the jealousy of being inside one of those things and looking at some nimble little company that pushes 13 times a day. I don't know what it's like at Discord, but I have never woken up without a little green arrow saying, "Update Discord." Gees, they must push ten times a day over there.

But what's the flipside then? It also means that, generally, you never get a call at 3:00 in the morning, right? They pay for it too, right? Are the jobs juicier in salary?

Melanie: Well, that's a good question.

Chris: Why would I work with all this crap, this stuff? I understand why because it's safety and regulations and laws and all these kind of important things. But that's undoubtedly a worse job, so I better get twice the salary, right? [Laughter]

00:17:34

Melanie: Yeah. There are a couple of things that I like more about working for larger companies. The benefits are usually a lot better, like really good. Healthcare is a non-issue.

You don't work after 5:00 p.m. ever. That's just a thing that you don't ever do - again. That kind of is what ended up freeing me up to work in open-source, somewhat, because I was able. I had the time and the energy to do a little bit of work after work (on open-source) and kind of start thinking about where I wanted my career to go next.

It's really secure. Yeah, there could be some big org change and everyone gets laid off. But generally, I was watching it take a year to lay off people who were actively doing harmful things, like in code.

Dave: [Laughter]

Melanie: I realized, wait, there's some security here.

Dave: [Laughter]

Melanie: I have a little bit of room to be a little bit more insistent about things I care about, like accessibility, like quality and markup and all that kind of stuff. They're not just going to say, "Okay. You know what? We're sick of your opinions. You're fired."

Dave: Mm-hmm.

Melanie: There's a whole process that they have to go through. When you figure that out, you can really use their internal processes to help them get better. There's a lot less insecurity around your job, I guess.

Chris: Yeah. Once you're in, you're in. [Laughter]

Melanie: Yeah, which it's what you make of it. I chose to make good things of it, and I'm not at a large company now. Actually, I'm at HashiCorp, a company that just recently went public. This is the smallest company I've ever worked for.

Chris: Oh, interesting. Tell us about HashiCorp. What's going on there? Are you continuing your accessibility - you know - career?

00:19:46

Melanie: Yeah, it's very cool. They recruited me to work on a design system.

Dave: Ooh.

Chris: Ooh.

Melanie: I'm an engineer inside of a design org, which is very cool. This is probably the coolest job I've ever had. It's very cool because I get to be around designers and people who care about design a lot more.

I'm okay at it, but I'm design-minded. I understand the concepts. I could do it, but I really like writing the engineering part better.

I just feel like I'm able to deliver a lot of value, and that's a really great feeling for me - being useful.

Chris: Yeah. That's nice. Does this design system have a name?

Melanie: No... and it's a source of consternation for me.

Dave: [Laughter]

Chris: Oh... No name. Okay.

Melanie: We're trying to name it.

Chris: It's probably not public then. Otherwise, it would be named.

Melanie: Well, all of HashiCorp's stuff is open-source.

Chris: Wow, so it's open-source without a name, so people -- for lack of a better name, it's the HashiCorp design system?

Melanie: Yeah, exactly, HashiCorp design system, which it might stay that. Yeah, and you can just watch it grow.

Chris: Yeah, and it could be a worse name. Sometimes you name things what they are.

Melanie: Correct. Yes. Correct.

Chris: Wow! Okay. Okay. So, the thing exists. I'm interested in this a bit because -- I mean a lot because design systems are, of course, fascinating.

Who does it serve then? Is it one of those multiple websites (at a minimum) and then other or does it go even deeper? Is it like serve the Android app - or whatever?

00:21:33

Melanie: Yeah, so most of the HashiCorp products are really targeted towards developers, engineers, sysadmins, that kind of stuff. They're trying to do -- well, they're successfully doing automation in all these different areas around app development, security, networking, and infrastructure - that kind of stuff.

Chris: Uh-huh.

Melanie: They're trying to make something that works with any cloud, so it doesn't matter if you're using Google, AWS, or Azure. That's fine. You can just still use the same product and manage all of those different things - resources - which I think is pretty cool.

Chris: That's what HashiCorp is, right? But you need to build dashboards and stuff.

Melanie: Yes, and if you ask somebody, "What do you use Ember for?" they're going to say dashboards. Infamously, Ember is the dashboard framework. It's really great for how we handle data and how we render things, and it's okay to be a little bit slower because you're literally at work at your dashboard. We're not trying to sell you something. We're trying to give you information that you need to do your work. Maybe the first render is a little bit slower, but everything after that is fine.

We have our internal product platforms are all Ember, but our marketing websites are all Next.

Dave: Okay.

Chris: Oh, interesting. It probably didn't hurt that you were Ember core when you got this job, right?

Melanie: I might have been recruited because I was Ember core.

Dave: [Laughter]

Chris: Okay.

Melanie: That might have helped a little bit.

Dave: It helps.

Melanie: I think it was more my work in accessibility and management said, "We want this to be accessible," so they specifically recruited for that.

00:23:33

Chris: Accessible and Ember forward. Fascinating. Okay, so the thing, does it serve anything other than websites?

Melanie: Not yet. What we're doing with design tokens, the team lead came from, I believe, Bumble before this.

Chris: Okay.

Melanie: He had a lot of experience with design systems and Amazon's style dictionary for design tokens.

Dave: Mm-hmm. Yeah.

Melanie: Which -- oh, my God! -- I was so excited to learn about this tool and start using this tool.

Chris: I've never really heard of it. Amazon design dictionary?

Melanie: Oh, my gosh!

Dave: Style dictionary.

Melanie: Style dictionary, yeah. It's very cool.

Dave: It's like a -- I don't know. You can just spit out JSON or you can spit out CSS vars or Sass vars or iOS crud, you know, XML files or whatever you need for that.

Chris: That seems like that's the heart of a design token, right? The whole point of them was, "Don't make them in CSS custom properties because that's really just output of it."

Melanie: Exactly.

Dave: Mm-hmm.

Melanie: Mm-hmm.

Chris: It should be some more agnostic language. In this case, the agnostic language is whatever this style dictionary thing is?

Dave: Mm-hmm.

Melanie: And you can convert to pretty much any platform for the output.

Chris: Yeah, that's super cool.

Melanie: It's super cool and it's useful because Figma (or any design tool, really), I haven't really seen them shift to a non-pixel-based design system.

Dave: Yeah.

Melanie: So, designers are shipping these things that are in pixels and four pixels here and six pixels here. I'm shipping things in relational units because it's for the Web.

Dave: Mm-hmm.

Chris: Right.

Melanie: I need to be able to handle Zoom. Yes, the browsers have gotten better at it, but we still need to use relational units.

Being able to pull some stuff from Figma, run it through a tool -- you know, I've written a conversion function -- run it through that tool and have the output be what I need it for the Web, that's super useful. A lot less me pulling out my calculator and doing math. You know?

Dave: Yeah. Yeah.

Chris: Cool. You're set up nicely for a non-Web thing. I only ask because - I don't know - I'm just curious about understanding this design system more holistically.

Does it end up on NPM? Is it one of those, like, if somebody is building a new Next site for a new marketing page at HashiCorp, can they just go NPM install HashiCorp design system? Now they got and then they use it?

Melanie: Yep.

Chris: Or are you like a mono repo setup, so you don't even need to bother pushing it to NPM because it's just next door?

00:26:29

Melanie: We are trying to do a mono repo setup, but you can also NPM install @hashicorp/designcomponent , /designsystem, or whatever.

Chris: Nice. Right, so it's one big ol' GitHub repo, which that we can probably know because I'm looking at it. [Laughter]

Melanie: Yeah. [Laughter]

Chris: That's cool. That's great! That's great. Then how do people really use it? Do they bring up the storybook and just be looking at it to know what's available? How do they consume it in that way?

Melanie: So far, we're a really new team, so we're still in trying to get everyone on our own team aligned, which that takes a little bit of time when you're a brand new team. But we're finding ourselves aligned philosophically, and we've been given the space to kind of work through technical opinions and details.

Our team lead calls it our scrappy website (for demonstrating). We'll make it fancy later. But for now, it's functional and our focus is on what components do we have now, what components are we building next--like right now we're doing our roadmap for the year--and that kind of thing. That's kind of where our focus is right now.

They've had a few internal efforts, and we're just trying to look at what do people need, though. We have enough experience on the team to, "In general, here's what we think you'll need," but we're actually going into the codebases and looking at, well, what do you have now and where could we actually bring improvements?

Chris: Mm-hmm.

Melanie: Accessibility, on a few pages, we've been able to give you 26% more accessible, for example, by fixing a few components.

Chris: Yeah, because you built it this way, but why don't you just replace it with the component that we've now shipped? It'll be more consistent with everything else we do around here, plus bonus accessibility points.

Melanie: Yep.

Chris: Enjoy.

Melanie: It's a very good selling point.

Chris: Less technical debt for you.

If we could talk friction for a minute, are there moments where they're like, "Yeah, I would use that, but you don't have a color prop"?

Melanie: [Laughter]

Chris: Literally, our sidebar is green over here in green land.

00:29:02

Melanie: The design org at HashiCorp, I'm very impressed with it. They're very strong, very cohesive, and there's a lot of unity there.

Chris: Mm-hmm.

Melanie: Sometimes we do get -- there are some of that because there's some of that everywhere. This is not a unique problem, right? I think those things will shake themselves out over time.

I've always worked at a place where it's very top-down, and it's very, like, you have the CTO coming in saying, "We're rolling out a design system and you're going to adopt it."

Dave: Mm-hmm.

Melanie: Managers are like, "Okay. We'll put that on our roadmap."

At HashiCorp it's like, "Please build this and we're going to be measuring whether or not folks are adopting it."

Chris: Okay.

Melanie: That's kind of neat, also kind of weird. I don't know.

Dave: That's the harder path, I think, because we were talking about it, weren't we, in the ShopTalk Discord. The insurgent path, I think is what it's called.

Chris: [Laughter]

Dave: You have to build up this army of users internally - or something.

Chris: Is it open to the point--? Let's say I'm one of these developers that's working on one of these Next apps - or whatever. I just know that -- because that skill set is very -- that is a front-end developer skillset.

If there's a sidebar component that I know needs to have a green background, but that's not one of the props, can't I just come over to this repo, add that as a prop possibility, push it, and now the design system is updated for my needs too? Or is that not cool because that person might not actually be on the design systems team and there's a whole process for adopting it?

Melanie: I would say any solid design system has a process for contributing. Of course, ours does because I'm very open-source, so I'm very, like, "Contribute. If you want to see change, make it happen."

Dave: Mm-hmm.

Melanie: "You can do it." Pure is welcome, and that's kind of our approach at HashiCorp as well. While the design systems team has final say and it's a very design-driven process, folks can definitely open an issue or open a PR.

Chris: Mm-hmm.

Melanie: I think we'll see a lot more of that as we get closer to parity with what folks have now.

Chris: Nice. How do these--? If you have Ember stuff and you have Next stuff, those are really different component syntaxes (as far as I know). Is it Web components or is there some other fancy tool you use to make them usable with both? How does it work?

00:31:49

Melanie: Yeah, so right now the Next team is actually just using the design tokens. They prefer to build their own components, and that gives them a little bit more flexibility.

With Ember engineers, they tend to want the prebuilt thing already easy, ready to go, and make it out of the box. I don't want to have to think about it.

I think I'm observing that very different mindset between different kinds of developers working on different kinds of products. Ember engineers tend to have apps that are a little bit more complex from what it's doing. It has to talk to servers, and it has to do all this different stuff.

Ember kind of frees you up to focus on what's important to you, but it means you give up the decision-making for a lot of the mundane details. If you love that, then you love Ember. If you don't like that, if you want to build everything from scratch yourself, then, uh, maybe you don't want Ember so much.

Chris: Hmm.

Dave: Well, and I wonder, too, if it's from a different angle. It's like I really want to use Framer Motion. You know?

Melanie: [Laughter]

Dave: That's got to be in there. Oh, man, Ember doesn't have that because it's all React only. Guess we're using React. You know? I wonder. It's sort of like all the influences that can choose your toolset.

Melanie: You know Yehuda Katz has this saying, "All good ideas end up in Ember."

Dave: [Laughter]

Chris: [Laughter]

Melanie: Sometimes--

Dave: Sounds very Yehuda - if I could say.

Melanie: It does, doesn't it? Yeah.

[Laughter]

Melanie: The idea is that sometimes we won't have an equivalent solution right away, or we'll say there's a little bit of a different way to do it. One of the other core team members, Ed Faulkner, created Ember Auto Import, so you could just use a JavaScript library. You didn't need an Ember version of it anymore.

Dave: Mm-hmm.

Melanie: But Ember thinks about some things differently and really kind of has some different ways to approach things. Even as we get this closer parity to the rest of, you know, to the other frameworks and we kind of want to make it easier for folks to use Ember or to be able to have the option and not have it be you have to go learn a totally new thing and think in a totally different way. There's still a little bit of that.

Chris: I love it. I appreciate Yehuda for being one of those code genius kind of like half-crazy guy, but who didn't go crazy and peace out and delete their repos or drive a motorcycle across Russia or something. Not that that's weird or anything, but I feel like the code geniuses tend to go crazy (in our industry).

Melanie: I think they burn out. You know I almost wonder if it's because of the constant hype cycle is just exhausting.

Dave: Yeah.

Melanie: I really appreciate shiny new things, but I'm kind of more of the kind of person who wants to find the thing that already exists and make it better, which is probably why Ember was a good fit for me. It really felt like it aligned with my previous experience, so I did PHP, like custom PHP apps and WordPress development before I did Ember. A lot of the stuff felt the same or felt similar enough to me that the transition for me was pretty easy.

Chris: That's cool. I had one design question for both of you. I can't talk about it intelligently in Ember land but React has this concept of spreading props. Meaning if you're designing a component, you have the option of (kind of at the root of the component) you just do ...props, and anything that would have came in as a prop when you call that component, it just is like, blah, and it barfs them out on the thing. The reason that you do that is because then it's like - I don't know - when I call this component, I could put ARIA label on it and it will just work. It'll just barf the ARIA label out onto the parent component, and I don't have to make a prop specifically called ARIA label and then pass it in and then put ARIA label. It'll just take whatever.

You kind of do that for overriding possibilities too because then if you pass a style prop in, then it will apply the inline styles on top of it. Then if somebody really, really wants a green sidebar, they just put style background color green on it and it will spread the prop and blast that background color green on it. It's this tradeoff between--

An alternative is to not spread your props, meaning that if you try to do that, it won't. It won't end up on the DOM element, in the end. So, too bad. It's like a way of exerting some control over the design system, like, "We don't allow that around here."

It feels like a philosophical choice of a design system. Do you have any strong feelings either way about, like, "Feel free to override this in any way," or "Please don't override this in any way"?

00:37:11

Melanie: Dave, you go first. I want to hear what you think.

Dave: You know that's tough, especially if you mix in prop types or some kind of validation, too, I feel like. Maybe it's different in React land, but in Vue land, it's just kind of like you have to say what props this have and give them types and stuff like that, or your linters. You have to give it a type if you're going to pass it in.

I could see situations where "Just chuck all props always," is the prop type, or checker would just be pissed all the time.

[Laughter]

Dave: But I don't know. Yeah, it's that constant thing. It's like how much is too much.

Yeah, I like this. There's a little model from Web components where, because it's usually just a class, like my dialog - or something - class my dialog extends HTML element, you can actually go "Class, not my dialog, extends my dialog." You know?

Melanie: [Laughter]

Dave: It's like you can kind of override and then inject your own CSS if you want to get real rowdy, but then that creates another component in the system, and now it's noisy or cloudy.

Chris: Mm-hmm.

Dave: But I don't know. I also don't hate just passing a color. [Laughter] I guess it would be so situational for me, but then that's where it causes problems because my definition of the right situation is not everyone's definition.

00:38:57

Melanie: Yeah, so I'll say in Ember we have what we call "splattributes," ...attributes.

Chris: Mm-hmm.

Melanie: If you add this to your component, when it's invoked, the person using the component can add extra ones, and it's fine, and they'll render. It's fine.

But for security reasons, Ember will throw an error if you try to add inline styles.

Chris: Oh, really?

Melanie: You can add a class name. You can add an extra class name and it will append the class name to the class, but we don't want you doing inline styles. I mean you can turn it off if you really want to, but it's not idiomatic. You're definitely going against the well-lit path, and we'll try to stop you multiple times because it's a bad idea.

Chris: [Laughter] Wow!

Dave: It's good.

Chris: Fascinating.

Melanie: That's probably, too, an enterprise thing. Think about you don't want inline styles in your banking. That's a security issue, right?

Chris: I'm not sure what the security issue is. I know that it's in bad taste because if people go crazy with that then it's like, "You've gone rogue!"

Melanie: You can do cross-site scripting.

Chris: Really?! All inline styles open up XSS?

00:40:13

Melanie: Before I was a Web developer, I was an intelligence analyst for the U.S. Navy, which is just a fancy word for spy. But it really made you think about -- it made me think about Web security first. That's probably the first thing I thought about when I was working on websites, like, "If I'm a bad guy, how do I hack this?" Or "If I'm a person with malicious intent, how do I hack this?"

Chris: But would it be a malicious intent that works for you (in this case)? I wouldn't suggest taking user input and putting it as a style attribute. That would be--

Melanie: I think one of the things I've seen about enterprise engineering is that "If it builds, it works" is kind of the mentality, and it kind of comes around to this idea that we're not really teaching Web fundamentals in a good, strong way across all engineering.

If you go to school for a computer science degree, you're probably not learning the stuff you need to build an accessible, secure Web application. That's probably where the tradeoff is.

Dave: That's interesting. "If it builds, it works," that's 1000% of Web development. [Laughter] It's built. It works. It's fine. It's good. Everyone can use it - of course.

Chris: That is a pretty good segue. I don't know if it was intentional or not, but that idea of -- oh, now I lost it. I'm sorry, but there's one thing we really want to talk about, which is the idea of accessibility prioritization as far as when you learn Web development. Why isn't it there so much? And why are there so many--?

These are kind of your words--when we talked about this on a previous show--that you wrote in about. There are so many freakin' geniuses out there that know a hundred billion things about Web development. They know everything. They're full-stack. They know how to write a database migration and they know how to build the design system. Blah-blah-blah. They just know. There are 500 things and, in their own minds, they're geniuses, and they probably actually are geniuses because a lot of this stuff is actually pretty complicated. Yet, have this tremendous blind spot for accessibility. How did that even come to be?

Melanie: Yeah.

Chris: How the hell did that happen?

00:42:43

Melanie: [Laughter] Because we don't use machines that are not our development machines. As much as we try, as much as we drill into our heads, "We are not the users," still we have to make it build and deploy. Right?

Dave: Mm-hmm.

Melanie: We have to figure out all these hard things like I need to write an adapter that serializes the data coming from a database and going into my data model. All of that needs to work together and, of course, five different people built six different APIs. All of that kind of complexity, on top of deadlines, on top of "Does it render in the browser, though?"

Chris: Yeah.

Melanie: Then the browsers are changing every hot minute, and it worked yesterday in Chrome and today it doesn't. What happened? Overnight, we got an update that broke some stuff. Sometimes that's a bug and sometimes it's on purpose.

In juggling all of that, we forgot to go use a different machine. We forgot to think about people who need assistive technology. Or maybe we just - worse - forgot that they existed.

I think we're having kind of this really great moment for accessibility in the Web right now where I'm seeing it in so many more places. As someone who has felt like it's insurmountable, "It will never change, I'm just going to go cry in the corner because I just can't seem to affect change. How do I do this?" But that you're seeing a lot more folks bring it up in their CSS course. Well, that's pretty cool.

Chris: Right. Doesn't that feel like that's the place for it, too - to some degree? You should learn those things right alongside everything else you learn in the very, very early days. So, by the time somebody -- you're looking at a tutorial that has div unclick on it, you're like, "Wait! Wait. Wait. What is that?" That doesn't seem normal to you. That seems like a mistake to you (the first time you see it).

Melanie: Yeah. You know I would say even like five years ago, I was having developers tell me, "Oh, just use a div. You're so old. Why do you want HTML?"

Chris: [Laughter]

Melanie: I'm like, "Oh, no. Okay. Yes, I might be old, but also [laughter], no, there's a reason."

Chris: That's even more. That's even a different category of active distaste for it.

Melanie: Yeah.

Chris: Not only like, "Oh, I didn't know that." It's like when you learn how to sort an array a different way. The reaction to that tends to be like, "Oh, how interesting. I didn't know that API was around." Applaud. Clap.

Then if somebody says, "What's that section element?" "That should be a div."

Instead of curiosity, it's like, "Meh! Meh!"

Melanie: Mm-hmm. Mm-hmm.

Chris: What the flip!

Dave: [Laughter]

Melanie: Well, you know why? Because you can use clever JavaScript to say, "In these situations, make it this. Make the component kind of look in this shape." If everything is a div, it's a lot easier. There are a lot fewer conditionals, right?

Dave: Yeah. Well, and it's a lot of thinking, right? You have to think about, "Oh, is there a better option for this element?" Not saying JavaScript developers don't think. I'm not making that generalization -- although I could.

Chris: Hmm.

[Laughter]

Dave: But I mean, for me, it creates a lot of choice. I can just go div item one, div item two, div item three. Looks good. Works. But guess what. Oh, well, LIs may be a better choice.

It lets you know. It's not immediately clear, the benefit, unless you kind of dig in and you peel back that layer, like, "Why does HTML even exist?" Or it's a structured markup language. Okay.

What are these structures? You know? Then the fact that accessibility OM is completely hidden from you unless you open the right panel in dev tools by accident.

Melanie: Yeah. Yeah. Mm-hmm.

Dave: Yeah.

00:47:08

Melanie: [Laughter] That didn't even use to be there, right? You kind of had to know. I've had to teach really brilliant JavaScript engineers. "Hey, your code needs to be able to talk to another machine's code."

Dave: Yeah.

Melanie: Like a screen reader, and that kind of blew people's minds at first. But some of this stuff we're seeing is--

The first approach I had towards teaching engineers about accessibility was kind of empathy, like, "Hey, care about people. Also, hey, don't get sued. Also, hey, you're missing out on more revenue."

But I would say, in the last few years, my approach has really evolved to be more like, "How can I give you better tools so you're aware of this thing." I worked a lot on Ember Template Lint, which will go through--

We wrote really specific rules based on accessibility criteria that will tell you if you do something wrong in your template and what you should do instead.

Chris: Oh, that's cool. Is it like form label input pairs and stuff like that - those kind of classics?

Melanie: You're missing a label.

Chris: Yeah.

Melanie: Or you put an interactive element interaction on a non-interact development.

Chris: Mm-hmm.

Melanie: You have nested interactive elements.

Chris: Nice.

Melanie: Yeah, the node AST.

Chris: You wrote your own little Axe - or whatever - for Ember.

Melanie: Kind of, yeah, because we do have -- we use Axe core as like the testing, so the dynamic part gets tested. But to have that feedback before you push, to have that feedback before you run your tests, inline while you're writing your code, that's really valuable, and we could also write fixers. So, you can run yarnlint:hbs--fix and if it's fixable, it will fix it for you. That was pretty neat to do for the community.

Chris: Yeah, the fixer is pretty amazing. My gosh.

Melanie: Yeah, it's pretty cool.

Chris: Yeah.

Melanie: Yeah.

Dave: Wow. That's going the extra mile there. [Laughter] Not just complaining. You're actually fixing.

That's the thing. I always go to button H2, like a button with an H2 inside of it does not work. It's actually wrong. [Laughter] It's wrong HTML. But a button inside an H2, you're good to go.

You're just like, "This is so weird. No one taught me that." [Laughter]

Melanie: Yeah. Yeah. Yeah.

Dave: I had to find that out 16 years into my career. Linter is kind of stepping in there to be like, "Oh, whoa, whoa, whoa, buddy." [Laughter] "You biffed it." That's pretty helpful and cool.

00:50:09

Melanie: It was kind of gaining the confidence. My career has kind of evolved over the years, right? I grew up in a religious cult, and my choices were housewife or missionary.

Dave: And you chose spy. [Laughter]

Melanie: Yeah.

[Laughter]

Melanie: If that's your calling, great for you, but it wasn't mine. So, I find that in working for the Web and showing up and also doing things that men have typically said women shouldn't do these things -- like women shouldn't be in the military, women shouldn't be software engineers -- there's part of me that's like, "Hmm. Watch me."

Dave: That's good.

Melanie: I'm a little bit spicy that way, right? There's gaining the confidence to show up in the first place, and then gaining the knowledge to say, "Oh, no. That's incorrect." Then evolving into a place where I'm saying, "This is not correct. Here's why. Here's what I'm recommending instead. Also, here's a tool that will help you do it."

That kind of evolution along the way is how I feel like I get to contribute to make the Web a better place, and that's pretty cool. That's how my thinking about accessibility has evolved. Yes, I get to be a better human because of it. Great. But if we could just turn this into only a technical issue -- we're producing better code, we're giving you more tools so you can still be a brilliant engineer and think about hard stuff -- but we're going to support you better. I think that's kind of where I'm at with accessibility. I want the tools to support us better, to make it easier for us to do the right thing.

Dave: I like it.

Chris: Yeah. That tooling stuff is so huge. I love the idea of catching it before it's even transformed the first time. It's right there in the editor.

Axe uses this term like shift left - or whatever - which I like now that I learned what it is. Although, I felt left out for a while. I feel like I heard shift left a lot in my career before I had any idea what it meant.

But it meant all the way to the right would be like catch accessibility problems when it's caused a problem for a real user and they write you an email. That's at the end of the process. That would suck, so let's move it a little sooner. Let's catch it because we're testing production with some tool.

Well, that's not all the way to the right, but it's still pretty far to the right. It shifted a little bit left. Well, that's testing it in the GitHub repo or something. Continuous integration shifted a little bit left. It's like, let's test it on our local machine before it's committed but after it's built.

Shift left even more and you're in Melanie town where you're checking your accessibility in templates. That's about as left as it can possibly be. The second the code has left your fingertips it's being checked for code. I think that's pretty cool.

Although, I do think they should be tested in all of those places because who knows what happens in the transforms. Having accessibility testing in CI is pretty cool. Having it run again after it's been deployed is also cool.

00:53:37

Melanie: Yeah, definitely. Then we can take it one step forward, which is really where I'm going kind of next with how I think about accessibility, like what's the future for me. That's continuous accessibility.

We have continuous deployment. We have continuous integration. How can we have continuous accessibility? Is this even a concept? How do we do this if we want to do this?

In the linting tool, we can have -- and I think we actually borrowed this idea from eslint. I don't even think this is a new idea. We can have something called a to-do. What this allows us to do is roll out a new linting rule and existing code gets a to-do to fix the issue but all new code is immediately subjected to that new linting constraint.

This allows you to roll it out, new linting rules, whenever you want to, to huge code bases. You're really putting power in the hands of the developer to incrementally improve their code. I'm pretty excited about this idea. I'm even trying to write a book about it.

Dave: Cool!

Chris: Nice!

Melanie: We'll see how that goes. Yeah. Yeah. About the metrics around how do you measure this. How do we accessibility engineering into a practice that can be quantified and not just qualitatively measured, and what does that improvement look like over time?

I got to work with some really brilliant engineers at LinkedIn doing specifically work on continuous accessibility in Ember, and it just got me thinking about things in a whole extra new way, and it's been really just -- I don't know. I'm excited to see where it goes next.

Chris: It's cool to see somebody that's been at it for so long excited about the changes and new things and new possibilities instead of just being like, "I'm going to burn it all down." You know?

Dave: Yeah.

Melanie: [Laughter]

Dave: You haven't entered your bitter veteran stage yet.

Chris: [Laughter]

Dave: [Laughter]

Melanie: I don't know, man. This June will be 25 years since I first started writing code for the Web.

Dave: Okay. Well--

Melanie: I'm going to have to take myself on a vacation or something. I don't know. If we're not still having a pandemic, maybe I will.

Dave: Celebrate. Get a milkshake. That's what I'm going to do.

Melanie: [Laughter]

Dave: All right, well, that's probably a great place to peel off here. Thank you so much, Melanie, for coming on the show. Long overdue, but for people who aren't following you and giving you money, how can they do that?

Melanie: Oh, they don't need to give me money. They can support Ember and open-source if they want to. I've got some open-source projects on GitHub that are always open for sponsors. I'm @MelSumner on GitHub. You can really find me -- I don't know. I think the first time I met Chris, he said, "Oh, you're Melanie from the Twitter."

Chris: Uh-oh.

Dave: [Laughter]

Chris: Nice. Uh, that could have been worse.

Dave: [Laughter]

Melanie: [Laughter] No, it was great. Twitter or GitHub, yeah. Or, of course, the ShopTalk Discord.

Dave: Oh, yeah!

Chris: Ah, nice.

Dave: The D-d-d-d-discord. Awesome! Well, thanks again, and it's exciting to kind of - I don't know. I like this accessibility automation stuff, and I like to see where you're going with it. So, thanks for coming on the show. Really appreciate it.

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. You've got to stay tuned for Episode 500. It's just around the corner, baby!

Then, yeah, follow us, @ShopTalkShow, for 16 tweets a month.

Chris: [Laughter]

Dave: We are doing videos over at the real CSS-Tricks YouTube channel. Of course, hang out in the Discord, patreon.com/shoptalkshow. We'd love to have you.

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

Chris: ShopTalkShow.com.