[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host Saron, and today we’re talking about Vanilla JavaScript with Christ Ferdinandi, Author of the Vanilla JS Pocket Guide Series and Creator of the Vanilla JS Academy Training Program.

[00:00:23] CF: For me, the web is a bit of a bloated mess right now and the front end build process is really complicated. I think we’ve really over-engineered what we do in a lot of ways.

[00:00:32] SY: Chris talks about how he went from HR professional to JavaScript expert, the pros of getting rid of all that tooling and learning good old-fashioned Vanilla JavaScript and why this is relevant, not only from a personal perspective, but from a public safety perspective as well after this.

[00:00:57] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. It also lets you use the most popular open source languages to build web apps. Also, you’re locked in to the service. So why not start building your apps today with Heroku?

[00:01:20] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. The TwilioQuest Program was created in secret to train an elite group of leaders to combat a shadowy organization known only as the Legacy Systems. Take up the tools, the software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:48] DigitalOcean offers the simplest, most developer friendly cloud platform. It’s optimized to make managing and scaling apps easy with an intuitive API, multiple storage options, integrated firewalls, load balancers, and more. Get started on DigitalOcean for free with the free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:02:13] When you need to focus on building, do you want to get bogged down by your database? MongoDB is an intuitive, flexible document database that lets you get to building. Mongo DB’s document model is a natural way to represent data so you can focus on what matters. MongoDB Atlas is the best way to use MongoDB. It’s a global cloud database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.

[00:02:49] SY: Thank you so much for being here.

[00:02:51] CF: Thanks for having me. I’m really glad to be on.

[00:02:53] SY: So let’s start by hearing more about your coding journey. How did you get into coding?

[00:02:57] CF: In a very roundabout way actually. So I’m a little bit like a bit of a Winnie-the-Pooh. I just kind of drift from things that interest me. I know a lot of folks like to have a plan of how they’re going to get from A to B, but that was never me. I cycled through, I took about five or six majors in college before settling in on anthropology, and senior year in college, I realized that as much as I loved learning about this stuff, I had no interest in actually doing it professionally and kind of by happenstance found myself working in human resources as like an HR professional for a little while. I had a lot of really strong opinions about what HR was doing poorly and how I’d like to see things change just as a profession. And so I started blogging about it and I really wanted to have more control over the look and feel of how my WordPress blog looked and things that it did. So I started kind of hacking around with CSS and HTML and PHP. I eventually became known as the HR guy who knows technology within the company I was working at. And on a weird lark, my boss and I, I was in the training organization at the time and we were experimenting with some interesting ways to teach people that wasn’t putting butts in a classroom and talking to people for eight hours, we had come up with this app idea that was going to cost like half a million dollars to have a prototype built with an agency. The internal IT team didn’t really have the resources to tackle it at the time. And he’s like, “Oh, you know some code, can you build it?” And the honest answer was no, but he’s like, “Well, can you learn?” And so I spent like two weeks just diving into the bowels of stack overflow, and I cobbled together the worst code I’ve ever written in my entire life. But by the end of it, it worked. And at that moment I was hooked. I knew that I didn’t want to do HR anymore. All I wanted to do was web development. It was so thrilling. And that was the beginning of the end of HR for me and the start of this new code journey.

[00:04:49] SY: So what did you build?

[00:04:51] CF: It seems so mundane at the time, but what we were trying to do was we’re calling it like micro learning or we’re like just-in-time learning, but we wanted to put together a library of video resources where people could just go and if they wanted to learn just like 5 or 10 minutes about X and then get on with their day a place for them to go do that sorted by various topics. I hate to use the term soft skills, but these were more things like communication and career development and stuff like that and not hard technical skills. And so it ended up just being like a really simple video player, which in retrospect might've been just easier to use YouTube or something like that, but at the time, security and all that. Yeah. It was just kind of a really wild thing. We ended up building another thing with a similar kind of approach that was like a scavenger hunt app for new hires to help them learn more about the company by running around our many buildings and finding cool stuff.

[00:05:43] SY: Fun.

[00:05:44] CF: Yeah, between those two projects, like that was it for me.

[00:05:46] SY: Yeah.

