Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: [Vampire voice] Hello, Shop-o-maniacs. Welcome to a spooky October version of the ShopTalk Show. I am Dave--blood--Rupert and with me is Chris--gravestone--Coyier.

Chris Coyier: [Laughter] Are you planning to do this the whole month?

Dave: [Vampire voice] Ooh, you betcha.

Chris: You're 30 days early, buddy. [Laughter]

Dave: [Vampire voice] Yes.

Chris: Yeah.

Dave: [Vampire voice] The whole month is spooky now.

Chris: I was thinking it would be baller just to throw up New Year's decorations at the house. Be like, "Happy New Year!" [Laughter] Just punt on the rest of the year. Just pretend like we've already made it.

Dave: Yeah…. Well, and so much of it too, right? [Laughter] What is Halloween this year? It's the holiday where kids go put their dirty hands into a bucket of candy where other kids put their dirty hands. That's not happening this year in 2020. I don't care.

Chris: No.

Dave: Maybe in your neighborhood, but I'm not abiding in that, so how -- how does life--? I don't know. Halloween is different this year.

Chris: Well, you've got to read the right blogs, man.

Dave: Yeah.

Chris: People got ideas for this thing.

Dave: Oh, really?

Chris: I mean the trunk thing was already big.

Dave: Trunk-r-treat. Yeah. Yeah.

Chris: Yeah, I suppose. Even that, though, it doesn't necessarily solve the dirty candy problem, necessarily. But I think people are already kind of self-segmenting unto close friend groups and you probably rock that to some degree.

Dave: Just a little -- little party, little hangout with the friends. I was thinking. I don't know if we could coordinate it but maybe a costume parade for the kids in the middle of the day or something.

Chris: Yeah, you've got to do the costumes. Come on.

Dave: Then it's like -- but then it's like we did a Halloween. We just did it in the middle of the day so that no one is tempted to go knock on doors and dig in candy bowls. [Laughter] We did it very distant. We did it very safe. But anyway, we'll see.

Chris: Yeah.

Dave: Hey!

Chris: Ruby's birthday is November 1st, you know.

Dave: Yeah.

Chris: Literally, on the day she was born, I'm like, oh, man, she's going to party so hard in college. Then at midnight when she's out at the bars she's going to be like, "It's my birthday!"

Dave: [Laughter]

Chris: You know what I mean?

Dave: [Laughter] Yeah, just like a double rager energy.

Chris: Yeah, double rager. [Laughter]

Dave: [Laughter] Oh, poor girl. She's going to -- she's got a future.

00:02:47

Chris: Well, today, we work up; it was October 1st. Hence, Dave's spooky intro, which also meant it's official garbage PR day because this is Hacktober now, so welcome to getting weird PRs on all your repos where people change one word so it looks like they're contributing to open-source so that they fuckin' get a T-shirt or whatever. I don't know.

Dave: Yeah. It's kind of like gamification of some cool thing happened, you know, and so now it's a less fun thing, you know. It's not -- I don't know. I'm dealing with an issue right this minute, but just trying to figure it out. But it's just kind of like, how do we--? I don't know. It's cool but, like, it's actually kind of a burden to open-source maintainers to have a sudden influx of interested parties. You know?

It's like, "Oh, okay. Cool. Well, I'm busy this October." Not me specifically, but you know. It's like, "I was actually busy and so this increase in volume does not help me manage an open-source repo," especially if it's just -- I mean maybe typos is like, okay, cool, a typo. But I've seen some and it's just like weird content edits and stuff like that, so I don't know.

Chris: The content, that's all I've been seeing is the, like--

Dave: Yeah.

Chris: "I put some headers in your read me," but it looks like I just guessed at some. I got one that was like, "This one is missing a read me, so the read me is going to contain the languages that GitHub suggests are in this repo, which I'm like, okay, that was automated. Good job. Not useful.

Dave: Yeah.

Chris: Yeah, it's pretty funny. I have kind of two minds of this. You hear a lot of, like, over years and years, there are always big maintainers of big projects have a different particular level of stress that befalls them. You know them much better than I do because you're a little better at maintaining open-source things that people are actually interested in.

Dave: I'm good at spinning up things. Less good at the maintaining.

Chris: But, you know, imagine you're Henry Zou, or whatever, that we've had on the show.

Dave: Yeah.

Chris: That's a big deal, right? They talk about the stresses that befall them and I've always listened with some interest, you know, but the fact is they represent much less of the developer community than most of us, so you can't build -- you can't make every decision at GitHub based on that, although you should help them.

I read one recently about vacation mode or something, like some open-source maintainer was like, "If I go on vacation and ignore this, I'm signing myself up for pain. Not only will it be hard to vacation, but it will be hard to come back. If I choose to ignore all of them, then what do I do when I come back?"

Should GitHub build vacation mode? That's where I'm like, there's nuance to this. You know? If I'm a product owner, we have enough technical debt over here. To build this whole feature out for this one thing, I could see how that would be a no even though it would clearly help this one person's life. You know?

Dave: Yeah. Yeah, no, I mean just on open-source, I have a commit, really helpful. Somebody was like, oh, lettering JS doesn't work with -- there are other problems with lettering JS. [Laughter] But letting JS doesn't work with whatchamacallit. Oh, I'm blanking. Emoji. Emoji because you know how some emoji are combination emoji, like girl plus astronaut if a female astronaut, or whatever. Are you familiar with how the Unicode staples them together with a non-breaking space?

Chris: I am. Yes.

Dave: It's kind of -- so if you do, like, whatever, female astronaut--

Chris: And zero-width space or something.

Dave: Yeah, zero-width space joiner or something. If you do whatever, femaleastronaut.split, it'll actually split it into three different things. When lettering JS does splits, it actually splits every character.

Chris: Oh…

Dave: It was just eating emoji. It's a problem. Then somebody came in and asked a question and fixed it. But I haven't merged the PR. It's somewhat of a dead project, but I haven't merged the PR just because, in my brain, I'm like, "You know, I should write tests to make sure that this doesn't break something."

Then somebody made a security patch, which again, like I should definitely care about but I'm also like, I should have tests so that I'm not just--whatever--approving PRs because somebody is like, "Hey, I want an emoji," or whatever. I want to make sure I don't break something.

Chris: Oh, I get it because you want to press that button. There's a button that just says, "Merge and approve," or whatever. it's tempting to just press it but this is actually changing code. That button wouldn't be there if there wasn't actual change, actual code actual changing, so how do you absolutely know that it's not going to break something? Well, you don't. You'll never know entirely, but at least you can write tests for the very most important functionality and make that that that stuff doesn't break.

