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 Mela.

They are Amanda Lutz and Sean Smith. Hi friends. Hey Mike. How's it going? We're all good here. Ready to roll. Got an exciting episode. Yeah, today we're going to talk about the 800 pound gorilla of web development JavaScript.

And we're going to talk about it with Chris Ferdinandi from the vanilla JavaScript podcast. Chris, welcome to the show. Hey everyone. Thanks so much for having me. Amanda, why don't you start off.

We're a resident JavaScript expert. Yeah, okay. Well the very first thing that we need to know is Well, I do know the JavaScript Chris has obviously got a lot of knowledge happening Chris. Tell us a bit about your background

Yeah, so I I'm a JavaScript educator my full-time job is teaching people JavaScript 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 kind of 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 kind of ethos is that we should be using less of it Right and just just heads up though for just before if I can fit this in here Amanda obviously knows all kinds of stuff about

JavaScript. I don't. I'm kind of, I 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 Sean? Yeah, I would say me and Mike are pretty equivalent. We're x jQuery guys

who struggle with regular JavaScript. And we're both kind of fans of Alpine because it's, that's a sprinkle in the JavaScript 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, 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. So do you only do the teaching online 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. 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 ebook 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 project kind of things for people who prefer to learn by like doing, but need maybe a little bit help getting started.

Oh, I'm interested in that. Hmm. Cool. 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 or better way.

Can you give some examples of what you consider over-engineering? Yeah, absolutely. So I know you both mentioned Alpine JS and so I'm just going to kind of... rag on frameworks from it here. But one of the big trends we've seen in the last few years

is 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. 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 gate keep 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 right now, are you specifically talking about some of the frameworks that work together to do these single page applications?

Yes. Like React and View and Angular. That's a big part of it, for sure. So we're talking about the 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. 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. But 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 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, 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. 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, this is not necessarily JavaScript related,

but the other day I was having an issue with my local, 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 made a workaround and I was like, oh, well, this will work for now. That thing can happen when you have all these dependencies on dependencies and plug-ins for a library and it just drives me crazy having to keep up with all that stuff.

Yeah! Yeah, especially like you throw in like a build process where you're using something like Laravel mix or Vite or Webpack, those things just overly complicate 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 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 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 then 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 you know, nothing against these tools. So like if you have a, I have strong feelings, but like, so there's a few, I think threads

we could pull out. First is I really, really strongly believe that if you are, if you're just learning. then the thing that's going to keep your momentum up as a learner is way more important than picking the perfect tool.

I think where I see beginners kind of 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, 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. 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

And that's probably just a bias for me. I don't have a computer science background It's a lot of the concepts of these more modern frameworks. They hurt my head Yeah, but you know, so that's 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 an industry treat them in a lot of instances as kind of like 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 is 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 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 too 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. WordPress is not good for that. So yeah, I absolutely agree with what you're saying.

I hope the listeners can hear me nodding. I really like that you're pushing for fundamentals. 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 regular JavaScript, and that's because we didn't really learn the fundamentals. But if you want to talk CSS, I have mastered 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 with JavaScript and it's always a jQuery solution. They just assume you're using jQuery because the solution was written in some time the

past 10 years or whatever that hell of a long that's been running. So would you say then that most developers WordPress is a little different, I guess, because it 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 and not bother with Alpine or jQuery or any of these things?

No, that was a great production part. Another sellout from the Sketch++ app here in settings, at the same time, or even predictably. beneficial. Like everything web development, it depends. Um, right.

That's the truth. So, um, I tend to view these things through like, what is best for the user? And for me, what is best for the user? Like the best, the best JavaScript for the user is as little JavaScript as possible

for a whole slew of reasons related to kind of performance and just, you know, amount of data usage and like a whole bunch of factors 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. Um, right. 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 modals

and drop downs, there are a whole bunch of accessibility considerations that you need to start taking into account. So someone who's visually impaired and moving around 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.

Modals 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 a bunch of components and then we don't have to think about, 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 a 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 errors than sites that don't. 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 efforts 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 level of comfort with code and your

