961: Keeping Up With the Fast and Furious Web ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fmegaphone.imgix.net%2Fpodcasts%2F5197fe5a-42f7-11f0-affd-87d9985a1760%2Fimage%2Fc86a54acd72683732c4773e25bf0ae14.png%3Fixlib%3Drails-4.3.1%26max-w%3D3000%26max-h%3D3000%26fit%3Dcrop%26auto%3Dformat%2Ccompress&w=512&h=512) ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 961: Keeping Up With the Fast and Furious Web - Category: #podcasts - URL: https://share.snipd.com/episode/22dcda7c-4801-4778-aab3-723ab3525552 ## Document Notes ## Highlights - **Judge Tech By User Benefit** - Understand why a new tool or library exists before committing to learn it. - Ask whether it meaningfully improves your users' experience before diving in. Transcript: Scott Tolinski They lament the next library. Now I got to learn this, the new frame. There's another new framework. Like I've seen all the comments. I've been on YouTube since 2012. So like, I know what people think and say about all this stuff. And I think that one of the key points is, one, you don't have to learn everything that's new. But you should understand why things exist and know that if it will benefit your users or not. Because at the end of the day, the people using your applications are really what matters. So when you're approaching what to learn, take a surface level view of, is this thing going to improve my users' lives in a meaningful way before taking that moment to really go deep on Something? Because again, at the end of the day, the user's experience is really what matters there. So like, when I see comments about like, oh, another new JS framework, it's like, well, you don't have to use it. But also like, what if this new idea unlocks a massive amount of new things for us? And I never want to like, dump on anybody's experience of like, having that attempt to build something that will change things massively for users. So that's tip number one, understand why things exist before you want to dive into if I need to learn this. ([Time 0:03:34](https://share.snipd.com/snip/6526252b-a3a4-4fb5-ba46-2496362da4db)) - **Mix Modalities To Solidify Learning** - Learning styles as rigid categories are misleading and often overemphasized. - Use multiple modalities (read, hear, do) because each strengthens understanding differently. Transcript: Scott Tolinski When you do want to dive in and learn something, I think one thing that I think often gets overlooked is this idea of learning styles. Learning styles, I don't know if you know this, is a controversial topic for some reason. It doesn't exist. It doesn't exist. I was actually, this is a story that I haven't told necessarily before because I don't know if I'm bound by any sort of legal obligation. There was a company that was attempting to acquire Level Up Tutorials. And I was in an essentially like an interview with this company about whether or not they wanted to acquire us and the guy I was like oh I'm about to go give this talk and I'm it's a it's a talking About how like I learn things uh differently than other people and he's like or I says about like learning things fast or something okay and this was back when I first gave this talk and He was like oh that's really interesting I also doing like a talk about like learning things. I was like, oh, that's, that's cool. Cause this guy wasn't a tech person. He was like a business guy. And I was like, okay, so like, uh, he's, he's like, so what's your talk about? He's like, well, it's about how learning styles don't exist. And I was like, oh shoot. I'm like, well, I think there's a hangup around that word or something. CJ Reynolds Right. Yeah. And if I can talk a bit about it, because I have a bit of an education background, like working as a full stacked instructor, like we had instructional organizers, people helping us come Up with curriculum and how to teach it. And I think the idea of learning styles itself, that every person has a specific way that they like to learn, that's a myth because we all learn in different ways. I think the right way to talk about it would be like, sure, I identify more with visual learning versus like actual like hands-on. And these are the different types of learning styles. Like are you a hands-on learner? Are you a visual learner? Do you need to hear it first? But in my mind, everyone can learn from every one of those things and should be learning from every one of those things. I think that's one of the main issues with learning styles is you don't want to just focus in on one of those areas because you actually, even if you do gravitate towards visual learning, Hands-on is still great for everyone regardless of if you like it or if you think it's effective. I think basically changing modalities really helps solidify concepts because just taking it in one way isn't going to be the way that you learn that thing. You have to get it hands on. You have to hear about it. You have to talk about it. So I think that's the main myth is like, we're not just one. ([Time 0:05:05](https://share.snipd.com/snip/d5689784-f7ff-45ef-8318-97c5e97a3f1d)) - **Personal Learning Preference From Tests** - Scott shared how his wife ran psychological tests and revealed his uneven processing strengths. - He prefers audio/video because written text doesn't always register for him. Transcript: Scott Tolinski But let me tell you, so you've met my wife, Dr. Tolinsky. When we first started dating, she was in grad school to become a psychologist and she had to perform x amount of like tests and so she did literally every psychological test like known To man to me in our first like year of dating uh so she knew what she was getting into wow if according to you did you it was happening or was it like a slide? CJ Reynolds Oh, no. Yes. These are very involved tests. Scott Tolinski Okay. They're very involved tests. She gave them to my friends. She was diagnosing people, not like literally, but like. Sure, practicing. Yeah, yeah. And one of the things that we discovered through my psychological exams with my wife is that I have no IQ. My IQ is invalidated by my results of the test because I did really well in some areas and very poorly in others. And some of that is defined by like my learning disability, whether that's dyslexia or whatever, but my brain does not process written word the same way it processes audio. And I always got on YouTube a lot of comments when I first started that video is really bad for learning. I can't learn on video. People should read blogs. They should read documentation. They should read the code. They shouldn't watch on like, I would publish videos and people would show up in my videos just to be like, why are you teaching programming on YouTube? And like in 2025, we can know how stupid of a comment that is. But like, for me, I never understood that because it's like, I need to hear somebody talk it through with me. And honestly, if it was somebody reading the documentation in a nice way, like I consume that better. And I do actually, when I read blog posts, I select and do text to speech because otherwise, I am not like physically able to really comprehend it as well. So I do think our brains do function differently. Now, I do agree that like having hands on having the different types of ways that you can learn things are all helpful to have that wide breadth for everyone. But in the same regard, like if you plop down a book in front of me and tell me to read this book, or if you give me an audio book, I'm going to walk away with two very different understandings Of that material. ([Time 0:07:56](https://share.snipd.com/snip/44d13d0a-4f4d-46aa-ae37-02afebef4006)) - **Play Fast, Then Debug** - Get hands-on as fast as possible and play with interactive demos to connect concepts. - Start coding before reading every doc so you surface real errors and learn how to fix them. Transcript: Scott Tolinski Make a lot of but getting your hands dirty, number two, very much an important part of the process. I try to get my hands dirty as fast as possible, even before I fully understand what the heck it is. So we just interviewed Evo Plaza about TypeGPU. And the number one thing I loved about TypeGPU is that they have a massive amount of interactive docs. I can get in there, I can change some values, I can see how it affects visually this thing that's being outputted. And that to me is so much richer of a learning experience than just like, all right, now I've got an NPM, let's get started. And then maybe the thing doesn't work. And then you're like, all right, I'm done. CJ Reynolds The interactive example is like in the world of education, it's like this idea of play. It helps a lot with kids. Because when they're playing, they're actually learning. But when we can go in and change a value and see it immediately reflected in the demos, that's huge for us because that connects the dots. Like, okay, now when I'm writing my own code with this library, that's what that value is for versus just telling somebody what that value is for. Scott Tolinski Yeah. Wes and I recorded an episode about like Strudel and some of these other things. It's for like making music in the browser with chain methods. And it's awesome. And Wes knows nothing about audio. And he was in there and just like messing with values and being like, oh, I made a hi-hat. Like he has no idea what he's doing there. And he was able to get something like real out there very quickly by playing around with it. That is like my number one hack for if you have the focus time to get your hands dirty and play that like makes such a huge impact on things. When I'm learning something to teach someone else, I will start working on this and start getting into the code without reading docs, without just glancing at things. And then when I hit little hiccups, those are the hiccups that people who don't read the documentation deeply beforehand are going to hit. And people miss stuff all the time, especially if they're looking at the docs. They're going to miss little things. They're going to hit a bug. And if you can get out in front of that and learn where all of the edges are ahead of time, you'll know, obviously, you hit edges, you find the answer. You hit edges, you find the answer. And that can get you, that's obviously not the most optimized way or anything like that. ([Time 0:11:03](https://share.snipd.com/snip/9a46b38c-064f-4179-995d-7a886acf3548)) - **Interactive Docs Accelerate Learning** - Scott described enjoying TypeGPU's interactive docs that let him tweak values and see results. - Wes (referenced) made music quickly by experimenting, showing play accelerates tangible results. Transcript: Scott Tolinski And the number one thing I loved about TypeGPU is that they have a massive amount of interactive docs. I can get in there, I can change some values, I can see how it affects visually this thing that's being outputted. And that to me is so much richer of a learning experience than just like, all right, now I've got an NPM, let's get started. And then maybe the thing doesn't work. And then you're like, all right, I'm done. CJ Reynolds The interactive example is like in the world of education, it's like this idea of play. It helps a lot with kids. Because when they're playing, they're actually learning. But when we can go in and change a value and see it immediately reflected in the demos, that's huge for us because that connects the dots. Like, okay, now when I'm writing my own code with this library, that's what that value is for versus just telling somebody what that value is for. Scott Tolinski Yeah. Wes and I recorded an episode about like Strudel and some of these other things. It's for like making music in the browser with chain methods. And it's awesome. And Wes knows nothing about audio. And he was in there and just like messing with values and being like, oh, I made a hi-hat. Like he has no idea what he's doing there. And he was able to get something like real out there very quickly by playing around with it. ([Time 0:11:18](https://share.snipd.com/snip/b0e2fc64-ec93-4796-bb3d-a3c749fdcd05)) - **Choose Projects You Care About** - Build projects you actually want instead of generic tutorials to force yourself to push through blockers. - Let passion for the problem drive persistence and deeper learning. Transcript: Scott Tolinski We hear all the time on here about like people being stuck in tutorial hell, pick a project that is something you actually want in your life. And push through that. One of my my favorite things to say is like, if you're building in, let's say I want to learn zero, zero sync, like local data syncing software. And you're like, I'm going to build a to do list because that makes sense. And then you hit an edge. And maybe you can't figure it out. A lot of percentage of people at that point, depending on how hard of an edge that is of like, Oh, shoot, I'm stuck. Aren't going to have the desire to push through that. And like that pushing through an edge there is like where so much good learning happens every single time. And so because of that, like one of the things I always suggest is really pushing that project to be something that you want. I say like let passion drive the learning. Where, like, if I'm building an app for my mom and it's not working, and I've already, like, dedicated that energy to be like, my mom needs this app. ([Time 0:13:41](https://share.snipd.com/snip/230c93e5-47a1-4dd5-b257-d049ca4f9bc2)) - **Prioritize Fundamentals And Debugging** - Master core fundamentals (browser APIs, CSS, JavaScript) because they transfer across tools. - Spend time improving debugging skill since finding the bug is often half the fix. Transcript: Scott Tolinski Something I can always suggest to people too is like we live in such a time where like all these libraries are hyper-focused on library-specific information. But the core fundamentals of stuff cannot be overstated. How important it is to learn browser APIs, to learn CSS deeply, to learn JavaScript as it is JavaScript and not some library implementation of it, to learn these things deeply. But not only that, like big concepts. When you're learning, right now a lot of people are learning, there's a thousand AI buzzwords and stuff like that, and some people are going to spend their time learning this specific Platform, specific way of doing things. Your time would be way better served learning what all of the big concepts are. I always say it's like learning the stuff that you can take with you because whether or not you agree with this or not, React is not always going to be the thing. And some people disagree with that, but it might not always be the thing. Just like Angular at one point was the thing, just like Backbone was the one. And React is obviously different than Backbone and Angular, but in terms of where it exists in the industry, in terms of the size and magnitude there. But learning the things that you can take with you from thing to thing and debugging those core issues, those core concepts will always serve you well no matter what. And on top of that, like I said, just debugging in general. And you mentioned it before, like pushing through those edges is where you pick up so much stuff, but it's also where you learn the skills to debug. Half the time when we're trying to solve a bug, it's just trying to figure out what the heck the bug even is. And so if you can reduce your time to finding what the bug is, your chances are finding how to fix it is endlessly faster. ([Time 0:16:14](https://share.snipd.com/snip/3acb054a-473f-4d8d-906a-90202f79d6e7)) - **Question Strong Claims And Hype** - Resist absolutist claims and marketing-driven dogma around tools and frameworks. - Treat paid endorsements and strong-sounding exclusivity as signals to investigate motives. Transcript: Scott Tolinski Yeah. Speaking about buying into the hype, I have a slide that says resist dogma. Influencers are lying to you for clicks. Let me tell you, there are so many times that I get an email from some company wanting to push their thing and offer some money for me to push it. And we don't accept sponsorship on Century. Perfect timing on Syntax, but we are owned by Sentry, right? And so because of that, I get to say no to all those things, which is great. But it's also very interesting to see other folks talk about the same thing you were just pitched without disclosing it's an advertisement. And I can see it. You are not being honest with this. And it is kind of shocking sometimes. And then I'll see those people's opinions then being echoed by people on Reddit or people on Twitter verbatim. And then it's like, oh man, that marketing campaign really worked. Like they really hit on that. Yeah. CJ Reynolds Marketing in the world of dev these days, is absolutely crazy. And it's kind of like evolved over the past five years or so. But that's another thing that we kind of have to learn and realize what's happening is like, when are you being advertised to? And when is something being hyped up? Versus when is this like an staying technology that's like foundational and is going to be used for years to come? That's another thing that we have to work on and be aware of. Scott Tolinski I think something, a good test for that is if somebody is saying like, this is the only way to do things and it's like a paid product. You know, if it's a paid product, then they're like, this is it. This is changes everything like that kind of approach. Now, I'm going to show Svelte all day long, but there's no financial anything involved in that, right? There's no I don't mean there's nowhere to Yeah, like, we like the framework. Yeah, we like the framework. And same thing with like view, right? I'm going to say nice things about it all day long. But yeah, it is something to be aware of that people who are saying, use this, never use this, you only use this, or this is the only way to do things. If somebody says, this is the only way to do things, they might not be saying it for financial gain, but they're saying for your clicks because it's not true. So resist that like dogma of this is the, the, the cult of this particular library or framework. They're all tools for your users, the users at the end of the day, they matter. ([Time 0:18:59](https://share.snipd.com/snip/4f638b0d-cfd7-4ad3-9649-503628c93d45)) - **Use AI As A Learning Assistant** - Use AI intentionally to summarize, explain, and generate scaffolding, but always verify outputs. - Avoid outsourcing learning to AI; write the code yourself to truly learn. Transcript: Scott Tolinski Yeah. AI. We haven't said the words AI. I know CJ, we got to say AI for the clicks. No, CJ has had a lot of great videos about AI and development. The thing I will say is that AI can be useful for learning, but used intentionally for learning. Summarize this. I read this paragraph eight times and I don't understand what it's saying. Summarize it. Explain it to me like I'm five. Here's a bunch of code. I have no idea what it's doing. But the things that are important is like don't trust it. It lies to you. Do not trust it. It will tell you all kinds of stuff. But also like you can use it to aid in your learning, whether that is more advanced text-to whether that is a back-and whether that is using it to compare things. That if you're giving it this bit of information and this bit of information, compare these two things. So get that information, then validate. But don't have—if you're trying to learn a topic, I'm trying to learn React.js. Don't go to your AI tool and say, write this React function for me. You're not going to learn shit that way. You're not going to learn anything. So you still like, not to say that you shouldn't use AI tools or whatever, CJ might say that, but like, not to say that you shouldn't use those tools, but if you're trying to learn something, It's the equivalent of letting your mom do it for you. CJ Reynolds Or hiring somebody to go do your learning. Right, yeah. Scott Tolinski What are you gaining out of that? CJ Reynolds I think the little bit of pushback I have is, yes, AI is good for learning, especially it takes a lot of work to figure out how to search the web and how to find the answer that you want. And so AI gives us that instant gratification of like, oh, it just tells me what the thing is. But the pushback I have is that process of searching the web, finding the answer yourself is something you'll need even when you don't have AI. And before we had AI, that's basically all we could do. We became really good web searchers, right? And that's kind of a skill that's going away with AI because you can just ask it a question and instantly see an answer. But like Scott said, you need to verify it and validate it. So my only advice to you is start to work that into your workflow. Like maybe take half the day and use web search instead of AI to work on that skill because you're going to reach a point in your learning and in the things that you're doing where AI can't Help you or it doesn't have an answer or the answer is wrong and you're going to have to figure it out yourself. But if you haven't practiced actually searching and figuring it out yourself, you're not going to be able to. Scott Tolinski Yeah. Yeah. And, you know, like were talking about TypeGPU a minute ago, and there are excellent examples and stuff in their docs. Let's say there's some new CSS API, and you can copy and paste the entire MDN page for that API, paste it into ChatGPT, and say, give me a demo with this. Maybe that spits out an example, working example, and then now you have like, yes, we just said, get your hands dirty, write it from scratch. But if you want to just see something in action, and then tweak it, modify it, explore it, and then go and write it for yourself, you can have a better idea. Or at least again, you're exploring, like in real demos in that way, if that doesn't exist. But yeah, you know, MDN, right? That's instead of Google, just go to MDN. ([Time 0:21:43](https://share.snipd.com/snip/f310aedc-da55-4d9c-bb7a-574c2e5ed8bc))