You're probably right to do that but is tricky because sometimes, oftentimes, it's just some bump to low dash or something and you're like, "I don't know." [Groans] Sometimes it comes from GitHub itself. They have this little bot that suggests it.

Dave: Right. Right. Well, and the security one, it's actually like, I understand the fix but I'm also like, "Did I intentionally make it insecure?" I know that sounds stupid, but it was like, was there another request that wanted it insecure, so I had to work around something? Not that I am like pro insecurity, but I'm just like, "I don't even remember what had happened or why."

It's like only if you're running lettering on content injection, like injected content, okay? Very kind of, again, limited use case, hopefully. But hopefully, you're just not allowing script tags in your input fields anyway. But they should also not process script tags or whatever.

The fix was, it actually converted a whole bunch of jQuery stuff to vanilla JavaScript, and that's fine. That's fine. But I was just like, "Oh, can you just do this with JavaScript or jQuery?" Do the EQ to zero instead of getting the raw JavaScript object. Ah! Anyway, I just was like, I think I can do this without -- in an easier impact. But again, it's like I have to have time. I have to have patience. I have to write tests. There is kind of a lot more to it in my brain than just hitting a green button - approve. That's where, again, being an open-source maintainer is hard.

I almost wish there aren't more people who are like, "Hey, can I help you maintain a project better?" Wouldn't that be a cool PR thing, like, "Hey, I'm going to get you set up on some basic tests. That's the first thing I want to do. Hey, I want to figure out your deployment, your versioning. I'm going to help you get a little thing going here"? That's helpful. That's helpful. You know. Anyway.

Chris: That is helpful. I think that's fair to answer that. Just be like, "Listen. I have no mental space for this. The reason that I'm not merging this is because I have concerns that I can't just be hitting this green button on PRs without tests, so I'm just going to leave this open for, say, six months. If the tests arrive in that time, whether I write them or somebody else does, cool. If they don't arrive, I'm going to close the PR. You know? But even that--

Dave: Yeah.

Chris: Even typing those words requires some bandwidth and time and patience and mental space that you might just not have because it's very legit to just be like, you know what? I literally just don't care. I care so little that I'm just going to hit archive on this email and just not even think about it because that's amount of mental space I have for this right now. [Laughter]

Dave: Yeah.

Chris: Yeah.

Dave: Yeah. No, no, I mean it's tough stuff, so.

Chris: Yeah.

Dave: Yeah.

Chris: Or I might log in and delete the damn repo because I'm sick of these emails. [Laughter]

Dave: That's extreme but yeah.

Chris: Yeah.

Dave: But that's even, too, like how do you -- I know you can transfer ownership and I'm actually very comfortable with the, like, you don't like how I'm managing it. Fork it and use your thing.

Chris: Yeah.

Dave: You know? Just fork it, please. Leave me out of this.

Chris: I think, in big business, that's pretty common. I've done that at least half a dozen time at CodePen where we didn't even consider doing it any other way.

Dave: Yeah.

Chris: It was like, this is obviously a change that's just for us. We'll just have the fork. Especially because it's not particularly difficult then to occasionally pull master into your fork.

Dave: Yeah.

Chris: Not master, but you know what I mean. Whatever their canonical thing is.

Dave: Yeah, the main upstream branch, yeah.

Chris: Upstream. There you go. Okay, well, that's cool.

Hey, I got an interesting email that I almost felt like wasn't really worth a blog post but it was interesting, like, quick mouth blog kind of thing. Somebody showed me the screenshot of some copy on the Web. Right? It was like in a contact page or something that said, "Blah-blah-blah, contact us. Please fill out the form at the right, and blah-blah-blah." In the screenshot, they triple circled the word "On the right" because on the right, as we know in the world of responsive design, is often wrong, you know?

Dave: Mm-hmm. Okay.

Chris: Like when is it on the right? it's on the right sometimes. It's not on the right on mobile. You know?

Dave: Yeah. Right.

Chris: They were just curious. What do you do in situations like that? Do you have a span that you swap out that says "below" then? They called it way finding, which I think is an appropriate term, you know, helping people know what you're talking about. What do you do? Do you just very carefully avoid language like that?

Dave: Yeah. No, I mean, sometimes, yeah, it's like fill out the form above or below and it's suddenly not below. You know? Yeah, if you can figure out verbiage that isn't so directional, I think that's smart, because LTR would also be a problem there, too. Stacking would be a problem there, too, or RTL.

Chris: Yeah.

Dave: Like Hebrew or something where it wouldn't make sense.

Chris: Do you think you would catch yourself or have you ever made a mistake like that? I'm just curious what your brain does when you're about to write a sentence like that, like you, Dave Rupert. Do you think you would catch yourself or do you think you would screw it up?

Dave: I think I would catch myself and I think I catch myself even when it's like "click here" because, guess what, we don't always click. You know? You tap. That's probably the most normal. You could probably say click and tap are sort of the same thing, but whenever I write, "Okay, click this button," or "Click the button in the forum," or whatever, I'm immediately like, ooh, that's probably not -- or it's just kind of like dated content, if that makes sense. I'm old. I say click. You know?

Chris: Hmm.

Dave: Like that's old.

Chris: Yeah. Yeah, kind of.

Dave: That's what old people say is click. I think we've tried to update it. Hip it up to, like, "Tap the icon," or whatever.

Chris: Even that is, really, you know? I don't know.

Dave: Right.

Chris: Doesn't feel right to me either.

Dave: Well, but you know. Hopefully, it just makes sense. [Laughter] Yeah. You know. Hopefully, it's obvious.

Chris: I think click makes sense, but you're right that it doesn't come off real good. Maybe "hit," although hit is kind of a little loaded too.

Dave: Yeah. No, I think there's some sort of -- I think, too. Have you ever been to one of those websites with coach marks or whatever? You know, overlays things. Then you go to the responsive view and all of a sudden those little arrows for the coach marks aren't pointing in the right direction anymore?

Chris: Sure. Yeah. Yeah.

Dave: That's something you've got to think about.

Chris: Yeah. We use Appcues now at CodePen and I'm impressed by the product. I think they do a good job. Theirs is very fancy. You know?

Dave: Mm-hmm.

Chris: You give it anchor elements and it does what it needs to do to position them based on the ID of the thing that it's looking for, so it hardly ever screws that up, but it is an easy thing to screw up if you're not invested in that. But we go so far as we don't even load that script on mobile because mobile is just going to be a totally different ballgame. The tool really isn't built to work like that. That's one of the reasons we chose it is because it's kind of desktop first, like CodePen is. Now, feel free to slap our wrist for that, but I happen to have an inside look at our analytics and even after all these years, it's 99% desktop, so sorry.

Dave: Right. It's not exactly a mobile workspace. But yeah, occasionally, I'll challenge myself to write a CodePen on my phone.

