Hi, Karl, please introduce yourself.

I’m Karl Stolley. I am the author of Programming WebRTC. For the first fifteen years of my career I was a university professor. Since mid-August of this year [2022], I’ve been a senior engineer at Daily, which is a company that builds real-time audio and video APIs for every developer.

What is WebRTC?

It is a web API. So it is something that ships in all modern browsers. It gives us a way of establishing peer-to-peer connections across the web, and it does so without any third-party server sitting in the middle.

I think it’s important to note how radical that is. For most of its history, the web, like most of the internet, has had a client-server architecture. Client makes a request, server handles that request and provides some kind of response in return. Whereas with peer-to-peer architecture, there is no requester, there is no responder. There are just these different peers that connect to each other, and most commonly, to stream either audio off a device’s microphone, or video off the device’s camera so that you’re able to do things like real-time calling like you would experience in Google Meet, Zoom, or anything like that. But right in the web browser.

In addition to audio and video, there is also capability for sending arbitrary data back and forth. This is actually part of the WebRTC spec: you can send blobs of binary data back and forth. This means that you have the opportunity to do more than just build something with WebRTC to make a Zoom clone, let’s say, and instead really think about how a peer-to-peer connection lets two or more users stitch their interfaces together in real time. So you can build an entirely different class of applications that can be highly collaborative, highly interactive, and yet still be very private, and still have very, very low latency, because again you’re not feeding the signal through a third-party server. WebRTC is the web API that supports all of those things.

WebRTC itself is built on a bunch of real-time communication protocols that are actually housed at IETF, in contrast to the W3C that oversees the WebRTC spec. So, really, you look at the different RTC specifications of the IETF, those are the lowest-level plumbing kinds of things, and those can be implemented in any internet-capable device, at least in theory.

WebRTC as a web API provides a web browser wrapper around those lower-level specs and protocols. WebRTC support is even in iOS and Android. I could build something so that I could be working happily from the comfort of my favorite desktop web browser and interacting with someone who’s running a native app on iOS or Android or whatever. That interoperability allows us to bring more first-rate native-style features to the browser and interact with the entire galaxy of internet-connected devices that have cameras and mics and so forth.

You’ve mentioned a few acronyms now. Who are these major players in developing specifications that affect your part of the development world?

The two that I mentioned are the W3C, the World Wide Web Consortium, which goes back to the pretty early days of the web. It was actually Sir Tim Berners-Lee who founded W3C. The other one, just to get acronyms expanded and out of the way is the IETF, which is the Internet Engineering Taskforce. It’s been around since the early days of the internet and was founded in the mid-1980s.

The W3C, predictably, is the umbrella organization that oversees pretty much every kind of open web standard and spec that a web browser touches. So they’re the ones that at least nominally now oversee HTML. That’s really under another organization called WHAT Working Group, or WHATWG, which is the Web Hypertext Application Working Group.

The W3C also oversees the CSS specification, and then they also oversee things like the web content, accessibility guidelines, which is less of a language and more of a set of practices for making things accessible. If you’re in web development, whether you realize it or not, you’re never more than a couple of steps away from some specification that the W3C has published.

The W3C is the umbrella organization in terms of how the organization itself is organized into various working groups. One of those working groups is actually devoted to WebRTC. You sometimes have to just study their org chart to figure out which specification is under which working group, and which charter. And all of those different byzantine things.

The IETF, their specifications are not necessarily…I mean, you can get easily overwhelmed by the W3C, because there are editors’ drafts and working drafts and final drafts…I’m forgetting exactly the nomenclature they use for a draft right before it gets voted in or voted on to become a W3C recommendation, which is their highest level of spec. It’s a recommendation.

They’ve only recently begun to embrace the word standard, because for the longest time they would say, “Oh, we don’t issue standards. No, we don’t.” But even internally you can see in their own documentation that they started talking about standards in relation to their specs.

IETF works on what are called RFCs, or requests for comments, which are like these forever evolving, living documents. They cover everything from how an email gets crafted to endianness when you’re sending a stream of bits and bytes over the internet. They plow a huge swath.

I couldn’t even begin to represent all that they do, because I only know a tiny fraction of it—usually as relates specifically to web technologies, since that’s where my primary development allegiances lie.

What stage in the process is WebRTC? Because I know that the technology, not specifically for web but for doing that real-time communication and all that, goes back to the ’80s. How did we get to where you are in the book, and what does it represent along that evolutionary path?

