The Stack Overflow Podcast

Teaching developers about the most lightweight web “framework” around, VanillaJS

Episode Summary

We chat with Chris Ferdinandi, affectionately known as the VanillaJS guy. He has a newsletter, podcast, eBooks, and courses all trying to teach people to use more resilient and simple browser-native JavaScript free of the complications that come from elaborate frameworks.

Episode Notes

What exactly is VanillaJS? Tongue-in-cheek, it's the most lightweight JavaScript framework out there and used by pretty much every website on the internet. Seriously though, it's just JavaScript…without a framework. 

If you're interested in reading and learning more about JavaScript, Chris has a bevy of courses and eBooks over at

Like Chris's ideas so much you want to subscribe to his newsletter? Right over this way!

Since you are a connoisseur of podcasts, check out Chris's own at

Chris has kindly put together a collection of resources for listeners like you at

This week’s Lifeboat badge goes to prograils for their answer to How can I read the number of lines in Fortran 90 from a text file?


Episode Transcription

Chris Ferdinandi There is no thing I've learned that is too small not to teach, even if it seems like something that's really basic and has been covered a million times. If you learned it, and you kind of like think about it in a way that makes sense for you. There's probably someone else out there who's going to benefit from that.

[intro music]

Cassidy Williams Hello everybody, welcome to the Stack Overflow Podcast. My name is Cassidy Williams, and I'm here with my lovely co-hosts, Ceora and Ryan Donovan. And we have a wonderful guest today, Chris Ferdinandi. How are you today, Chris?

CFe I'm doing great. Thanks so much for having me.

CW We are excited to have you. And we also would love for you to introduce yourself because you do a lot of awesome things. I've known you from like the CSS tricks community, I would love it if you could tell us a little bit more about yourself.

CFe Yeah, so I'm, um, I'm known on the web as the Vanilla JS Guy. I didn't invent the term Vanilla JS, but I spend a good chunk of my time evangelizing using more browser native kind of stuff, and maybe building things in a way that's a little bit more simple and resilient. So I have a JavaScript newsletter that comes out every weekday over at I also put out a bunch of ebooks and courses over at Run a podcast at, you're probably sensing a trend here. I run some workshops, just a whole bunch of like, educational stuff around using more of what the browser gives you out of the box.

CW So you don't have free time is what I'm hearing.

CFe I don't, no, I wish I did. No, that's not entirely true. I have some free time. Not as much as I'd like. But we'll get there. 

Ryan Donovan Since you're you're big Vanilla JS guy, do you think frameworks are unnecessary?

CFe No. Well, let me caveat that. I think they are overused. I also think they have their place. I think a lot of times as an industry, we tend to reach for a handful of really large, I'll call them multipurpose tools. So we go for like the Reacts and Views, which are kind of like the kitchen sink libraries. And a lot of times, tools that do similar things, but maybe are a little bit narrower in focus may actually be better choices for the things that we're building. I also just kind of high level, think that a lot of these tools serve an important job in paving the cow paths for the things that eventually become browser native. We saw this happen with jQuery, where jQuery solved a lot of real problems that we had as developers, and then eventually got eclipsed by stuff that the browser gives you out of the box. But people continue to use it for a really long time afterwards anyways, just out of habit.

Ceora Ford I want to like rewind a little bit. And I want to hear what got you into developer education and teaching JavaScript in the first place. I'm always interested in like, what was that like aha moment for everyone who does developer education as their thing.