ability to access kind of off-the-shelf tools and then actually implement them. You know, like I have a short list of kind of drop-in plugins that I like to use. There were plugins in the jQuery world, like Vanilla JS, they're just libraries, but like

really lightweight dependency-free libraries that do very specific things. Like I have one I recommend for modals, I have one I recommend for drop-downs. You can find those over at vanilla.jstoolkit.com.

Like I have a whole list of like- Oh, so these are- drop in libraries that you wrote yourself or that you've just you're linking off site to something that another person created. Yes, both. So some of them are

mine, some of them are third party ones that that I I've vetted. I I use myself on 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 kilobyte you know but

they they're it's like just the barest amount of code and they do just one thing. 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. So Chris you you touched on accessibility a lot which is one of the things that we've talked about regularly

on this podcast. Lots of episodes we touch on it and we have two episodes that we recorded specifically on accessibility. It's a thing that we all support and find important. 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, you know, avoiding these multi-purpose 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.

Like as developers, we have an obligation to... building things excessively, the same way that someone who's building, like a construction company has a responsibility to make sure that it's up to accessibility standards like

you need to 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. So the first one is the A11Y project.

A11Y is a neuro-nem that stands for it. I may have pronounced that wrong. It 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 kind of color contrast checkers to kind of behavioral expectations.

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 going to be a lot

different than people who have a variety of disabilities might. So someone with neuromuscular capability, a condition, for example, like let's say I have ALS or 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. Maybe I am visually impaired and that could mean I can't see it all. It could mean that I'm low vision 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 inversed 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 put his eye right up against the monitor and

have it zoomed in at like 400%. 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. 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. For example, actually just this morning I was making some updates to the search functionality on my website. 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 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. The screen reader will announce

that you're now on a new page with this content. Where's mine's doing more of a JavaScript thing? 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, okay, cool, it's going to announce all the content. In retrospect, that's terrible. Like, 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 do that kind of 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 kind

of you get better at with. doing actual testing with real people 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. And I went to a government website which is 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. 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 is just trying to use them will. Like the default settings, all the kind of configurations in there, they can be very noisy by default.

And some people like that, some people don't. But like the experience you're getting is someone who's never used it before is very different from someone who's like 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, 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 and what its current state is. And that gets really confusing too.

Like I often think about like 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 ARIA attributes and keyboard interactions and things like that. It's a one tool that I use all the time for this 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.

I'll make sure I get you all links to all this too so you can drop it in the show notes. Oh yeah absolutely 100% thank you or I'll be or I'll be googling as as I write the show notes. No worries 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 this free face or wherever you get your podcast. So we've talked about disabilities and

accessibility. You are a person living with ADHD. Yeah do you want to talk about how that informs your work, your teaching, everything. How does that you know. Great question Mike. Yeah that's a good one we could do like

literally a whole episode just on this. So just real high level because ADHD is not new but a lot of people's perception of it or understanding of it was really informed by like 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 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. 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 and so sometimes your attention may be

split amongst a dozen different things and so you're a little bit like like a puppy at a dog park just kind of chasing after every ball that gets thrown around. Other times you can actually go into something called hyper

focus 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

well I got a lot done and I did not care for myself for my bodily needs at all today. Yeah it creates a whole like a whole slew of interesting things and if we were to look at it just in the context of web development I find

Lots of animations on websites, which I know can be very invoque, depending on who the designer is. I find them wildly distracting. They make it really difficult for me to parse information. One of the other things that doesn't get talked about as much

when we talk about accessibility is neurological impairments. And 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, 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 writing to a fifth grade level, for example, or grade five level, depending on where you are. And specifically for that reason. Using big words, using lots of run-on sentences

that can make it really difficult to parse information. I hate parallax effects on websites. Here's my ADHD cooking. And I'm bouncing around to a bunch of different ideas right now. This is just sticking to one.

But 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 this now. Reduced motion, I think it's preferred reduced motion.