The WebRTC 1.0 specification became a finalized W3C recommendation in late January of 2021. That spec had been in development for almost a decade. So that goes back to 2011, 2012. I would have to do some more homework to give you the complete lineage going back to the 1980s. Even UDP, which is the primary network protocol that gets used with WebRTC, goes back to the early 1980s

And then some of the technologies that are used to describe the WebRTC session that’s about to happen also go back to late ’80s, early ’90s. So there is some very old technology that’s there. Part of the design of that, even if the IETF was to…I don’t know that I’ve ever read this, but you look at what they did, and you have to believe that they thought this, and that is that this real-time stuff is going to be huge. As always-on, hyper-fast network connections become more and more routinely available to larger and larger swaths of the planet, the real-time stuff is going to do the same thing as the telephone did in terms of connecting people at vast distances and changing the kinds of activities that are possible.

So the IETF chose to build WebRTC around a bunch of older technologies, partially because they were well supported, but also because they weren’t patent encumbered. So you could build this stuff and not have to pay huge licensing fees to get the basic networking and protocol off the ground.

Where we stand right now, WebRTC 1.0 is a finalized recommendation. Work on what will eventually become the next edition of WebRTC has already begun. I think everyone is working under the impression that that will be WebRTC 2 rather than a WebRTC 1.1, but that remains to be seen. And it’s always possible that an intermediate point-release spec could appear.

At this point, there is work on the next edition, and most of that is taking place on GitHub. There’s also a WRTC listserv where those discussions are ongoing.

You’ve done quite a bit of work in open source, and specifically you had a development research group dedicated to investigating open source technologies. Can you tell me about that?

Yeah. That was a team of graduate students that I worked with. One of the tricks about working with graduate students, particularly master’s students, is they’re only around for a couple of years. And so, that group, we would tackle a problem. We’d look at some aspect of web design or web development, or students would bring some aspect of open source from their own research, and then we’d talk about it, build some kind of prototype, or write some code. But there was always a constant churn of people coming in and out the door.

So it wasn’t my most successful project ever, but it was really fun to have an opportunity outside of class to talk about and do some research on open source. And for a lot of those students, they would bring—because most of them were working people—they would bring problems that they were working on at work, and we would discuss them and talk about how those things might be approached differently. It was—we didn’t do a whole lot of hard research or big academic publications—but it became like this little open source support group internally. That was really nice while it lasted.

What are some of the more interesting technologies that are currently out there for supporting open source?

That’s a really interesting question. In some ways—and this is maybe going to be a cop-out answer—for me some of the most interesting stuff about open source isn’t necessarily the technology that supports it so much as the human element that refines how a particular community does its open source work. That’s everything from contribution guidelines and codes of conduct and things like that.

We need more places that are more open and more welcoming. I also get the sense that more projects are taking their own documentation seriously and seeing that as just as important of a contribution or a feature of a project as any line of source code that might get written. And of course, for me, I’m always interested in tools like JSDoc to give a very basic example of where you’re aligning documentation and code writing and making those things part and parcel of a commit. So that you’ve got a commit that not only shows that its tests are passing but it also includes adjustments or additions to the documentation as well.

You came to development with a background in, of all things, rhetoric. What is rhetoric? What does that mean to you, and how has that affected how you write technical books and how you communicate?

My standing joke about rhetoric is that it’s the dirtiest word that you can get an advanced degree in. I’ve got both a master’s degree and a PhD in rhetoric. Usually the word rhetoric is bandied about by politicians. Like, “Oh, that’s just empty rhetoric. That’s just heated rhetoric. They’re using that divisive rhetoric.”

It’s become a shorthand for an insult, and there are some interesting historical reasons for that. Actually going back to the sixteenth century when rhetoric became unmoored from its origins alongside Greek philosophy. It was part of the original trivium: grammar, rhetoric, and logic.

It was a way of not only speaking but of crafting arguments and speaking effectively in at least three different broad occasions. So, classically speaking, you had forensic rhetoric, which was what you would speak in the courtroom. So, in that case, you were speaking in order to try to persuade a judge or a jury about events that have happened and as to the probability, or likelihood, that your version of those events is what indeed happened.

You’ve got political rhetoric, which is, well if forensic rhetoric is rhetoric based on what actually happened, you’ve got political rhetoric, which is, what should we do? What should the future be like? Of course, that’s going back to the Roman senate and things like that. You’re debating legislation and future courses of action.