CFe So for me, it was I'm sucking at JavaScript really bad and bombing a bunch of interviews for like a really long time. I started my professional life as a human resources guy. And I was in just kind of like general purpose HR for a while, and then eventually training and development. But I had a lot of really strong opinions about things I didn't like about HR and what I wanted to see done better there. So I started blogging about it, as all millennials with strong opinions do. I had a WordPress blog, and I really wanted to have more control over how it looked. So I started hacking my way through like PHP, and CSS, and HTML, largely with the help of Chris Coyier and CSS-Tricks and some of his stuff. And the more I did it, the more I was like, oh, this is really cool. Like, I want to do more of this. So I started doing more and more of that in my day job and eventually decided I want it to be my actual day job. And I went on a bunch of interviews, I applied for a bunch of jobs. At the time, I was specifically teaching engineers career development stuff. So I took a bunch of the things I was teaching them and I was like, alright, let me use this and try and get into development. And for like, the first year, I bombed every single interview I went on, as soon as they started talking about JavaScript stuff. It was one of these weird things where like, I wasn't designer enough for the design jobs, and I wasn't developer enough for the developer jobs. I was in that weird in between space that is a very legitimate career now, but like a decade ago, wasn't. And so out of necessity, I begrudgingly started learning JavaScript. And he was way harder than it should have been. Because most of the tutorials kind of started from this place of you know, a bunch of things already. I found that really frustrating. So after I somehow figured some of this stuff out, mostly honestly, by taking like jQuery things, because jQuery has amazing documentation, and reverse engineering them into like, browser native JavaScript. I was like, alright, let me write about this. So if someone else like needs to figure this out, it's there. And it kind of took off from there. Like the articles on how to do jQuery thing without jQuery were getting more traffic than anything else on my site. And after a while, I was like, Oh, maybe I should like really Just focus on that, because nobody cares about any of my like musings on the new Pixar movie, but they seem to really like this JavaScript stuff. And so it just kind of took off from there.

CF How did you kind of find your teaching style? Or what you believe is, I like to always hear too what people think is makes good developer educational content? Is that something that you just naturally were good at? Or is it something that, you know, as someone who struggled with learning JavaScript, do you just do this is what I wish I had when I was learning? Yeah, I want to hear more about that.

CFe So it probably involves a level of self awareness that I'm not entirely sure I have. But I have been told by people that I have a knack for explaining complicated things in a way that feels not complicated. And I imagine a lot of that is me grossly over simplifying a lot of things when I explained them just to make it a little bit more palatable. I don't know if it was a learn style, or something I just kind of innately am able to do, but I feel really strongly that my teaching style is not inherently like the best teaching style, it's just the best teaching style for a certain type of person who learns the same way that I do. And, you know, like, there are a lot of really great educators in this space, who all have very different ways of approaching the same thing. But for me, my approach is, like, break things down into their smallest components. Don't assume anybody knows anything about it ahead of time. And, like, one of the things I just I found about myself is I learned best when I'm able to go from, there's this thing I want to do to Oh, wow, I made a thing that works as quickly as possible. So I like to get people from kind of concept to you made a thing and it works as fast as possible. And so when I talk to people, like one of the things I've noticed, just like a lot of beginners get really hung up on is, what tool should I start with? Or what should I learn first, or what's the right way to learn how to code and I don't think there is one one of the things I've found is like different people like some people really like they find View or React way easier to get started with than the browser native stuff. Some people find the exact opposite. Some people find jQuery easier. And especially when you're in that beginner phase, I don't really think it matters, you can kind of back your way into the other stuff, whatever kind of place you start in. Yeah, I think whatever kind of gets you gets you going, gives you that like that learning inertia is the most important part. I totally deviated from the question you were asking. I am really sorry.

CF You're all good. You're all good. I just was thinking too, I feel like this is one of the reasons why like some people when they want to get started with like creating content, writing ebooks, whatever. Yeah, they're always like, oh, well, there's so much out there already. I don't want to, you know, repeat what everyone else has already said. And I think you made a really good point about how like, each person has a different perspective and a different teaching style, that there's someone out there who resonates with you better than anyone else, or better than most other people. So I think that's like why you should still do it, right? Because the way I teach the way Cassie teaches, the way Ryan teaches the way Chris teaches, is all different. And there are people who probably would learn best from each one of us, you know?

CFe Yeah, well, you know, the other thing too, you brought up a handful of things I'd love to kind of unpack but like, so I have students who have taken both my stuff and like say Wes Bos' stuff, right. And we cover a lot of the same topics. But we have really different approaches to the same material, like Wes tends to be really animated and exciting. And he's very video focused. And I'm much more like written and I'm not going to go off in a bunch of different directions. I really, really like to kind of like narrow in on one thing. And I have some students who like my stuff more than Wes', I have some stuff who like Wes' and stuff more than mine. I have some people who like both of our things at different times in their learning arc, depending on kind of are they just getting started? Or are they looking to dig a little bit deeper. And you're also going to have a bunch of people who haven't heard of person you think is a big name in the industry, and they'll stumble upon your thing, and it'll be really helpful. And so, you know, along those lines, one of the things that really kind of helped me get going was, there is no thing I've learned that is too small not to teach, even if it seems like something that's really basic and has been covered a million times, if you learned it and you kind of like think about it in a way that makes sense for you, there's probably someone else out there who's going to benefit from that. I'm a really big proponent of teaching what you learn, if for no other reason than it will probably help you learn it better. I found for me the kind of the biggest like aha moments in learning something new as a developer come from when I try to teach it because it forces me to really understand how it works so that I can explain it in the most plain way possible.

