Guest Chris Ferdinandi
Season 05 Episode 9
– May 03, 2022
47:37 Show Notes
- Chris's background and history with web development
- Single Page Applications
- Tiny libraries that Chris recommends at: The Vanilla JS Toolkit
- Living with ADHD
- Recommendations for novice developers starting out
- Go Make Things - Website 101 Podcast Listener Page
Accuracy of transcript is dependant on AI technology.
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.
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
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
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.
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.
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 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
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,
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.
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,
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.
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.
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
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
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.
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,
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,
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
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.
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,
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
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
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.
Have a question for Sean, Mike, and Amanda? Send us an email.
- 1 Meet your Host - Sean
- 2 Meet Your Host - Mike Mella
- 3 Wes Bos - Your Web Boss
- 4 Tailwind CSS with Adam Wathan
- 5 Starting my own Website with Bill Campbell
- 6 CSS is Awesome with Kevin Powell
- 7 Meet Your Host - Amanda
- 8 11 Things to avoid doing on your website
- 10 Hiring Junior Devs and How to Stand Out from the Crowd
- 12 Contract Opinions From Not a Lawyer
- 13 Talking to a New Dev