Then the third form of occasional rhetoric is what’s called epideictic rhetoric. Epideictic rhetoric is usually about celebratory rhetoric. Like giving a toast, or praising somebody on a holiday, or even the occasion of a funeral oration, or something like that, where you’re saying nice things about a person.

Alternatively, and I always love this, because there is the git blame command, if you also have a git praise command, that’s epideictic rhetoric. There used to be a git praise command, but now you have to alias that yourself to git blame. Whether to praise or to blame depends on the actions, and how you see them, of the person you’re talking about in a given moment.

Fast forwarding through a whole lot of history and some modern times, my interest in rhetoric and the reason that I spent seven years of my life studying it beyond college, was that it’s, broadly speaking, a study of how human beings use symbols, in the best cases to avoid armed conflict or at least hitting each other with sticks.

That if we can talk and we can reason things out and we can present cases and arguments, things like that, that we’re likely to make a better society and a better world. Outside of those highfalutin’ principles, I’m interested in just how effectively you can communicate. Words can be clumsy and confusing. They can carry connotations that a speaker might not otherwise intend.

Of course, everything in judging the success of a particular piece of writing or communication is whether you had the intended effect on the audiences that you intended to affect. That’s where technical writing—to bring this all back to earth and the present day—to me is such an interesting case, because it’s so difficult to choose the right words, even to refer to some technical concept, talk about lines of code in a file, or something like that.

How can you be as precise as possible without also being a complete bore and dreadful to read? This is turning into a winding answer but the dissertation that I wrote for my PhD—which please don’t ever look that up, because it’s embarrassing—but it was me being interested in how we use symbols broadly. And the symbols I was mostly interested in were computer symbols. Particularly like web languages and things like that. And how can acts of writing code themselves be persuasive or themselves put forward a particular point of view from a particular technical approach or perspective.

These days I’m very much interested in collaborative environments. Like, how do we cooperate when we’ve got teams of anywhere from dozens to thousands of people working on the same code base? Again, most of the time we manage to have those kinds of collaboration, and people don’t get into fist fights, although certainly they can come close.

But my interest in that has to do with core aspects of human nature for wanting to manipulate symbols, so as to affect the world around us, and whether we do that through a piece of technical writing, or we do that through a shell script, or whatever it is that we’re working on, that to me will always be a source of endless fascination.

How can writing code be persuasive? How can you put emphasis on readability and on beauty, where code has clarity, concision, focus, and that inevitable part, where it is uplifted. Where do you see efforts like that happening in code creation?

I mean, maybe I’m just skewed because of the languages that I tend to pay attention to, which usually Ruby is a big one for me. Rust is something that I’ve started to pay more attention to, but even beyond individual languages, I’ve become a fan of this conference devoted to language design called SPLASH: Systems, Programming, Languages, and Applications: Software for Humanity. It’s a conference of ACM, or the Association for Computing Machinery, but nobody calls it that anymore.

I think it speaks to the power of all the processing and everything that we’ve got at our fingertips now. Think about a language like COBOL or some ancient language like that. Those languages didn’t have the luxury of being expressive. They didn’t have the luxury of like, “What’s the most beautiful way to structure a method call or something like that?” Most of them didn’t even have methods because they’re all functional programs. I think that as language is proliferate and as developers have a genuine choice, at least at certain levels of what language they’re going to use, they can pay attention to that aesthetic quality of, what does your syntax look like? How beautiful is it? How happy does it keep a developer who’s writing in it?

Those are actual substantive considerations in a language. It’s not just a kind of like, “I’m this developer-aesteticist who if I have the right semicolons to terminate my lines, my delicate sensibilities won’t possibly withstand that.” But then it is a real consideration, these languages that we design. I think that where I sense the most tension in that is, yes, when there are opinionated languages or opinionated frameworks, where the tension comes in is from the people like me who love a high-level API that I can use for most of what I’m doing, and I can strip it back, or go into, if that’s the porcelain layer, I can get down into the plumbing if I need to, to do that. Versus somebody who’s more like the kind of developer that my brother is, who I think would be happy if he could program machine language for vending machines and elevators all day long because he loves that super-low, practically bare-metal kind of thing.

I think that he represents a particular kind of developer that needs to be persuaded, perhaps, of the fact that a language can be functional and beautiful. I mean, he’s a big Perl and Python guy too. So it’s not like he’s completely divorced from anything like that.