Chris: Yeah, well.

Dave: That would be awesome, a CodePen phone challenge.

Chris: That's why it's not chicken or the egg because it's not 99% because we offer not mobile support at all. In fact, we've bent over backward to make that work over time. Still, the statistics are like that.

Dave: Yeah, but it is a nice to have, like when I'm visiting a CodePen, because I check my phone at night and I see cool CodePens or whatever. It's always nice to have access, I guess is what I'm saying. I'm not dumped into a giant website experience, so I can kind of poke around at the code. But even that, I think that's just the form-factor is hard. The keyboard, typing on the keyboard is hard. It's not necessary CodePen problems. It's more like visual real estate plus keyboard problems.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Framer. Literally, framer.com/shoptalk, go there to sign up for free or to get 20% off if you go for any of their paid plans, which is super cool. Thanks, Framer.

Good design work, it should clearly communicate a message. The same is true for you, a designer. You should be clearly communicating a message. To whom? To the people you need to sign off on your design: your manager, your client, your CEO. You know? Why are you still presenting flat, lifeless product ideas? Put an interactive prototype into the hands of those people and watch their eyes light up and they'll buy into your vision.

It's much more convincing to present an interactive prototype. Framer is your secret weapon. Start from scratch or import work from another design tool. Drag and drop. Build these powerful, interactive components. Set up transitions, animations, which is almost expected these days that your app has when it's moving from one page to the next or on state to another state that it has transitions to get you there. Create your own stunning animations, all visually. It's a Web app, you know. Beautiful for it.

Rich, realistic prototyping just became intuitive in Framer. Just take it from Bruno, a product designer at Shutterstock. "Framer is an extraordinary resource for rapid prototyping. It has improved our team collaboration by providing an easy way to share the designs between engineers and project managers. It's built-in tools have been essential for quick prototyping and user testing." Oh, how awesome is that?

Again, that's framer.com/shoptalk where you can sign up for free or get 20% off any of their paid plans.

[Banjo music stops]

Chris: Uh, let's do a few questions. People wrote in some interesting ones here. Here's a little quicky from Bill Loose. "Would our industry still be convinced that SPAs were the best thing to do if we had to pay for the frameworks that made them possible? I've been thinking about how different everything would be if we had to pay for our dependencies." But don't you pay, Bill? Don't you pay in technical debt and performance?

Dave: Blood, sweat, and tears.

Chris: [Laughter]

Dave: You know, I mean, so yeah. I think this would be different. I mean Microsoft, in the 2000s, had dotnet framework and you paid to get that, you know, like you pay enterprise licenses. Shoot. Netbeans, you pay for that.

Chris: Mm-hmm.

Dave: You know like these frameworks. You know like frameworks that you pay for totally exist and, like, it's a great business model but it's also very, like, you are locked in. Unity, there's a free edition but you actually pay if you get big enough. In other ecosystems, there are pay to play setups, right?

Chris: Mm-hmm.

Dave: It would look very different. What I like about the Vue community is they're very transparent about, hey, pay to support this. I've always said this, but their community support ethos or whatever is very contributor positive. [Laughter] Is that a way to put it? They're very, like, hey, this is how this lives. Support it.

Chris: Hmm.

Dave: I like that but, yeah, it would be different. Every time you install Lodash, you had to chuck a buck. That'd be different.

Chris: Yeah, that's -- yeah, yeah. There is just too much of it for that, right? Not that the world can't change, but there's just not -- you'd be moving mountains to have that kind of impact, especially now that NPM exists, for example, and there are millions of things on there to have a model that says, "Well, I have a thing, too. You have to install it in a different way and it costs a dollar." Yeah, good luck.

Dave: Yeah.

Chris: Then how do you prove the quality of that thing? Now, you see it in design a little bit because it's easy to prove the quality of it, so there is KendoReact or whatever and there's Tailwind UI and there are things that are like, hey, look. See how good this is? Give us $100. [Laughter]

Dave: Mm-hmm. Yeah.

Chris: Then you get it because you can see it is, but I don't know how good your Lodash alternative is. I can't see the code until I buy it? What?!

Dave: Yeah. Nah, it'd be different. It would have to be very convincing. In some ways, open-source has won out.

It's interesting, Bill ties like funding to single-page app frameworks and stuff like that. Yeah, I don't know. I think it could be any project, not just specifically React aps or whatever. You know. If you had to pay for a React router or something, it would probably be a different world.

Chris: Yeah, maybe. I'm not poo-pooing on it. I don't write code ever that doesn't have a clear way to monetize it. I'm not an altruistic coder. I don't ever do anything if I'm not--

[Laughter]

Chris: If I haven't entrepreneurialized it at least a little bit or at least I believe that it's in service to other things that I do that make money. I'm all about it. [Laughter]

Dave: Yeah. Yeah, well, I mean, like David DeSandro is a great example. He charges for Masonry. He charges for -- what's his new one? Fizzy? No, that's his company, Metafizzy. His new slider thing.

Chris: He must have a dozen of them.

Dave: Yeah.

Chris: Oh, the slider isn't particularly new, is it? What is that one?

Dave: Newish.

Chris: I love that.

Dave: In the last decade.

Chris: [Laughter] Sure.

Dave: I'll find it here. Anyway, here we go. Isotope is one. Flickity. That's it, Flickity.

Chris: Yeah.

Chris: Okay, Flickity. You know he charges for that and I think he has a, "Hey, you can use this on your personal site license, whatever. But if you're a company and you want to use it," and this is a perfect example where it, for me, it's worth it to pay for this because it's like I know he's put effort into it. I know a responsive care cell is kind of a hard thing to solve, like in a good way. I know he's chucked some attention at accessibility. Is it perfectly accessible? I don't know, but he's at least tried, I think, to some degree.

Is it worth money to me? It is. But does it have as many downloads as React slider?

Chris: No. Yeah.

Dave: Probably not, so you know. Yeah, I mean I think--

Chris: I love Dave. We should get him on the show to talk about this because I bet he's just steeped in thoughts on this kind of stuff. I know that he thinks about the economics of it heavily too because, as you might know about Dave, Dave has got another job. This isn't Dave's job. You'd think it would be because it's not just one of these things. He's been entrepreneurial doing all kinds of stuff. He sells logos. He sells--

Dave: That's the best thing he does. He'll make like 20 logos in a day or something. I don't know. It's….

Chris: Yeah, and then be like--

Dave: But then he will sell each one.

Chris: Yeah.

Dave: And it goes up in cost or something.

Chris: Yeah, it's great. Then he does free stuff, too. It's like impossible not to run across Dave's work. Yet, it's not enough. It's not enough to do the family thing. You're like, if Dave can't do it, who the hell can?

