---
title: Vanilla Javascript - Fundamentals before Frameworks
date: 2022-05-03T05:00:00-04:00
author: Sean Smith
canonical_url: "https://website101podcast.com/episodes/season-05/episode-9/vanilla-javascript-fundamentals-before-frameworks/"
section: Podcast
---
<!\[CDATA\[YII-BLOCK-BODY-BEGIN\]\]>[Skip to main content](#main-content)Guest Chris Ferdinandi
Chris Ferdinandi helps developers with ADHD thrive. His ADHD tips newsletter is read by hundreds of developers each weekday. Learn more at ADHDftw.com.
[ ](https://twitter.com/ChrisFerdinandi)
Season 05 Episode 9 – May 03, 2022
47:37 [Show Notes](#show-notes)
## Vanilla Javascript - Fundamentals before Frameworks
0:00
0:00
1.0x
0.75x1.0x1.25x1.5x2x
[](//dts.podtrac.com/redirect.mp3/website101podcast.com/uploads/mp3/season-05/S05-E09-chris-ferdinandi.mp3)
Learn why Chris Ferdinandi believers there's a simpler, more resilient way to make things for the web with vanilla Javascript. We also take a detour into accessibility.
### Show Notes
- Chris's background and history with web development
- Single Page Applications
- Libraries
- Tiny libraries that Chris recommends at: [The Vanilla JS Toolkit](https://vanillajstoolkit.com/)
- Accessibility and best practices with JavaScript
- Living with ADHD
- JavaScript and education recommendations
- Recommendations for novice developers starting out
- What's coming up in JavaScript that Chris is excited about
- Go Make Things - [Website 101 Podcast Listener Page](https://gomakethings.com/website101/)
### Show Links
- [Go Make Things](https://gomakethings.com/)
- [Alpine Js](https://alpinejs.dev/)
- [Vue](https://vuejs.org/)
- [React](https://reactjs.org/)
- [Angular](https://angularjs.org/)
- [jQuery](https://jquery.com/)
- [WebAIM](https://webaim.org/)
- [The Vanilla JS Toolkit](https://vanillajstoolkit.com/)
- [The A11Y Project Checklist](https://www.a11yproject.com/checklist/)
- [Sean uses a screen reader](https://caffeinecreations.ca/blog/using-a-screen-reader/)
- [A11Y Nutrition Cards - blog post](https://daverupert.com/2018/08/a11y-nutrition-cards/)
- [A11Y Nutrition Cards](https://davatron5000.github.io/a11y-nutrition-cards/)
- [MDN Web Docs - prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion)
- [Vanilla Js Academy](https://vanillajsacademy.com/)
- [Go Make Things - Website 101 Podcast Listener Page](https://gomakethings.com/website101/)
Powered Transcript Accuracy of transcript is dependant on AI technology.
**\[00:00\]** Welcome to another episode of the website 101 Podcast. This is the podcast for people who build websites or maintain them and want to be better at that. This is season five episode nine. I'm Mike Mella. They are Amanda Lutz and Sean Smith. Hi, friends. Hey, friends. Hey, Mike. How's it going? We're all good. You're ready to roll. I got an exciting episode. Yeah, today we're going to talk about the 800 pound gorilla of web development
**\[00:32\]** JavaScript. And we're going to talk about it with Chris Ferdinandi from the JavaScript vanilla JavaScript podcast. Chris, welcome to the show. Hey, everyone, thanks so much for having me. Amanda, why don't you start off your resident JavaScript expert? Yeah. Okay. Well, the very first thing that we need to know is, well, I do know the JavaScript. Chris is obviously got a lot of knowledge happening. Chris, tell us a bit about your background. Yeah, so I'm a JavaScript educator. My full-time job is teaching people JavaScript.
**\[01:05\]** And my focus is specifically around beginners, people who do other things and are looking to transition into web development. And my, I guess, my guiding principle, if you will, is that a lot of the way that we build for the web today is potentially a little bit over-engineered. That's why I really focus on what I think is a simpler and more resilient way to make things for the web. So even though I teach JavaScript, a big part of my ethos is that we should be using less of it. Right.
**\[01:36\]** And just to heads up, though, just before if I can fit this in here, Amanda obviously knows all kinds of stuff about JavaScript. I don't. I'm used to be a JQuery guy a little bit. I'm really trying to upgrade my JavaScript skills. Sean, if I can speak for him, is sort of along the same lines as me? Would you say so? Yeah, I would say me and Mike are pretty equivalent. We're XJ query guys who struggle with regular JavaScript and we're both kind of fans of Alpine because that's a sprinkle in the JavaScript
**\[02:09\]** that we used to do with JQuery, but it's all in line, works nicely with Tailwind. And we'll get into that stuff a little later. But I think it's great that your podcast, the vanilla JavaScript podcast. The thing I like about it the best is it's super short. Everything is like 10, 15 minutes. It's really easy to consume. I think a 15 minute episode is a long one. That is the byproduct of my ADHD. I don't have the focus to do them for longer than that. Nice, nice. So do you only do the teaching online
**\[02:40\]** or do you also pre-COVID? Do you also teach in person? Is it just the podcast, like, where can people generally find you in your knowledge? Great questions. Yeah. So you can find all things me over at GoMakeThings.com. That's kind of my home on the internet. So before I was a web developer, I was actually an HR guy in the training and development kind of wing. So I used to do in-person training, but not really around technical stuff.
**\[03:11\]** And as long as I've been doing web developer education, it's been exclusively online. So in addition to the podcast, I also have a series of courses both in video format and e-book for people who prefer to learn by reading. I run an online workshop about three or four times a year. So that's kind of the semi asynchronous. You're doing a little bit every day, but you don't have to do it at a fixed time. And if you want to batch stuff at the end of the week, you can do that too. And I'm also working on a series of kind of self-paced
**\[03:45\]** project kind of things for people who prefer to learn by doing, but need maybe a little bit help getting started. Oh, I'm interested in that. So I would actually like to jump back a little bit to what you said in your intro about the way we build websites is over-engineered. And there's a simpler, better way. Can you give some examples of what you consider over engineering? Yeah, absolutely. So the, yeah, I know you both mentioned Alpine JS,
**\[04:23\]** and so I'm just going to kind of rag on frameworks for a minute here. But one of the big trends we've seen in the last few years is kind of this do everything in JavaScript kind of approach where all of the HTML, all of the CSS, everything is being authored in JavaScript. And I think that's a good experience for a certain subset of developers who are really comfortable with JavaScript and an absolutely awful one for a whole bunch of other developers who are not.
**\[04:53\]** So a lot of teams have people whose expertise is more around things like accessibility or CSS specifically, and a lot of the tools that we use kind of gatekeep them out of the process or make it more difficult for them to do their work. It also means that a lot of the things we build now have these weirdly deep dependency trees where you need to NPM install a bunch of stuff before you can get going. So are you right now, are you specifically talking about some of the frameworks that work together
**\[05:23\]** to do these single-page applications? Yes. Like React and View and Angular. That's a big part of it, for sure. So, you know, we're talking React, View, I know Alpine is, like, View-esque and mercifully doesn't necessarily need an install step. But even just kind of the whole, like, rendering your UI with JavaScript introduces a bunch of fragility into the process and sometimes it's needed or helpful.
**\[05:54\]** But a lot of times it's just we do it because it's the tool we know. And so we just kind of always grab it. You know, one of the, I think one of the biggest things I've seen with a lot of the folks that I teach is because almost every job description these days mentions like react or angular or some sort of other library experience. I mean, because these tools are so big and all encompassing and do so much, a lot of people who are learning feel really overwhelmed by that process. Because for the most part, it is not like the way I learned, I know Mike, Sean, you both mentioned
**\[06:28\]** and jQuery, that's how I learned too. Like the process was open a text editor, open a browser and code. And I didn't need to open a command line prompt. I didn't need to install anything. I didn't need to understand these advanced concepts before I could actually make something appear in the UI. And it can be a lot harder now. And I think one of the things I've observed is a lot of senior developers talk about these tools as being time saving and providing a lot of benefit.
**\[07:02\]** But I think a lot of times the benefits that they provide are stronger for more advanced developers than for beginners. And I think they also pass a tax along to the people who actually use the things we build. So we are saving potentially time ourselves as developers and then passing a cost onto our users for the benefit that we get. And I think maybe that's prioritized the wrong thing. Yeah, I mean, it's not only that, it's also, I find that the complexity that it introduces to your development stack, like for example,
**\[07:35\]** this is not necessarily JavaScript related, but the other day I was having an issue with my local, you know, setting up a dev server locally with valet or whatever, and something went wrong, and I spent an entire day trying to solve it, and I didn't even solve it, I kind of made a work around and I was like, oh, well, this will work for now. And that kind of thing can happen when you have all these dependencies on dependencies and plugins for a library, and it just drives me crazy having to keep up with all that stuff, you know? Yeah, especially like you're throwing like a build process
**\[08:06\]** where you're using something like Laravel mix or Vite or Webpack. Those things just overly complicated things as well. Yeah. So Chris, I teach web development part-time at Seneca College here in Toronto. And one of the things that I do like about the development classes is that we are taking everything, we're stripping everything right back to the basics, go to the foundation. Like yeah, in the third semester, the students start looking at bootstrap a little bit, but just for the sake of, more so for the sake of knowing that above the idea and the concept
**\[08:40\]** of front end frameworks as opposed to be a bootstrap developer. So we're trying to do, I'm trying to do a lot of the same type of thing with JavaScript. Just start with the basics and here's like the idea of a variable. It's just a name that you give a piece of data, and I'm building a little bit more logic on that instead of trying to sit down and just be like, here is some library that's only going to be popular for the next six months. That's awesome. And nothing against these tools, so like I have strong feelings, but so there's a few I think
**\[09:18\]** threads we could pull out. The first is I really, really strongly believe that if you are just learning, then the thing that's going to keep you are momentum up as a learner is way more important than picking the perfect tool. I think where I see beginners get frustrated and give up most often is when they feel stuck and they don't know how to get unstuck, like that rush you get from, I have an idea,
**\[09:52\]** I've made a thing and now it's running in a web browser, is the thing that really early on when you have no idea what you're doing, is the thing that keeps a lot of people going. And if a framework or library helps you do that more effectively, then I care about that way more than like, you know, the purity of, you know, vanilla JavaScript or whatever. I think the thing I struggle with is I feel like a lot of modern tools actually add a lot of friction for beginners, whereas something like JQuery took a lot of it away.
**\[10:25\]** And that's probably just a bias for me. I don't have a computer science background, and so a lot of the concepts of these more modern frameworks, they hurt my head, but you know, so that's one aspect of it. I think the other thing is libraries were built to solve a very specific set of challenges and they do those things very well, but they also do a bunch of other things poorly. And we tend to, just as in the industry, treat them in a lot of instances as kind of like
**\[10:58\]** a given or just a thing that everybody has to use because that's just what we do now. Even when they're not always the most appropriate choice for the task we're trying to accomplish. And I think for me, that's where a lot of my frustration with modern web development comes from. React can be an amazing tool for a very specific thing for which it was designed. And in many cases, it's actually one of the worst choices, especially compared to some other newer options that are available now. Yeah. Well, and I think that we've seen this repeated time and again, not even just with JavaScript
**\[11:31\]** or whatever framework you're using, but like all of us have complained at one point about WordPress. Like WordPress is fine for what it's good for, but to often, I don't know if it's WordPress or the people who are making the themes for it, and they're now trying to be everything accessible to everybody, and now it's just, it's become so big and bloated and heavy, and it's like just, that's WordPress is not good for that. So yeah, I'd absolutely agree with what you're saying. I hope the listeners can hear me nodding. I really like that you're pushing for fundamentals.
**\[12:07\]** That's what it really feels like is vanilla JavaScript understanding the fundamentals. And I know we mentioned earlier, both myself and Mike, we struggle with a regular JavaScript. And that's because we didn't really learn the fundamentals. But if you want to talk CSS, I have master CSS. I know it really deep, and this is what I wish I had with JavaScript. Yeah. I've said on many of these shows that it really bothers me that I look up how to do something
**\[12:41\]** with JavaScript, and it's always a jQuery solution. They just assume you're using jQuery, because the solution was written in some time in the past 10 years or whatever that hell over long that's been running. So would you say then that most developers WordPress is a little different, I guess, because that has all these built-in things and it can be a little bit of a no-code thing. But for the average developer, who's sort of just building a normal site where they want some drop downs, maybe a modal window or something, would you say their best bet is just vanilla JavaScript
**\[13:12\]** and not bother with Alpine or JQuery or any of these things? So like everything web development, it depends. You're right. That's the truth. So I tend to view these things through what is best for the user. And for me, the best JavaScript for the user is as little JavaScript as possible for a whole slew of reasons related to performance and just amount of data usage and a whole bunch of factors.
**\[13:46\]** Using as little JavaScript as possible will often produce a better experience for the people using the thing you built than throwing more at it. That gets complicated by the fact that poorly implemented JavaScript, but less of it is worse than more JavaScript better implemented. So when you start talking about things like models and drop downs, there are a whole bunch of accessibility considerations that you need to start taking to account. So someone who's visually impaired and moving around
**\[14:17\]** with a screen reader or trying to navigate by keyboard, can they actually use the thing that you've built? And drop downs and modal windows kind of seem like really simple things because they're everywhere. But doing them well is actually really complicated. Models in particular are notoriously badly done like 90% of the time. They're just always terrible. And where this gets really complicated is the promise of libraries like Alpine or View or React or whatever is, we can standardize
**\[14:50\]** a bunch of components and then we don't have to think about, you know, these are questions that just get solved by the library. The reality is, in most cases, libraries actually do a very poor job with this. There's the web aim is an accessibility organization that does kind of a study of the top million sites in the web every year. And one of the things they find consistently over and over again is that sites that use libraries have more accessibility hours than sites that don't.
**\[15:21\]** This year there was one kind of reversal of that trend. It was specifically around React, ironically, who for years kind of had an issue with this. And then over the last 12 months or so, I feel like really put a lot of energy into focusing on doing things more excessively. And so their sites actually had fewer accessibility errors on average than sites that use no library at all. Really long-winded way of answering your question, though, which is to say, it depends Generally, yes, I like to see people use less JavaScript in general, but depending on your
**\[15:56\]** level of comfort with code and your accessibility to access kind of off the shelf tools and then actually implement them. Like I have a short list of kind of drop-in plugins that I like to use, or there were plugins in the JQuery world in vanilla JS, they're just libraries. like really lightweight dependency-free libraries that do very specific things. Like, I have one I recommend for models. I have one I recommend for dropdowns. You can find those over at vanillajstoolkit.com.
**\[16:26\]** Like, I have a whole list of like- Also, these are drop-in libraries that you wrote yourself or that you're linking offsite to something that another person created. Yes, both. So, some of them are mine. Some of them are third party ones that I've vetted. I use my cell phone projects that I really like. The thing they all have in common is they're really, really tiny, like, you know, some of them are under a kill-a-bite. You know, but they, it's like just the barest amount of code. And they do just one thing.
**\[17:00\]** I think if I had one other criticism of modern web development, it's that we love, like, we love the Swiss Army knives that include all the things. And like a lot of times all we really need is like a spoon or a pair of scissors. like we don't need all these other things, right? So Chris, you touched on accessibility a lot, which is one of the things that we talk about regularly on this podcast, lots of episodes we touch on it and we have two episodes that we recorded specifically on accessibility. So it's a thing that we all support and find important.
**\[17:34\]** What I would like to know is how do you approach accessibility when you're writing JavaScript? Like, what are some of the best practices that you can do, especially since you're recommending that avoiding these multipurpose libraries as much as possible? It's tough, because accessibility is in many ways like a specialty or a discipline in and of itself. But it's also one of those things that is not just the responsibility of the accessibility person.
**\[18:06\]** Like as developers, we have an obligation to build things excessively. The same way that someone who's building a construction company has a responsibility to make sure that it's up to accessibility standards, like you have ramps and doors that are wide enough to accommodate wheelchairs and things like that. So there are a few great resources that I turn to all the time. I turn to all the time. So the first one is the A11Y project.
**\[18:39\]** A11Y is a neuronym that stands for, I may have pronounced that wrong, stands for accessibility. So you've got the A, you've got the Y, and then there's 11 letters in between. So A11Yproject.com has a ton of resources. Most importantly, for my purposes, they have a checklist of all the things that you'd like to see in a properly accessible site, everything from color contrast checkers to behavioral expectations.
**\[19:10\]** But it's a really big and potentially overwhelming list. It's the kind of thing where if you're working on a project, you want to make sure these are all the things you need to look for. People are going to be interacting with the things you've developed in a lot of ways. And if you're someone who does not have disabilities, you may not always think of these things. So if you're someone who navigates the web exclusively with your eyes and a mouse, the way you consume the web is gonna be a lot different
**\[19:42\]** than people who have a variety of disabilities might. So someone with neuromuscular capability, condition, for example, like let's say I have ALS have Parkinson's using a mouse is difficult for me. I may navigate the web exclusively with a keyboard. I am not visually impaired, I can still see, but I can't use a mouse. And so making sure that interactive components can be interacted with with just a keyboard is really, really important.
**\[20:14\]** Maybe I am visually impaired. And that could mean I can't see it all. It could mean that I'm low So I need to zoom in quite a bit on things to see them. It could mean I have some sort of condition that requires me to view things in a high contrast mode. I used to work with a developer who he had his colors on his screen in-versed and then he would literally put his face like right up to the monitor to see it. He didn't use a screen reader when he coded, but he would like put his eye like right up against the monitor
**\[20:45\]** and have it zoomed in at like 400%. And another extreme, you also have people who can't see it all. So they use a screen reader, which announces everything that's happening on the screen to them. And when you're just reading text on an article, that's relatively straightforward. But when you start getting into interactive components, it becomes a lot more nuanced. So for example, actually just this morning, I was making some updates to the search functionality on my website. And one of the things I realized I actually did a really bad job with is how someone who they type in a query and they hit enter or
**\[21:24\]** they hit the search button, how they know that results actually showed up because on my site it's instant but on something like WordPress, it actually loads an entirely new page and so like the screen reader will announce that you're now on a new page with this content, whereas mine's doing more of a JavaScript eating. So on my site, the way it's set up right now, it actually just starts reading the entirety of the search results, which at the time that I implemented it, I was like, OK, cool, it's going to announce all the content.
**\[21:57\]** In retrospect, that's terrible. People who use screen readers don't need every single piece of text that just showed up on the page automatically read to them. They need to know that there are now results. and then they can use their tools to navigate through them, however, they feel most comfortable. So I'm going to be updating that to announce, you know, like 27 articles found, for example. And then now that they know the information is visible, they can do something with it. I really like having in this situation
**\[22:29\]** do that kind of for rules. And accessibility is way more nuanced than that. And the disabled community is not a monolith. So what works for one person with a disability may work very poorly for someone else with that same disability. And kind of getting a sense for which approaches to use when is really something that you get better at with doing actual testing with real people
**\[23:00\]** who have disabilities with trying these things out yourself and kind of trying to navigate through your website with a screen reader turned on and seeing what happens. I did test out a screen reader and I made a recording of myself trying it out and it was difficult. It was a, and I went to a government website which was supposed to meet the accessibility standards and stuff, it was interesting. I recorded myself using it and I mean to revisit that sometime in the future.
**\[23:31\]** Now, one caveat about this, because I have this conversation with my students a lot. So a lot of people who use screen readers are very good at them. And they will use these tools way differently than someone who has no disabilities. And it's just like trying to use them will like the default settings, all the kind of the configurations in there. Like they can be very noisy by default and some people like that, some people don't. But like the experience you're getting
**\[24:01\]** as someone who's never used it before is very different from someone who's proficient in this tool and uses it every day. That said, a lot of people with disabilities don't have proficiency with these tools yet, and so they can potentially get bombarded with a lot of information. Sometimes the HTML alone can surface important information, but sometimes for interactive components, it can't. You need things like different ARIA attributes to let assistive technology like screen readers know what the component is supposed to be doing
**\[24:33\]** and what its current state is. And that gets really confusing, too. Like I often think about accordions and tab navigation as functionally the same thing. You have some content that's hidden, you click a thing, it becomes visible, and the other things go away. But from a screen reader expectation, they're actually different, and they have different expectations around already attributes and keyboard interactions and things like that. It's a one tool that I use all the time for this
**\[25:05\]** is A11Y Nutrition Cards from Dave Rupert. And it lists a bunch of common components and the keyboard behavior expectations and the ARIA attributes that you want to have and all that sort of goodness. So I just wanted to throw that in there because it's another really useful tool when you're building interactive stuff and you're trying to do it excessively. Cool. I'll make sure I get you all linked to all this too so you can drop it in the show notes. Oh yeah, absolutely, 100%. Thank you. Or I'll be Googling as I write the show notes.
**\[25:37\]** No worries, I have, I'm pulling these things up, so I'll just send it all over when we're done. Variable equals Amanda. If enjoy website 101 podcast equals true, then go give us a positive review on Apple Podcasts. I can't even do it with a straight face. or wherever you get your podcasts. So we've talked about disabilities and accessibility. You are a person living with ADHD.
**\[26:07\]** Yeah. Do you wanna talk about how that informs your work, your teaching, everything? Like, what, how does that, you know? Great question, Mike. Yeah. Oh, that's a good one. We could do like literally a whole episode just on this. So, just real high level, because ADHD, it's not new, But it's not new, but a lot of people's perception of it or understanding of it was really informed by the 80s and 90s when it was still kind of this newer thing that was poorly understood. So, ADHD is a very badly named condition.
**\[26:41\]** So it stands for Attention Deficit Hyperactivity Disorder. It used to be known as ADD or ADHD depending on whether people had the hyperactivity or not. Now they just, they call it all one thing and it has different kind of subtypes. Okay. It's very badly named because you do not have a deficit of attention with ADHD. You just have a very bad ability to regulate it. Sometimes, your attention may be split amongst a dozen different things. You're a little bit like a puppy at a dog park, just chasing after every ball that gets
**\[27:14\]** thrown around. Other times, you can actually go into something called hyperfocus where you become so fixated on the thing that you're interested in at the moment that you ignore everything else including like eating, going to the bathroom and you'll just, you'll come out of this whole 12 hours later like, oh, whoa, I got a lot done and I did not care for myself or my bodily needs at all today. It creates a whole, like a whole slew of interesting things and if we were to look at it But just in the context of web development, I find lots of animations on websites, which
**\[27:52\]** I know can be very invoked depending on who the designer is. I find them wildly distracting. They make it really difficult for me to kind of parse information. One of the other things that doesn't get talked about as much when we talk about accessibility is neurological impairments. So you may have people using your website who, whether it's ADHD or Down syndrome, it just takes them longer to process information. And so writing in very clear, plain language,
**\[28:26\]** short, simple sentences, being more direct in the way you communicate can go a really long way in helping people consume the information and get on with their life. A lot of government organizations talk about, you know, writing to like a fifth grade level, for example, or grade five level, depending on where you are, you know, it's specifically for that reason, you know, using big words, using lots of run-on sentences that can make you really difficult to kind of parse information. I hate parallax effects on websites.
**\[28:56\]** Here's my ADHD, and I'm bouncing around with a bunch of different ideas right now. I'm just sticking to one. But like parallax, scrolling animations, those sort of things, they do not work for me. I find them wildly distracting, and since we're talking about this, there is a setting in both Windows and Mac, and potentially Linux, that allows you to say that you prefer to reduce the amount of animation in your user interfaces. It's called, hold on, I need to look at that now.
**\[29:27\]** I think it's preferred-reduced motion. I think that's the best. Yes, and so there is both a media query that you can listen for in your CSS, And a way to listen for that in JavaScript as well, that you can use to turn off or dramatically reduce animations in the things you build. So for example, on my site, I have smooth scrolling turned on. So when you click an anchor link, it's gonna animate you down to that link.
**\[29:58\]** And for a lot of people, it's useful because it lets you know like, okay, the website just scrolled me down here, I didn't jump to a new page. But if you're someone who gets motion sickness or you find that disorienting, it can be a lot. So I have a media query that says if prefers reduced motion is enabled, don't do that. Disable the animation, just jump there right away. And I do that in a lot of my scripts as well. So if you have fancy parallax stuff going on on your site, you probably want to disable
**\[30:28\]** that if someone has prefers reduced motion turned on. Cool. I didn't even know that was a thing. Yeah. It's a newer kind of thing just in the last couple of years and a lot of folks don't know about it. One of the big discussions that I had with some friends the other day was around whether you need to disable all animations when prefers reduced motion is enabled or just some of them. For example, if you have animations that are specifically designed to draw attention to
**\[30:59\]** a piece of interaction that's really important for a user, like you need to click this button where you can't proceed. For example, like that kind of thing where a user might get confused, like, why isn't this doing anything? Like, do you want to disable that animation or not? And there wasn't really a concrete, concrete consensus on that one.
It was the kind of thing where it was like, well, it depends. You probably want to test it. Maybe you still want to keep the animation there, but you want to make it less like, jumpy or bouncy. So it's a little less disorienting for people, but you still want to do something to draw attention to it.
Like, maybe a subtle pulse versus
**\[31:33\]** like a screaming, hey, look at me, kind of animation, or maybe even reducing the speed of the animation. Well, even that thing you just mentioned about the skip link where you click link and it goes down to a lower part of the page. I wouldn't have thought that that would be something that would be disabled if they don't prefer the motion. I always thought that's always basically a UI or UX benefit that it tells them they're not in a new page, but I can see what you mean if you are disoriented by motion sickness
**\[32:04\]** or whatever, that could be an issue. I think that's an easy win, too, because I add the smooth scrolling to every site that I build. I think it's an easy win to disable it for prefers-reduced motion for sure. The issue for me is this is kind of going into another area here, but with clients, I'm currently working with two different clients, where one loves animation. Just goes nuts for it. Anything I do that has to do with animation, they just doesn't matter if it's helpful
**\[32:35\]** in any way. So it's really like... Give me all the glitter. Yeah. And another one that just does not want anything, and it looks like a very plain sight. I do my best for both of them, but sometimes that's the issue, right? I'm kind of like more like along your lines where I don't need all kinds of crazy parallax stuff and that going on, but it really is a matter of opinion for some people when accessibility is not involved, right? And then it becomes a whole issue of like, well, it's your website, but it's not really for you.
**\[33:06\]** It's for your audience and what do they want? And then the testing comes in and all the rest of it. I try to be really goal focused. So if your goal is X and the thing you are trying to do takes away from that goal, then like I'm not doing my job as a professional for you. Like my job is to make your site and the business that it supports as successful as possible. And so if the thing you want is going to negatively affect users and therefore create business issues for you,
**\[33:37\]** then that's a problem. You all live in Canada, I live in the US. There are some pretty strong accessibility laws in both of our countries. And in the US, lawsuits have started to really heat up around accessibility things. So, when carrot doesn't work, that's sometimes when stick comes out, you know, and we can talk about things like the Beyonce lawsuit. And you know, it seems like a really small thing. But if you don't tweak this color, you could get sued for a bunch of money and you don't want
**\[34:08\]** that. And sometimes that's enough to, you know, to do it. Yeah, nudge them in a direction. I want to get back to talking about the Javascript education and teaching the students. As I said before, I teach Seneca and development and the thing that's both cool and I feel weird about the program is that it's all of the students no matter what they're interested in, have to take the development class. So if you're interested in UIUX, if you're interested in design, if you're interested in development,
**\[34:41\]** all of the students take the development classes, all of the students take the design classes, all of the students take all of the classes. So I find that a big problem, especially when it comes to JavaScript, is that there's almost like this PTSD type of fear of even talking about JavaScript. Like do you have any recommendations and how do you get them pass that and start to get excited about, oh I'm gonna play, I'm gonna mess around, I'm gonna try to do this, I'm gonna, and then start to feel that that positive reinforcement
**\[35:11\]** of oh hey, I won, I made it do a thing. I think one of the biggest mistakes I see beginners make is trying to jump into projects that are too big too soon. And then you get really like, it just everything grinds to a halt, and then you give up. And you know, so I'll see students who like, they're like, I want to build an app. And then they just like jump right into like, I'm going to build it to do app, or I'm going And then they get really like, it just kind of starts to fall apart.
**\[35:46\]** And so I run this workshop program called the Vanilla JS Academy, where every other day you were getting a project, like a few lessons in a project. And at the end of the program, you've built like a few dozen things. And I'll give you an example, right? So one of the things we do is we build a game inspired by Monsters Inc. mind sweeper, where you have to open a bunch of doors to find all your monster friends, but if you find a door with a sock behind it, you lose.
**\[36:17\]** And we don't just start right off with, go build the game. You know, it's, here's an array of monsters, shuffle it and display them on the page. That's the entire task is just that. And it seems really simple. And it is, but it can also be a little bit challenging because we get into things like accessibility concerns and how do you know whenever things displayed and to people actually know what the monsters are like if I'm using a screen reader like does it just say monster monster monster monster like monster one two three or does
**\[36:47\]** it describe the monster you know that kind of thing and then we start to layer in features like okay now hide the monsters behind a door when the doors clicked show the monster okay cool now you've got a semi-functional game now let's do do something where you actually track, did they find the sock, they automatically lose, did they find all the monsters, they win, you know, like in kind of tracking that. And so rather than just jumping right to build the game, we start small and we layer in over time. And for someone who's totally new to JavaScript, I really like the show hide component as
**\[37:25\]** a starting point because it is so basic and touches on a lot of fundamentals. There's a button, here's some content. Click the button, hide it, click the button, show it again. And now how do you turn it into maybe more of an accordion? Where if you click one and you show the content, any other open pieces of content get hidden. But you don't do this all at once. You don't just jump into building a accordion. You start with one little thing and you layer. And I found once students do that once or twice, it becomes a much easier thing for them.
**\[37:57\]** They're like, oh, this is really cool. I'm going to go play with all this other stuff now. And they get a better sense of how to break big things up into little pieces that get kind of assembled like Legos over time. Yeah, it's a good approach. Thank you. You're welcome. So, Chris, what are your recommendations for novice developers just starting out other than what you just said, take your course? I mean, like, yeah, go become a farmer, go do something else. I joke. I love them.
**\[38:27\]** This web thing is never going to catch on. No, yeah, that start small is really one of the big ones. The other thing that I would recommend is if you Google how to get started or develop a roadmap, you'll find a lot of these like, here's all the things you need to know to become a web developer, and it's got like a million things on it, including all these libraries and frameworks and build tools, and you don't need most of that, especially not to get
**\[38:59\]** started. Beginner developers are not expected to know everything, and you can have an amazing career being a front of the front end developer who specializes just in CSS and HTML if you want. And so what I tell my students is find the thing that you're really excited about and dig into that. And then when you feel like you've hit a natural point where you want to pivot into something else or you find it no longer interesting, then pivot. But don't feel like you have to boil the ocean and learn all these things to get into this profession. There are still
**\[39:31\]** so many things I am absolutely just abysmal at. I was actually just talking with some friends the other day about how like I still build my back ends in PHP and try to avoid doing the back end stuff as much as possible because I'm really bad at it. And like I've even like pivoted now into, I don't even want to mess around with databases, I just use flat JSON files that I read and write into and out of because I'm not lazy now. But yeah, you don't have to know everything. It's really the key takeaway here. There's so many things you could learn,
**\[40:04\]** but you don't have to learn all those things. In fact, you probably shouldn't unless you really want to. You could go crazy trying to chase after all the things. Yeah. So we talked about novice developers, what about more seasoned developers like myself and Mike who are not particularly skilled at JavaScript, but we know CSS, we know HTML, we have fundamental understandings of accessibility and most of the other stuff that you need.
**\[40:35\]** But we want to improve our JavaScript skills. Where would you suggest that we start with something like that? Yeah, so I mean the obvious answer is gomakethings.com, obviously, but of course, of course. I can't say what the best approach is for everyone, but having a specific thing you're trying to accomplish, and remember, keep it small, and breaking that down into little parts
**\[41:06\]** and researching how to do just that little thing. That is a really good way to get better at these sorts of things. I gotta say you just spoke to me because last week, I did something brand new in JavaScript that I shared with both Amanda and Mike. Initially, I asked Amanda for some help, and she said, oh, I can help you later in the afternoon, but I wasn't patient. And I just started googling it, and I figured it out. It was something to do with fetch And I got it working.
**\[41:38\]** Basically, I followed your approach. It's like I broke it down into steps. Nice. Got a step done with lots of Googling and lots of comments in the code and success. Awesome. Yeah, and so that's the kind of thing where once you've gotten just a little bit comfortable, it becomes a bit easier to do. Over time, you start to get more efficient at Googling things. Like that is really, I think, the most important skill web developer can have is just knowing how to search efficiently and how to filter out
**\[42:09\]** like the good stuff from the garbage. One of the other things I will mention just because I know that Sean, you and Mike both kind of have that jQuery comfort. One of the things that helped me a lot when I was learning after I failed JavaScript interviews over and over again for two years was taking jQuery things and converting them into vanilla So rather than just trying to write from scratch, I would write a thing in jQuery and then be like, okay, how can I piece by piece start to convert this
**\[42:39\]** into just a plain old vanilla JavaScript thing? And I got a really good understanding of the fundamentals from doing that. It's very possible that this last question is going to be a bit of an oxymoron because what is coming up in JavaScript? What are you really excited about? But if you're excited about just going back the throwbacks to vanilla JavaScript, it's been around forever. It's not changing. So there's two angles to this. And for me, new JavaScript features are great
**\[43:12\]** because they usually replace things that we have to rely on libraries for. And so anytime I can cut a library out, that is a great thing. I love platform native features. The caveat to this is I am someone who really likes broad browser support, and so I tend not to pay much attention to what's future roadmap because I don't want to have to run build processes that like patch new features back for old browsers. I just want to be able to write them and have them work everywhere and not have to like run
**\[43:46\]** a build step. But that said, the two things that I am most excited for. There is a new dates and JavaScript have always been terrible to work with. There is a new temporal API in the works that will take all of these things that people have had to use like DateJS or DateFNS or all these like third party libraries for and just do them way more easily. It's like a really smart, sensible API that will make working with dates a lot easier and
**\[44:19\]** working with time zones and all sorts of fun stuff like that, fun stuff, quote-unquote. If you're a nerd who's into that sort of thing. That sounds so nice, I'm so looking forward to that. The other thing, and I actually think this one is way more important personally, is there is another API in the works that is designed specifically for sanitizing HTML strings. So you can do, I've got some API data and I'm going to wrap it into HTML and inject it
**\[44:51\]** into the UI really easily today without a library. The problem is third party content can have malicious code in it. And when you inject it into the UI, it can open you up to a whole slew of cross site scripting and security issues. And it's really, really dangerous. And so there is a new spec in the works that will give you a browser-native way to sanitize this stuff. Just build right into the browser so you don't have to worry about doing that yourself. Did I do it right?
**\[45:22\]** Is this library up to date? Is there some new attack I didn't know about that's going to completely do me in? And so just being able to say, here's a string of HTML. It's got some third-party stuff. I don't know what's in there. Pass it through this method. Get the clean HTML back out. I cannot wait for that to hit browsers because it will make my life a million times easier. Sounds good to me. Well, I, for one, am very, you know, excited to get going. You've made it clear that I don't have to dive into
**\[45:52\]** react full fledged right now because I don't want it to, but yeah, I'm gonna definitely take your advice and learn things piece by piece. Yeah, I really, really enjoyed this conversation, Chris. Thank you so much for coming on. Amanda, Sean, Mike, thank you for having me so much on. One thing I just want to mention, for anybody who's listened here, if you loved what we talked about, you want to dig into any of the things we talked about a bit more detail. At gomakethings.com slash website 101, I've put together a custom page with links to all of the stuff
**\[46:22\]** we've been talking about, as well as a bunch of related articles and podcasts and things like that, just if you want to dig deeper on any of this. Excellent. Great. Thank you. All right. Thanks very much. Hey, thanks for listening today. This is Mike Mella. You can find me online at belikewater.ca or on socials at Mike Mella. The website 101 Podcast is hosted by me, Sean Smith. You can find me online at my website, caffeinecreation.ca, and on LinkedIn, where my username is, caffeine
**\[47:00\]** Creations. One third of the website 101 Podcast Talent is provided by me, Amanda Loots. You can find me online at my website, AmandaLoots.com. I also hang out on Twitter sometimes. You can find me at Amanda Loots T.O. Go ahead, someone else take over. I'll always take over after the guest talks. We should plan that too. I'll cut all this out. Go ahead. Or you could leave it in. I love a good awkward transition.
**\[47:30\]** We often put this stuff in the, well, not often, we're starting to put them in outtakes, but it might make it in there.
Close Transcript
Have a question for Sean, Mike, and Amanda? [Send us an email](/contact).
[](https://www.google.com/podcasts?feed=aHR0cHM6Ly93ZWJzaXRlMTAxcG9kY2FzdC5jb20vZmVlZC5yc3M%3D)[](https://itunes.apple.com/ca/podcast/website-101-podcast/id1449510012)[](https://open.spotify.com/show/3rmSM1R9t6q1U8DmYWJRSO?si=NrYPMgDaRV6Dd56PjEaPow)### Season 05
- 1 [ Meet your Host - Sean](https://website101podcast.com/episodes/season-05/episode-1/meet-your-host-sean/)
- 2 [ Meet Your Host - Mike Mella](https://website101podcast.com/episodes/season-05/episode-2/meet-your-host-mike-mella/)
- 3 [ Wes Bos - Your Web Boss](https://website101podcast.com/episodes/season-05/episode-3/wes-bos-your-web-boss/)
- 4 [ Tailwind CSS with Adam Wathan](https://website101podcast.com/episodes/season-05/episode-4/tailwind-css-with-adam-wathan/)
- 5 [ Starting my own Website with Bill Campbell](https://website101podcast.com/episodes/season-05/episode-5/starting-my-own-website-with-bill-campbell/)
- 6 [ CSS is Awesome with Kevin Powell](https://website101podcast.com/episodes/season-05/episode-6/css-is-awesome-with-kevin-powell/)
- 7 [ Meet Your Host - Amanda](https://website101podcast.com/episodes/season-05/episode-7/meet-your-host-amanda/)
- 8 [ 11 Things to avoid doing on your website](https://website101podcast.com/episodes/season-05/episode-8/11-things-to-avoid-doing-on-your-website/)
- 9 [ Vanilla Javascript - Fundamentals before Frameworks](https://website101podcast.com/episodes/season-05/episode-9/vanilla-javascript-fundamentals-before-frameworks/)
- 10 [ Hiring Junior Devs and How to Stand Out from the Crowd](https://website101podcast.com/episodes/season-05/episode-10/hiring-junior-devs-and-how-to-stand-out-from-the-crowd/)
- 11 [ AlpineJS with Caleb Porzio: Lightweight javascript in your markup.](https://website101podcast.com/episodes/season-05/episode-11/alpinejs-with-caleb-porzio-lightweight-javascript-in-your-markup/)
- 12 [ Contract Opinions From Not a Lawyer](https://website101podcast.com/episodes/season-05/episode-12/contract-opinions-from-not-a-lawyer/)
- 13 [ Talking to a New Dev](https://website101podcast.com/episodes/season-05/episode-13/talking-to-a-new-dev/)
### All Seasons
- [Season 01](https://website101podcast.com/season/01/)
- [Season 02](https://website101podcast.com/season/02/)
- [Season 03](https://website101podcast.com/season/03/)
- [Season 04](https://website101podcast.com/season/04/)
- [Season 05](https://website101podcast.com/season/05/)
- [Season 06](https://website101podcast.com/season/06/)
- [Season 07](https://website101podcast.com/season/07/)
- [Season 08](https://website101podcast.com/season/08/)
- [Season 09](https://website101podcast.com/season/09/)
<!\[CDATA\[YII-BLOCK-BODY-END\]\]>