CF I have literally built a career off of it.

CW There have been times where I've like tried to look up a problem that I have and I find my own question on Stack Overflow. I'm just like, oh, well, here we are! And we have an answer.

CFe Yeah. That's always amazing. When you Google something and find yourself, I love it. 

CW It's memory now.

CF So one thing I've been thinking about a lot, I'm still pretty early on in my career. So I think like my whole thing has been, I'm still a beginner. So I really understand the perspective of people who are new and don't know what's going on. So that helps me to teach things to them better. And I think if you can teach beginners, you can teach anybody. But one thing that I keep hearing is that over time, you start to lose that, the more expertise you gain with a certain technology, you start to miss out on like the nuance that, you know that beginners don't know. And so I've been thinking about this a lot. It's like me jumping ahead, like five years. I always wonder what am I going to do when I get to that point where like, I'm an expert in Graph QL, or JavaScript now, not an expert, but like, know, a lot more than beginners do. And so you start to have blind spots about like, what beginners do and don't understand. So if you have any tips, as far as like getting over that I literally was thinking about sending out a tweet asking people like later on today about that, because it's something I think about a lot.

CFe So there's an official name for that, too. It's called the experts dilemma, where you totally forget what it's like to be in that beginner spot. So the trick is to never get good at anything, and then you'll never have to worry about that.

CW Wow, I'm on the right track!

RD Maybe that's the one lesson!

CFe Barring that, one of the things I've found, honestly, helps me is I have not tried to aggressively like level up. My, this is the wrong way to phrase this. It makes it sound like I'm not trying to teach my students but like, I have never tried to up shift into like, okay, I'm working with like expert developers now. I am constantly interacting with folks who are kind of that early career coming in from design or just coming in, like brand new to development. And so it doesn't completely insulate you from that. But I find that the more I interact with people who are early career, the more it keeps kind of those assumptions in check for me, because if I say something that is kind of that like, oh, I've internalized this so much, I forget that all people don't know it, there's a really good chance someone is going to be like, what the heck is that? And then I can back up and be like, oh, yeah, let me explain that. Sorry. And so interacting with early career developers a lot, whether it's mentoring or like my case, I have a Slack community where I'm constantly chatting with folks and getting asked questions about things, is really, really helpful. You know, if you don't have access to those kinds of things, obviously, like, answering questions on Stack Overflow and seeing the kinds of things people are talking about is really helpful. But for me, you know, this may not work for everybody. But for me, it's honestly just been having a lot of conversations with people who aren't in that same career space as me has been the most helpful. They keep me honest.

RD I've gotten to interact with a lot of like, architects and people who are expert at things. And it's exactly right. Like, they don't know how to talk about things in a way that unless you're an expert, you understand. And that is the hardest thing with them is getting them to explain it. They're like, but surely you should just know this.

CW What's been kind of fun is my mom specifically, she really likes to watch my conference talks and podcasts and things. It's fun. But then she's like, I have no idea what you're saying. Could you explain this. And so my mom can explain what an API is, even though she is not technical at all. And that has honestly helped me a ton. Because there are certain things where I've had to completely simplify it at the core, and then kind of add on a little bit because she does not want to learn how to code but she wants to know what I'm doing. And I do think having non technical people in your life helps a lot in that regard.

RD One of the hardest things for technical people to grasp is the sort of metaphor and abstraction of it. Because it's all metaphor and abstraction at some point. Like getting them to understand that an API is a piece of text that you write out that produces data for you. That's not how you think about it. Like this is fetching data, it's how I you know, store my data information.