I think the case still has to be made that a language’s beauty, or its aesthetics, is more than just a skin-deep kind of thing, and it speaks to the overall thoughtfulness that goes into the engineering of a language. I think part of that becomes to strip away the fact that, actually, languages themselves are engineered. Some of them are engineered really well, and some of them are JavaScripts, or maybe not at the time and take years to overcome their own shortcomings, and their own lack of attention in those kinds of details.

Since you work with quite a lot of web work, I assume JavaScript is a big part of the reality for you.

It is, although I think that JavaScript gets used on the web way more than it needs to be.

What else could be used?

Well, we need more attention to HTML. That’s the least sexy thing someone could ever say. I look at certain frameworks, and I won’t name them. There is so much reinventing the wheel. Like, “Oh, let’s come up with this custom element or this custom data structure that’s going to do this thing.”

Then I pull up the HTML spec, and I’m like, "There is literally already an element that a) does it better than you and b) does it everywhere without anybody having to download any additional code for JavaScript to interpret what’s going on. The sense I get from most web developers, including a lot of web developers I really respect, is that HTML got finished some time in around 1998, ’99, and nothing interesting has happened there ever since, which couldn’t be further from the truth.

That’s why you look at most tutorials, you look at all kinds of code, and it’s div tag this, and div tag that, div, div, div. It’s like, div’s fine, and there are some interesting reasons historically I think why people fall back on the div tag. It literally has no semantic meaning attached to it beyond being a generic division. But on the flip side, it has no default browser styling attached to it, either. And so, it does become this kind of catchall.

So, you see people, even just within vanilla HTML, using the div tag to write their own idiolectic HTML, and that’s unfortunate for a lot of reasons, not the least of which is for accessibility, and the tremendous advancements that we’ve had in assistive technologies in the last ten years. For the longest time, JAWS was the IE of the assistive technology world. It was just the 900-pound gorilla, and everybody who needed an assistive browser used JAWS.

And now of course we’ve got every operating system, from Windows to Mac OS, to most flavors of Linux, all with very robust operating system–level assistive technologies. And there is actually a whole slew of web standards, and specifications that are specifically about mapping those lower-level, operating system–level preferences that somebody might have, with what’s going to actually happen in the browser.

As a super basic example, if someone specifies in their operating system like, “Hey, I need a high-contrast environment.” What that usually does is, of course, make sure that the brights are really bright, the darks are really dark, and that usually colors are reduced in number, because you can only get so much contrast within a given color palette. But what we can do as web developers is to say, “Okay. We’re not going to make this person specify that same preference in their browser, or God forbid on a specific website.”

Burdening the user like that seems to be finally going away. For the longest time you could go to a website like, “Here is this letter A up in the corner, so you can change how big the text is.” We don’t have to do that anymore if we engineer the thing correctly. We can adapt directly to what somebody is doing or what their preferences are, which is the other part of what needs to happen on the web, and that is more CSS. Like, people are still using way too much JavaScript to introduce animations, and it’s just so wasteful and nonperforming, because you’re stuck to JavaScript’s event loop when you’re going to animate something going across the screen, versus if you do animations and transitions and stuff like that native in CSS, you’re able to tap right into WebGL and be able to have battery smooth animations that don’t cause a hit in performance for the pages that you’re viewing. Again, not forcing anybody to download another, even additional bite of JavaScript, or something, to make it all happen.

When working on the web, do you see a future where there is a way to be expressive on the web, and pay tribute to things like abstraction, and testing, and code documentation? And all those things that are taken for granted in the rest of the developer world?

Yeah. I mean, let’s talk about testing, because that’s a big one for me. It’s something that, even though I’m not teaching anymore, but toward the end of my teaching career, I started bringing more and more testing to front-end stuff into the classroom. I used to be like, “We’ll do testing for like the last two weeks.” Then it became like, “Well, how can I structure an entire introductory front-end web-development class around testing?”

To me, the gateway drug to being serious about testing is just linting. So, we’d work…In my professional practice, I’ve got my HTML linter, I’ve got my CSS-style lint, I’ve got my ES lint, just to put some guardrails around my own inclinations toward stupidity and making dumb mistakes. Like, let’s bring all that stuff here so that we can catch little things that inevitably happen. Who hasn’t had a style sheet that caused them to lose substantial amounts of hair? It turns out, your class selector, you forgot to put a period in front of it.