Dave: Yeah, well, and that's where, you know, big money like corporations doing open-source comes in, you know.

Chris: Yeah. I bet if he just made Flickity and he just put the word "React" at the top, he'd probably double his money.

Dave: [Laughter] Maybe. Well, and you think about 11ty. I know they have an open collective kind of thing going on. Maybe some corporate sponsors, you know.

Chris: Yeah. Zach Leatherman, employed. You know?

Dave: Yeah, employed. Yeah, so maybe one day he'd be able to 11ty full time, but that's a lot of ways off. There's probably even -- he probably likes his day job and maybe the first hire is actually somebody to do community or something or triage bugs for him or something.

Chris: Oh, I see. Stay employed and hire somebody anyway? Oh, clever.

Dave: You know. I mean--

Chris: I did that.

Dave: That's what I would consider. Yeah, right? Like, oh, shoot. I could pay somebody to merge down this emoji PR?

Chris: [Laughter]

Dave: I'll just do that because I don't have the brain space to switch over to that.

Chris: Yeah. Yeah, the cost of switching, too. Isn't that a classic? You always think of Sophie when you think of that.

Dave: Yeah, Sophie Shepherd, her contact switching because she was trying to do code and managing or even just going from meetings to one-on-ones. It just was burning her out. I felt that too. You go from project one to project two to project three, and you're just like, "Dude, I don't even know." [Laughter]

Chris: [Laughter]

Dave: I don't know where I'm at now.

Chris: Yeah. I think it gives you some strength to some degree, but at a really high cost. Tell me. If you can switch between a front-end and a back-end project in very different languages in a very different folder structure, yadda-yadda-yadda, and just instantly be able to work? I mean that's a serious -- you're good, you know.

Dave: Oh, yeah. Well, and I even had an experience. Recently, I was doing that. I was operating. I was like, I am operating, dude. I'm going.

Chris: [Laughter]

Dave: Then, like Tuesday or Wednesday afternoon hit and it was just like, "Ah, man. I don't got it. No gas in the tank. The brain is dead. I can't do it," so you can just suddenly run out of energy if there's one hiccup or one twist, you know. Oh, well.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Imgix. That's imgix.com. It's a powerful image and processing API. I'm going to get into it and explain it. I think it's a fantastic product.

I asked them once how you pronounce it and I have it right, so this is podcast friendly, Imgix. Imgix, imgix.com. Like I said, fantastic product.

Let me set the stage for you a little bit, though. You know we talk about build processes sometimes on this site. You could, for example, make sure that your build process optimizes all your images. By the time that they're up on your Web server and they're being served to people, they're optimized. That's one of the things you need to do.

I don't think it's optional either. You have to be serving your images in an optimized format. Sure, okay, you can do that yourself. But I always feel like if I do it myself, it's limited compared to what a company who's absolutely focused on this job can do. Then it's not just the optimizing it, but it's the serving it in the correct format and being able to manipulate it in different situations. Let me talk about that a little bit more.

For example, how you set up Imgix is like this. You have a master location of where your images are. Maybe it's your Web server and it doesn't matter that much. I don't think you need to pre-CDN your images because what Imgix does is it sits in front of your master images as the global CDN, which is fantastic anyway because you need a global CDN for your images if you want your site to be fast and responsible. In fact, Lighthouse will ding you for it if it's not. So, if you're going for those good scores, that's important.

Maybe it's an S3 bucket. That's a common way. That's the way I've worked with Imgix before. That's your master location and then you have these URLs that are like yourdomain.imgix.com. Then what you have then is the ability to add query parameters that's like, I want to it served in this size. I want it to be automatically compressed the best that you possibly can.

Let's say I change the aspect ratio. I want you to crop it. I want you to crop it towards this focal point. I want you to blur it. I want you to make it black and white. I want you to combine it with this other image. It has all these powerful possibilities while being served from a global CDN.

You wouldn't even need to put this stuff in your build process because you could just make the images that you upload in dev or while you blog or whatever be the master images that are just huge, unoptimized, just source images, which I think is kind of nice because then you're not ruining your source image. Then because you're serving them through Imgix, they're optimized in the best possible way. They're served in the best possible format.

We did challenges at CodePen where we did four weekly challenges that kind of dug into those things. For example, the picture element is one of them. You know how you want to serve responsive images and do fancy art direction kind of stuff, then you could use Imgix, and then all you have to do is change the query parameter of the master image to be like, well, I wanted it this size at this particular breakpoint and this size at this particular breakpoint. You can be fancy and just have one master image. You're not hand-making all these images. It's the way to go. Thanks so much for this sponsorship, Imgix.

Chris Enns: Make sure you visit imgix.com/shoptalk and sign up to receive a $300 account credit.

[Banjo music stops]

Chris: Here's Jesse Gundy, who is asking. He's like a decade-long front-end developer. Whatever. We have his little, short version of his life story here, but the important thing is, Jesse says, "I don't like social media." [Laughter] "I've gotten off it, personally. I'm wondering, what are the best ways to promote my projects without relying directly on Facebook, Twitter, Instagram, et cetera? I know there are aggregation sites out there always looking for fun things to share. Any suggestions on how to get your stuff out there without creating a bunch of accounts yourself?"

Dave: Man, this is tough. I saw this question come in one night and I thought about it for a good long while and I have nothing to say because social media is very much the broadcast channel. I can blog on my RSS and eight and a half people will see it. [Laughter] I could submit it to Product Hunt. Is that what it's called, Product Hunt?

Chris: Yeah. That's one day of glory. Yeah.

Dave: I'm going to get, yeah, eight thumbs up and one day of glory. I can--whatever--crash Hacker News and I'll get downvoted. I can post on Reddit or something. You know no one is going to -- it's tough without some kind of broadcast channel, and even now that all those channels are algorithmic too, you kind of have to be involved because you get rewarded for involvement, I think. I don't think you can just show up and be like, "I haven't tweeted in five years so here you go. Here's a new project." I don't think it always worked like that. Yeah, you can get lost in the stream of content, so I don't know. You can do a blog.

What are your thoughts? I have nothing.

Chris: Well, yeah. It's tricky. It's tricky but I would also -- to me, that paints the picture as, well, Jesse, you're going to have to get over yourself and get some social media accounts because it's the only way. But I'd like to tear that wall down. For example, on all the projects I work on, I mean here I have CSS-Tricks Google Analytics open right now. Combined for all social media, incoming, it's a little over one percent, but we're talking one percent.

Dave: Oh, wow.

Chris: I don't care about social media in CSS-Tricks. It doesn't work for us. It doesn't do anything for us. There is some immediate impact sometimes. For example, with something that's really like an instant slurpy, like we have a Flexbox poster for sale. You tweet it. You probably get a couple sales, right? That's good.