[00:05:46] CF: And then it took me I want to say a little over two years to go from I’m an HR person who’s been hacking around with code for three years to I’m actually working in this industry. It took a really long time to make the jump.

[00:06:01] SY: So before we get into that, what did you build that app in?

[00:06:04] CF: So it was built on top of WordPress. It was one of those like the devil kind of things. So it was WordPress with some just kind of custom HTML and CSS sprinkled in, but it had, I think at the time, no JavaScript in it. I resisted JavaScript for a long time. It’s really interesting that that’s my primary focus now because I was very much hesitant to get involved with JavaScript for a good while.

[00:06:26] SY: Why?

[00:06:27] CF: Imposter syndrome. So as a person who went through many majors in college and had a background in human resources and no computer science degree, I just assumed that all developers have CS degrees, and I was this like weird fraud trying to break into the industry. So JavaScript always felt like way more like scripty and intense then I wanted to get involved in, and to be frank, I was just really intimidated by it, especially given how many like answers to questions start off with just and then like a whole bunch of stuff that read like a foreign language to me, and so I steered clear of it for a long time. The only reason I ended up learning it in the first place was because I could not find a job without it. Every job description I saw wanted either someone with way more design experience than I had or someone with JavaScript experience, and I really wanted to be a web designer for a while and I have no natural talent at it. So it was out of necessity really. Once I started learning JavaScript, I found a lot more doors opened up for me. I think today things might be a little bit different. I think CSS is such an amazingly powerful language. It gets a lot more respect now than it did five or six years ago, not as much as it deserves, but…

[00:07:37] SY: It’s getting there.

[00:07:37] CF: It’s getting there. We’re on our way. But at the time, JavaScript was, for me, a way to actually break into the industry.

[00:07:43] SY: So you said that it took you two years from the moment that you built that HR app to actually working in technology, which I don’t think is necessarily a long time. I think it’s relative. People spend years doing it. Some people do it in a matter of six months, which is, mind blowing and incredible. What were you doing during those two years? What did you spend your time on?

[00:08:01] CF: I spent maybe the first eight months trying to find a role in the company I was currently in. I kind of knew the culture there. I had a reputation as the HR guy who knows tech, so I thought it was going to be maybe a more easy thing to get into. I had already had some kind of front end web experience, not with JavaScript, but with the HTML and CSS side of things already going back a couple of years with both my blog and then doing some like animal rescue stuff. So a lot of it was just networking. I think the most important thing I did, even though I didn’t end up finding a role internally was I just spent a lot of time talking to people in the roles that I knew I eventually wanted to move into, asking them what a day in the life was like, the kinds of skills they felt were critical for them to kind of get to where they are today, how they saw the industry changing over the next few years. That really gave me a lot of direction around the kinds of things I should be focusing on and where I should be maybe turning my attention. Eventually after going on a series of really failed interviews where they would start to get into some like JavaScript questions and I would just like freeze up, I decided that I needed to take some time to actually learn JavaScript, which for me started by messing around with jQuery then going on more interviews and getting asked about some fundamental underlying questions of like why I did what I did in jQuery or how certain stuff worked, and I realized I had no idea what was happening under the hood, and that’s when I dove head first into the VanillaJS part of my journey.

[00:09:30] SY: So it’s interesting because you started doing interviews and it sounded like maybe it was a little early in the journey for that, and then it didn’t go well. You paused. You went back to learning and then you try it again.

[00:09:42] CF: Yeah. Yeah. That would be a really fair way to describe it. I always kind of had an eye out for job openings and things like that. But yeah, there were a lot of false starts. One of the questions I get asked a lot by my students is like, “How do you know when you’re ready to actually start applying for jobs?” And I think for me, it’s important to start applying and trying to go on interviews before you actually feel you’re ready because one of the things I found is a lot of people sell their own skill short or they overestimate how good other people applying for these jobs actually are.

[00:10:15] SY: That is true.

[00:10:16] CF: And so you may actually be more qualified than you realize. My background in HR gives me a little bit of an interesting perspective on this, but like a lot of times recruiters just throw a bunch of things at a job description to see what sticks. And so there will be skills in there that are either impossible for someone to have, like five years of experience in a framework that came out three years ago or something like that or things that most of the applicants they get aren’t going to have. And then I think the more important thing is when you go on job interviews, even if you completely bombed them, you learn things about yourself and areas of your skillset that maybe need to get shored up. So like for me, it became really apparent really quickly that I needed to get over my fear of JavaScript because it was the only way I was going to get hired at the time for the kinds of roles I was going for.

