S2:E5
[00:00:00] Todd Libby: Welcome to the Front End Nerdery Podcast, a podcast about front end development and design. I'm your host Todd Libby. My guest today is teacher creator of the VanillaJS Academy and Go Make Things and Pixar fanatic, like I am, Chris Ferdinandi, Chris, how are you doing today?
[00:00:18] Chris Ferdinandi: I'm doing great, Todd. Thanks so much. How are you?
[00:00:22] Todd: I'm well, thank you. So would you tell the listeners a little bit more about yourself.
[00:00:25] Chris: Yeah, absolutely. So, I, I help people learn, JavaScript specifically of the vanilla flavor. So, browser native, just kind of baked right into what comes with your computer. And a big part of what I do is focus on simpler and more resilient ways to make things for the web.
I really, just from my own experiences, like teaching myself JavaScript and then working with a lot of others, I've kind of come to the conclusion that a lot of what we do today is maybe a little bit more complicated and over-engineered than it needs to be. And so, I try and focus on, ways that we can do what we do, in, in an approach that's a bit more easy and sustainable.
[00:01:04] Todd: Great. So, let's jump right into the questions. So how did you get started in your development journey?
[00:01:12] Chris: Yeah, so, in a previous life, I was a human resources professional, which is about as exciting as it sounds. I was a Toby if you're a fan of The Office.
[00:01:30] Todd: Yep
[00:01:30] Chris: I, I kind of fell into that. I, I went through five or six majors in college. Eventually landed on anthropology cause it was really, really interesting. And then, at the start of my second senior year, I realized that as much as I love learning about this stuff, I had no interest in actually being an anthropologist when I got out of school. I'm kind of a homebody.
And so, the idea of traveling around the world and living in different places, seemed really exciting earlier in my college experience. And then by the time I got close to graduating, I was like, I kinda just want to like stay home. So, I, I fell into an internship in HR, liked it well enough to kind of keep doing it for a little while.
But I had a lot of really strong opinions about ways I didn't think HR was good or things that I thought, you know, could be done better. And so, I started blogging about it because none of my friends wanted to hear me talk about this stuff. And I really wanted to have more control over the look and feel of my blog, which was powered by WordPress at the time.
So, I did some Googling. I ended up on CSS tricks. Chris Coyer had, has this awesome now like 10 or 15 year old series of articles on, basically getting started with your own WordPress theme. And so, I took kind of the boiler plate theme there and started hacking my way through it. And then really, really like found it exciting.
I'm someone who has the name of my site, gomakethings.com would probably lead you to believe likes to make things. But I have no natural talent for working with my hands. I can't do woodworking or welding or anything like that. And so, programming is a way for me to kind of, I guess, like exercise that, that want.
And so, I started trying to bring more of this into my day job. I was at the time working in a career development capacity, and so I started kind of creating these little, like web things for people focused around career, career development internally at the company I was working at. And I eventually became known as the HR guy who knows tech.
Which is weird cause I was working in a technology company, and you think that would be a lot more of us. But it was not. And I eventually landed in the training and development organization. Where my boss at the time and I came up with this idea for a way to train people that was more like short little YouTube clips, and less like let's get a bunch of people in a room for eight hours and talk to them.
And that doesn't seem very revolutionary now because things like, you know, Udemy and Team Treehouse and stuff were kind of the norm. But at the time that was kind of a weird novel concept. And so, we came up with this prototype and we went to our IT department and we're like, hey, we'd like to like pilot this.
And they're like, cool, it'll cost you a hundred thousand dollars and it'll take a year to build. And it probably won't look like you want it to. I'm like, well, that's not going to work for a pilot. So, we went to an outside agency and they're like, yes, we can definitely do this. We'll have it ready in like six weeks, it'll cost half a million dollars.
And we're like, all right, that's not going to work either. So, my boss is like, hey, can you build it? You do stuff with computers. And I was like no, I definitely can't like, I don't know how to do that level of like back-end-y kind of stuff.
[00:04:17] Todd: Yes
[00:04:17] Chris: And he goes, well, can you learn? And that was literally the question that changed the whole course of my career.
I, I spent two weeks digging into the, like the deep bowels of Stack Overflow, trying to figure out how to hack WordPress into a semi-functional prototype of an app. And I don't know how I pulled it off. It is the ugliest code I ever wrote in my entire career, but it was functional enough that we were able to demo it to, some executives and stuff like that.
And that was the moment that I knew I had no interest in doing HR ever again, and I want it to be a, a programmer. And so, I spent the next two years trying to teach myself enough, like programming or coding that I could actually make this a viable career for myself and applying to a bunch of jobs and failing interviews over and over again.
But that was really kind of the start of the whole thing for me. And it, it was a, just a random series of, you know, kind of a happy little accidents and having a manager who asked me the right question at the right time.
[00:05:13] Todd: Yeah, definitely. That's, you know, that's a great way to get in, get your feet wet for sure. That's you know, I, I, I didn't start with WordPress, but when I started using WordPress, so when it was before, before it was known as WordPress, when it was B2/Cafelog, before Matt forked it and then made all these billions of dollars, I use that for a little while and I was, I was picking it apart and trying to know how, you know, learning how to, how that worked and that's how I get to learn.
So, yeah, that's a, that's a great story. So, let's dive right into the big question.
[00:05:53] Chris: Absolutely.
[00:05:53] Todd: So, I've been bingeing podcasts lately. And you've been on a few of them that I've listened to. And I wanted to take the time to sit down with you and talk to you about what the hell are we doing to the web?
How are we making it worse? And over-engineering the hell out of it? Because
[00:06:14] Chris: Yes.
[00:06:14] Todd: that's what it seems like we're doing.
[00:06:17] Chris: Yeah. Yeah. So, the, the high level, we can rip this apart, but I'll just, I'll do my, like kind of my high level thesis or my like teal TLDR kind of version here. But, we have, I guess the one-liner is, we use JavaScript for everything, even when we shouldn’t.
The slightly bigger version of that is, we have somehow become convinced as an industry that, state-based UI libraries and JavaScript libraries in, in general are the, the one true approach for building everything. And these tools are incredible feats of engineering that serve a legitimate purpose in a narrow set of circumstances and absolutely wreak havoc on users and the people who build the things that people use in a whole myriad of other circumstances.
There's kind of this like false notion that. Like things like React and Vue, make building for the web easier. And sometimes that is the case for a specific subset of developers. But in many cases, they make the things you're building harder to build, to maintain. They make them worse for the users.
They make them more fragile. There are some new tools and techniques that can kind of mitigate some of those things, but they introduce even more complexity into the build process. And so, kind of, if you think about every decision you make, when you're building for the web as a series of trade-offs, you know, we are, I think we're making the wrong kind of trade-offs in a lot of situations, and we can unpack all that.
There is a lot of different ways to kind of come at this conversation. So, I'll defer to whatever you think makes the most sense, Todd. But,
[00:07:55] Todd: Yeah.
[00:07:55] Chris: but yeah, that's, that's kind of, it is, we're overusing JavaScript and, and it’s bad. And that's a weird thing to say as someone whose whole kind of career now is teaching people JavaScript.
[00:08:04] Todd: Yes, it is. But you know, I, you know, I've listened real closely to, when you've talked about this on other podcasts and I'm just sitting there shaking my head. Yes, yes. And, you know, we, you know, occasionally, you know, I, I pop into, your Slack and, you know, yes. Oh yes. There's that? I guess the first thing that I noticed being that it's been part of my main focus for over a couple of decades now is the accessibility side of things.
And when I see a span with, or a div with JavaScript in it for somebody trying to make use, trying to make it act like a button I cringe. And then I cry a little, you know, it's things like that. Things like, you know, it's not that it affects well, I, I guess I would defer to you telling me that a three gigabyte node modules folder that I need to take a second mortgage out.
So, I had, so it has its own home next to me, things like that, you know?
[00:09:23] Chris: Yeah.
[00:09:23] Todd: you know, I, and I know you, you know, you, I point people to a lot too on the accessibility side of that. You know of what we're talking about here. So, I guess let's start off with the accessibility side
[00:09:40] Chris: Yeah
[00:09:40] Todd: and what is the over-engineering doing to the web accessibility wise?
[00:09:45] Chris: Yeah. So, this one's kind of an interesting one. So, I have a lot of mixed feelings on this particular thing in particular. So, WebAim is an accessibility group that for the last few years has run an annual survey of the, or an audit of the top million sites on the web where they go and, they just throw them through one of those automated accessibility, audit tools to see what kind of errors get spit out.
The, the standard caveats here. They sometimes throw false flags where they say something's in error when it's not. More often, they miss a bunch of stuff that's in there that can't get easily detected by an automated tool. But the general trend they have found year after year is that sites that use JavaScript library.
JavaScript UI libraries specifically have more accessibility errors than sites that do not. Last year they saw an interesting switch in that trend in one particular area. And that was sites that use React have fewer accessibility errors than other state-based UI tools. And also, I think I'm not a hundred percent sure on this.
So, don't, don't hold me to this one, but I think even sites that don't use any state-based UI at all, and from my position, I think a big reason why that happened is I've seen React. And a lot of the folks in that community spend a lot more time focused on accessibility than they did in the past. So, when I think about just kind of this general trend of state-based UI libraries, more accessibility issues.
Using Vue or React doesn't just inherently cause you to write inaccessible code. You know, what you put in determines what kind of comes out when it renders that into HTML. I think the bigger issue with these tools is they encourage this. There's a component for that kind of mindset. Where a lot of developers don't give a lot of thought to, okay, how am I going to engineer this component?
They just grab a, an off the shelf component and pop it in. And that's one of the big selling points of these libraries is like you have a whole ecosystem of tools you can just drop in. And that leaves a lot of developers in a position where they're not necessarily informed or equipped to evaluate these tools on whether they are accessible, do the right thing, kind of work the way they should.
For a wide kind of range of circumstances, and companies like this too, because it allows them to hire a bunch of inexpensive junior developers, not give them any sort of proper training or mentorship, and they can write functional code because they can just grab components, pop them in and spit them out.
And it's like a machine. And I think when you see kind of the React story where, you know, React actually saw a reversal of this trend and their stuff is more accessible. I think that speaks to the power of these tools when used with components that are accessible out of the box. It can, it can empower people who would struggle to write things excessively, to do some more easily, because I'll be honest, I am a very big advocate of accessibility on the web, but it is still the absolute hardest part of making things for the web today.
Especially when you start getting into more interactive components. There's a lot of low hanging fruit, but when you're designing complex interactive components, there's so many moving parts. The disability community is not a monolith. And so, what works for one set of disabled users will not work for another set.
Just inherently there's a lot of kind of different groups you have to think about. And a lot of trade-offs you have to make and doing something that solves a problem for one group of people may actually cause a problem for another group. And it's just, there's a lot of, kind of a lot of moving pieces here.
And so, I think having kind of out of the box components, can make that better when they're designed well, but it often doesn't. And I think the bigger issue here is we have a, a build process now that, that just kind of prioritizes making things fast versus making things well or understanding how they work or understanding the different kind of things that you have to think about it.
When you're building for the web. And I, I, for me, I think is maybe the real danger around some of these tools, in addition to the kind of the fragility that building with JavaScript introduces to, to the web.
[00:14:01] Todd: Yeah. And, you know, it’s those things that you mentioned that I see a lot of, not only on daily basis, but I hear a lot of people in the accessibility community talking about that as well. So,
[00:14:16] Chris: Yeah.
[00:14:16] Todd: Yeah.
[00:14:17] Chris: Yeah, and I mean, you know, the, the thing for me is like, I, what I, what I long for, I think my, my dream end state is that a lot of, a lot of these things that people lean on library components for, they do so, because they are legitimately hard things to build.
It's the same reason why JavaScript library were popular back in the jQuery era too, because interactive components are just inherently hard to create. You know, I think about things like tabs and accordions and like you can slap together some basic functionality, but there's a lot of just kind of a lot of moving parts that you have to account for keyboard interactions and focus states and screen reader announcements and that sort of thing.
And what, I think what I would really love is a future where the web offers native components that do those things, and we don't need to rely on third-party libraries for that. And I think a really good model for that is something like the details in summary elements, which when used in conjunction allow you to create a disclosure component, where you can click it and it expands and you click it again and it collapses.
And if the browser is old and doesn't support that interaction pattern, the content is just expanded by default. So, it's out of the box, progressive enhancement and, you can style it with CSS. You can change the way it looks. It exposes a JavaScript event. So, if you want to hook into it and bolt in some additional functionality, you can do that.
I would love more stuff like that for things like tabs, drop downs and I'm flying spaghetti monster helped me here. Carousels, you know, I hate them.
[00:15:56] Todd: Yep, yep.
[00:15:56] Chris: Most users hate them
[00:15:57] Todd: Yep.
[00:15:57] Chris: but marketing departments want them,
[00:15:59] Todd: Yep.
[00:15:59] Chris: and sites end up with them. So, they might as well be accessible.
[00:16:02] Todd: Yeah.
[00:16:02] Chris: You know, I think a bad example of this is the dialogue element, which is supposed to solve modals and does so very poorly, with no consideration to accessibility in the browsers that have actually implemented it.
[00:16:13] Todd: Right. Yeah.
[00:16:13] Chris: So, it could cut both ways. And I think a lot of people look at it and they're like, oh, I actually just saw a tweet about this the other day. From a rather prominent developer where he was, you know, giving Firefox a hard time for not having implemented it. And it's almost a good thing because you don't want people to use it because people just assume, oh, it's browser native. It must be accessible and it's not.
[00:16:32] Todd: Yeah.
[00:16:32] Chris: So, I could rant, I'll get off the soap box and I'll turn it back over to you, Todd.
[00:16:39] Todd: No, no, that's great. That's exactly, you know, I, I saw that, I saw that tweet, you know, and it's like, if it were implemented detailed or a
[00:16:49] Chris: Dialogue
[00:16:49] Todd: dialogue, if, if, if that were implemented properly, that'd be great,
[00:16:54] Chris: Yep.
[00:16:54] Todd: But it's not. So that's, it, it kind of reminds me of the whole to an extent the whole color contrast thing with, with WICAG 3 and APCA scoring, don't use APCA scoring, it's in beta, please don't use APCA scoring.
[00:17:14] Chris: Yeah.
[00:17:14] Todd: So yeah. So, I wanted to touch on the performance side
[00:17:20] Chris: Yes.
[00:17:20] Todd: of what's happening to,
[00:17:23] Chris: Please.
[00:17:23] Todd: because that that's always been an issue. So, I try on my personal site, you know, I I've been working to get performance on that and I'm an Eleventy user. I love Eleventy. And, you know, I've been working for on and off here, tinkering around for like a year, trying to get my site performance as well as accessible because I got, I'm in that, you know, I'm that one of those accessibility people, I need to have my site that way performance.
How is this, you know what we're talking about with Frameworks and in all this, how is this affecting performance on the web as well?
[00:18:06] Chris: Yeah. Great question. And so, this is actually what got me into Vanilla JavaScript in the first place. Many years back Dave Rupert wrote about how he ripped jQuery out of his site in favor of browser native JavaScript and saw like, like over a second increase in or decrease in his page load time.
It was just from that one little switch. And I kind of started me on this whole journey, but so the, the high-level version is that of all three pieces of the front-end stack, HTML, CSS and JavaScript, JavaScript is, and always will be, the, the worst part of that stack when it comes to performance, for a variety of, of reasons.
So, when, when like a JPEG gets downloaded, the browser reads through it and then displays it. When HTML gets downloaded, the browser just starts writing it in real time. And the kind of the caveat here is when a, when a browser requests a site or any asset from a server, it gets sent back in bits and pieces called packets.
Because to send a giant file all at once is technically problematic. So, it gets broken down a little four 14 kilobyte chunks, and as they come into the browser, they get handled in different ways. So, you know, with HTML, it's just gonna start rendering that as it comes in, but with something like JavaScript because of how it works, the browser waits until it gets the entire file back.
And then with JavaScript, it actually has to go through and compile the whole thing. And then read through it once to see what's going to happen before it actually starts executing it. You know, whereas with other types of files, it doesn't necessarily wait, with JavaScript. It does. Now, because JavaScript also often changes the DOM.
If the browser runs into a JavaScript file, it will, it will stop rendering until it's completed all those other steps with the file, because it wants to make sure it's not going to render something that's just going to get removed or changed a few seconds later.
And, for similar reasons JavaScript files also block all of their files from being downloaded. Normally the browser will download multiple files at a time with JavaScript. It stops all the other downloads and just focuses on that one, because again, those other downloads might not be needed. They might get removed by the JavaScript, whatever.
So, it creates this bottleneck in the rendering process. And so yeah, JavaScript is just really, really a, just really damaging to performance. It's also incredibly fragile. So, like if you mistype an HTML element, the browser is going to treat it like a div, ignore it and just keep going. It'll render all the stuff in it and say, okay, this is probably just a div and keep going.
If you mistype a CSS property, the browser ignores it and keeps going. If you mistype a variable in your JavaScript file or forget an important semi-colon somewhere or something like that, it just like completely craps itself and breaks and everything stops working. And I'm sure listeners of this podcast have run into this where you hit the white screen of death, where nothing shows up or you click a button, and nothing happens at all.
That's usually because of errors in JavaScript files. And it can be really dumb things too. Like, you try to access a property on an object that should be there, but for some reason, the API returned a response that didn't have that, that property on it. And so, you go to access it and it's not there.
And the file throws an error and then literally nothing else after that works, like those kinds of errors are really, really dumb. And so, this, this dependence on JavaScript for so much has resulted in a web that is slower and, way more prone to breaking. And none of this is to say that you should never use JavaScript, but more that we, we over rely on it, in areas where using different approaches would actually result in a better experience for our users.
So, there's a couple of, I think, emerging trends that I've seen that, maybe mitigate some of these issues to lesser or greater degrees. And we can dig into those if you want, if you had other things you wanted to ask about this, Todd, I want to pause here in case you want to kind of pick into anything I've said a little bit.
[00:22:19] Todd: No, let's dig right in.
[00:22:20] Chris: Okay. Yeah. So, the two things here, so React and Vue and Angular are huge. React is actually and Vue are actually probably small compared to Angular, which is just a massive behemoth, but
[00:22:23] Todd: Yeah.
[00:22:23] Chris: React and Vue are both 30 kilobytes minified and gzipped, which means, you know, all the white space has been removed. All the variables have been shortened to like single letter characters.
[00:22:44] Todd: Yeah.
[00:22:44] Chris: And they've been compressed. And then when they come to the browser, they get uncompressed. And so that uncompressed size is usually somewhere in the order of like megabyte or more. And that’s a lot like the abstraction of all that code.
It, it just, it's a lot for browsers to work with. It ties up a lot of memory. It can just really start to bog things down. And so, this trend I've seen, that's really exciting, is exciting, is, the rise of micro libraries. And let's see here. I'm just going to look up my own article on this so I can speak more intelligently about it.
But so micro libraries are kind of what they sound like. So micro libraries are libraries that do similar things to React and Vue, but at a fraction of the size. And so, the trend, as far as I can tell, started with Preact, which is a three kilobyte alternative to React that uses the same API, but with less code underneath.
And they've done this by dropping a few features, sitting a little bit closer to, to the metal. So, they've baked in fewer abstractions. Jason Miller, the guy who built it, claims he's working on a rendering engine update, that actually like results in even more optimizations to the rendering.
But like right now, the current version of Preact in addition to being a 10th of the size of React, actually renders the UI four times faster, both on initial load, and once it's fully loaded on like state changes and things like that to just by virtue of having less, less code, fewer abstractions, fewer things sitting between.
The change you're trying to make. And the rendering that actually happens. You're just eating up less of the browsers resources and that results in a faster UI for your users. And also, because you're shipping way less code, the initial UI is going to render faster because you're waiting for less stuff to download.
There are other similar tools, so Vue had Alpine.js for a while. That inspired Evan You, the guy who actually built Vue in the first place to create his own alternative called petite-Vue, which is a about six kilobytes, subset of Vue optimized for performance enhancement. There's also a kind of a new kid on the block, SolidJS, that, you know, similar kind of approaches to React and Vue, but, just with its own, own kind of conventions.
And so, if you need state-based UI and you want to run that in the browser at this point, I think it's really hard to argue that React is a better choice than Preact. It has the same exact conventions, same exact API. It's a fraction of the size. It's faster. It's just objectively better, in my mind.
But this still has the problem of being a, a thing where the HTML is rendered in real time in the browser, like you're still putting that cost on the user, and you still have all the fragility that goes along with that. So, I think the more exciting trend is around JavaScript compilers. This one, as far as I can tell, started a few years back with Svelte, which was built by Rich Harris who works for the New York Times.
He realized that while state-based reactivity is a good thing, handling that all in the browser is not. And so, he built a compiler that lets you author your, your UI’s using a state-based UI approach. And then, Svelte will take what you've written and spit out mostly pre-rendered HTML. With, a little bit of mostly browser native JavaScript to handle the Reactive stuff.
So, it, it basically, it lets you write in a state-based UI approach, but it produces JavaScript. That's more like the kind of old-school DOM manipulation we would have written by hand five or 10 years ago. So theoretically giving you the best of both worlds.
[00:26:20] Todd: Yeah.
[00:26:20] Chris: And that's pretty neat. But you know, you have a lot of folks who are already deeply kind of embedded in a React or Vue kind of kind of world.
And, so there's this, this new compiler on the block called Astro. And I can send you links to all this stuff if you want to drop it in the show notes, Todd, but Astro is, this new tool that builds on Rich's idea for Svelte, and works mostly the same way, but lets you pull in components from all of your favorite JavaScript libraries.
So, you can take a Svelte file, and a React component, a Vue component, mash them all together into some sort of like weird Frankenstein type creation. And it will compile those into mostly HTML with a little bit of Vanilla JavaScript.
And so, it takes the stuff that Vue or React is going to do and drops the library out entirely and abstracts it away into just some, you know, a little lightweight, kind of DOM manipulation snippets. Jason Lengstorf, I want to say his last name. I know I'm butchering it. Jason I'm really, really, sorry. He works over at Netlify.
[00:27:24] Todd: Yep.
[00:27:24] Chris: He actually, did an experiment with this, a month or two ago now where he took a, a Next.js library that he had, or app that he had, and he chucked it into Astro.
It was like 90%, the same code with a few tweaks. And the, the thing that got spit out used 90% less JavaScript and loaded, quite a bit faster because it got rid of all this JavaScript. And so, yeah, that's, I think that's a trend that I expect to see more of in the future, because it allows organizations to continue using these approaches they've already been using, but ultimately ship less JavaScript to their users.
So, you end up with something that's faster, and less likely to break. And that's great. If you send to my hesitation here, I think the thing for me is, people seem to really like these approaches. I still find them wildly over-engineered and wildly more complex than they need to be.
And I'm excited about what these tools mean for users, but as a developer myself, I still hate them because it is just not the way I like to build for the web. And I understand I'm probably a dinosaur at this point who builds things in a very old kind of way. But, yeah, it is just not, it's not for me.
I, I appreciate them for what they can do for the web. But they are not my preferred way to build things.
[00:28:45] Todd: It, it seems to me cause I, I, you know, for, I don't know ever, you know, since React came out, I guess I've just been sitting back and been like, okay, you know, I've been watching these things and it's like, how I guess, and, and, and I'm not calling anybody this at all, that is a developer, but how lazy are we trying to get with having all this stuff, do it for us.
But yet it has the effects it's having on the web. I mean, granted, we still have speaking of dinosaurs, we still have sites out there that are probably 25, 30 years old.
[00:29:30] Chris: Running on jQuery, yeah.
[00:29:32] Todd: Exactly.
[00:29:32] Chris: Haven't been updated in ages and they still work, you know?
[00:29:36] Todd: Yeah, yeah. The Space Jam site.
[00:29:38] Chris: Right.
[00:29:38] Todd: That was around for how long? And
[00:29:41] Chris: Right.
[00:29:41] Todd: You know, but that, and I just actually ran across an example, that a friend of mine and I were talking about, and I looked up on archive.org and it, you know, I don't think it's, it's not still alive, but, that thing was a behemoth. And I don't remember the specifics exactly, but it's like how many examples of that are out there still?
And I guess where I'm trying to go with this is that, you know, well, how, how, you know, geez, I don't even know how to put this, you know, the way that the tooling is now. Okay. Yeah. Granted, I'd love to spit out a few sites and not have to worry about maintaining it, any more than I have to, because I'm so short on time, but me being the, the kind of person that I am, I like to get my hands dirty in the code.
I like to write my own code. I like to write my own CSS, HTML, love to write, you know, those two and JavaScript, even though still I don't do it well, which we'll go into a little bit later with the stuff that you do, but.
[00:31:09] Chris: Yeah.
[00:31:09] Todd: How, how are these tools supposed to make it easier? But it seems like they're making us lazier is
[00:31:17] Chris: Yeah.
[00:31:17] Todd: I guess what I'm trying to ask.
[00:31:19] Chris: Yeah. So, so it's complicated. I think, I think there's a, I think there's a few kind of forces at work here. I, I gave a, I gave a talk at one point, where I described this as kind of like this, this hype cycle almost. And, you know, so I, I think one of the, you know, one of the key kind of things here for me is that for a certain type of developer that is specifically someone who, who is a real deep expert on JavaScript, these tools absolutely do make their process easier.
Largely because it lets them focus on the skills that they already know, JavaScript and ignore the skills that they're not as comfortable with. So, like CSS and HTML, and, you know, so, I don't know that I'd necessarily call it making us lazier because like these tools involved sometimes some pretty complex JavaScript.
And I think getting set up with tools like this is, is one of the reasons I hate them is I think the kind of the setup time is just so laborious
[00:32:33] Todd: Yeah.
[00:32:33] Chris: and so complicated and so fragile. I absolutely hate it. But, yeah, I think it prioritizes one type of development over another. I think the other thing that I have seen happen, is these tools get created that solve a legitimate problem in a narrow context.
So, you know, Angular already existed when Facebook created React. They created React because, you know, it solved some problems they had that Angular didn't or solved them in a way that they, you know, they needed it to. And you know, Facebook has a really massive absurdly complex kind of UI. And they have a bunch of different teams working on a bunch of different sub-products that all get pulled into this one big product.
And they had a lot of issues with things not looking consistent and yada, yada, yada, and so React really solves a lot of problems for them in that regard. And then, you know, they do some talks, they go on podcasts, they go to conferences, they talk about it, they evangelize it, look at this cool thing we built because it's good for recruiting, right?
[00:33:35] Todd: Yeah.
[00:33:35] Chris: Like you talk about how cool your tooling is. Developers want to go work there.
[00:33:40] Todd: Yeah.
[00:33:40] Chris: This evangelization gets kind of baked in as thought leadership. And so, you get a bunch of people who don't work at Facebook, wanting to use these tools and talk about how like cutting edge and powerful they are. This kind of fuels this bandwagon approach where people feel like if they're not doing this thing, they are not, you know, they are not up-to-date, they're not real developers.
They're not like kind of, worthy of being hired, which then causes a lot of recruiters and companies to be like, oh crap. If we want to hire the best people, we need to start using these tools because that's what developers want to use because all the thought leaders are talking about it, and everybody feels FOMO for not using them.
[00:34:15] Todd: Yep.
[00:34:15] Chris: And so, you start seeing more job descriptions talking about how they're looking for people with React experience, which then causes more of this like bandwagon feeling of like, oh crap. If I don't learn this, I’m never gonna get hired. Cause all the jobs want someone with React and on and on and on and on and on the problem is you do this enough and these tools start to create a whole set of new problems.
And then you get people creating tools that solve those problems. So, you have things like Svelte and Astro, which solve the problems that are created by the tools that got overused after solving a very narrow set of problems. And then you get people evangelizing those tools. And I mean, absolutely no disrespect to Rich Harris here, because I think what he built he's built is a really good thing that will result in a net better experience for people who use the web.
So, I'm not in any way trying to say that, like, you know what Rich built with Svelte is bad, but I think you can see a similar kind of thing happen where Rich is evangelizing the tool, he built that solves a lot of problems created by the things that came before it. And you start to see more thought leadership around those tools, which I myself have been guilty of because I talk about these tools as a way to fix some of the problems with React and Vue.
And if that catches on, we'll see another cycle of this bandwagon-ism. And so, I don't think any of it is ill intentioned. I just, you know, and I totally understand how it happens. It just, it results in this really bad kind of never-ending cycle of garbage on the web. You know, even jQuery. jQuery came about at a time when building things, doing DOM manipulation was really, really hard.
And it solved some really big problems that a lot of developers had and then it no longer became necessary, but there was so much inertia around it that, you know, up until this year, it was still continuing to be growing and being used on more and more websites. It just finally started to see a backslide, like literally just, I think at the end of 2021.
But yeah, so these things have kind of these really long, long ripple effects. And I don't hate the tool. I just, I hate the overuse of the tool in situations where they're not appropriate. I think for me, that's the real, kind of the real bummer about a lot of this stuff is we take, hey, this thing solves a really like important problem we have in this narrow context and gets generalized to, so let's use it for everything.
[00:36:33] Todd: Yeah.
[00:36:33] Chris: It's like, Frank's Red Hot, you know?
[00:36:38] Todd: Yes, it is. Well, I, I, that kind of takes me back to a quote and I don't know where I heard it or read it or whatever, but it basically said a good, a good craftsperson, never blames their tools. So yeah.
[00:36:52] Chris: Yep.
[00:36:52] Todd: It's and yeah, it's probably not making us lazy. It's, it's probably not a good, it's probably not a good word for it.
It's I guess, you know, that the, I guess, and I've played around with some of these a little bit and by no means, am I an expert in, you know, I love to learn. So, maybe it's just the, I guess, the autopilot, so to speak kind of feeling that I get with, okay, now it's put up and, and it, you know what you said, you know, it, it, it's got all these complex JavaScript, you know, things going on and it already solves the HTML, CSS side, so to speak and thus, you know, the person can focus more on that JavaScript side.
So yeah. That's yeah, that's, that's good. It's a good way to put it. Getting away from that because you, you had said something, you know, that kind of, I think we've had this conversation before with, I see job listings and they're like, you know, I don't, I, I correct me if I'm wrong, but React is what, eight to ten years old or something like that.
[00:38:14] Chris: Ooh, actually.
[00:38:14] Todd: But you see maybe, maybe old, maybe a little bit older than that.
[00:38:20] Chris: That's a great question.
[00:38:20] Todd: But,
[00:38:21] Chris: I've never thought to look that up, but it's been around for a while
[00:38:24] Todd: Yeah.
[00:38:24] Chris: at this point.
[00:38:28] Todd: But you see HR people are, or, you know, recruiters asking, you know, we need 15 years of React or, you know, we need 40 and I'm exaggerating here, but we need, you know, 45 years of PHB or whatever. Why does the hiring process suck so much? And I know we've talked about this before.
[00:38:50] Chris: Yeah. Oh, that's a great question. And my background in HR kind of gives me a little bit of a, an inside baseball knowledge here. So, yeah, so the reality is, no disrespect to recruiters out there. But most recruiters specialize in recruiting and not the technology they’re recruiting for. This is the same reason why, if you're a JavaScript expert, you will get recruiters emailing you about Java openings.
Even though the two are completely unrelated. You know, it's, it's just a, a thing a lot of times, depending on the organization they're in, they're recruiting for a handful of different teams using a handful of different web stacks. And they literally cannot know all of the technology that they're, they're recruiting for, especially since their actual specialty is sourcing.
Not even really evaluating people, more just finding people to then get evaluated by the teams. And so, I used to like jokingly say that recruiters are lazy and to an extent that's partially true in the same way that I'm lazy, in that we're all busy. And if there's something you can kind of optimize or offload or not think about, you will.
To let you focus on the other things. And so, if the industry is shifting towards React, and hiring managers are like, oh, you know, we should use React because everybody else is using it. And that's what all the developers want to build with. That's what recruiters are going to look for or put in their job listings.
Or they're just going to kind of like throw out a big net and say any sort of, you know, library experience is great. We want that. And, yeah, it's, it's really, there's not anything like, particularly like deeper, insightful here. It's just kind of a, I don't know the tech very well. So, I'm going to slam a bunch of buzzwords in, because this is what I see in other, other kind of job descriptions.
And the more that happens, the more it happens, because, you know, you look at other competitors, job descriptions and you kind of copy some of the stuff in there. And it just becomes this self-perpetuating cycle.
[00:40:44] Todd: Yeah.
[00:40:44] Chris: And React and Facebook, definitely won the kind of the marketing wars around libraries, they just flooded the market with talks and thought pieces and, you know, and all that. And so, kind of like React became, like the de facto tool that most people want to use, or at least talk about in job descriptions.
[00:41:09] Todd: Yeah. I experienced the, and I'm trying to remember here real quickly. They wanted somebody with some JavaScript knowledge. It wasn't a lot. It was kind of like on the junior level, whatever that is.
[00:41:35] Chris: Yeah
[00:41:35] Todd: I mean, we can go into, we can go into that some other time, the different levels, but they wanted it somewhat similar to a junior level knowledge of, of JavaScript.
And they ended up asking me questions about Java and I'm like, that's not anywhere close to what you asked. You asked for JavaScript not Java. But so, I want to swing this back to, the, the learning, piece, because you have your platform, which I wanted to, you know, talk about a little bit. I have taken your courses; I enjoy your taking your courses.
And here's the reason why. Those small bite size videos that you have. Tell me so much more than somebody that just goes on and on for an hour, hour and a half plus. And I get more value because maybe it's because I don't have, you know, a, a, a great attention span at times, but, you know, it's, I, like I said, I, I find so much more value with your minute and a half videos on a certain topic where you get right to the point.
So, what I wanted to ask is. One, what's going on with your academy? And two, how can people, take your courses? And, if, if they're looking to improve and believe me, I've improved my JavaScript skills, taking your courses. So how can they, you know, take your courses and how can they improve on this?
[00:43:11] Chris: Yeah. And it's, you know, the, the funny that you mentioned, the short thing actually came to a realization like just, just the other week that, A big part of the reason why all of my like videos and tutorials and everything are really, really short, is because I have ADHD and I do not have the attention span for long videos.
I know some people really love the like long in-depth courses, but my stupid ADHD brain just loses focus after, after a few minutes. And so, a lot of, I never clicked with me that the reason I make all of my stuff that way is because that's how I prefer to learn. But it works out nicely because apparently a lot of other people feel that way too.
[00:43:46] Todd: Yeah.
[00:43:46] Chris: But, yeah, so I, I, right now I have a few different ways people can learn. The first is a newsletter I publish for free five days a week. You can find that over at gomakethings.com. Just short little kind of snippets. This week we've been talking about different ways to kind of loop through and manipulate arrays and objects.
But its, its usually very beginner focused, just cause I love working with, with beginners. I also have a series of courses and books, depending on whether you prefer to learn a video or by reading or a combination of both. So, it's the same content either. But that's over at vanillajsguides.com.
And these, I call them pocket guides because they're really short and focused and they'll get you in and out of a topic in about an hour. So, everything from DOM manipulation to state based UI, to ES modules, to service workers. The other thing I know the thing Todd, that you've gone through that you really enjoyed, was the Vanilla JS academy.
And, this is, you know, for folks who don't want something self-paced, or they have a tough time maybe staying disciplined around, kind of self-paced learning. This is now a six weeklong, online, remote kind of semi asynchronous workshop. And so, the way this works is every Monday, Wednesday, and Friday, I put out three to five, just really short lessons around a handful of topics.
And then I throw a project at you that uses some of what you just learned. And then on the in-between days, we look at, how I approach this project. It's not always the only way. It's just the way I approached it. As well as some common issues with challenges that I usually see kind of developers make when they try to solve these, these projects.
And there's a Slack channel involved. So, you and a handful of other students are going through this at the same time. You can share your work, ask questions, learn from each other, which is really cool. And then every two weeks I also run, a video office hour session where you can ask me kind of questions in real time.
We can share screens and walk through code. And, yeah, so those are kind of the big thing. I have going on, 2022, 2022? Is that right? Yeah, I have, man, ADHD time, I'm all a mess.
[00:45:50] Todd: Yeah.
[00:45:50] Chris: I have a whole bunch of like other things I'm planning to I'm planning to do. I don't know how many of them I'll actually get to.
But one of the things that I'm hoping to work on is more of like a project based series where. You know, similar to the way academy works, but maybe a little bit more self-paced where, instead of looking at a, like a specific topic, like DOM manipulation, we look at a project like, you know, how to build a to-do app or, how to build a, a game.
And I just kind of fumble with, fumble my way through it and kind of progressively make it better and steps we might start with, with, you know, like a small little thing and then we'll build on top of it. So, I have that kind of in the works. Right now, the Vanilla JavaScript academy, has a kind of a beginner level where we look at some DOM manipulation essentials or DOM essentials.
And then, an advanced version where we look at like structuring and scaling code as a project grows, I want to build an advanced version that looks at how to build apps. do things like token based authentication with like login screens and maybe using serverless to build a fully functioning app.
So that's kind of in the works. And then I have just kind of a couple of other like random ideas bouncing around in my head around maybe an updated career guide for developers. I've had a lot of folks since talking more about mighty, my ADHD mentioned, hey, I have that too. How do you actually get anything done?
So, I've been thinking about maybe putting together, some resources around that as well. But yeah, if you are listening to this and you want to find any of this stuff or dig in deeper on anything, Todd and I have been chatting about, I actually have a dedicated page I put together just for this podcast.
So go make things.com/front and nerdery, you can include dashes or not. It'll get you there either way. And that'll have links to all of the stuff I just talked about as well as everything else Todd and I covered, in this episode,
[00:47:39] Todd: Awesome. So now is the time as we wind down here that I get to the last three questions I always ask my guests. So, are you ready? It's kinda like the hot seat.
[00:47:49] Chris: Love it.
[00:47:49] Todd: First question. What about the web these days excites you and keeps you excited in what you do?
[00:47:57] Chris: Ooh, great question. Yeah, so for me these days, I'm actually less excited about the web as a platform, and more excited about seeing a whole new wave of students, kind of get excited by the web themselves for the first time.
I've found that as I've gotten older, I find way less excitement in building things myself and more in teaching other people, which has really kind of committed me to doubling down on web education in 2022.
[00:48:28] Todd: If there were one thing you could change about the web that we know today, what would that be?
[00:48:34] Chris: Ooh, that's a great question. You know, there's a part of me that wants to say JavaScript was a mistake, but that's not really true because it's enabled a lot of like really interesting and interactive stuff.
I think for me, if I could wave a magic wand and change anything, it would be more HTML, native, interactive components. I would love to see more just native HTML that does interactive stuff. So, like, like video or details in summary. I want that for all the things. I want a drop down component. I want a tab component.
[00:49:06] Todd: I would have accepted any answer and I've had a bunch of them. It is a wide range, but yeah, that is, that's definitely one that's, that's high on my list, that you just mentioned. So, the last question is, your favorite part of front end development or design or anything really that you like the most that you quote unquote nerd out over?
[00:49:31] Chris: Yeah. So, for me, I alluded to this a little bit at the beginning, but I love making things and I'm not good at working with my hands. And so, for me, the thing that has kept me in the industry, as long as I've been, is that code enables me to have an idea and make it a thing. In a really, I think sometimes reasonable and quick amount of time.
One of my favorite things to do these days is, like if we, you know, like my wife and I have a thing we need, and there's not an app that exists to do it. I can go make it. And that's really, really, like for me, a really interesting thing to be able to do, like, a few years back, I created an app that allows us to kind of store all our memories about like fun things that have happened in our life in one spot and then go back and look at them.
And there are other apps that could've done that too, but none that worked with like the simplicity and ease or exactly the way I wanted. So, I built my own. And then, because it's my own, I can export the data out of it whenever I want and get it in whatever format I want and then do other things with it.
Like we recently put together a book of memories from, you know, our time together. And, yeah, for me, it's really that it's, it's being able to kind of have an idea and make it a reality. Just kind of on my own using a bunch of tools that exist because we're all just standing on the shoulders of giants.
[00:50:53] Todd: Yeah, definitely. So, I do have, I, I, you know, I normally end it here and go into my little outro, but I got to ask because I have been meaning to do this, but I have not had the time to do this. The D and D thing that you have. Can you talk a little bit about that? It is, it's a site that you have for, for
[00:51:16] Chris: Oh.
[00:51:16] Todd: like, yeah, go ahead.
[00:51:17] Chris: Yeah, sure, sure, sure. Yeah. So, I, I love Dungeons and Dragons, but, and this is, again, this is a bias with my ADHD here D&D is very rule heavy. And like the current version is actually probably one of the most rules light versions of D&D that has ever existed. But, when I am trying to run games, I just can't keep track of all those rules.
And as a player, I find that like trying to manage like, okay, so, when I jumped my jumping distance is my strength times this modifier, and then it just, it breaks the immersion of the game for me. Like I'm someone who, when I'm playing, I really like to imagine myself as like a druid who can control the powers of nature or like a, a, a fierce barbarian battling, you know, like evil forces and, and stuff.
And I'm like getting lost in the crunch really breaks that for me. So, I ended up creating my own little like rules light RPG system, that is mostly just common sense based, like, could your character reasonably jump over that distance? Yes, or no? If you're unsure, roll some dice and find out if they definitely could, it just automatically works.
If they definitely couldn't, you automatically fall in the cliff and fall in the canyon and, you know, fall to your death and die. And it, or get really hurt, whatever. But, yeah, that's basically it. If anybody's interested, you can find that at kitchentableadventure.com.
But the basic dice mechanic I, I took from the Powered by the Apocalypse system and modified it just a little because my system doesn't use any sort of modifiers for things like strength or wisdom or anything like that. Just cause again, I hated dealing with, with all of that. It's a very bare bones, like make up a concept, come up with a few things about your character.
Okay. Let's go play. Does it make sense in the world? Yes, no. And, and that's basically it, so, yeah, that's, that's, that's basically it, in a nutshell,
[00:53:16] Todd: I do have it on the list somewhere in this chaotic garbage mess that I have going on here at my desk. So now, I'd like to close out the podcast with letting my guests know and tell the listeners what they have currently going on and where people can find you. I know we talked a little bit about just a little bit of a go, but anything else that you'd like to, you know, let people know that you have currently going on and, and, and where people can find you online?
[00:53:48] Chris: Yeah, no. The biggest thing, if you, if you enjoyed this talk or, you just, you want more of this sort of thing, or you want to send me an email or tweet at me telling me how terribly, terribly wrong I was about something, head over to gomakethings.com/frontendnerdery and, you can find all the things including how to contact me and tell me what an idiot I am.
[00:54:27] Todd: That's not true. Anyway, so, Chris, I want to thank you for coming on and spending part of your day with me today. I know that you are in New England. I used to be in New England, and I do not miss the weather you're having out there. So,
[00:54:19] Chris: Yeah, it's actually, it's warm today
[00:54:21] Todd: Oh, is it?
[00:54:21] Chris: at 37 degrees.
[00:54:22] Todd: Oh, there we go.
[00:54:22] Chris: Yesterday, it was like, I think the high was like 19 Fahrenheit, which is just brutal.
[00:54:27] Todd: I don't miss it, but anyways, yes. Thank you for coming on spending part of your day with me. I appreciate that. And, again, it was great to talk to you. And then, I'll do my little closing speech here and we'll wrap this up, so
[00:54:44] Chris: Awesome.
[00:54:45] Todd: Thank you, listeners, for tuning into the Front End Nerdery Podcast. I'll be back next time with a new guest, new conversation about front end design, development or other topics. If you would please rate this podcast on your podcast device of choice. Like, subscribe and watch it on the Front End Nerdery YouTube channel. Links to transcripts and show notes will be there as well as on gomakethings.com/front end nerdery and, that's it for now.
I'm Todd Libby, and this has been the Front End Nerdery Podcast. Thanks. And we'll see you next time.