But it's not repeatable. I can't do it every hour. Otherwise, it doesn't work anymore. It's just this little hit to remind people. Maybe, if you're lucky.

The other day, somebody else tweeted about our Flexbox poster and I just inexplicably got 4,000 likes by people. It just kind of exploded. We made some sales from that, but not like -- we didn't make 1,000 sales. You always make some tiny percent of it. I don't even know if we made 100, but it may have been something like that. Probably less, though. But that's awesome! Wow! A little social media snowball moment. Cool.

That's not going to happen again. It's not something you can rely on. That was nice, but that didn't require us doing anything. That was other people's social media, so you don't necessarily need your own for that. It just needs to be something shareable.

This year, and I know this is coming up on, well, we're clearly in October now. As of January 1st, I just started to just ignore our social media on CSS-Tricks. I was like, in past years, I would wake up and I would consider it a job. I'd fill a little queue. I'd use Buffer to queue up tweets so they'd sprinkle out throughout the day. Isn't that what publications do? They sprinkle out their social media messaging over time? I was just like, I just don't care anymore.

I can't look at traffic reports that tell me that one percent of our traffic come from social media and spend all day on this. That's a crazy man's errand. It's not a good idea, so I just didn't.

Dave: Yeah.

Chris: But what I did do is I set up automation. When you hit the publish button on CSS-Tricks, it automatically gets tweeted. If we want to write a nice message in there, you can. The social media card comes from the featured image on the post and all that. It's just a soapbox. It's an outgoing soapbox of what we publish. You know how much social media traffic we have? The same as last year. It's the same.

Dave: Yeah.

Chris: It just doesn't matter. The CodePen social media story is not that different. The traffic numbers are higher, so the percentages might even be lower. I think it's nice to be there to some degree, although, as ever, less and less happy with Twitter leadership.

Dave: Sure.

Chris: I was so upset reading that Coinbase fricken' article. I thought that was such a -- so bad, and I'm still processing how I feel about it. Then to scroll down to the bottom and have Williams down there just being like, "Yeah! Mmm! Good!" You know?

Dave: Yeah.

Chris: You're just like, that is so gross, you piece of shit. Anyway.

Dave: [Laughter] No, it's -- I think I like Jesse's, like, "I'm not going to social media." I actually admire that but, unfortunately, if you take that out of the equation, I'm less like -- I don't know the correct way to--whatever--boost your products or your side projects and stuff like that. The only way I can think of is, you are involved in the communities that project is trying to serve.

Chris: There you go.

Dave: If that makes sense.

Chris: Yeah.

Dave: You don't -- whatever. You don't boost -- try to boost your traffic from CodePen social media, but you're involved in the CodePen community or the code pens. Let's say, go, take a step back. You don't boost the traffic to CodePen from the CSS-Tricks, but you're involved in the CSS sort of community. The tie-in happens through that, right?

I guess it would depend. I made a drawing app called Prompts. It was like an Inktober thing. It's cool. I like it. It's a very fun toy for me and I guess I maybe need to update it for this year's Inktober. Shoot. I have more open-source to do.

[Laughter]

Dave: Dang-it! But I'm not heavily involved in the Inktober community, so maybe it's not a thing I should do. I'm not a super drawer. This was more to, like, help me draw more. You know? Maybe I'm the totally wrong fricken' person and the idea is already dead in the water because I'm not really active in that community at all, in whatever that community means. Is it making YouTubes, commenting on YouTubes? Is it hanging out on Reddit boards or whatever?

Chris: It's hard to put a point on, but you'll know if you're a known drawer. You'll have drawer friends. You'll read drawing news. You'll post your drawings.

Dave: Yeah.

Chris: I know it's hard to put a point on, but I think you'll know it and other people know it if you're a drawer.

Dave: Yeah, and if I was a drawer and I was involved in the drawing space, man, this app would be very popular. [Laughter] Not really, but you know. It's that thing. it's like if you had something. If you're in that community, then I think you'll have more success. Whatever that looks like, it doesn't have to be social media, Facebook, Twitter, Instagram. But maybe you find out where the community exists.

Chris: I think that's right, too. I have a final thought on this, too, is that I have a working theory here that really good products and really good writing, really good apps, really good drawings don't go unnoticed.

Dave: Mm-hmm.

Chris: The world is too connected for that. If there's an absolutely incredibly written blog post about X, it will get seen. It will get its day in the sun. There are not blogs out there of developers writing about technology incredibly well that just have dust bunnies on them because they get one view a month. It just doesn't happen. It's a quality thing, too. If you make something, if you have some product -- Jesse, right?

Dave: Yep.

Chris: --that's amazingly well done, it's going to do okay.

Dave: Yeah.

Chris: You don't need Twitter to make sure that that happens. You know?

Dave: No. No, there's some security or whatever in, if you're producing something good, it'll appeal to the right people and it'll find the right people, yeah, who will make nice things on your thing.

Chris: Sure. Sure. Sure. Do you have any thoughts rattling around in your head here? At the end of the show, we are going to invite our friend Jeremy Keith back to the end here to read part two of Jay Hoffman's Web History series. It's just so lovely that Jeremy was able to do this for us. I think you're going to enjoy it.

Dave: Yeah. I appreciate both of them giving time in writing and then reading this stuff. It's really cool. No, I don't have anything, so we can just cut over to that if you want.

Chris: Sure. Let's do it.

[Banjo music plays]

Jeremy Keith: Dennis Ritchie had a problem. He was working on a new, world-class operating system. He and a few other colleagues were building it from the ground up to be simple and clean and versatile. It needed to run anywhere and it needed to be fast.

Ritchie worked at Bell Labs. A hotbed of innovation, in the '60s, and '70s, Bell employed some of the greatest minds in telecommunications. While there, Ritchie had worked on a time-sharing project known as Multics. He was fiercely passionate about what he saw as the future of computing.

Still, after years of development and little to show for it, Bell eventually dropped the project. But Ritchie and a few of his colleagues refused to let the dream go. They transformed Multics into a new operating system adaptable and extendable enough to be used for networked time sharing. They called it Unix.

Ritchie's problem was with Unix's software. More precisely, his problem was with the language the software ran on. He had been writing most of Unix in assembly code, quite literally feeding paper tape into the computer, the way it was done in the earliest days of computing. Programming directly in assembly -- being "close to the metal" as some programmers refer to it -- made Unix blazing fast and memory efficient. The process, on the other hand, was laborious and prone to errors.

Ritchie's other option was to use B, an interpreted programming language developed by his co-worker Ken Thompson. B was much simpler to code with, several steps abstracted from the bare metal. However, it lacked features Ritchie felt were crucial. B also suffered under the weight of its own design; it was slow to execute and lacked the resilience needed for time-sharing environments.