[00:11:07] SY: I love that piece of advice because I think it helps you manage your expectations as well. If you go into something knowing that you’re not quite ready to interview and you get rejected, you’re in a much better emotional state to kind of deal with that. You know what I mean? Like it’s not going to feel like a huge blow because, hey, you weren’t ready anyway. And I think you’re much more open to taking that feedback, taking those lessons learned, do what you did, which is go back, spend some time learning, try again. So I love that idea of applying, maybe just short of when you think you’re ready for it.

[00:11:41] CF: Yeah. The other thing too is interviewing is really hard. It’s not a skill that I think most people are naturally good at. And those first few interviews you go on, like even if you’re ready, you’re not going to be really well-versed at your first few interview even if you do the like practice with a friend or interview yourself in a mirror thing, like it’s very different to be in front of a hiring manager or recruiter or your potential teammates talking about yourself. So it’s good to get those first few really terrible interviews out of the way when you feel like you’re not actually…

[00:12:12] SY: Get them out of the way. Yeah.

[00:12:14] CF: Yeah. By the time you really are like ready in there, you’re an interview pro or an interview, say, intermediate, farm league, and you’re much better positioned than you would have been if you were just starting this.

[00:12:25] SY: So it sounds like you had a fairly productive two years and it sounds like you had a plan and you were learning and moving and growing. Did you ever have any moments of frustration as you were teaching yourself as you were trying to get that first job?

[00:12:38] CF: There were definitely some, I’ll call them dips, I guess. The advantage I had, it feels a little unfair, but within HR specifically, my big focus was on career development in a tech company, teaching engineers how to grow their career.

[00:12:54] SY: That’s great.

[00:12:55] CF: So I was able to take everything I had been teaching them and just kind of leverage it on myself. So I maybe have a bit of an unfair advantage here, but I had tried to learn JavaScript a couple of times by going through like some of the free like learn to code things that were on the internet at the time. There’s a much better ecosystem now than there was back then. But you know, it was things like make an alert window pop up, add multiple numbers together. It was one of those like I’d go to learn it and it’d be boring, and then they’d throw a bigger problem at you and I wouldn’t know how to connect the pieces. So I was really starting to feel like I just didn’t have a brain for development, didn’t have a brain for design. I was like, “Maybe I don’t belong here.” For a while. That first year I was like just rejection after rejection, bombed interviews. I was starting to think this just wasn’t for me.

[00:13:40] SY: So you mentioned these dips. How did you get through these dips?

[00:13:44] CF: I think for me, the thing that really drove me to keep going, even though I was feeling particularly frustrated, was just being frank I was just done with HR. I had hit a point where kind of the career I was in just didn’t align with the kind of stuff I wanted to be doing anymore. And even though I was kind of going through this like I don’t really know kind of phase, like the most exciting stuff about my day job was when I got to do more coding stuff in my HR role and I was like, “No, this is so much more exciting. I’m done with HR.” So that’s really what kind of pushed me to keep going even when I was feeling like maybe I wanted to give up.

[00:14:25] SY: What are some of the tools and resources you use during those two years?

[00:14:30] CF: There were a few things. Stack Overflow helped a bit. It’s interesting. There’s a lot of like really kind of passive aggressive stuff on Stack Overflow, but there are also some really awesome people who are willing to jump in, like I had been banging my head against a wall for two days trying to work through this problem, and finally after like not finding anything that was working, I posted a question there and within 15 minutes someone who gotten back to me with like a really simple thing I had messed up and that was amazing.

[00:14:57] SY: Nice.