I think that's the thing that comes from. And so there is a 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. And it's 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. Like disable the

animation, just jump there right away. And I do that in a lot of my scripts as well. So if you have like fancy parallax stuff going on on your site, you probably want to disable that if someone has prefers reduced motion turned on. Cool. I didn't even know that was

a thing. Yeah. Yeah. It's um, it's, 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. So like for example if you have animations that are specifically designed to draw attention to a piece of interaction that's really important for a user like you need to click this button

or 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 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 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 would be 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 or whatever that could be an issue for sure. 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. Yeah, 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, it just doesn't matter if it's helpful 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, and 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. 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 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. you, 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, 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 that. And sometimes that's enough 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, 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 past 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 positive reinforcement 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 wanna build an app. And then they just like jump right into like, I'm gonna build it to do app,

I'm gonna build it and then they get really like. It just everything just kind of kind of starts to fall apart. 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 built a game inspired by Monsters Inc. and Minesweeper

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. We don't just start right off with, go build a game. Here's an array of monsters, shuffle it and display them on the page.

That's the entire task is just that. It seems really simple. It is but it can also be a little bit challenging because we get into things like accessibility concerns and how do you know when everything's displayed?

Do people actually know what the monsters are? If I'm using a screen reader, like does it just say monster, monster, monster, monster, monster, monster, one, two, three or does 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 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. 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, like, the show hide component as a starting point because it is so basic and touches on a lot of fundamentals. Here'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 build an 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. What they're like, oh, this is really cool.

I'm gonna 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, take your course. Yeah, no.

Go become a farmer, go do something else. I joke, I love this. Web thing is never gonna catch on. Right? Yeah. No, yeah, that's, Start Small is really the, is really one of the big ones. The other thing that I would recommend is if you Google like how to get started or like

developer 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. Right. You know, including all these libraries and frameworks and build tools and like you don't

need most of that, especially not to get 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 so many things. I am absolutely. just a bismal ad. I was actually just talking with some friends the other day

about how I still build my backends in PHP and try to avoid doing the back end stuff as much as possible because I'm really bad at it. And I've even 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,

but you don't have to learn all those things. In fact, you probably shouldn't, unless you really want to. Like 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.

But we want to improve our JavaScript skills. Where would you suggest that we start with something like that? Yeah, yeah, so I mean the obvious answer is gomakethings.com, obviously. 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 and researching how to do just that little thing,

that is a really good... 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.

And 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.

Basically, I followed your approach. It's like I broke it down into steps. Nice. I 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 a web developer can have

is just knowing. how to search efficiently and how to filter out 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 JS things. 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 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

like what is coming up in JavaScript? Like what are you really excited about? But if you're excited about just going back to 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 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 wanna 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 a build step. But that said, the two things that I am most excited for, there is a new dates in JavaScript

have always been terrible to work with. True. There's a new temporal API in the works that will take all of these things that people have had to use like date.js or a date.js or date.fns or all these like third party libraries for.

And just do them way more easily. And it's like a really smart sensible API that will make working with dates a lot easier and 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 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? 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 cleaned 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, react full fledged right now, because I don't want to, but yeah, I'm gonna definitely take your advice and learn things piece by piece. Yeah, I 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 wanna mention, for anybody who's listened here, if you loved what we talked about, you wanna 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... Oh my, cool. Links to all of the stuff we've been talking about, as well as a bunch of related articles and...

Amazing. Podcasts and things like that, just if you wanna dig deeper on any of this. Excellent. Great, thank you. All right, thanks very much. Thanks for listening today. This is Mike Mela. You can find me online at belikewater.ca

or on socials at Mike Mela. The website 101 podcast is hosted by me, Sean Smith. You can find me online at my website, caffeinecrations.ca and on LinkedIn where my username is caffeinecrations. One third of the website 101 podcast talent is provided by me, Amanda Lutz.

You can find me online at my website, amandolutes.com. I also hang out on Twitter sometimes. You can find me at Amanda LutzTO.