Ritchie's solution was to choose neither. Instead, he created a compiled programming language with many of the same features as B, but with more access to the kind of things you could expect from assembly code. That language is called C.

By the time Unix shipped, it had been fully rewritten in C, and the programming language came bundled in every operating system that ran on top of it, which, as it turned out, was a lot of them. As more programmers tried C, they adapted to it quickly. It blended, as some might say, perfectly abstract functions and methods for creating predictable software patterns with the ability to get right down to the metal if needed. It isn't prescriptive, but it doesn't leave you completely lost. Saron Yitabrek, host of the Command Heroes podcast, describes C as "a nearly universal tool for programming; just as capable on a personal computer as it was on a supercomputer."

C has been called a Swiss Army language. There is very little it can't do, and very little that hasn't been done with it. Computer scientist Bill Dally once said, "It set the tone for the way that programming was done for several decades," and that's true. Many of the programming paradigms developed in the latter half of the 20th Century originated in C.

00:45:23

Compilers were developed beyond Unix, available in every operating system. Rob Pike, a software engineer involved in the development of Unix, and later Go, has a much simpler way of putting it. "C is a desert island language."

Ritchie has a saying of his own he was fond of repeating. "C has all of the elegance and power of assembly language with all the readability and maintainability of assembly language."

C is not necessarily everyone's favorite programming language, and there are plenty of problems with it. C#, created in the early 2000s, was one of many attempts to improve it. However, as it proliferated out into the world, bundled in Unix-like operating systems like X Windows, Linux, and Mac OSX, software developers turned to it as a way to speak to one another.

It became a kind of common tongue. Even if you weren't fluent, you could probably understand the language conversationally. If you needed to bundle up and share some code, C was a great way to do it.

In 1993, Jean-Francois Groff and Sir Tim Berners-Lee had to release a package with all of the technologies of the Web. It could be used to build webservers or browsers. They called it libwww and released it to the public domain. It was written in C.

00:46:43

Think about the first time you browsed the Web, that first webpage. Maybe it was a rich experience filled with images, careful design, and content you couldn't find anywhere else. Maybe it was unadorned, uninteresting, and brief.

No matter what that page was, I'd be willing to bet that it had some links. And when you clicked that link, there was magic. Suddenly, a fresh page arrives on your screen. You are now surfing the Web. And in that moment you understand what the Web is.

Sir Tim Berners-Lee finished writing the first Web browser, WorldWideWeb, in the final days of 1990. It ran on his NeXT machine and had read and write capabilities - the latter of which could be used to manage a homepage on the web. The NeXTcube wasn't the heaviest computer you've ever seen, but it was still a desktop. That didn't stop Berners-Lee from lugging it from conference to conference so he could plug it in and show people the Web.

Again and again, he ran into the same problem. It will seem obvious to us now when considering the difficulty of demonstrating a globally networked hypertext application running on a little-used operating system, NeXT, on a not-widely-owned computer, NeXT Computer System, alone at a conference without the Internet. The problem came after the demo with the inevitable question: how can I start using it?

The web lacks its magic if you can't connect to the network yourself. It's entirely useless isolated on a single computer. To make the idea click, Berners-Lee needed to get everybody surfing the Web, and he couldn't very well lend his computer out to anybody that wanted to use it.

That's where Nicola Pellow came in. An undergraduate at Leicester Polytechnic, Pellow was still an intern at CERN. She was assigned to Berners-Lee's and Calliau's team, so they tasked her with building an interoperable browser that could be installed anywhere. The fact that she had no background in programming--she was studying mathematics--and that she was at CERN as part of an internship, didn't concern her much. Within a couple of months, she had picked up a bit of C programming and built the Line Mode Browser.

Using the Line Mode Browser today, you would probably feel like a hacker from the 1980s. It was a text-only browser designed to run from a command-line terminal. In most cases, just plain white text on a black background, pixels bleeding from edge to edge. Typing out a Web address into the browser would bring up that website's text on the screen. The up and down arrows on a keyboard could be used for navigation. Links were visible as a numbered list, and one could jump from site to site by entering the right number.

It was designed that way for a reason. Its simplicity guaranteed interoperability. The Line Mode Browser holds the unique distinction of being the only browser for many years to be platform-agnostic. It could be installed anywhere, on just about any computer or operating system. It made getting online easy, provided you knew what to do once you installed it.

Pellow left CERN a few months after she released the Line Mode Browser. She returned after graduation and helped build the first Mac browser.

Almost soon as Pellow left, Berners-Lee and Cailliau wrangled another recruit. Jean-Francois Groff was working at CERN, one office over. A programmer for years, Groff had written the French translation of the official C Programming Guide by Brian Kernighan and the language's creator, Dennis Ritchie. He was working on a bit of physics software for UNIX systems when he got a chance to see what Berners-Lee was working on.

00:50:15

Not everybody understood what the Web was going for. It can be difficult to grasp without the worldwide picture we have today. Groff was not one of those people. He longed for something just like the Web. He understood perfectly what the Web could be. Almost as soon as he saw a demo, he requested a transfer to the team.

He noticed one problem right away. "So, this Line Mode Browser, it was a bit of a chicken and egg problem," he once described in an interview, "because to use it, you had to download the software first and install it and possibly compile it."

You had to use the Web to download a Web browser, but you needed a Web browser to use the Web. Groff found a clever solution. He built a simple mechanism that allowed users to telnet into the NeXT server and browse the Web using its built-in Line Mode Browser. So, anyone in the world could remotely access the Web without even needing to install the browser. Once they were able to look around, Groff hoped, they'd be hooked.

But Groff wanted to take it one step further. He came from UNIX systems and C programming. C is a desert island language. Its versatility makes it invaluable as a one-size-fits-all solution.

Groff wanted the Web to be a desert island platform. He wanted it to be used in ways he hadn't even imagined yet, ways that scientists at research institutions couldn't even fathom. The one medium you could do anything with. To do that, he would need to make the Web far more portable.

Working alongside Berners-Lee, Groff began pulling out the essential elements of the NeXT browser and porting them to the C programming language. Groff chose C not only because he was familiar with it, but because he knew most other programmers would be as well. Within a few months, he had built the libwww package. Its official title would come a couple of years later.

The libwww package was a set of common components for making graphical browsers. Included was the necessary code for parsing HTML, processing HTTP requests, and rendering pages. It also provided a starting point for creating browser UI and tools for embedding browser history and managing graphical windows.

Berners-Lee announced the Web to the public for the first time on August 7, 1991. He posted a brief description along with a simple note. "If you're interested in using the code, mail me. It's very prototype, but available by anonymous FTP from info.cern.ch. It's copyright CERN but free distribution and use is not normally a problem."