It looks like an element selector, except there is no such element as whatever the wacky class is that you’re styling. And of course, if you bring a linter to the party, you’re going to have a lot better chance of catching that. The weird contradictory/question-raising mechanism of why testing is more popular in the front end is that web languages are the most permissive and forgiving things that they could possibly be.

You can butcher something so horribly and make it barely recognizable as HTML, and the browser is going to do something with it. It may not be what you intend, but it’s going to do something with it. It’s not going to throw any errors at you, it’s not going to complain at you, it’s going to do the best it can. And to a certain extent, CSS is very much the same way. Like, it’s not going to throw you many useful errors if you even think to open up a console, look, and see. Most browsers will throw deprecation warnings on stuff that it recognizes, but on things it doesn’t recognize it will just give it a shrug. So, we need, as developers, ethically to bring additional quality controls, and other kinds of tools to a first-rate web-development workflow.

I’m a big fan of visual regression testing. It doesn’t matter how small the project is. If there is even a small chance…Like, I’ve got a friend who is a therapist here in Chicago. She asked me to make a small site for her because she’s striking out on her own and going to work independently as a therapist rather than be involved with a group. It’s a simple,small, one-page site, and I have a full suite of visual regression tests on it written in a framework called Backstop, which is not the most sophisticated thing in the world. All it really does is take headless Chrome and make screenshots of her site at whatever breakpoints that I specify, and if there are particular elements I’m interested in, I can grab those. If I want to have the entire CVS receipt–sized page as it renders on a phone, I can grab that.

Then all it really does it diff against subsequent screen captures of those pages. What’s great about that is that if there is something that needs to get fixed in her CSS, or if there is something that I want to try or whatever, then I’ve got this battery of tests that’s going to help me with that, including refactoring CSS.

Nobody that I know routinely refactors their CSS. They write, and write, and write CSS, and your page looks like it’s supposed to look, and then they never think about it again, because it’s its own Jenga tower, where like, “I don’t want to rewrite this style, because if I do that, then it’s going to break all these other things.”

If you’ve got a battery of visual regression tests set up against your style sheets and against your page designs, then you could go back and say, "Hey, I think this was some magical thinking here that I set height: 100% here, or with a redundant background: inherit.” Whatever the wacky thing is that you in some moment of dark desperation put in your style sheet. You can go through, strike those lines, and rerun your regression tests. And if there is no change, then guess what? That line of CSS is literally not doing anything, and so it needs to go.

Then I think a step up from there is more end-to-end testing. I’m a big fan of the framework Nightwatch, which just got acquired by BrowserStack not long ago. I think that’s only been maybe a year ago. They’ve already done amazing things with that framework and made it so that you can do all kinds of tests and you can link in to the WebDriver API, which all modern browsers support now. It’s another web standard.

You can write your Nightwatch tests across all different browsers, and then boom. Do the same thing that all the big kids in backend development do and run a battery of tests with every commit, or every deploy, or whatever it is that you want to do. You can tell, I’ve got a fair amount to say about front-end testing.

What about the other things? For example, code documentation?

I think the trick with documentation is the trick with most software. You set out with the greatest intentions of writing a framework or something like that, but if you’re not willing to put in the ongoing maintenance on it, eventually it’s just going to go to rot, and it’s going to be a security headache for some devops team down the line or something.

I think documentation is the same way. Everyone thinks that documentation is a good idea, and most people think, “Hey. First stab at documentation here. Let’s document this API. Let’s write all the stuff up. Let’s get fancy. We can bring markdown to this and we can make it really cool.” The problem is that, much like software maintenance itself, documentation maintenance is completely unsexy work.

It’s a lot of fact checking, it’s a lot of cross-checking, it’s a lot of opportunity for error, it’s a lot of opportunity for frustrating other developers, which I think is the other demotivational part of documentation. If you do try to do the right thing, and write documentation for your framework, or your software, or whatever it is, and then you find somebody that gets steered wrong, they will let you have it and yell at you for your malfeasance, for, “Fow dare you let this API method be improperly documented? And, you wouldn’t believe how many hours I lost,” or whatever it is.

I guess my overall thing is to understand documentation as a commitment that a project, or a company, or whatever has to make. Then build it into your pull-request templates, so that people have to tick that box and say, “I’ve updated the documentation.” Or, “The documentation doesn’t need updating.” And make the documentation, if it’s possible that your documentation lives in the same repository as your actual project, that you can review those things together.