[00:14:57] CF: I think just kind of like big picture. The web development community certainly has some issues, but it is my absolute favorite thing about this profession. There are people that I looked up to as really big deals in this space that I emailed and I said, “Hey, I’m trying to break into web development. Can I just pick your brain for like 15, 20 minutes like on a Skype chat about your career journey and like how to make it?” There were a ton of people who wrote really interesting articles on how to do stuff that I would have questions about or get stuck on or I’d email them and they would just be like, “Oh yeah, here, let me help you work through this problem.” It started to make me feel like maybe actually I did belong here even though I didn’t have a computer science degree. It was also where I learned that most front end developers don’t actually have one, and I wasn’t as weird of an outlier as I thought I was. There’s nothing wrong with having one. They’re great if you have one. Awesome. And they can certainly help open doors that wouldn’t otherwise, but they’re not necessary. And I was really shocked to learn how many folks that I look up to also taught themselves and fumbled their way into this industry.

[00:16:16] SY: TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Explore the Mysteries of the Pythonic Temple, the JavaScript Test Lab, and more all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud, download and play TwilioQuest for free at twilio.com/quest.

[00:16:41] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a Google cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service, so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.

[00:17:30] SY: So let’s switch gears and talk about Vanilla JavaScript, VanillaJS. How would you describe VanillaJS? What is it?

[00:17:37] CF: It’s just a catchall for using browser native JavaScript methods and browser APIs rather than using libraries, third-party frameworks, and things like that. I think the term actually started as a joke. There’s this like VanillaJS website that positions it as the hot new framework that comes in, which is zero kilobytes. For a while, every time you Google how to do X in JavaScript, you get answers for jQuery because that was like the really big thing at the time and then it became Backbone and then it became React and Angular and getting solutions that were just pure non-framework-y JavaScript was really hard to do. And so people started just using this term as a way to kind of say it’s not any of those things. Over the years, it’s kind of stuck and become this thing that more and more folks use. It still confuses a lot of people. So I feel bad about that. But it has become a really good way to filter out all the noise when you’re trying to search for solutions that don’t use any third party stuff.

[00:18:36]SY: So what is so important about learning Vanilla JavaScript? If I’m going to be using or if I guess my company uses React or Angular, Backbone or any of those, why not just use the JavaScript way of doing it in the framework? Why do I need to know JavaScript on its own?

[00:18:54]CF: So there’s a few reasons. If you already know and are really comfortable in React or Vue or Angular, awesome. But one of the things that I’ve found for a lot of beginners is like I have a lot of students who have come to me and they’ve tried to learn React. Let’s be honest. If you’re trying to find a job and you want to be super, super marketable, React is not a bad way to go. So many job descriptions are looking for it. But they get really kind of hung up on it or they get really good at copy paste, but when it comes time to go build something on your own, they get really stuck. And one of the things that I have really come to appreciate about Vanilla JavaScript is that even if you know you want to go dig into a framework, learning VanillaJS is going to help you pick that up faster. It’s going to help you write code better in that framework. And if you want to jump ship to another framework later or move on to another kind of tool, it’s much easier to kind of pick up because you kind of have this baseline of conventions that cut across all the different tools you might use. The other reason why I’m particularly passionate about it is, it’s a little bit controversial, but for me, the web is a bit of a bloated mess right now, and the front end build process is really complicated. I think we’ve really over engineered what we do in a lot of ways and Vanilla JavaScript is a way to cut through a lot of that, maybe simplify the way you make things, but also give the end user a potentially faster and more enjoyable experience with the things that you build.

[00:20:28] SY: How would you compare learning Vanilla JavaScript with learning JavaScript through React? What are the biggest differences between the two?

[00:20:39] CF: For starters, you can skip any sort of build steps. So in particular, if you’re learning React with the JSX kind of flavor of it, which is I think the most popular way to use it.

[00:20:49] SY: And what is JSX?

[00:20:50] CF: So JSX is a compiled language where you can author your HTML in a JavaScript-y kind of way, maybe a little bit more easily than you could do it in just straight up JavaScript and then you have to run it through some sort of parser or compiler that converts it into JavaScript proper that can run on a browser. It provides a simpler syntax for adding variables and things like that into templates, although there are some native JavaScript ways to do that just as easily now too. But at the time, it was kind of a nice advantage of React. But to a lot of the React tutorials involve opening up a terminal, installing some stuff with command line from NPM, and then before you can actually run the code you’re writing in a browser, you have to compile it. And those things aren’t inherently bad, but it adds a lot of extra complexity to someone who’s maybe just trying to get started whereas with Vanilla JavaScript, you can open a browser, open a text editor and just start going, like you could write everything in a single HTML file if you wanted, and that’s often how I teach my students because it just kind of removes all of the other stuff they have to worry about. For me, that’s really, just from a learning perspective, I think one of the bigger kinds of things is just all of the tooling can go away and you can just focus on the code that you’re trying to learn.