If you were to email Sir Tim Berners-Lee, he'd send you back the libwww package.

By November of 1992, the library had fully matured into a set of reusable tools. When CERN put the web in the public domain the following year, its terms included the libwww package. By 1993, anyone with a bit of time on their hands and a C compiler could create their own browser.

Before he left CERN to become one of the first web consultants, Groff did one final thing. He created a new mailing list, called www-talk, for a new generation of browser developers to talk shop.

On December 13, 1991 -- almost a year after Berners-Lee had put the finishing touches on the first-ever browser -- Pei-Yuan Wei posted to the www-talk mailing list. After a conversation with Berners-Lee, he had built a browser called ViolaWWW. In a few months, it would be the most popular of the early browsers. In the middle of his post, Wei offhandedly -- in a tone that would come off as bragging if it weren't so sincere -- mentioned that the browser build was a one night hack.

A one night hack. Not even Berners-Lee or Pellow could pull that off. Wei continued the post with the reasons he was able to get it up and running so quickly. But that nuance would be lost to history. What programmers would remember is that it only took one day to build a browser.

It was "hacked" together and shipped to the world, buggy, but usable. That phrase would set the tone and pace of browser development for at least the next decade. It is arguably the dominant ideology among browser makers today.

The irony is the opposite was true. ViolaWWW was the product of years of work that simply culminated in a single night. Wei is a great software programmer. But he also had all the pieces he needed before the night even started.

Pei-Yuan Wei has made a few appearances on the frontlines of Web history. Apart from the ViolaWWW browser, he was hired by Dale Dougherty to work on an early version of GNN.com, the first commercial website. He was at a meeting of Web pioneers the day the idea of the W3C was first discussed. In 2012, he was on the list of witnesses to speak in court to the many dangers of the Stop Online Privacy Act (SOPA). In the Web's early history Wei was a persistent presence.

00:55:12

Wei was a student at UCLA Berkley in the early '90s. It was HyperCard that set off his fascination with hypertext software. HyperCard was an application built for the Mac operating system in the late '80s. It allowed its users to create stacks of virtual "cards," each with a bit of info. Users could then connect these cards however they wanted and quickly sort, search, and navigate through their stacks. People used it to organize their recipes, replace their Rolodexes, organize research notes, and a million other things.

HyperCard is the kind of software that attracts a person who demands a certain level of digital meticulousness, the kind of user that organizes their desktop folders into neat sections and precisely tags their data. This core group of power users manipulated the software using its built-in scripting language, HyperScript, to extend it to new heights.

Wei had just glimpsed Hypercard before he knew he needed to use it. But he was on an X Windows computer, and HyperCard could only run on a Mac. Wei was not to be deterred. Instead of buying a Mac computer -- an expensive but reasonable solution the problem -- Wei began to write software of his own.

He even went one step further. Wei began by creating his very own programming language. He called it Viola, and the first thing he built with it was a HyperCard clone.

Wei felt that the biggest limitation of HyperCard -- and by extension his own hypertext software -- was that it lacked access to a network. What good was data if it was locked up inside of a single computer? By the time he had reached that conclusion, it was nearing the end of 1991, around the time he saw a mention of the World Wide Web. So, one night, he took Viola, combined it with libwww, and built a Web browser. ViolaWWW was officially released.

ViolaWWW was built so quickly because most of it was already done by the time Wei found out about the Web project. The Viola programming language was in the works for a couple of years at that point. It had already been built to accept hyperlinks and hypermedia for the HyperCard clone. It had been built to be extendable to other possible applications. Once Wei was able to pick apart libwww, he ported his software to read HTML, which itself was still a preposterously simple language. And that piece, the final tip of the iceberg, only took him a single night.

ViolaWWW would be the site of a lot of experimentation on the early Web. Wei was the first to include an early version of stylesheets. He added a bookmarking function. The browser supported forms and embedded media. In a prescient move, Wei also included downloadable applets, allowing fairly advanced applications running inside of the browser. This became the template for what would eventually become Java applets. For X Windows users, ViolaWWW was the most popular browser on the market - until the next thing came along.

Releasing a browser in the early '90s was almost a rite of passage. There was a useful exercise in downloading the libwww package and opening it up in your text editor. The Web wasn't all that complicated. There was a bit of code for rendering HTML and processing HTTP requests from Web servers or other origins, like FTP or Gopher. Programmers of the Web used a browser project as a way of getting familiar with its features. It was kind of like the "Hello World" of the early Web.

In June of 1993, there were 130 websites in the entire world. There was easily a dozen browsers to choose from. That's roughly one browser for every ten websites.

This rapid development of browsers was driven by the nature of innovation in the Web community. When Berners-Lee put the Web in the public domain, he did more than just give it to the world. He put openness at the center of its ideology.

It would take five years, with the release of Netscape, for the Web to get its first commercial browser. Until then, the "browser makers" were a small community of programmers talking things out the www-talk mailing list trying to make Web browsing feel as revolutionary as they wanted it to be.

Some of the earliest projects ported one browser to another operating system. Occasionally, one of the browser makers would spontaneously release something that now feels essential. The first PDF rendering inside of a browser window was a part of the Midas browser. HTML tables were introduced and properly laid out in another called Arena. Tabbed browsing was a prominent feature in InternetWorks. All of these features were developed before 1995.

Most early browsers have faded into obscurity. But the people behind them didn't. Counted among the earliest browser makers are future employees at Netscape, members of the W3C and the Web Standards Movement, the inventor of cookies (and the blink tag), and the creators of some of the most important websites of the early Web.

Of course, no one knew that at the time. To most of the creators, it was simply an exercise in making something cool they could pass along to their Internet friends.

01:00:08

The New York Times introduced its readers to the Web on December 8, 1993. "Think of it as a map to the buried treasures of the Information Age," read the first line. But the "map" the writer was referring to -- one he would spend the first half of the article describing -- wasn't the World Wide Web. It was its most popular browser; a browser called Mosaic.

Mosaic was created, in part, by Marc Andreessen. Like many of the early Web pioneers, Andreessen is a man of lofty ambition. He is drawn to big ideas and grand statements. He once said that software will "eat the world. In college, he was known for being far more talkative than your average software engineer, chatting it up about the next big thing.

Andreessen has had a decades-long passion for technology. Years later, he would capture the imagination of the public with the world's first commercial browser: Netscape Navigator. He would grace the cover of Time magazine. He would become a cornerstone of Silicon Valley, defining its rapid "ship first, think later" ethos for years, and seek and capture his fortune in the world of venture capital.

But Mosaic's story does not begin with a commanding legend of Silicon Valley overseeing, for better or worse, the future of technology. It begins with a restless college student.