Like, here we see the change in the documentation, here we see the change in the code base that reflects that documentation change. There is only a certain level that you can, I guess, automate a lot of that stuff, depending on what people have set up. I mean, if you do something like JSDoc that’s embedded documentation, you’re still relying on somebody going up five, 20, 80, 130 lines to where the JSDoc lines are to compare them against the method call or whatever that’s being changed, way below. At least being intentional about that is better than just hoping for the best.

How do you recruit content creators and writers? And how do you get them more involved in development?

That’s a good question. I think I’ve been fortunate to work with a lot of content creator types who are close to the web, and so it’s not a foreign thing, but I’ve certainly been a consultant and moonlit on occasion as an independent developer with clients who are like, "Yeah. We want a website, and good news, we got all of our stuff in Word documents.”

So then you go and you look, and your heart breaks a little bit because this group of really talented content people have spent hours and hours and hours and hours formatting their Word documents to look exactly the way that they want them to look on the web. And then you have to explain to them that the browser viewport is flexible and all these things. And that some of what they’ve done is going to be locked into a Word document and are going to be really difficult to extract.

I think part of it is, and I don’t know how to even admit this, but for years I’ve just freaked out when I would teach. I would freak out at my students who are web developers and software developers and things like that. And every time they go to write anything, they go to Microsoft Word or they go to Google Docs, and it just makes my head explode. It’s like, you’re a developer, you should know better than to use Word. Where is your text editor? Where is your GitHub gist, if nothing else, where you can just hammer this stuff out in plain text?

I’ve got friends and family who teach elementary, high school. That’s how from the very earliest age kids are taught to write digitally, in a word processor. It’s like, man, that’s weird, because so little of how information travels the globe anymore is anything that looks remotely like a Word document. At best, that’s internal communication. Everything else is on the web, or it’s in web-backed kinds of frameworks. It’s like, why does the Word processor hold on with such a death grip over people’s imagination of what it means to write.

I mean, I suppose it’s the same as every high school student to this day. Like, you’ve got to set up your Word document for double spacing, and you got to indent by a half an inch, all this stuff. And it’s stuff that goes back to the typewriter and to copyediting. Of course, most student writing is never going to be copyedited.

So, there is really no good reason as to why there should be a double-spaced page other than, well, once upon a time, there were buttoned-down men and women who would mark your copy with a pen or pencil. You needed double spacing to accommodate those marks. And still, I think if you pick up the MLA style guide, or most other things like that, that’s the guidance that’s given for preparing manuscripts.

To me, I don’t know if this is a cop-out answer, or I’m wildly naïve, but it’s like, we’ve got to start thinking more expansively about what content is and where it gets created, and where it’s going. And really think about how much our word processors, especially really highly-featured ones that can do all this fancy-pants desktop publishing stuff as it was called in the ’90s.

And realize like, "No. Actually, if you write it in this format you’re locking yourself in particular ways, and you’re cutting yourself out from developing as a writer who can write effectively for these other ways that we send information from point A to point B.

I think in my coming-of-age with computers, everybody was really hung up on WYSIWYG: what you see is what you get. That was like…I remember the first desktop publishing program I integrated with was from Xerox. I can’t even remember what it was called, but it was a 286 DOS machine…Barely had EGA graphics on it.

You had to do this translation. You had where you lay out your page in Xerox Publisher, or whatever it was called, and then when you go to hit Print, assuming you’ve got a laser printer that cost $80,000, or whatever it was at the time, and then you’ll get this professional-looking page that comes out.

Once we got deeper into Windows 3.1, and fully fledged graphical interfaces, you were able to re-create the page on screen. So, what’s in my word processor, or what’s in my page design software, what I see is what I’ll get when I print. And of course, that spirit was behind some of the early attempts to expand access to the web beyond a core group of people willing to write HTML was like, “Okay. Here is FrontPage. Okay. Here is Dreamweaver.” Or even going back before that like, "Here is Netscape Composer.”

Even the W3C themselves had their own tool. I can’t remember now what it was called, but everybody was trying to make that WYSIWYG model work, because it was contemporaneous with the birth of the web. Like, the web comes out in a real big way in the mid ’90s, which is like peak page-design software that looks like on screen when you print it, or peak word processors that now you don’t have to make a logical leap between what’s presented to you on screen and what actually rolls off the printer.