CF What's been interesting for me is having to explain to people as like an Apollo GraphQL developer advocate having to explain like, what GraphQL is, and what Apollo does to family members and stuff like that, who like have no idea what anything is, as far as like coding or anything. It's been really interesting. I don't know if my explanation is there yet, but I always consider it a win when I explaining something that's like complex to someone who has like, no idea what anything is, like, you know, NFTs and crypto and all that kind of stuff is relatively popular now. And I've had a lot of my non-tech friends be like, oh, well, you know, I figured you know, NFTs are, can you explain it to me? And I'm like, ehhh. I've had that conversation like six times now. I've gotten to the point where like, I can simplify it enough to help them understand kind of what's going on, even though I don't know if I really understand what's going on. But that makes me feel good whenever like, you know, or I'm talking to my grandma or something like that. And she's like, oh, what are you doing for work? And I explain what GraphQL is and she's like, oh, that kind of makes sense. And it's like, yeah, that's a win in my book.

CFe Yeah, the what is an API conversation happens almost every time I talked to my dad about work. I don't know why APIs are specifically the thing that comes up. 

CF It's almost like the the whole learning concept of like, explain it to me like I'm five, right? If you can explain something to it like a child in a way that's understandable. It's like, you must really know what she's talking about. Because sometimes I think, you know, we use these terms, and then we're like, someone will ask her what does that mean? It's like, I don't really know. So it forces you to dig deeper on that too.

RD I had a question, Chris, related this, when you're explaining to brand new coders, what is the sort of foundational information you start with?

CFe Yeah, that's a great question. Actually, I've been thinking about this a lot. Because I'm thinking, I almost need to, like back it up even more than I currently do. But I presume that my students know what a tag at this point, know what a text editor is, and know how to load JavaScript into like, an HTML file or browser. And then I kind of pick up from there. So a lot of my like, early, kind of foundational or essential kind of stuff starts with like, okay, here's how you get an element. So I'm assuming they already know, HTML, I guess, is really, really the takeaway here, you know. So I start with like, here's how you get an element from the DOM, here's how you might add or remove a class or like, set or get an attribute. And then we kind of build up from there. Not all of my programs are like that. But my foundational, like courses and things like that. That's the starting point. And I've been thinking that I probably would like to create something that backs it up even further and talks about maybe some of the stuff that I take for granted, like, here's what a text editor is, here's how you load a file into a browser, that kind of stuff. That's definitely missing from my curriculum that I rely on maybe some other other resources for folks to come in with that. So far, it hasn't been problematic. But I can imagine at some point, it might be.

CF I always think about where do we draw the line with, like, assume no prior knowledge. Because if you really assume no prior knowledge, your article or your lesson, or whatever would be super long.

CW Incredibly long.

CFe I kind of want to have like a free, if you've never done anything related to web development at all, like start here kind of thing, so that the people who then hit my JavaScript courses have kind of that bare minimum foundational knowledge. But I'm not having to reteach it over and over again. But up to this point, I've relied on the fact that there are a lot of really great resources out there that teach some of that stuff already. Yeah, that is a really good point, though, right? Like, where do you draw the line? I think it probably varies from person to person. And depending on who your audience is, or who you're trying to, like, talk to.

RD Yeah, I think with any sort of developer content you're putting out there, you need to have some sort of baseline assumed knowledge, like on the blog, we have to assume that everybody has some programming ability. We can't say, you know, when you're programming, here's what debugging is. And it's like, everybody knows this already.

CW Well, speaking of drawing the line, I'm going to draw the line at the end of this podcast.


CW Chris, thank you so much. I'd love to give a lifeboat. A lifeboat is a question on StackOverflow that has an answer score of 20 or more to a question score of negative three or less, and it goes on to receive a score of three or more. And so the question is 'How to read number of lines in a Fortran from a text file.' I did not know people were still using Fortran. But hey, that is the top one and we'll share it in the show notes. I've been Cassidy Williams, you can find me @cassidoo on most things.

RD I'm Ryan Donovan. I'm the editor of the blog and the newsletter here at Stack Overflow. You can find me on Twitter @RThorDonovan. And if you have a great idea for a blog post, please email me at

CF And I'm Ceora Ford. I'm a developer advocate at Apollo GraphQL. And you can find me on Twitter, my username there is @ceeoreo_.

CFe And I'm Chris Ferdinandi, you can find me at And if you enjoyed our chat, will have a bunch of resources related to this conversation.

CW Nice! Got that redirect going.

[outro music]