When Sir Tim Berners-Lee posted the initial announcement about the Web, about a year before the article in The New York Times, Andreessen was an undergraduate student at the University of Illinois. While he attended school, he worked at the university-affiliated computing lab known as the National Center for Supercomputing Applications (NCSA). NCSA occupied a similar space as ARPA in that they both were state-sponsored projects without an explicit goal other than to further the science of computing. If you worked at NCSA, it was possible to move from project to project without arousing too much suspicion from the higher-ups.

Andreessen was supposed to be working on visualization software, which he had found a way to run mostly on auto-pilot. In his spare time, Andreessen would ricochet around the office listening to everyone about what it was they were interested in. It was during one of those sessions that a colleague introduced him to the World Wide Web. He was immediately taken aback.

He downloaded the ViolaWWW browser and, within a few days, he had decided that the Web would be his primary focus. He decided something else too. He needed to make a browser of his own.

In 1992, browsers could be cumbersome software. They lacked the polish and the conventions of modern browsers without decades of learning to build off of. They were difficult to download and install, often requiring users to make modifications to system files. And early browser makers were so focused on developing the Web, they didn't think too much about the visual interface of their software.

Andreessen wanted to build a well-designed, performant, easy-to-install browser while simultaneously building on the features that Wei was adding to the ViolaWWW browser. He pitched his idea to a programmer at NCSA, Eric Bina. "Marc's a very good salesman," Bina would later recall, so he joined up.

Taking their cue from the pace of others, Andreessen and Bina finished the first version of the Mosaic browser in just a few weeks. It was available for X Windows computers. To announce the browser, Andreessen posted a download link to the www-talk mailing list with the message, "By the power vested in me by nobody in particular, alpha/beta versions of 0.5 of NCSA's Motif-based networked information systems and World Wide Web browser, X Mosaic, is hereby released." The Web got more than just a popular browser. It got its first pitchman.

That first version of the browser was impressive in a somewhat crowded field. To be sure, it had forms and some media support early on. But it wasn't the best browser, nor was it the most advanced browser. Instead, Andreessen and Bina focused on something else entirely. Mosaic set itself apart because it was the easiest to use. The installation process was simple and the interface was, relatively speaking, intuitive.

The Mosaic browser's secret weapon was its iteration. Before long, other programmers at NCSA wanted in on the project. They parceled off different operating systems to port the browser to. One team took the Mac, another Windows. By the fall of 1993, a few months after its initial release, Mosaic had feature-paired versions on Mac, Windows, and Unix systems, as well as compatible server software.

After that, the pace of development only accelerated. Beta versions were released often and were available to download via FTP. New features were added at a rapid pace and new versions seemed to ship every week. The NCSA Mosaic was fully engaged with the Web community, active in the www-talk mailing list, talking with users, and gathering bug reports. It was not at all unusual to submit a bug report and hear back a few hours later from an NCSA programmer with a fix.

Andreessen was a particularly active presence, posting to threads almost daily. When the Mosaic team decided they might want to collect anonymous analytics about browser usage, Andreessen polled the www-talk list to see if it was a good idea. When he got a lot of questions about how to use HTML, he wrote a guide for beginners.

When one Mosaic user posted some issues he was having, it led to a tense back and forth between that user and Andreessen. He claimed he wasn't a customer and Andreessen shouldn't care too much about what he thought. Andreessen replied, "We do care what you think simply because having the wonderful, distributed beta team that we essentially have due to this group, gives us the opportunity to make our product much better than it could be otherwise."

What Andreessen understood better than any of the early browser makers was that Mosaic was a product, and feedback from his users could drive its development. If they kept the feedback loop tight, they could keep the interface clean and bug-free while staying on the cutting edge of new features. It was the programming parable, "Given enough eyeballs, all bugs are shallow," come to life in browser development.

There was an electricity to Mosaic development at NCSA. Internal competition fueled OS teams to get features out the door. Sometimes the Mac version would get to something first. Sometimes it was Bina and Andreessen continuing to work on XMosaic.

"We would get together, middle of the night, and come up with some cool idea. Images was an example of that. Then we would go off and race and see who would do it first," creator of the Windows version of Mosaic Jon Mittelhauser later recalled. Sometimes, the features were duds and would hardly go anywhere at all. Other times, as Mittelhauser points out, they were absolutely essential.

In the months after launch, they started to surpass the feature list of even their nearest competitor, ViolaWWW. They added forms support and rich media. They added bookmarks for users to keep track of their links. They even created their own "What's New" page, updated every single day, which tracked the Web's most popular links.

When you opened up Mosaic, the NCSA What's New page was the first thing you saw. They weren't just building a browser. They were building a window to the Web.

As Mittelhauser points out, it was the tag which became Mosaic's defining feature. It succeeded in doing two things. The tag was added without input from Sir Tim Berners-Lee or the wider community. Andreessen posted a note to www-talk only after it had already been implemented. So, firstly, that set the Mosaic team in a conflict with other browser makers and some parts of the Web community that would last for years.

Secondly, it made Mosaic infinitely more popular. The tag allowed for images to be embedded directly inline in the Mosaic browser. People found the Web boring to browse. It was sterile, rigid, and scientific.

Inline images changed all that. Within a few months, a new class of Web designer was beginning to experiment with what was possible with images on the Web. In some ways, it was the tag that made the Web famous.

The image tag prompted the feature in The New York Times, and a subsequent write-up in Wired. By the time the press got around to talking about the Web, Mosaic was the most popular browser and became a surrogate for the larger Web world. Mosaic was to browsing the Web as Google is to searching now.

Ultimately, the higher-ups got involved. NCSA was not a tech company. They were a supercomputing lab. They came in to help make the Mosaic browser more cohesive and maybe more profitable. Licenses were parceled out to a dozen or so companies. Mosaic was bundled into Spry's Internet in a Box product. It was embedded in enterprise software by the Santa Cruz Operation.

In the end, Mosaic split off into two directions. Pressure from management pushed Andreessen to leave and start a new company. It would be called Netscape.

Another of the licensees of the software was a company called Spyglass. They were beginning to have talks with Microsoft.

Both would ultimately choose to rewrite the Mosaic browser from scratch, for different reasons. Yet that browser would be their starting point and their products would have lasting implications on the browser market for decades as the world began to see its first commercial browsers.

[Banjo music plays]

Dave: All right. Thank you, again, Jeremy. That was awesome. Thank you, Jay, for writing that as well. Maybe we'll have you all on one of these days.

Chris: [Laughter]

Dave: One of these days. [Laughter] Chris, did you have anything else you'd like to say here?

Chris: Um, I don't think I have any other than ShopTalkShow.com.