I think for, especially in content creation programs; and here I’m thinking of everything from students that go to major in technical communication or written communication or straight-up writing or even in design programs and things like that. The sense that what I see on my screen is the unfortunate gold standard for what is “good” content.

I used to teach Dreamweaver in my web classes eons ago. The problem is that, and the way I would present this to the students is, the way the WYSIWYG software presents itself to you in a web context is a comforting lie, because yes, you could get really good at Dreamweaver. And you can make a page that looks amazing in Dreamweaver’s interface, and everything is pixel perfect; it’s where you expect it to be; it does what you want.

The problem is that literally nobody on the planet is going to look at your site in Dreamweaver. That’s not even what that software is for. They’re going to look at it in Internet Explorer, or they’re going to look at it in Netscape 6, or whatever the browser was of the day.

Those are all going to be slightly different experiences because they’re all slightly different engines, and, I think, the idea of semantics rather than being so hung up on, “Is this to the pixel exactly the way I want it?” to, “Is this what I intend it to mean?” I don’t want to be too gossipy at work, but with the blog at my company, we were having some issues with how some small thing was formatted on our blog. Somebody said, “Well, if we do the markup like this, then it’ll look fine.”

My response was like, "Yes. It will, but if somebody prefers to look at a site in reader mode, or is using assistive technology, or just, ‘we don’t want to hate ourselves next time around when somebody designs the blog,’ we need to be fixing this issue at a different level, rather than trying to twist some markup around in this particular blog post to get it to behave a particular way. Like, “Yes. That will solve this problem right here right now.” But it opens up a whole bunch of other ones that are going to happen either immediately, for readers that do things like use reader mode on their browsers, or down the line for us when it’s like, “Oh, yeah. We’ve got to go back and clean up all these blog posts, so we do this hacky little thing in the markup.”

I think that is a problem with content creation: it becomes a very big pile of hacky little things that are done in the service of content. It’s unfortunate, because we do have so many people who are excellent writers, or excellent visual designers, excellent content creators, who don’t have the tools…And here I’m talking as much about mental habits as I am about software, to make that transitional leap to what one might have written at some point in Microsoft Word, and what now you need to write to make something into an accessible experience on the web. Not just accessible for low-vision users, but for people who are on old phones, who are on really slow network connections and things like that. How do you make that sense of accessibility thrown wide open?

Earlier, to compare what you talk about, the experience not matching Dreamweaver, you pointed out that in a way, the looseness, the laxity of the language and the specification is the strength of the web experience, because when you experience through that imperfection, you’re still experiencing it, whereas in many parts of application design for desktop and for mobile, you have to have perfection or it won’t run.

So, as you were talking, it just really struck me that you have to step back from the tools and from the language. So, how do you provide the best experience understanding that imperfection and flaws are simply part of what you are creating?

Yeah. I think that’s incredibly well said. It runs against the human weird need to consider a computer as “perfect.” You can do some pretty remarkable things, and then that true sense of feeling less than perfect yourself, because you can’t do the perfect thing right upfront. That’s why I always love to teach beginners, because you had the number one job that you have as a teacher of beginners, and it doesn’t matter if you’re teaching in front of a classroom, you’re in a bootcamp, or you’re writing a tutorial, whatever it is.

The number one job, and I don’t usually make big proclamations about the number one, or the primary, but this one I’m willing to arm wrestle somebody over. The number one thing that you have to do for beginners in matters of computing is to normalize failure, to celebrate, if I’m teaching a class on Ruby or something like that. Yes, it’s totally possible that you write the most basic Ruby program in the world and you go to run it and you get a giant console full of stack traces.

That is such a demoralizing thing for a beginner because they want their program to just run. If you can demonstrate and reassure and say, “No. Let’s actually look at all that stuff. Yes, it looks like the console just threw up and now you’ve got all this mess where you wanted your simple little program input and output to be. Let’s look at that. Let’s talk about what it is to read that, and let’s talk about what a magnificent thing, that even if this seems impenetrable to you at this moment, that forever, for as long as you opt to write in this language, or any other language, that you’re going to get error messages. And you can either live in fear of them, or you can begrudgingly embrace them at the very least.” That there is stuff to be learned here. That when you write something, and you have an expectation that it’s going to look, or act one way, and it either doesn’t, or it just completely errors out on you, that’s where the learning happens.