[00:22:08] SY: So for your students, do they generally have a preference of learning Vanilla JavaScript versus learning JavaScript through a framework? I’m wondering if other people or most people that you talk to have that resistance to JavaScript that you used to have.

[00:22:23] CF: Yeah, so the people who come to me usually come for a few different reasons, but they are almost always biased towards wanting to learn the fundamentals first or in addition to. So I get a lot of people who have been using jQuery for years and are kind of feeling like in this new world, they don’t actually understand how JavaScript itself works because jQuery makes it really easy to just work with the documentation and copy-paste some stuff, which again nothing wrong with that. That’s actually how I learned. I think you can back into the language that way and it’s awesome. I’m of the opinion that anything that gets you from, “I don’t know what I’m doing,” to, “Oh my God, I made something that works.” Faster is awesome because it keeps that momentum and excitement going, but I get a lot of folks like that. They want to understand the language they’ve been working in for a couple of years better. I also get a lot of people who want to learn frameworks, but just find it confusing, can’t wrap their head around it and feel like if they understood the fundamentals of JavaScript better, they could learn those frameworks better. And then I have a very passionate subset of my students are folks who have no interest in ever going into frameworks and just really like being able to take advantage of all the amazing stuff the browser can do for you out of the box today and just don’t feel the need to kind of go over there. And that’s certainly not all of my students, but it’s a good number of them.

[00:23:41] SY: Would you say learning Vanilla JavaScript is a good first step before learning a framework? Is it basically the prerequisite? Is it the foundation or do you feel like people should actually be using Vanilla JavaScript in production code?

[00:23:56] CF: So yes to both, which is cheating a little bit. So I think if you know you want to go into a framework, I think it’s important to learn Vanilla JavaScript first because I think it’ll make learning the framework easier and I think it’ll help you evaluate when to use certain things in the framework and when to use things with just Vanilla JavaScript. It’ll make that easier for you. I know a lot of folks were really deep into React and also know VanillaJS and tell me that one of the things they love most about React is that you can mix it with VanillaJS really easily, and there’s a lot of stuff that they just don’t need React for. They lean on VanillaJS more heavily, but I am a big advocate of using more VanillaJS production code and shedding the frameworks entirely.

[00:24:36] SY: Wow!

[00:24:36] CF: The pendulum I think is finally starting to swing back in my direction. I think we’ll maybe settle into a happy middle ground at some point, but from my perspective, and I’m not alone here, but I am part of maybe a vocal minority. We are overusing frameworks and not that they don’t have their place, but I think we tend to use them way too much for a lot of situations that they just either weren’t designed for or aren’t appropriate, and it’s resulting in a web that is slower, more fragile, more expensive for users to operate on, more prone to breaking. I shouldn’t say objectively because there are people who disagree with me, but from my perspective, it’s worse in many, many ways.

[00:25:15] SY: How do you know when it makes sense to use a framework and when it makes sense to just do Vanilla JavaScript?

[00:25:24] CF: This is an area where I think there’s a lot of debate, but for me, a framework is a tool of last resort. Not all frameworks, so when I think about the big ones, like Angular, React, Vue. These to me are tools that were built to solve a very specific problem, which is JavaScript at scale. The type of scale we’re talking about is like React was built by Facebook. It was built to solve the massive front end application and massive front end data set that they need to deal with. And we use it for all these things that are not really that level of scale. So React is 30 kilobytes minified and gzipped. So after lots of really heavy kind of compression, it’s 30 kilobytes of code. So the uncompressed version that the browser has to render and parse is much bigger than that. The reason it’s so big is because it has things in it, like the Virtual DOM that I know a lot of people get excited about because it can make front end performance better, but it can make front end performance better for really large datasets and UIs that have tons of elements in them and DOM nodes. Most of the things that most of the people I interact with build are not at that level of scale, and in many cases, the initial load performance of pulling down 30 kilobytes of JavaScript and having the browser have to manage that is actually worse for performance than the gains you get from using a framework. There are some smaller alternatives that do similar things. Like one of the nicest things about tools like React and Vue is they let you use state or data objects to generate user interfaces and there are lots of alternatives that are much smaller and have similar APIs. They ditch the Virtual DOM and they get loaded into the browser a lot faster. So things like Preact, which is kind of a Virtual DOM list version of React that has a similar API or hyperHTML. There’s a new kid on the block felt that gives you a React-like experience, but then compiles out into Vanilla JavaScript. I think these tools aren’t necessarily bad, but I feel like one of the things we do as an industry is we go for the multipurpose tool when all we really need is the fork or the scissors. We’re grabbing these tools that do a ton of things and most of those things we don’t need. We’re passing that cost onto the user for our own convenience. I get a lot of pushback on that one. Not everybody agrees with me.

