558: Esoteric Weird Content Editable Problems with Kristin Valentine

Download MP3

Kristin Valentine from Vox joins the show to talk about text editor CMS fun across multiple sites, Vox's Chorus, The Verge redesign, sharing Design Systems, theming articles, and a fun new game called "Can Your Text Editor Do This??"



Kristin Valentine

Kristin Valentine

Web · Social

Engineer at
Vox Media Product.

Time Jump Links

  • 00:49 Guest introduction
  • 01:44 Picking a text editor CMS
  • 10:12 Why does Vox use Chorus?
  • 12:45 Setting up Chorus as a Saas
  • 14:09 The Verge redesign
  • 17:01 How can sites share Design Systems, with different feels?
  • 22:41 Sponsor: Frontend Masters
  • 23:51 How does The Verge tackle themes?
  • 29:59 Are articles cached?
  • 30:55 Rewriting the Quill editor
  • 38:43 When do you start over in a new tool?
  • 43:51 Are you front of the front or back of the front?
  • 46:30 Can Quill do...


[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... um, I was going to say, "Eater--Rupert." [Laughter] With me is Chris--Vox--Coyier. Hey, Chris. How are you doing today?

Chris Coyier: Block Editor Coyier.

Dave: Ooh, yeah.

Chris: I am all good. We are going to end up talking journalism and building tools for journalists and - I don't know - CMSs and the news and whatnot because we have a very special guest on, Kristin Valentine. How are you? Thanks for joining us.

Kristin Valentine: Hi. I'm good. We can also talk about Quill. I know that's been mentioned on the show before. [Laughter]

Dave: Oh, yeah.

Chris: Ooh... Nice.

Dave: I feel like, in the Discord, the ShopTalk in the D-d-d-d-discord, every six weeks somebody is like, "I need help. What WYSIWYG do I use?" Right?

Kristin: Yes.

Dave: And you have opinions, so I think that helps in this conversation.


Kristin: I have opinions. They might be spicy. We'll see.

Dave: Good. Good.


Chris: Yeah. Let's say you're going to build an app and it has a thing that you need to write text in the app. Obviously, a text area is the Web's answer to that, which is not very good if you want to do something like make a word bold or have a header or insert a link or do literally anything that has to do with content production, which comes up, apparently, every day in the world of building websites. Yeah.

Yeah, we used to talk about this more on the show. Maybe it was early Luro days, Dave, when you were trying to figure out which one you were going to use.

Dave: I tried out five.

Chris: Wow.

Dave: You start with... I forget what would be the first one. It might have been Quill, actually, was where I started. But then you need one feature. You need an image-y thing, or you need a link, or tables. That's, I think, tables was what broke me. [Laughter]

Chris: Oh...

Dave: Then I try all these other things. I'm trying this one from Facebook. It's written in Reach, but maybe I could port it to Vue. I don't know. But is it going to meet the needs? Is it installable and generic enough? I just feel like you run the whole gamut of all these things.

We ended up settling on Tiptap, which is great, but you get on the marketing site and it didn't pass the smell test from my coworkers because the marketing side is all about, oh, it's like concurrent editing, a bunch of people editing the same document all at once, you know, GraphQL.

Chris: Mm-hmm.

Dave: It's just like, "No, no. We just need one person writing in a text box." Then you get drunk. You say, "I'm going to write it in content editable."

Chris: Ooph!

Dave: You just delude yourself. Then you go to the full other spectrum. You're like, maybe FKC editor is the right choice. [Laughter]

Anyway, how do you choose a WYSIWYG? What's the proper--? [Laughter]


Chris: Well, especially for a thing that you expect, you know, newsrooms full of people to use, right? This is a big choice for you all.

Kristin: Yeah. I wasn't on the team when that choice was originally made, but we do have to do all that stuff. We have to have concurrent editors and auto-save and all those other features that make it infinitely more complicated. We also support editorial workflows, which also increases complexity.

For us, an editor that just outputs HTML won't really cut it, so we did something that does operational transforms and stuff like that. That cuts out quite a few edits right there.

Then because we're not really a website builder, like a WordPress, we allow them to put some amount of special blocks like tables and stuff. But all the editing for tables is completely outside of the actual Quill instance because, like you found out, it can be really complicated to put some of those really special UIs because Quill has such a specific opinion about the document itself and it doesn't allow extra HTML in there.

Dave: Mm-hmm.

Chris: Mm-hmm.

Kristin: Yeah, so whether we will always stick with Quill, I couldn't really say. But I think, for us, it works pretty well, especially with the multiuser editing piece because it does a really good job of merging conflicts together. We also support version history so, yeah, it's a whole thing.

Chris: Ooh... that's... [Laughter]

Kristin: Yeah.

Chris: That's a nontrivial addition.

Kristin: Yeah. Yeah.


Dave: Let's set the stage. You're at Vox, right?

Kristin: Yeah.

Dave: You work on Chorus. Is that the name of the custom, behind-the-scenes, CMS that powers all of Vox?

Kristin: Yeah.

Dave: It powers Eater, Vox, The Verge, Polygon.

Kristin: That's right.

Dave: The other ones... sport one. [Laughter] SB Nation, right?


Kristin: Sport Ball Nation, yeah.

Chris: There's probably like a movie one.

Dave: Sport Ball Nation. [Laughter]

Kristin: [Laughter] Yeah.

Dave: It does all that, so how many people? Can you ballpark? Is it tens of authors, editors a week, or is it hundreds, or is it a thousand?

Kristin: Yeah, I mean it's probably closer to a thousand because we have--

Dave: Wow.

Kristin: SB Nation is giant, and there are just a ton of freelance editors and writers. There are just a ton of people just on that site alone.

Dave: Mm-hmm.

Kristin: They're not heavy users, but they are there. And you know some of our Verge authors, they're in there all day long, so it runs the gamut from people sort of casually in their quickly to people with heavy use, so that's another tricky thing about working on it.

I will say we've gone through a number of mergers and acquisitions over the last few years, so we have now New York Media as well as G9, which they have the Dodo and a bunch of other gigantic sites. They all have their own customer CMSs too. [Laughter]

Dave: Oh, neat.

Kristin: Yeah. [Laughter]

Dave: You get to paratroop into a different world.

Kristin: Yeah. Yeah.


Chris: Interesting. Then is the goal, like, "Whatever. I get it. Acquisitions happen. It makes sense that they weren't using our CMS pre-acquisition, but it sure would be nice if they would"?

Kristin: Yeah. I think when New York came on, we had an idea about merging everything together. Then G9 came on. I think there was a little bit of a reevaluation of, like, "You know New York has a totally different opinion about how websites should work, and we can't just keep merging everything together," so we're kind of in a place where we want the services to be able to sort of talk to each other but we don't necessarily want everyone on the same CMS.

Chris: Hmm...

Dave: Hmm...

Kristin: New York is much more design-focused, and they're a little bit more of a builder tool than ours is, so I think we've come to the conclusion that different people want different things and it's just too impossible to make everyone do the same thing.

Chris: Yeah. Interesting.

Dave: Yeah. I've seen a lot of - I don't know. You hear... I think time, too, right? Over time, does something become a major burden to maintain?

We talk with a lot of companies who were kind of more in the design system space, but it's like, "I don't have one design system. I have five completely different design systems from every brand we've acquired in the last ten years." It's just wild. You know.

Sometimes the work is normalizing it. But sometimes the work is, how do I just let them be weird and not lose our mind?

Kristin: It's a very tricky balance.

Dave: Yeah.

Chris: I wish I was privy to the conversations of post-CSS-Tricks acquisition, but I wasn't really. But I did know, because I contracted a little while post-acquisition that they definitely had a goal of re-platforming the thing.

In my own brain, I was like, "Oh, man. That's just going to suck for you."


Chris: This is an ancient WordPress site with all kinds of little bespoke stuff that it does, and I just don't know. Good luck, I guess.

But I was hesitant to say that it's a bad idea because if it's the one little weird black sheep outlier of everything you own, that can be problematic too. Why keep around some WordPress expert when you have none else of those on your team? That would be surprising to me being a hosting company. You'd think there's probably tons of WordPress on your platform and it probably doesn't hurt to have some expertise in that on your team.

But that aside, it was interesting to see the immediate push to get off the CMS. And I didn't get to hear the conversations of, like, is that a smart idea or not? It sounds like it was New York in this metaphor. Just let it be weird.

Kristin: Yeah.


Dave: Why does Vox need Chorus? Why not just spin up a WordPress multisite? That's good enough, right?


Kristin: Yeah, that's a great question. I mean it's always the "buy it or build it" question. I think, for us, at least at the time when we built Chorus, we really wanted something focused and had all those editorial steps and workflows, and something like WordPress just didn't quite have it.

I've only been at the company for almost four years, so I wasn't part of those early conversations. But I think part of it is, for instance, SB Nation just has hundreds of communities, and managing all of those communities is tough. I've tried to run a multi-site. I haven't touched WordPress in years, but running many, many sites on a WordPress instance can get pretty hairy also.

Yeah. I don't know what all, if they looked at all kinds of CMSs in the very beginning, but the very, very original... SB Nation was the very beginning of Vox Media. That was (and still is) a gigantic Rails app, custom Rails app.

Dave: Oh, yeah.

Kristin: Yeah.

Dave: Okay.

Kristin: Yeah, so the current version that we have of Chorus came much later because it all used to be a Rails app. Chorus, the editorial tool that I work on now that's what the writers see, it is a Ractive app, which is an old JavaScript framework that no one uses anymore.

Dave: Oh...

Kristin: That we are rewriting in Vue. But the original version of that is only, I think, like five or six years old.

Dave: Oh, wow.

Chris: Ractive?

Kristin: Yeah. Yeah.

Chris: I've never heard that word before.

Kristin: Yeah.

Chris: Wow.

Kristin: Well, yeah, exactly. [Laughter]

Dave: Now it's going to be in Vue. If I recall, I feel like Scott Kellum used to work on Chorus and Mandy Brown, I think was involved at one point, too.

It's just very interesting. I like the "built it, buy it" thing. If you're in the business of publishing, you should own your publishing tools, right?

Kristin: Yeah.

Dave: That should be a core piece of it.


Chris: Yeah. I think Vox is plenty big enough to have their own CMS and have that not be a questionable choice. In fact, there was another twist to it, though, right? They're like, "If we're going to build this thing, maybe we'll sell it, too," and then you did for a while.

Kristin: We did. Actually, that's why I was brought on to the team originally. I worked on the SaaS business.

Chris: Ah...

Kristin: Yeah, I spent most of my career in design agency land and contracting land. So, yeah, I was brought on, on the SaaS business, and worked on basically working on the front-end of This Old House.

Chris: Wow!

Kristin: They don't anymore, but they ran on Chorus. Yeah, which was a weird--

Chris: Dream job!

Kristin: [Laughter] Weird choice.

Dave: Bob Vila? Is that... Bob Vila?

Chris: Yeah.

Kristin: Uh-huh.

Dave: Do you know Bob Vila?

Kristin: No.


Dave: Oh...

Chris: Damn it.

Kristin: Yeah, it was... But yeah, most of the customers are actual media companies or nonprofits. It ended up not being a great fit for us. There's a lot of support and stuff that goes on, obviously, in a new SaaS business, as you're well aware. And I think that we just decided it wasn't quite what we thought it was going to be.

Honestly, Chorus just originally was not set up to support any design system ever, so I think we just decided it cost too much for us to make it happen. But we got a lot of great things out of it, which is building our own internal API that made things like The Verge redesign possible. Yeah.

Dave: That's... Yeah, that's probably a good segue. You worked on The Verge redesign.

Kristin: I did.

Dave: I've been a reader of The Verge for many years, as my Feedbin likes will attest.

Chris: [Laughter]

Dave: But this is kind of a big... It was a little bit like, "Let's just wipe it out and redo it," right? It was kind of a big one, huh?


Kristin: Yeah. Yeah, I mean that's a totally new technology on the front-end. Obviously, I worked on the tooling side of it. But the front-end basically went from Rails app to Next.js app, so it was a pretty big deal for us.

Dave: Yeah.

Kristin: Yeah, and eventually, we will... All of the sites that are on Chorus will eventually be on that platform.

Chris: Hmm...

Kristin: Yeah, there are a lot of exciting ideas around that, like this concept of quick posts, which is those short... And it's essentially tweeting to the homepage.

Chris: They're great.

Kristin: [Laughter]

Dave: Yeah.

Chris: Yeah. It's a good idea.

Dave: Tweeting to the homepage. I actually wish more people did that. I don't know.

Chris: Right.

Dave: Like the New York Times, it's like you've got to pay $50 a month for it. It's like, "Yeah, I'm going to support journalism. I'm totally doing that." Then the articles are like 70 pages long. It's like, "There's a little village in eastern Australia that blah-blah." You know? It's about climate change, and you're like, "Okay, cool. Yeah, show me a chart and a graph about fire or something. That's what I actually want." Anyway.

Kristin: Yeah. I think the idea... I mean part of the idea around that was they are very active in our Slack. They're like, "You know we wish people could see all of these posts, like links that we post, and this chatter. We think it's interesting." It's like, "What if we could put this on our website?"

And that was, I think, a lot of the seeds of the idea for that was like, "We have interesting discussions but it's not a story. There's no story to write about this. It's just an interesting thing that we think we want to share with our readers."

Chris: Yeah, and can those two things live side-by-side? And the design kind of proves yeah, totally, they are interesting. I'm a big fan.

It was so shocking when it came out. It certainly - I don't know - had people talking anyway, for better or worse. I'm sure people found stuff to hate about it immediately.

Interesting that it feels like a while ago now, at least many months ago, and it's not different. You certainly didn't back down from it or anything.

Kristin: Well, there were tweaks here and there to make it more readable or just things like that, but yeah.

Chris: Oh, that's great.

Dave: I think it's interesting. I do have a question. Hopefully, we're not treading into hot drama territory. But I know Yesenia Perez-Cruz worked a lot on design systems for Vox (at large). It's in her A Book Apart book and stuff like that.

This seemed like a divergence from maybe the existing setup. Is it very different code-wise? Is it an ejection from the design system, basically? Are you worried about that or thinking about that at all?


Kristin: I think, for quite a while, we've been rethinking the design system. In a sense, we kind of have multiple design systems. We have ours internally and externally. I think, as we've wanted to rebuild the front-end, we thought a lot about how can the sites share a design system but also have a very different feel.

Dave: Mm-hmm.

Kristin: Then starting over in a new technology. For a while, we were actually working on something else that ended up getting shelved that was sort of like a design system builder, like very meta design system. [Laughter]

Dave: Yeah.

Kristin: Yeah, so there's been a lot of different thought around this. Yeah, we've kind of moved in a different direction. But I think, overall, we still want some amount of similarity. I mean they're all going to share components. They're all going to share a lot of the same.

Dave: A lot of them are articles, lists, feed lists, right? Those are similar, I guess.

Kristin: Yeah. Fancy blog. Fancy blog.

Dave: Fancy blog.

Chris: Yeah, but if they are too the same, it's a little boring, right - or something?

Kristin: Yeah. Well, they all have different editorial goals and ideas, so how can we make something that is maintainable for our small teams? I think that's another... It's not like every single site has their own designer and team to build everything bespoke. It's like, how do you give people bespoke things without making it impossible to manage?

Dave: Well, you know there's stuff like review card, right? The new Verge one is very different. It probably looks... you know. But the data is maybe the same as what's on an Eater card.

You're in the CMS. You probably could tell me exactly. It's exactly the same data. But so much of design systems, we talk about the visual, like, "Ooh, yeah. Look. It changes the looks," right? But maybe the story is actually, "No, now we just call it the same thing, and it's the same thing in the database now, and that's really the power from the design system."

I don't know. Has that been your experience is kind of like now the data is better? What problems do you sort of anticipate going forward now that you've ejected from the design system? Is there anything you're worried about?


Kristin: I think our approach... I mean it's the best we can do. I think it can be a little tricky when you're doing one site at a time over a long period of time. It's like you build a design system that you think is going to scale with additional sites, but you only have one site. So, now we're working on what does it look like to have a system with Polygon and The Verge both sharing it.

Dave: Mm-hmm.

Kristin: You know that's the moment when you start to find all the things that are really bespoke to The Verge, and you're going to have abstract that out. I think that is the tricky part.

Dave: But maybe that makes sense because Verge and Polygon are similar. Even some articles get cross-posted or whatever.

Kristin: Yeah.

Dave: It's a similar DNA. It's not totally different.

Kristin: Yeah. We'll see what it's like when I bring Eater Maps onto it. [Laughter]

Dave: See how it goes.

Kristin: Yeah. Yeah, I'm not too much part of the audience experience anymore since I work so much in the CMS. But yeah, the only thing we built special for that site was quick posts. Everything else is the same data-wise and CMS-wise.

Chris: Hmm...

Dave: Very neat.

Chris: You're saying there is a moment where the article gets written and then it gets plucked out of Chorus and put somewhere else for final touches and stuff before publishing or no?

Kristin: Uh-uh. No.

Chris: It gets published right from Chorus, right?

Kristin: Yeah.

Chris: Yeah, okay. Yeah, fair enough. So, if Chorus can't do something, it's not going in the article.

Kristin: Yeah. We do have another tool called a custom story kit, so if they really want something extra super fancy that we just can't support, then they can basically almost make a little mini website and post it using the tooling.

Chris: Oh...

Kristin: Yeah, so it's basically a middleman site that pulls the data in from Chorus. Obviously, that's a much bigger lift. But if they want it, they can go whole-hog on a totally custom story. Often, it's a package of stories together.

Chris: Hmm... The old, like the Snowfall thing or whatever, right?

Kristin: Yeah. That's what I was going to say. It's very Snowfall. Yeah.

Chris: Right.

Dave: Everyone loves Snowfall.

Chris: Everybody. Everybody loves it. We tried to get the Snowfall people on.

Dave: Yeah.

Chris: Because there was an anniversary, but it didn't work out.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you by Frontend Masters. There are so many courses on here, the highest possible quality courses, almost focused on maybe you're already a front-end developer and you need to learn a new technology or really level up. You definitely can be a beginner, too. Think of that.

I think a lot of people that listen to this show are kind of in that intermediate zone. This is the place for leveling up and learning new technology.

We've got courses on here about Next.js with Scott Moss. We've got Ben Huong on here, Brian Hull, Kent C. Dodds. Sarah Drasner is on here. Nobody I'd trust more than Jen Kramer to teach intermediate HTML and CSS. Just amazing. The best of the best. And Dave! [Laughter]

Dave: Hey! I've got a Web components course up there. I don't know how I slipped in, but I did. Let me tell you; it's going to teach you Web components. Yeah, if you're interested in that. I feel like they're a hot topic this year, so people should go sign up and watch it.

Chris: Yeah. Dave, you're early to game, as usual. You know what's going to be big.

Dave: I used my code smeller, and I smelled out the next big one, baby.

Chris: Yeah, dude. Web components are not going anywhere, and you might as well learn them now. Check it out at

[Banjo music stops]


Dave: Occasionally, The Verge will do themes, right? I'm trying to think of the last one I really dove into. I feel like it's sort of end-of-year, just themes about different areas, sectors of technology and stuff like that. Am I describing that? Do you have a name for that? [Laughter]

Kristin: Not really.

Dave: They're kind of a little bit art directed. They're a little bit similar in vibe and tone. Is there anything special y'all do for that, like art directing posts on The Verge, or is that something you kind of had to move away from?

Kristin: We have quite a few options for them to change their headers and then, if there are a bunch of themed stories, they can create packages. There'll be kind of a homepage of the package with a big splashy header and then all the stories get sort of bundled together.

Dave: Mm-hmm. Okay.

Kristin: That might be what you're talking about.

Dave: I think that's exactly what I'm talking about. How do you build a package? What do you do there? Do you just make a custom code a homepage? They're all very different, I feel like.

Kristin: Yeah, there's a story type called a package that has totally different metadata fields on it, and then you attach the stories to it. Then they can go in and totally change the header of the story.

There is an ability to add custom Sass to any story. As much as you try to build a perfect design system, somebody always wants special CSS for everything, right?

Dave: Mm-hmm. Mm-hmm.

Kristin: That got a little bit trickier with using Next.js and the structure. The HTML structure totally changed. That was a little bit tricky, but they can go in and make little, special customizations to things if they want.

Dave: Yeah. I guess that CSS stuff works if you don't change the HTML.

Kristin: Yeah. Yeah.

Dave: When you do that, now it's pain town.

Kristin: Yeah. There's always the big warning: Things could change at any moment. [Laughter]

Dave: Yeah. It's funny. I don't change my code that often. But even old, art-directed posts are just crumbling. [Laughter]

Kristin: Yeah.

Dave: It's just like, how did I mess that up so bad?

Chris: Oh, dude.

Dave: Think about it, I think ahead. I architect and then, still, it's like, "Cool. No background colors." [Laughter] It's like, "How did I mess up background colors?" I don't know.

Chris: That's a tough one. The Verge is next, and you had it your way. It worked out well enough that you'd make all the sites use that same approach.

Kristin: Mm-hmm.

Chris: I think is what I heard. That's kind of cool. Does that mean that Chorus is kind of a headless CMS or supports that, too? Is the next site just hitting an API to get the stories that it needs to get internally?


Kristin: It is, yeah.

Chris: Yeah.

Kristin: When we were running the SaaS business, that is what it is, is a headless CMS. Not all of the sites, but that was the end goal was to be a headless CMS. Anything that's still... and most of the sites are still on the Rails app, so that isn't headless. But the Next.js app is, and any future sites, as we move forward, will be.

The Chorus API essentially came out of that whole process of the SaaS business. Similarly, the actual story editor is its own app that is almost like a headless editor in a way that we also interact with a CMS with the API. We also directly make Rest requests as well. But yeah, it's all... The end goal is to be all APIs.

Chris: Then you mentioned (just because it stuck out to me) that Chorus, I guess, as you continue to work on it, has that weird, old JavaScript framework that I hadn't heard of.

Kristin: Yeah.

Chris: But now is going to be Vue.

Kristin: Mm-hmm.

Chris: Whereas these front-ends are going to be React. That just seems interesting. They're just enough different teams with enough different leadership and stuff, or is there something about the technologies that makes them a better fit? Is it just like these teams like them better?

Kristin: Yeah. I don't know the answer to that question.

Chris: Yeah. That's all right.

Kristin: There's some history there. There's some back and forth. I think, at this moment, there are only a couple of Vue apps. I think our revenue teams all ended up moving to React as well since we have some revenue products like Concert, like ad products as well, and those all use React now.

I think there was some discussion years ago. There was some concern because they were originally on Vue that, like, "Are we going to be able to hire Vue developers for these? Do we need to go to React because there are just more people using React?" So, they went that direction.

We stayed on Vue. There are enough teams to handle it, though. Not so much on Ractive. [Laughter]

Chris: Oh, yeah. Right. Right. You should watch the React documentary because they weren't using Ractive, but it goes all into the Facebook having some weird internal JavaScript framework that they were already kind of using in production. Then having React threaten it, essentially, even though that was an internal project, too. So, it's kind of a different conversation than y'all had, but they had to choose to sunset their weird language, which is probably the right choice.

Kristin: Yeah.


Dave: The move to Next, you said it kind of had... You had to change some stuff. But that headless API basically was making that work. Are all these pages--? Like there are 15 billion Verge articles. Are they all statically generated, or are they on-demand kind of sort of situation?

Kristin: Yeah. Yeah, everything is very heavily cached. It's kind of that, like, if no one has hit it, then it has to be generated, and then it's generated. Then there are infinite levels of caching going on there.

Chris: Right.

Kristin: Yeah. I don't pretend to understand all of the caching layers involved in that but there are many. [Laughter]

Dave: Yeah.

Chris: I think it's fast.

Kristin: Yeah.

Dave: I'm clicking around. I just was like, "Oh, there it goes. There it goes." You know? There's no... It doesn't seem to be waiting on a response, so that's pretty impressive.

Chris: What's day-to-day like? If you're heavily involved in this Chorus team? Obviously, you are. Is it like, "We have a vision for Chorus 5," or whatever it's going to be "and we're just going to pluck away at it until it's ready"?

And now it's driven entirely by internal choices, right? There are no customers of Chorus left anymore to placate, right? If there's some need of Chorus, it's serving Vox specifically.


Kristin: Yeah, we do still have some SaaS customers on it. But yeah, at this point we're all in on serving our editorial internal users. I mean we're in kind of... It's kind of a long-haul rewrite of everything, so not only are we moving all the front-ends to Next. We're also, like I said, moving the Chorus to Vue. It's kind of like the eternal slow rewrite.

Chris: Hmm...

Dave: Hmm...

Kristin: Right?

Dave: Yeah.

Chris: Familiar.

Kristin: Yeah, I mean I mentioned Quill at the beginning because I'm kind of like arms deep in rewriting the core editor.

Chris: Whoa!

Kristin: Which is a challenge. Yeah.

Chris: The core editor. But going from Quill to Quill?

Kristin: Yes. It's changing, so I don't want to get too deep into this because I'll start ranting. [Laughter]

Chris: [Laughter]

Dave: Yes.

Kristin: It's weird.

Dave: Yes. Let's go. Esoteric.

Kristin: Esoteric, weird content, editable problems. Yeah. We originally, when we implemented this... because we have, like I said, you can insert blocks and stuff, like tables and sidebars and whatever. The HTML that Quill has in it to show these or what they're typing is very specific. Essentially, we're just passing all that stuff that they see, the little square with the, like, "This is your table data," that's actually an iframe because we need to sort of have a block, a chunk of HTML in Quill that we tell Quill we don't actually want. We don't actually want to save that HTML. That's just for showing the user where the table is in the actual editor.

This is why I don't want to go too deep into it. [Laughter] It's very hard to explain.

You have the document itself, right? Which is essentially a bunch of operational transforms. It's JSON. It's just like structured data. That gets transformed into the HTML that the user sees in the actual editor, right?

Dave: Okay.

Kristin: Anything that's not text, we sort of used iframes to show it because it's like a little context the content editable div doesn't have to care about.

Chris: Hmm...

Kristin: The problem with that is sometimes we'll have articles that'll be like "100 Christmas gifts," you know, like yearend gift guides that are hundreds. There ends up being hundreds of iframes on this page.

Chris: Okay. I could see how that is problematic, a little bit, yeah.

Kristin: It is. Yeah. It starts to slow down rendering quite a bit.

Chris: Mm-hmm.


Kristin: I'm trying to figure out how to... Quill has this idea of embeds.

Dave: mm-hmm.

Kristin: Which is sort of similar. It's like, "We're going to insert a bunch of HTML and don't put this in the document. It's just for the person to see when they're looking at the editor." But putting a bunch of HTML into a content-editable div that is not content-editable is nightmare town. [Laughter]

Dave: Oh... Yeah. Okay. Yeah.

Chris: Whoa.

Dave: That is a div you're putting in the big content editable div.

Kristin: Yeah.

Dave: But you do not want people to edit that div.

Kristin: Yes.

Dave: So, now it's a problem. Yeah.

Chris: Hmm...

Kristin: Yeah. They edit. They actually edit the actual in like a sidebar outside of Quill, and it all gets inserted just for visual purposes. I'm trying to deal with the browsers all like to put cursors in different places when you do this.

Dave: Mm-hmm.

Kristin: And you can't just hack some white space because Quill doesn't like random HTML being put into it. So, it has been absolute nightmare town trying to figure out how to do this in... make this work consistently across all browsers because content editable is a challenge.

Chris: Hmm...

Dave: Yeah.

Chris: I've never even thought about content editable, the nestability of it. Can you make a sub-element not content editable?

Kristin: Yeah.

Chris: That's an acceptable scenario, and the browser respects it?

Kristin: It does. Yeah. Yeah.

Chris: Oh, gosh. Interesting.

Kristin: But it seems like it treats it slightly differently. You can sort of control where a user's cursor goes. If you click on something, you can make the text expand, like the selection expand, let's say.

Dave: Mm-hmm.

Kristin: For instance, when you have a copy/paste field, you can have them select all that text. The selection API is challenging. Let's just say that.

Chris: Yeah.

Dave: Yeah.

Chris: I know that it exists, but I've never had to really wrestle with it for something.

Kristin: Yeah.

Chris: It does seem a little scary.

Dave: I was trying to use it for something, like highlighting, I guess. I just wanted to make a highlighter or something like that. Man, it's so weird because it's just like, "Cool. Range." You get into this whole range object in JavaScript. And it's just like, "I don't know what this is." [Laughter]

Then it's like, "Just put a number in here. That's the start number and that's the end number." But you're like... But there's HTML in there. What is the range if there's an anchor link selected?

It's hard is what I want to say. It's not as simple.

Chris: Yeah. I imagine there's a little console.logging involved there.

Kristin: Oh, yeah.

Chris: Seeing what you get.


Kristin: Oh, yeah. I've gone down absolutely wild routes like making them all Web components.

Dave: Yeah.

Kristin: Apparently if you make the slot and a Web component isn't supposed to maybe be a content editable and then Firefox, it isn't, but in Chrome it is, but only sort of. You can... [Laughter]

Dave: Wow.

Chris: Hmm...

Kristin: Yeah. Yeah.

Chris: Not that I'm advocating for this, necessarily. But this is a tool for internal usage of your team.

Kristin: Yeah.

Chris: Is there a theoretical world in which you tell the people who write for your company, "Can you please use," whatever browser turns out to be the best one?

Dave: Shortcodes or something. Shortcodes.

Chris: No. All ya'll are using Chrome. Sorry. You know?

Dave: Yeah. Is that--?

Chris: No. Probably not.

Kristin: No. No.


Kristin: They mostly use Chrome, so I guess there's that. But yeah, I don't know. I don't know what the end solution is. I'm still working through this thing.

Chris: Yeah. Or like you wrap it up in--

Dave: Electron?

Chris: Yeah, an electron and be like, "Double-click this app. This is how you write for us."

Dave: Now you're using Chrome. Yeah.

Kristin: There we go.

Chris: Yeah.


Chris: No, that's not a good path forward for Web stuff, generally, but it does seem like you can only bang your head so long. And you're in this unique position where the rest of your websites, the whole world reads them. That's journalism and stuff. Of course, you have to support all browsers.

Kristin: Yeah.

Chris: But internal tools, sometimes you get some leeway.

Kristin: Yeah. Yeah.

Chris: Okay. Then you fight with Quill in Quill. It reminds me of every time I ever was like, "Oh, why is WordPress doing this one weird thing?" The reply guy would be like, "Have you looked at Ghost?" or something.


Chris: You'd be like, "Yeah, I'm going to switch my whole CMS because I had one little problem." But how many problems until you do start thinking about, like, "Oh, maybe Tiptap does look kind of good"? You know? I don't know.


Kristin: Yeah. I'm not going to say I haven't thought about changing Quill to something else. I think one thing that's tricky is all of our millions of records are using this structure that Quill uses.

Chris: Yeah, right.

Kristin: Do we have to change the version history of every story ever? Once we start getting to the scale, it's really a big challenge to change the data structure. Our versions, just the versions alone is millions of records.

Chris: I can't imagine. Yeah.

Kristin: [Laughter] Yeah.

Dave: Yeah. Yeah. Yeah. Oh, man.

Chris: You'd have to find one that is also real-time whatever. I think of Pros Mirror because we use Code Mirror at CodePen. The new Code Mirror is very... it's theoretically collaboration-friendly, and it's kind of BYO your own real-time technology but I think does kind of have opinions. I think OT's what it wants you to use or that's what the examples are built in. Then this Pros Mirror product is built with the same type of spirit.

But, yeah, switching is not. That would be - I don't know. It'd be a job you'd be like, "You know what? I think somebody else can worry about that."

Dave: Yeah. [Laughter]

Kristin: Iframes are great. We love iframes.

Chris: Yeah. [Laughter]

Kristin: Let's go back to that. [Laughter]

Dave: I was thinking, too, then you have a conditional renderer in your template, right? You have oldpost.whatever ERP or whatever. Then you have, like, newpost.erb. Now you're just in pain town because people won't understand why something doesn't work. Gah! Yeah.

We chose Tiptap, and it's... Sorry. It is Pros Mirror-based, but they give you a little... They give you a choice.

Chris: Oh, it is Pros Mirror.

Dave: Do you just want the HTML dump or do you want the block editor style where every field is this little JSON tree? It's like element P content text lorem ipsum. It's tough to be like, "Do I want just a chunk of HTML that people can edit or do I want this JSON document that I have to now write all this logic to render that?"

You have to kind of pick your poison early in the product. You can't really just be like, "I'm going to do whatever." [Laughter] I don't know.

Kristin: Yeah.

Dave: I guess you can do, like, description_html, description_json in the database. You could maybe say both, I guess, for a while, and then transfer. But yeah, not fun.

Kristin: Yeah, this is by far the largest company I've ever worked for with the most visibility, so it's been quite interesting for me to experience some of these giant-scale problems.

Dave: Yeah.


Kristin: Yeah, like watching... I think the first time I opened our deploy dashboard to deploy something and to be like, "There are 90,000 active users." I'd be like, "Ah... okay."


Kristin: Please don't crash. [Laughter]

Chris: Yeah.

Dave: Do you ever become desensitized to it where you're just like, "Who cares. They're just getting it"?

Kristin: Uh... I think other people do. I don't. I sweat every time I deploy anything. [Laughter]

Dave: Yeah. Palms sweaty ... spaghetti.

Kristin: Yeah.

Dave: Yeah.

Kristin: Oh, yeah. Now that I'm in the CMS, it's a little bit less concerning. But when I was deploying to the audience experience, that was... yeah.

One time, I deployed something--I don't exactly remember the details, but--it took everything down, but not immediately. There was an hour of caching for most things for most people. So, I had an hour to fix it.

Dave: You go to lunch and then... yeah. Yeah.

Kristin: [Laughter] Like, okay. At the end of this hour, all of the sites will go down, so you better fix it real fast. [Laughter]

Dave: Oh, my gosh.

Chris: Oh, no.

Kristin: Yeah.

Dave: Challenge.

Kristin: It did get fixed. Yeah.

Dave: Good.

Kristin: [Laughter] I think that I've never been so sweaty in my life. [Laughter]

Dave: Yeah. I have a question. You work on the WYSIWYG editor for the Vue app on the admin tooling of a large content site. Do you consider yourself front of the front or back of the front?

Kristin: I would say I am solidly middle front. [Laughter]

Dave: All right.

Chris: Middle of the front.

Kristin: Average front.

Dave: Middle front.

Kristin: [Laughter] Yeah. Yeah. That's a great question because I think, when I joined, I was very front of the front. Not that I didn't have experience in the back of the front. But yeah, these days I'm mostly in solid component land, not so much dealing with CSS architecture, not so much dealing with a lot of those things. I mean I still do some of it, but I spent so many years in the front of the front. I've been sort of more interested in the back of the front. Even the back part a bit.

Chris: Mm-hmm.

Dave: The full... yeah.

Kristin: Yeah.

Dave: Back of the back.

Chris: I think if you're concerning yourself with operational transforms, I guess that's by definition the middle.

Kristin: Yeah, right? [Laughter]

Chris: Yeah.

Kristin: I mean, in a way, our app is also kind of in the middle.

Chris: Yeah.

Kristin: Yeah. Where does the back start anymore? I don't know. I don't even know anymore. [Laughter]

Dave: Yeah. Well, yeah. The middle is probably the perfect description just because you're very - I don't know. Yeah, you're working very JavaScript app to make a very specific tool, but that tool's job is to spit out the front, right? You can't just be normal JavaScript bro and just wash your hands of it and say, "Yeah. No big deal. Whatever. It works." You have to care, right? It has to work.

Kristin: We also have our own, like the front-end is all built using a shared Web component library that we have. Most of our UI like dropdowns and input fields are all custom Web components that we built.

Dave: Ooh...

Kristin: Yeah, so that's an added... So, a lot of stuff is ready to go, and I can just use our Web components for that stuff.

Dave: Kind of build out what you need.

Kristin: Yeah. Yeah.

Dave: Hmm... Hmm... Now I have Web component questions but go ahead.

Kristin: [Laughter]


Chris: All right. Let's do a little Roulette thing of, like, can Quill do it.

Kristin: Oh, boy.

Chris: Can your usage of Quill do it, right? Okay. H1 all the way to H6.

Kristin: I think we do H1 to H4.

Chris: Yeah.

Kristin: I mean it could.

Chris: As an aspect of control, like, don't use H5. It's too far.

Kristin: Yeah. Yeah. Basically.

Chris: Okay. Okay. A block of syntax highlighted code.

Kristin: We have... There isn't a code block but there is an HTML block.

Dave: Hmm....

Chris: Oh... Okay.

Kristin: Perhaps you could.

Chris: You can't put custom HTML in Quill, but you can put HTML in Quill. [Laughter]

Dave: I could put a pre-tag in. I feel like that counts.


Dave: I feel like that counts.

Chris: Yeah.

Kristin: We have... So, you can't put random HTML into Quill itself, but we have our own custom block that you can put HTML into.

Chris: Oh... Okay. Okay.

Kristin: Yeah. So, we save it. But what we render is that weird little iframe into Quill itself.

Chris: Okay.

Dave: Does Nilay Patel write his own custom HTML? Please say yes. He's my hero.

Kristin: [Laughter]

Dave: No?

Kristin: That's a great question. I don't know. I don't know the answer to that.

Dave: He's just like riffin'. Love it.

Kristin: Yeah.

Dave: That's what I imagine. Anyway--

Chris: Can you put an HR?

Kristin: Yes.

Chris: Yeah. Yeah. Okay. What about a swipeable image gallery? Is that just like a standard feature?

Kristin: It is. We have an image gallery. We also have one of those image tools where you put two images and you can slide the slider back and forth to compare the two images.

Chris: Oh, right because you might be reviewing a camera or whatever. Yeah. You've got an image swiper, too. Okay. Cool.

Let's say you wanted to just have two columns, just a paragraph on the left and a paragraph on the right.

Kristin: Let's see. We have... You can put... It's funny how this is a hard question to answer. I don't think so. We can put images like that, images next to each other. We can align sidebars left and right. Maybe you could hack it to do it, but we don't really have a columns.

Chris: A columns.

Kristin: Yeah.

Chris: No columns?

Kristin: No.

Chris: Not native?

Kristin: No.

Chris: Okay. What about a button, just like a link that's going to look like a button?

Kristin: No. [Laughter]

Chris: No. No buttons.

Dave: What about a bulleted list, because I've never seen any big news publication use a fricken' bulleted list?

Kristin: What?! Yes. Yes, you can have a bulleted list.


Dave: I've literally never seen one.

Kristin: What?!

Chris: Oh, come on.

Dave: I feel like, find one. Prove me wrong.

Chris: [Laughter]

Dave: But I've never seen a fricken' bullet.

Kristin: Someone was just complaining that they couldn't put an end mark at the end of a bulleted list, so I know they use them. [Laughter]

Dave: Whoa! Okay. All right.

Chris: Wow. You know what I feel like more falls down is when you go one level deep with the bullets, that the second level bullet is usually maybe a little forgotten about. It ends up being the open circle, which I think is the default user style sheet.

Dave: Nesting bullet. Yeah. Yeah.

Chris: Yeah, the nested bullet gets a little funky and it never has enough space between the list item above it and the new list below it. It's just easy to forget about. I'm sure Vox is all over it, though.

What if you needed to embed a Google Map? What would you have to do there?


Kristin: Oh, boy. Maps is probably a whole other hours.


Chris: Oh, no.

Dave: Part two: maps.

Kristin: Yeah. I mean we have... Like I said, we have Eater Maps.

Dave: Yeah.

Kristin: So, maps are definitely part of the product, but you can't just put a random map in the middle or a regular story.

Chris: Oh, okay.

Kristin: Yeah.

Chris: What if you wanted to embed a TikTok?

Kristin: We have embeds. Yeah. Yeah.

Chris: It would just take... Is it like O-embed?

Kristin: Yeah, so we use iframely, so you could just put in whatever embed.

Dave: Mm-hmm.

Chris: I see. You just leave the URL right there and it'll do its thing?

Kristin: Yeah.

Chris: Oh, that's nice.

Dave: I see. I'm looking at an article for an e-bike, and it looks like you do asides, like little--

Chris: Oh!

Dave: --baby articles inside the article.

Kristin: Yeah. Mm-hmm.

Dave: Hmm...

Kristin: Mm-hmm.

Chris: That's nice.

Kristin: Yeah, those are sidebars. They can insert sidebars.

Chris: Sidebars.

Kristin: Yeah.

Chris: Do they look like that in Chorus, though, or do they just look like a block? What's the WYSIWYG seen?

Kristin: It's not really a WYSIWYG in the sense that it does not really look like what it's going to look like in the audience experience. They're all just kind of gray blocks.

Dave: Hmm...

Kristin: You can see what you wrote but it doesn't look like that exactly.


Dave: That's kind of like a contention point, right? We worked with some content folks for a big software company in Redman, Washington. It was a point of contention that they could not see the preview or the final product until it was done building. I think, though, over time, their imagination could start to do it, but they weren't willing to take that time. [Laughter]

But it's interesting, right? People want it to look good or they have control in their Microsoft Word or their Notion or whatever (where they wrote it). But the final product maybe looks different, right?

Kristin: Yeah. We have a preview screen they can go to, so they can definitely see what it looks like before they publish. But that's not in the editor itself.

Dave: Okay. It's like click to view.

Kristin: We've actually... Yeah. We actually have a layout screen as well, so the sort of Quill editor that you type in doesn't do any layout anything except maybe right and left text.

Dave: Mm-hmm.

Kristin: You go to a totally separate screen that looks like a full, real preview of the story where you can actually right and left-align images and group things together, so that's a whole entirely different editing experience for them.

Chris: Wow!

Kristin: That gives them a much better sense of what it's actually going to look like when published, and it has mobile preview as well, and Amp preview as well.

Dave: Still doing Amp, huh? Still keeping the dream alive. [Laughter]

Kristin: Well, hopefully not for much longer. [Laughter]

Dave: Yeah.

Chris: Yeah. You got strong-armed into it. You know? You can't blame anybody. Fascinating because that is kind of a potential struggle of essentially static site generate type of tools plus headless CMS is how do you do previews without maybe having to do a whole site build or whatever. It looks like you've cracked it, at least for y'all. That's awesome.

Kristin: Yeah. Yeah.

Chris: Yeah. You definitely need to look at what a post looks like before you hit the button. You know?

Kristin: Oh, yeah, especially if there's customer Sass in there. [Laughter]

Chris: Yeah. There you go.

Dave: Yeah.

Chris: Sass, you said, too. When you add special styles to it, it's in Sass?

Kristin: Yeah. I think that might have changed when we moved to Next. The Verge right now has some of their own special preview stuff because they're different than everybody else.

Chris: Yeah.

Kristin: On the Rails app at least, yeah, we were compiling all of that into CSS so they could use variables and stuff if they wanted.

Chris: Oh, right. Oh, fascinating. Oh, gosh.

Dave: Oh, yeah. I guess people can choose the template they want to show. You probably have more than one article template. Wow.

Chris: Oh, I didn't even think about that. Yeah.

Dave: So sophisticated.

Kristin: It's an onion. The layers just keep going... forever.


Dave: That's great. That's very cool. Well, hey, I do think we are at time but this has been very educational for me. I don't know. Working on a big CMS like this is something I've never done, and so it's very cool--

Chris: Yeah.

Dave: --to hear how it works and what goes into it. Appreciate you coming on the show and talking about it. For those who aren't following you and giving you money, how can they do that?

Kristin: They can't, really. [Laughter]

Dave: Okay. Perfect.


Kristin: Go read The Verge.

Dave: Go read The Verge.

Chris: There you go.

Dave: That's great. Easy. They have an RSS feed.

Kristin: Yep.

Dave: It's about 40 articles a day.

Kristin: Yep.


Dave: Get ready.


Dave: Plug in. Get ready. All right, well, thank you so much for coming on.

Chris: Yeah. Thank you.

Dave: We really appreciate it. Yeah.

Kristin: Thank you.

Dave: Thanks, dear listener, for downloading this in the podcatcher of your choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Follow us on Twitter or Mastodon, @ShopTalkShow. Then if you're on Mastodon, Gosh. [Laughter] My brain stops when I start saying that. Anyway--

Then join us over in the D-d-d-d-discord,

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

Chris: Oh... Publish.