The thing I think I’ll probably miss most about teaching is that it was like, you got to not only, as the teacher, learn from your own mistakes, you got to learn from all the interesting, weird mistakes that others would make around you, your students. To the point that after a while you teach for a long enough number of years, and the student comes to you with a problem, you’re like, “This is terrible.” I’m like, “Oh yeah. What you did is you made this little mistake there.” You get to see enough of other people’s mistakes that you build up a repertoire, and you can see the source of the mistake coming from a mile away. You know exactly where to point students, and it’s rare to encounter something that is a true head scratcher. Like, I don’t know how this happened; I don’t know what happened.

Just being around enough beginners for a long enough amount of time, you get to see the same mistakes, over and over, and over again. The weird trade off is that students think that you as the instructor must be really smart, when the fact is, you’re probably not all that smart, but you have seen a lot of mistakes, and if you’re teaching the right kind of class, you could actually draw that out and say, “Look. Go teach a class to somebody.” Because you’ll see all this interesting stuff, and then when it happens to you personally, you will be completely equipped to solve your own problem, because you have already seen that error.

That is so much in software development. It’s not like, “Oh, I’m going to be the hot shot doing this new thing.” It could be like, "No. You’re going to go into a job some day, and your team’s Slack, or whatever you use, all day long. And you’re going to be, “Why am I getting this weird error? Our documentation says this; our past iterations say that. Why does this certainly do that?”

Really turning a beginner’s head and saying, “No. You think that being an awesome programmer means you’re going to write lots of code that’s going to do what it’s supposed to the first time.” When in fact, what you just saw with your first program that was all a four-line model, blowing up; that is what you’re going to see most of the time when you’re developing software. And it’s about developing, the detective/coping skills to handle that, that really is so much of the job of just becoming a developer. Like, can you use an error message to pull yourself out of whatever hole it is that you wound up in?

So, Karl, how can people follow you?

I’m on Twitter @StolleyDotDev

That’s right. And I just learned the other day that it’s more accessible if you have a multi-word Twitter handle like that. Presumably even for a first and last name to do intercap style capitalization. I love my lowercase handle, but apparently, assistive technology now knows to break intercap words at the capital letter. So, I recently changed it to SDT. So, that’s the best way to get hold of me. I blog.

You blog where?

I blog mostly on Medium, or I’m also on my website, which is stolley.dev, with a true dot, not D-O-T.

If people wanted to meet up with you in person. How could they do that?

I spread my life between both Chicago, Illinois and Grand Rapids, Michigan, where my wife lives much of the time and works. So, I’m always down to meet up for a coffee, or something like that. In terms of conferences I go to, that’s changing a little bit now in my life as a former academic, but I’m still…Like I spoke in October at the RTC Conference in Chicago. And there’s a few ACM conferences here and there that I go to.

And do you ever give talks at rhetoric conferences?

No. That part of my career has been over for probably about a good eight years now. I wasn’t able to do the things that I wanted to do in rhetoric for an audience of rhetoric people. So I don’t go to rhetoric conferences anymore.

I just think it would be hilarious for you to be doing rhetoric at a rhetoric conference, where the point is to experience rhetoric as a rhetorician.

Right. Yeah. I mean, that’s a whole other conversation that’s going on there.

I now know how to spell epideictic, however. Thank you so much for your time!

Another fantastic spotlight, and I think that’s one of the best explanations of WebRTC I’ve seen to date!

I have some questions for you Karl!

• Other than video chat, where else do you think WebRTC is currently commonly being used? And where do you think it may end up getting used more in future?

• What other radical web or browser-based tech do you think we’ll see in future?

Thanks for writing the book, we should definitely do a book club for it one day! For anyone interested, here’s the original thread for the book: Programming WebRTC (PragProg)

I now know that such a word exists, never mind spell it All the rhetoric about rhetoric cracked me up as well

Thanks so much, Aston!

I think it’s still pretty early days for WebRTC. Streaming video is a compelling feature that’s seeing wide adoption, for sure, but I suspect that we’ll see more use of audio-only WebRTC as well (especially since historically there’s overlap between WebRTC and VoIP). I think there’s a good case for seeing more embedded systems, such as using WebRTC to control drones (really!), and other cases where super-low latency is a must.

In that spirit, one of the browser-based technologies I’m keeping an eye on is WebTransport, another Web API in development in conjunction with the WebTransport over HTTP/3 spec at the IETF. In ways that mirror or echo WebRTC, WebTransport supports bi-directional, low-latency streams. It’s still pretty early days for the technology, but it’s definitely one to watch.