[00:27:44] SY: Tell me about that. Tell me about the pushback. What do people usually say?

[00:27:47] CF: The biggest pieces of pushback I get is around my portrayal of 30 kilobytes of JavaScript is a lot. So the big argument here is you can jeez it. You can minify. Everybody has fast internet connections these days. The iPhone of today is not like the iPhone of five years ago. This really isn’t that big of a deal. I’ve sent hundreds of kilobytes of JavaScript down and it works really fast. And I think for us as web professionals, that can often be true. Certainly not always. There are plenty of really talented web developers in developing areas who don’t have really fast internet connections. The Nigerian web development scene, for example, there’s a lot of really talented folks there who are working with really terrible internet connections, but there are also people in kind of developed areas who do not have the types of internet connections that a lot of us as web professionals take for granted. Areas in the middle of the United States have really bad internet. They do not have broadband speeds. You might be on a mobile device where you’re in maybe an area with spotty reception. I’m on AT&T. When I go into Boston, that’s more of like a Verizon City. I get really terrible internet connection. The big buildings block the signal. It’s horrible. Sites that were built with these large amounts of JavaScript, they time out before the files load or they take minutes to load. It’s really painful. The other thing is modern iPhones are really, really fast. Most people do not have modern iPhones globally speaking and especially if you look at maybe the emerging internet, the next billion people who are coming online. They’re using lower power to Android devices that are really inexpensive and they do not handle JavaScript nearly as efficiently or elegantly as the devices that I, as a professional web developer, may use to access the web. So it’s really easy to throw this stuff off. It’s not a big deal when you have really fast internet and a powerful device, but a majority of the world is not like that, and it has really big implications to them.

[00:30:01] SY: Coming up next, Chris talks about the impact on business, coding with Vanilla JavaScript can have and what resources he recommends to get started after this. Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Also, make sure to check out their podcast, Code[ish], which explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

[00:30:51] With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predictable pricing to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with a free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:31:29] So it sounds like there are benefits to using Vanilla JavaScript as an individual developer, but it also sounds like it’s beneficial for companies to adopt Vanilla JavaScript as well.

[00:31:39] CF: The impact on business is really something that I should probably talk about more. You know, like people not being able to access your stuff is obviously a problem, especially if you’re in the ecommerce space, you run a business where you’re selling people things online, and there are some use cases around this. So last year, GitHub decided to remove jQuery from their application in favor of native browser methods and custom web components. They made a very deliberate decision not to move into like React or another framework and just use what the browser gives you out of the box. And their rationale around this was that it made their front end more resilient. They were able to build kind of some progressive enhancement on top of it, even if the JavaScript fails, a lot of the stuff that you want to do their work through like old school form submissions and things like that. Netflix did something similar where they had a client-side React-based application and they ripped React out of the front end for their initial views. They were still using it as a server side language, but they took it out for the front end. In doing so, they found that the loading time and time to interactive for Netflix.com decreased by 50 percent. So the site got twice as fast by ripping React out, which is kind of a big deal.

[00:32:49] SY: Wow! That is a huge deal. Oh my goodness. Very cool.

[00:32:52] CF: Similarly, MeetSpace is a video chat app that when they built their app, they decided very deliberately to just use Vanilla JavaScript. And as a result, they benefit from a client-side app that’s ready to use and just 200 milliseconds on a typical internet connection. So like a fifth of a second. It feels almost instantaneous. It’s really, really cool. But this also cuts the other way, like this can have really negative impacts. One of the articles I read late last year, it was by a woman named Stephanie Stimac who wrote about Location, Privilege, and Performant Websites. The long story short here is she had moved into a new home where it was going to be several weeks before she could get internet installed at her house. So she was working off of her phone and tethering and things like that, and she figured not a big deal, but what she didn’t account for her is she had moved into an area where her cell phone connection was kind of spotty. During a really severe storm, power got knocked out to her house and trees were blocking roads in and out of her home. And because the electricity company’s website was built with like a very large amount of JavaScript on her phone, which I think had like maybe one or two bars at the time, it was taking five minutes for the page where you would report a power outage to actually load. So even if she had had functional internet to her house, it wouldn’t work because the power was out. So she had to use her phone. And the tool that the company built to report these sorts of things would not load on her mobile device because of how heavy it was. And fortunately, within 24 hours it got fixed for her. But you could imagine in like some of these more severe storms and more remote areas where things can be down for days or weeks at a time, like this poses a serious safety risk if people can’t use the things you’re building. And she is a web professional with like top of the line equipment. So this wasn’t like some old school phone. This was like her modern iPhone. These things are important, both from a public safety perspective and from something like just if you’re running a business and you want more people to be able to use it. Performance matters and building things that work for more people matters.

[00:34:55] SY: So if folks listening are inspired to learn Vanilla JavaScript, what is the most important thing that they should keep in mind?

[00:35:02] CF: You don’t have to know everything right away. The area where I see people fall down most frequently when they’re trying to learn is, “I’m going to build a to-do app,” or some other like kind of big project. You can start small and work your way up and that’s totally cool. The other thing is it’s also totally cool to back into Vanilla JS. I have people who are like, “Look, jQuery is just easier for me to wrap my head around.” That’s great. You can make mental maps from like, “Oh, if you do this in jQuery, you do this in Vanilla JavaScript once you get comfortable,” and that’s totally cool. Keeping that like enthusiasm up about the web and learning is so much more important than the specific tools that get you there.

[00:35:41] SY: So what resources would you recommend for people who are interested in getting into Vanilla JavaScript?

[00:35:47] CF: There are a handful of really great things out there. Just a shameless plug, every weekday I publish a really short article on a VanillaJS topic. So if you’re really short on time…

[00:35:56] SY: Every weekday?

[00:35:57] CF: Every weekday. So five days a week.

[00:35:59] SY: So five times a week. Wow!

[00:35:59] CF: Five times a week.

[00:36:00] SY: That’s a lot of content.

[00:36:02] CF: It is, it is, and it’s worked out really well. But if you’re looking to like baby steps into this, that’s a good way to do it because they’re bite size. You can just read it quick while you drink some coffee in the morning or tea and then get on with your day. That’s maybe a good starting point. If you wanted to dive into this stuff a little bit more deeply, there’s so much great content out there. So shamelessly, I have some little eBooks and video courses that are, again, really short. They’re like an hour or less each. Wes Bos just put out a fantastic new Vanilla JavaScript course late last year. That is also worth checking out. And then I think honestly, the most important thing that you can do is maybe kind of try and fumble your way through a project. I have a list of project ideas and starter templates to get people going over at learnvanillajs.com. So if you’re kind of looking to just teach yourself and dive into some of this stuff, lots of ideas. They tell you the skills that that project will focus on. I’ll give you a template to get you going so you’re not starting completely from scratch. So that might be a useful resource for folks as well. And then there’s obviously a ton of really great articles. CodeNewbie is awesome, of course, and there are just so many amazing bloggers and articles out there. One thing I’ve put together specifically for CodeNewbie listeners is a lengthy list of other resources, if you want to dig into more of this stuff. So if you head over to gomakethings.com/codenewbie, all one word, just a laundry list of articles and other podcasts that you could listen to and things to check out around what we’ve been talking about today.

[00:37:38] SY: Wonderful. We’ll include that link and all those links actually on our show notes. So thank you for that. Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Chris, are you ready to fill in the blanks?

[00:37:54] CF: I am.

[00:37:55] SY: Number one, worst advice I’ve ever received is?

[00:37:58] CF: That you have to stick with a job for at least two years before looking for the next one.

[00:38:03] SY: Oh, interesting. Tell me about that. There’s this idea that kind of gets spread that if you leave a job before two years are up, it makes you look like a job hopper and it looks bad when you apply for your next one. And if you do that, like if you’re leaving your job every three months for like three or four jobs in a row, maybe. But what I’ve found is that sometimes it causes people to stick around in either toxic jobs or jobs that just aren’t a good fit. They seemed really good on paper and you went through the interview process and then you get there and you’re like, “Oh, this is very much not for me.” You’re almost better off cutting your losses and the company’s losses and quitting earlier because if they’re going to have to replace you in a year and change or two years anyways, it might be better for them to get someone new in there that they can train that’s going to stick around longer anyways. I think for me this really came to head. One of the first web development jobs I took, the commute in for the interviews was only like 40 minutes, and then when I started going during normal working hours, it turned out it was actually more like one and a half, two hours. So I was spending three hours in a car every day and it was just absolutely brutal. I had been told that work from home might be a possibility once I got settled in, and then every time I asked about it, they’re like, “Oh, actually no, we don’t do that here.” And so I really felt like I’d gotten bait and switched and conventional wisdom would tell me I’d have to slog with that for two years before looking. But I quit after I think like three months and the job I found after that was way, way, way better.

[00:39:26] SY: Good for you.

[00:39:26] CF: And it wouldn’t have happened if I decided to stick around for two years. Yeah. So that’s it for me. The worst advice.

[00:39:32] SY: Number two, best advice I’ve ever received is?

[00:39:36] CF: Network, network, network.

[00:39:38] SY: Yeah. I love this one. Tell me.

[00:39:39] CF: Every awesome career move I’ve ever made has happened because of someone that I know. If this is not one of those obnoxious, like you have to know the right people to get in kind of things, like you can network knowing no one. You can start from scratch and build your way up there. But I think a lot of times, like one of the really terrible things that happens about jobs that get posted online is the process for getting a job approved internally is sometimes so lengthy that by the time a job description hits the internet the person who’s hiring for that role has already started networking and kind of picking out a pool of candidates just from people they know. And by the time it shows up on the web, they already have like two or three people that are going to be in. And so knowing people can tip you off to roles like that before they get posted. It can help you kind of zero in on new opportunities or things you might not have heard about otherwise. And honestly, if you don’t know, like maybe you’re just kind of a team of one or you’re out by yourself and you’re not sure how to get started, one of the best things I’ve ever done here is I’ve reached out to people that I admired in the industry and said, “Hey, can I just pick your brain for 15 minutes? Or if you live near someone, can I buy you coffee?” It’s amazing how many people are willing to give you a little bit of their time just to talk about helping people get in their career.

[00:41:00] SY: Number three, my first coding project was about?

[00:41:04] CF: So my very first coding project was a personal blog about human resources and my first professional project was an animal rescue website.

[00:41:11] SY: Ooh, animal rescue. That sounds like fun.

[00:41:13] CF: Yeah. I didn’t talk about that much on this show and I probably should have, but I still work for them, Paws New England, pawsnewengland.com. We adopted a dog from them right when I was kind of starting to get into coding and their website looked very dated and I wanted to do more of this. So I offered to overhaul their website for them and I’ve been working with them ever since.

[00:41:31] SY: Wow!

[00:41:32] CF: So it’s been really cool.

[00:41:33] SY: That’s amazing.

[00:41:34] CF: Yeah. It was also a good way to get some professional experience when I was still trying to like start out.

[00:41:37] SY: Yeah. And with a very important cause.

[00:41:40] CF: Yeah.

[00:41:41] SY: Number four, one thing I wish I knew when I first started to code is?

[00:41:46] CF: That you don’t need a computer science degree to be a real programmer. And again, there’s nothing wrong with having one, but I felt like a total fraud for two years before realizing that all of the devs that I looked up to didn’t have one either. And if you want one, absolutely go get one. I know tons of great developers who have them, but I also know tons of great developers who don’t.

[00:42:05] SY: Absolutely. Well, thank you again, Chris, for joining us.

[00:42:08] CF: Thank you so much for having me. This is great.

[00:42:17] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.