We need to stop calling it “AI”

I think, like, the only thing that hasn't changed is simply building stuff is going to help you learn. And if you are able to build way more and way larger stuff now that you have AI and the lessons that you have, Like, you're gonna go down so many rabbit holes, and I will tell you, please go down those rabbit holes and deeply understand the problems that you hit rather than just swearing into the box. Because when you fully, deeply understand what these problems are and and how you could possibly tackle and and solve them, that is going to make you a better developer, but the better person who makes things.

Welcome to Syntax. Today, we're talking about I don't understand Shad Cien. We got a potluck Node JS you bring the questions.

Why use PNPM over NPM? What does the standards process look like? We'd let's take a look into that. Like, if something gets added to HTML, CSS, JavaScript, the browsers, like like, how does that even happen? What does that process look like? Right? What should you focus on in the age of AI, especially for beginners? Right? Should you go low level and, like, understand the fundamentals really well, or should you go high level in, like, architecture and and kind of, like, steering? Kinda interesting answers to that one. Also, really interesting question about design systems. Why do no design systems use our modern features? Right? We have dialogue and anchor and pop over and scroll snap and, like, all of these new amazing HTML features. And it seems like, especially in React land, none of them use them. So we're gonna answer why that is. Submit your questions to us. If you have a question you'd like us to answer on a Scott podcast coming up, go to syntax.fm.

In the nav, there's a button that says potluck. You can type your question in, and we'll answer it on an upcoming episode. Well, let's get into it. First question from Digital Server says, hello, Syntax OG listener. First time, Paula Wes. Thank you for sending that in. I have been doing front end development for a long time. I see I've seen many different CSS component approaches from bootstrap to preprocessors, scoped components, utility classes, CSS, JS, etcetera, etcetera.

For every single approach, I see the pros and cons. But my question regarding specifically Shad CSS approach, what is the benefit of installing components in our project? I understand we own the code, but is that a good thing? How do we handle updates? What happens if a component has a vulnerability after we update all of our custom code gets deleted? I'm having a hard time understanding the pros of this approach. K. So if you've never used ShadCn, the way that it works is that when you install a ShadCn component, it literally is just putting the component and all of its code into a folder inside of your workspace. There's no, NPM dependency where you're, like, importing the component from Shad CSS, and then you're, like, kinda changing it. It literally just, like, copy and paste the code in it. And, like, this this approach has been kind of a favorite of mine since, like, the WordPress days. Like, do you remember WordPress? Scott remember, but WordPress has this idea of of child themes. Mhmm.

Meaning that, like, you could take, like, a parent theme, and then you could sort of, like, modify the bits that you want. And I never liked that approach. I like simply just, like, taking a theme, copy pasting it, and then just being able to get into the code and edit it. There's no, like, weird dependencies. There's no black box behind that type of thing. And I I can see why that is is a little bit weird. I think the benefit to that is that you are simply able to own a 100% of the code.

Similar to, like, a CSS reset, you're not, like, getting updates to, a specific component. When you bring in a component, you that is the component that you are going to use. And if there is a new or updated or bug fixes to any part of that component, then you have to either manually apply them or use some sort of AI to apply them. But, typically, you just say, like, yes. This is the component that I want.

And, like, vulnerabilities, a lot of the stuff is not implementing its own logic. It's using other libraries that it it leans on, and those libraries can continually be updated.

And it's just like if you were to write the component by hand, it's simply just like a bit of a a head start in a, a standard way of creating your components. So I I absolutely love that. I don't wanna have to, like, worry about when a component updates, especially because a lot of the ShadCN is about how it looks and and, like, how it actually renders out.

And you I don't necessarily want it updating and then changing the look or the feel or the functionality of how that works.

Yeah. Yeah. I would I would, I would make a couple of, like, statements here based on, like, the things that you're worried about, Digital Surfer, I don't believe are things that are real problems.

Like, how many times have you had a component that has a vulnerability, like a an a UI component? Like, it's a it's a Node. It's a whatever. That's not typically where these types of things live. These these are very, you know, show this, hide this, move this Yeah. Some CSS, some aesthetics.

So, like, to me, that's not a concern.

Two, again, like, an up when a component updates, it's almost always a bad thing. Right? When you build something, you don't build it so that it grows as the component updates. You build it so that it works when it's done and ready.

And when it's done and ready, typically, you're not wanting that component to change unless, like, you really want. Like, to me, that's like a a part of it. Change, then you change it. Yeah. Right. That's like a burden to have to worry about a library getting an update, and all of a sudden, my UI possibly will change. Like, I hate that. So, especially in the world of now with with, AI and and these types of things, like, we can own more of our code. And and I argue, and I don't Node. Like, I'm I'm definitely on the edge of the person who's always building my own stuff rather than installing libraries anyways for a lot of these reasons. I'm building it for my use case, for my site, not JS, like, a general purpose component. So, therefore, I don't care, as long as it works in my current ecosystem.

So I would say a lot of these concerns are concerns that maybe you've developed without having actually experienced them. Like, how many times have you actually experienced a a a vulnerability in a UI component? Or have you been like, oh, I really need to get this latest update of this,

select list component that was written once? You know? Yeah. And and even then, if there is like like, for example, let's say there is, something wrong with your select list. Let's say there's accessibility issue or there's a bug with touch on Bos.

That bug is not in.

It's in the upstream. It's either in Radix UI or base UI. Those are the component libraries that are those are, like, the lower level libraries that ShadCien are built on top of, and those things do get updated. Right? So if there are bugs, there are for some reason, there is a security vulnerability in one of these, then it's gonna be updated. But, like, you gotta think about Shadzy and as it's your own code. And as soon as you bring that into your project, you're responsible for maintaining that thing. So what if there's a Sanity vulnerability in your own code? Then, yeah, you gotta fix it. Yeah. Yeah. Totally.

And if you want to see all of the errors in your application, you'll want to check out Sanity at sentry.io/syntax.

You can sign up today and get two months for free. Century is just a really incredible tool for not only tracking your performance, making sure application has no bugs, but even just seeing what goes wrong when something goes wrong because things go wrong all the time when we're coding. And you don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

So okay. Cool. Next question here from Rafael.

Next question after this is gonna be from Michelangelo. Okay. From Rafael.

Why choose Pnpm over NPM? Okay. So PMPM is an alternative that many people love, myself included, primarily just because of speed. Now there's a number of other features that make PNPM cool, which I'll I'll mention, but the big one is is that PNPM uses a global store and then Symlinks package version. So that way if you install, you know, the same package in five different projects or whatever, it's still just referencing that one, package on your computer system.

Making it so you don't have to have 10,000,000,000 copies of every package you use if you use similar packages throughout projects.

Other than that, it's really just very fast because of that. It only has to download what it needs to download, and therefore, you're not going to have to grab everything all the time.

And in addition, PNPM, like, they pioneered a lot of features in package managers that like, for instance, PNPM made it so that you have to approve, post install, runs of things. Therefore, that's giving you more security because if I install a bunch of stuff, it can't just run a bunch of code for me after install. I have to approve that it's allowed to do that.

Gives you options to limit how, like, when a package was last published. If you want to go ahead and install that or not, it has baked in, update functionality. So p n p m update I l gives you an interactive picker to, pick which updates you want, which, again, npm and Node, there's things for this. It's not like there isn't, but, like, it's all just baked in. Yeah. It works really well, and it's fast.

And I just like it. Yeah. Patching isn't a huge one for me JS the PNPM patch Yeah. Where if you have a dependency and, like, there's, like, some bug upstream, it's really easy to simply just patch that and have it install for you. Right? The workspaces are a lot easier. It's faster. It's just it's like, Npm is not necessarily bad, but there's just a lot of little paper cuts and and security issues JS we've seen in the last, couple months as Wes, where these things are simply just way easier, way better. I like, I don't even I don't even think about this type of stuff anymore. It's just like Yeah. I just use PNPM, and it just works. And I'm like, I'm not fussing over how frustrating it is. I don't wanna have to spend any any amount of time on on fussing with any of this stuff. I just know PNPM JS the best, and I don't have to mess with it anymore. Same with like, like, Yarn was that for a long time, but, like, I never got into yarn because it was just just weird, and half the stuff didn't work. PNPM is just fast. It always works. I know it's it's gonna be secure. You're in good shape. Yeah. Yeah. I like PNPM a lot. Again,

oh, also another thing, I I like not having to use the keyword run, like, PNPM. Yes. You just do PNPM script name instead of PNPM run. That's so stupid, but it's just like, I don't get yeah. I I I never got the need to write what I'm running. Think the reason why they do that is because

PNPM doesn't encompass all of NPM. Right? Like, there's no, like, publishing, and there's there's a lot of, like, stuff that's not built in to to PNPM. And it's maybe not stuff that you need, but simply just being able to write PNPM dev, it's the silliest thing ever. Silly. But I hate having to type Npm run dev instead of just npm dev. Also, a PNPM

does workspaces really well. They do workspaces which a lot oh, you said workspaces. Yeah. Yeah. The monorepos stuff inside of PNPM means I don't have to reach for a bunch of other tools, and I love that. Exact like, what do we used to use? Lerna before PNPM? And Lerna. Yeah. So Or,

Just so much. Else was there? Yeah. There was just the whole developer tooling space has gotten so good in the last five years. Like, if you're new to, you don't realize how much of a pain this whole space was, especially at the, like, height of the webpack days.

We just spent days and days building all of our stuff. Yeah. For sure.

Next question we have here from three zero three eight seven five five two. I logged ESLint Stack Overflow today purely for sentimental reasons, and I looked at my very first Stack Overflow question.

Cher, your very first Stack Overflow plus, the date it was made, and what you were up to at the time. If you want CJ two, please. Okay.

I thought this was a kind of interesting question because, like, I I'm almost embarrassed at some of my early Stack Overflow questions.

It shows growth.

It shows growth. Let me let me share my screen here a sec. Alright. I had over sixteen years and ten months. I've had a 155 questions. That's I was happy.

The Wow. Stack Overflow questions. If we go to the very first question I asked was 08/17/2009.

Wow.

That's, what, six seventeen years ago. JQuery cycle Wes.

Pause on load and hover action. So I had a question with jQuery's cycle Wes, like, this kinda, like, slideshow. And I wanted for Wes you hovered over top of it, I wanted it to to pause. Right? JQuery Node out transparency in IE. Right? I wanted Internet Explorer to to, fade out when you hovered over top of it. JQuery hover is delayed. CSS link spacing and paragraph spacing.

So here is the site. The banner image at the site says Wes Photography.

I'm not gonna go into it, but I have some very, very silly and simple questions. And if you look at my highest one, Google Maps API, simple multi marker example, a 07/17/2010.

That's your highest score on a question. Highest. I just could not. I just wanted to put the frickin' pins on it. And I think at this time, I was like all jQuery. Like, I couldn't do anything other than write jQuery.

So be using the Google Maps Wes, it was it was foreign to me because it wasn't it wasn't jQuery. Right? And at the time, everybody would simply just look for a jQuery plug in that did Google Maps or something like that. But I was like, I'm gonna use straight up it.

And, I asked somebody to just give me a simple example of how how it's working, and somebody provided that. And I I specifically remember building that. That was really fun. Yeah. My very first one was 2011,

and it was about jQuery, UI accordion,

not What's what's your, username?

Oh, what is it? Tora, r t c, t o r a r t c? Yes.

So member for 14.

See, I haven't updated. It still says I live in Ann Arbor. Ann Arbor. Man. Yep.

Yep. Oh, yeah. My number one question is for Apollo server time out while waiting for stream data.

Change the you also had a jQuery accordion question about the same time. Yep. JQuery UI. Even know each other back then. I know.

Meteor with Meteor had this way of doing async await, called fibers, and I was like Oh, yeah. Yeah. You always had to write inside of a fiber. It was kind of obnoxious.

Man, what's what's your very first Wes, though? It go to your First question is about,

the u I the jQuery UI. Basically, hey. This code that I had found on a blog wasn't working.

And this what's funny is that the the the the suggested one or the actual, answered one is that this is not directly possible at that time. It was a bug. So So somebody

patched jQuery to allow for this.

Unbelievable.

That was that was a crazy time. I used to, like, spend time on Stack Overflow and specifically wait for new questions to pop up and, like, try to answer them as fast as possible.

And then people would try to scoop in, before and answer the question. One kind of interesting thing is Stack Overflow emailed me the other day, and they said, hey. We're launching Stack Overflow for agents.

Meaning that, like, let's give the agents a spot where they can post all of their questions.

And I thought first of all, I was like, that's that's dumb. Yeah. But then I was like, may maybe not. Like like, it does it make sense to have a spot for agents to I don't know necessarily, like, post their questions, but, like, if if you solve something that was specifically tricky

Yeah.

And all of that knowledge, where does that go? Mhmm. Maybe back into the the data set to be trained on. But, like, it's you used to write a blog post, or you used to put it on on on Stack Overflow, and then other people could find that. Like, thousands of people would find these questions that they also hit the exact same issues. Yeah. And It actually would be nice if they because,

along the same line, I was having issues with, like, like, my graffiti library. AI doesn't know about it. Right? So it's like, how do you teach AI about it? So AI is going to make assumptions.

And instead, you know, the way I've landed on as an MCP that, like, what are you trying to do? I'm trying to build this.

And then it gets directly to like, it gets to the answer that it needs faster.

So ins like like, what if agents were like, this is the question I'm trying to answer. Let me find all of the times that this question has been answered before and then get answers faster instead of just, like, either guessing or not guessing, but, like, formulating what it should do in that moment. Right? It's like looking for validated approaches.

And and I think that's good because often it will

just, like, do a workaround or or implement sort of a half assed thing. Whereas if the real answer has been figured out by somebody, should that information be posted somewhere for others to benefit from it? Maybe. I don't know how you possibly even, like, moderate something like this Wes you're just letting bots post a bunch of content.

But maybe the, the power hungry Stack Overflow mods will also be interested in moderating all the agents that post questions.

Yeah.

Okay. Cool. I mean, I I miss the Stack Overflow. It's such a a vibe from from, you know, that, like, era. Just Yeah. I was

yeah. Definitely. Pnpm wasn't great because you would have a Wes, and then you post it, and then you hope you wait for, like some sometimes it'd be answered, like, within an hour, but sometimes it would be days before somebody who clicked on your obscure tag found it and and went through it to fix the fix the issue.

Kocai Scott, can we get video on Apple Podcasts, please? Yes.

Yeah.

We are yes. We are waiting for our podcast provider to finally implement it.

If for the longest time, Apple Podcasts only allowed video if you had two separate feeds. So you would have the audio feed and you would have the video feed, and there there wasn't really a specification in RSS on on how it worked.

And then, Spotify came out and was just like, you know what? Screw the specification. Yeah. Just upload it to us, and then we can do it. And it's part of the reason why we moved over to Megaphone, which is owned by Spotify for hosting. Because what that allowed us to do is we could upload the video and the audio at once, and it simply just published it as as soon as we have it. Before we Yarn on Libsyn, and what would happen is our poor producer, Randy, would have to wait for the audio to be released publicly on the RSS feed, and then he would have to, like, go at 8AM and upload the video to Spotify because it it it didn't exist before then. And then he had to wait, like, two hours for the video to actually pop up on Spotify, which is annoying. Now Apple finally allows video, on their podcast, and we are waiting for our provider, Megaphone.

They said it should be about a month or so before they actually do that. So, hopefully, it'll just show up one day, and, and the video is starting to be going there. But kind of a sad thing for standards, where, like Mhmm.

Podcasts JS, like, some people, obviously, lots of people a lot of you listening still use, like, standard RSS reader clients and whatnot whatnot for this type of stuff.

But the the only way that a lot of this went forward was by just people going around the specification and and implementing it themselves.

Yes. I and I I don't know about US. I primarily personally watch or listen to most podcasts in my PocketCasts audio feed specifically and only myself.

All of the podcasts rather than getting into video. But for a huge portion of people, video is podcast, and podcast is video. Net even Netflix is not podcast now. And, I I it's funny because when we were interviewing folks for the, initial syntax producer role, Somebody made a big old stink about how podcasts are audio and only audio. And even though I'm interviewing and applying for this job that is a heavy video job, I'm gonna show up just to tell you that I don't think podcasts should be Yeah.

Very odd choice, but I don't I I think it's been validated that podcast is video. You know? Even though I listen to most of my podcasts on audio, I think podcast is video. Podcast podcast is clips,

a lot Node. And and podcast is like is clips. Celebrities now. Like, my wife watches the Amy Poehler one. You Node? If it it's it's kinda nuts.

But Can pot yikes. Yeah. I don't mind celebrities. What I don't like is the I do. Late night hosts. And that happened with early YouTube. Do you remember when, like, Jimmy Fallon and Colbert started popping up on, like, the YouTube trending? I remember being like, get out of here. This is not your thing.

This is not your thing. That's how I feel about celebrities. And the celebrities of podcasting, it's always just like, let me talk to my other rich celebrity friends about their celebrity lives, and, oh, what is this funny story that you did one time on a TV set? Like, I don't care. I don't care at all. Like, you you you And a lot of it is,

like, very clearly, like, scripted or they're like Yeah. Like, there are producers in it, and it's just like, oh, I you guys are are ruining the not ruining it, but you guys are abusing the the thing. They're ruining it. Wes. They're ruining it. That's okay. That's Deno. With a lot of this stuff is you you gotta play the game. Right? Like, that's everything that gets popular, people figure out how it is. It's social media is even that way as well. You gotta play the game if you want your stuff to be seen by other people, which is frustrating, but, you can either be bad about it or or go along with it. Shevin says, how are proposals and changes implemented into browsers? For example, ECMAScript, JavaScript, TypeScript, Node, CSS, HTML. What is the process from idea to code? How do we follow the process and keep up to date with the happenings? Yeah. So every single, like, language or or browser has, like, a different process for proposing new APIs. Right? Like so with JavaScript, there is a committee called TC thirty nine, and they are are simply just concerned with what does JavaScript, the language, look like. This is, I want I want semicolons here or I want a sync await or I want functions to be able to return, like, streams, like Wes we got generators, things like that. Right? So they're not cons they're not like, oh, should we get, HTML in Canvas? That's that's not what t c 39 is about. They're simply just like, what does the language look like? And what you do, where you implement the language JS totally up to you. You can stick it on the server. You can put it in a browser. You can put it on a microcontroller.

Whatever you wanna do with it, we're just building the language. You figure out where it goes.

And and t c 39 has several different stages from stage zero all the way up to stage four. We've done many episodes in the past as to, like, what features. And, typically, when things start to hit, stage three or even, like, state they have, like, a stage 2.7 now, which is when it's been approved, then you know things are gonna be starting to be put into the browser. So there's you can take a look at the t c 39 active proposals, and you can look at them on GitHub. They also have meetings and whatnot that they'll they'll go through a lot of them. Typically, when things hit stage two, they'll start to be behind a flag in Chrome, and you can play with them. And and that's the point where if you're, like, a complainy person, that's the point where you should start using them to like, HTML and Canvas is exactly that right now, where it's it's just a proposal. We're trying to figure it out, and so many people are playing with it and figuring out what the edges are, which is beautiful because now we're all saying, hey. I wish it did x, y, and z.

That feedback is incredibly important at that stage versus

when it actually gets shipped. Right? Yes. It's a fascinating process. Node one that I have the patience for personally.

I'm more of a, I like this. Yeah. I don't like this kind of guy. The the people that do the standards process are

are amazing. So a browser as Wes, like, CSS has the CSS working group.

The browser itself has the what w g, the what working group, and they are responsible for, like, features that actually get implemented in the browser.

So, so, like, for example, fetch.

Fetch was not a JavaScript feature. It was a initially, just a a a browser feature, and that's why we didn't have fetch in Node for so long.

And it it Wes standardized, and it has been implemented everywhere now. But if you wanna look into that, look at the what working group.

CSS also has a CSS working group you can go into. And, often, there will be subcommittees for these Wes, like, somebody's like the CSS Anchor working group Wes it's three or four people that are simply just obsessed with CSS Anchor and working through it.

That's a good one to to look into as well.

Yeah. Yeah. And sometimes things never leave at all. Sometimes they they get just up to the precipice like decorators and then come back down. Do you see they move back down again? Decorators been around forever.

Moved down again. Yeah. There was a time when decorators were the only thing I wanted in in JavaScript. I used them, like, crazy. I love decorators in practice.

But Yeah. It's been a long time since I used decorators. TypeScript.

All of these, like, things that are more projects, they also will have their own weekly meetings and and whatnot. And I often find it kind of fun to just, I don't go to the meetings because I find them not necessarily boring, but they are they're very low Vercel. And the people that are are looking through features are are really getting into it. But once things start to look a little bit firmed up, at that that point, I will start to play around with it and and take a look into it. I feel like that's a a pretty good spot for Syntax to be as well, because we can take it from these folks who are, like, very technical and then make demos, talk about it, whatever, bring it to, like, the masses, and then and then people will chime in with their thoughts, which is important for the standards process.

Yeah. Yeah. I I appreciate the folks that are able to do that. Alright. Next one here from Bike Shredder nine thousand for Bike Shredder.

Bike Shredder.

Okay. Not Bike Shredder.

Bike Shredder, Bike Shredder. Those are both actually Bike Shredder is a pretty cool name. One of my most recent pet peeves is when people talk about AI like it's actually AI.

It's not. It's an LLM.

It mathematically predicts the next most likely token all based on the previous set of tokens.

My opinion is that the more you understand this, the better you will be at using the tool. It's impressive, and it's very good at text based tasks like coding, but it's not AI.

What do you think? Am I bike shedding? Probably bike shredder. I gotta ask for for you.

Like, what does that mean to be AI then if it's not just token prediction? Like, how much of what we're doing in our brains is just token prediction? Or you you have your knowledge that has been gained over time and your brain is working out the next most probable thing to do. I mean, like, I'm not saying it is or it isn't, but, like, at what point does it matter the means at which it is giving you the answers? Now you can argue, like, sentience or the Chinese room stuff or any of that. Like, there's there's so many different angles that you can look at, like, what AI actually is.

But, like, for me, I I don't I don't necessarily think the transport really or, like, the the technology of what is AI matters as much to me as long as it's able to act artificially in that way.

So to me, it being an LLM, I don't personally doesn't disqualify it for me, but I'm not a scientist. So Yeah. It it is statistically probable, meaning that, like,

if you the LLM providers have to put randomness into it so you don't get the same output every single time. I'm working with, Flux images right now, and it gives you it literally gives you the same image every single time that it it output. Not exactly the same, but almost exactly the same image every single time with the same input, and the same, like, seed value as well.

And that's because you start with the same thing, and it it will statistically try to to guess what it is that you want. I like, I get it. We get it. We get it that it like, this is just math at the end of the day, but holy hell JS it good. Man. You know? Like, it's it's doing exactly what I was doing. Everything? Isn't reality

just math? Like, it's all math. It's all math all the way down. Right? Like down, except for choosing colors.

That's that's taste.

But I don't know. I think, like, the people that are Taste is matte. I think that that whole trope of, like, it's not actually artificial intelligence, like, who gives a shit? It it made a website that is exactly what I wanted in, like, six minutes or, like, it I told it to write something in a specific way. I took in the inputs of what I wanted, what people wanted, what, what I had available to me, example code. It took all of those inputs, and it it gave me the output that I I was looking for. Right? It statistically did a great job.

So I I think Yeah. Those annoying tropes of, like, it's just, it's just sand that I can think is is kind of like yeah. We get it. And it it's funny and everything, but it's also it's a fantastic technology. It's very good.

I think it is funny. I was almost like to me, like, when when you say that, like, early in days, I remember saying something about, like, what the AI Node. People are like, yeah. AI doesn't know anything. Yeah. No. It doesn't know anything.

I think I think where you can stop it is where people think that it is actually, like, sentient, where, like, it has reasoning. Yes. Because it goes back and forth, and it just puts the prompt back into itself. And and those steps of saying, maybe I should think about x, y, and z. That prompt is is great because then it will figure out exactly what you want.

But the the fact where you get to people being like, it needs a therapist or it's people are falling in love with it or people think that it is going to like, that's something we haven't seen. It's it hasn't yet maybe discovered.

It has, though. I'm I'm trying to say, like, it has not discovered things that were not known, but it it has been able to, like, compute math problems that humans haven't been able to do.

But maybe that's just the the iteration over and over. The problem I have is when people are saying that it is like it's like a like a live being.

And I I guess that's probably your thing here. It's artificial intelligence.

I think we understand what we mean when people say AI.

Yeah.

Yeah. Next question. Anonymous says, I'm about to change companies and work on a React design system.

Don't tell my employer just yet. Sorry. Too late. We log your IP address, and we figured out who it was, and we sent it to them.

Coming from a company with a large design system only using HTML, vanilla JS, and pure CSS. But what I'm seeing on big name design systems, think IBM Carbon, Adobe Spectrum, these are all big design systems that these companies have, like, put out because they have thousands of applications, and they need their buttons to look exactly the same across all of them.

So what I figured out is that they use very little of the modern native, web elements such as dialogue details, etcetera, even though their browser support is way good enough already.

Are they missing out on the built in benefits and baked in functionality? Yeah. This is this is a question that I have myself as well as well. It's like, where are the design systems using CSS anchor and dialogue? And, like, Scott just had an entire talk at React

saying this exact thing. Right? Like, tell me. Rattle off a few of the things that the React developers are not using. Yeah. React developers, they're not using you know, one thing that I think, a lot of people aren't using, the scroll swipe API or scroll snap API. And CSS is so much more powerful, than a lot of people use it for, like Instagram Reels or swipers or this or that. People are just thinking about these scroll snap APIs being for, like, carousels.

But, like, the the thing that's great about these is so many React components implement that stuff with JavaScript that JS, like, you know, changing a translation value when you're you're clicking and dragging. You're always gonna get worse FPS than native scroll.

Sorry. My dog's huffing and puffing in the background. Oh, he's gonna he's gonna yeah.

But, yeah, it it is so funny. The accordion stuff, like, details and summary are really good. Popover, anchor.

People, don't realize that anchor can even swap when you get close to the edge of the screen, really reducing a ton of, extra JavaScript you might need. Where where are the the libraries for this stuff, man? I don't know. I've been trying to do some of this with my graffiti library to make it, like, a basis for other things, but, again, that's like a a whole thing. You know? And and yeah. I I I don't know. What are people missing out on? In the past, it's often been animation. So, like, the native dialogue doesn't animate.

The native details and summary doesn't animate.

There's, like, little things here with the Node, this or that, but, like, all this stuff can be augmented with JavaScript or even better now that there's at starting style or allowed discreet for animations, like, you can progressively enhance.

It's it's like pea people look at it as two lanes. It's like you can either use the React component or you can use the browser APIs.

They're not like, oh, you can augment the browser APIs with JavaScript to make that what you want. Like, I that's that's the world that I live in. So I don't know. With AI, it's, like, gotten way easier too. Like, we were talking about with the ShadCN stuff to own your components and build them based off browser standards. I I think we have to wait for this these new things to make their way into,

like, the into base UI or or Shad CSS because right now, it's it's a hard place, but a lot of people simply do not care about a lot of these new features because they just boop boop boop. AI does it all for you, and it it works. Oh, it works. Exactly what you wanted. So the we warp on the spot Wes, like, we're finally at a spot where all of these things are in the browser.

They're fairly well supported, but a lot of these, like, lower level libraries, they were built when these things didn't exist, and and they're not necessarily just want to have to swap it out. You know? It's it's kinda tricky to have to to swap it out. They're not always one to one feature parity, so it would be a lot of work. And I think the people that are are doing those things don't necessarily care because they're everybody's head is just on AI right now. I think we'll probably get to a spot eventually where we'll see a lot of these new component libraries come out that are using them under the hood, using scroll snap and anchor and dialogue and and all these good things. And then you will and because of that, everybody will simply just start to use those, which is very refreshing. So I think if you were building a design system yourself, I would 100% use all of the new stuff that you possibly could, given what browsers you need to support.

Yeah. I think one of the big things that people don't think about is how much less work you have to do with the native stuff.

Like, the native dialogue element gives you keyboard support. It gives you focus trapping.

Like, these these things come automatically, and you're not having to write oh, hit the escape key and trigger the the close function pnpm any of that stuff. So I I think also

is a lot of companies are scared about accessibility because you can get into some real trouble when your your site is not accessible.

So because of that, people just you just use React ARIA, and and you know that React ARIA is going to be accessible, and you don't really have to put a ton of time into making sure that some weird edge case of, like, your your cursor is captured when you click this thing. Right? It just does a lot of that for you. So once React Aria starts to implement a lot of these things, then, again, we'll be in in good shape. I think a lot of people are using React bubble JS in, they are stuck in their React bubble. That's that's, I think.

Next one from Arun Nambiar.

As AI gets better at execution, I keep seeing two camps emerge among early career engineers like me. One camp is trying every new tool, model, framework, and AI workflow to avoid being left behind. They're shipping more than ever, building lots of projects and moving incredibly fast, but often with a shallow understanding of what's happening under the hood.

Any question you ask leads to the reply, why ask me, just ask AI? The other camp is using AI more like senior engineers, accelerating implementation while still focusing on the fundamentals, architecture, debugging, security, and developing deep expertise in a smaller set of technologies.

But that means moving slower and potentially missing some trends and being caught in FOMO that everyone's ahead of you. Sorry. My dog is losing her mind. I'm gonna send her outside. It's like driving me nuts. Sorry.

Let's see.

What what are we talking about? There's nothing going on. If you wanna leave, you can you can leave. You don't need to leave. Thank you.

Can we keep that part in?

Oh, alright.

Okay.

Sorry, folks.

So they're either in one camp where they're putting everything to the AI or the other camp, like senior engineers Wes they are, focusing on fundamentals architecture and debugging.

Which approach do you think is more sustainable over the next five to ten years? As AI continues to improve, does it make sense to spend a significant time mastering programming fundamentals, or is the higher leverage skill becoming the ability to direct AI effectively to get a working solution as quickly as possible? I'm gonna, take the worst possible answer and say both of them, because I do think there's different skills there that you should probably learn now. How we work with AI models and AI in general is going to change as the models evolve over the next few years, etcetera. But understanding the fundamentals, the architecture stuff, being able to debug and really have a good understanding of what the issue is without having to rely on the AI will save you a ton of time and money.

I'm trying to think of, like oh, okay. So last night, I got a robot.

He's currently shut off, which is why it looks like this, a Ricci mini. And the Ricci mini app was crashing, and the camera was intermittently working.

And in general, there was something odd going on. You could prompt to infinity to check the logs and do all this. And trust me, I had an AI prompt going about reading the logs, and it kept saying, well, there must be a problem with the the servers crashing for some reason. And why is the server crashing? I don't know. It could be these following reasons, and it's just trying stuff.

And me being the smart guy I am, I said, what if there's just something running on the port that the thing is trying to access it on? And they I was like, great idea. So, obviously, I checked the port, and there was something running on it. It was a process that I had I started a while ago, and I killed it, and then the whole thing just worked.

So the story is is that I could have prompted until Sanity, and maybe it would have gotten there.

But the fact that I was able to have the fundamental understanding to know why these things might have been crashing allowed me to direct the AI and validate that so much faster.

So I think you need to get both because people who are good at prompting and can get something that looks great at the end of the day works well, that's a whole skill in itself.

But you'll get there faster if you know what the heck you actually want. I I think I I tend to agree with that because

on one aspect of it, like, the people that are so nitty gritty into something. Like, I think about the the pure computer guys that we had on, where they were so obsessed with the performance of a diff and so obsessed with the performance of a a tree of, like, a sidebar of files, how quickly that could be rendered that they just went low, low, low Deno on that. You you would think, like, with AI, do we need to care about how, like, a sidebar renders these days? You know? But they opposite is true, and and they were using all these AI tools to figure out how do you make this thing even faster. So I think on on some regard, like, yeah, like, going going deep on specific aspects to get the best performance. Mhmm.

But then at at the same regard, like, the higher level architecture things are going to be super important as well because, man, oh, man, I have made a lot of these, like, Vibe Node apps, and I'm just, like, not happy with them after spending three or four days on them. And at that point, like, probably all of you listening have done this as Wes, where you're like, I have this awesome idea. I'm gonna build this, and then just not very good. You know, I didn't you didn't really spend a lot of time on, like, yes, it's very good at writing the. Yeah. It's disposable and it's very good at writing the actual code.

But what you warp it to do, how you want it to function, what the UI looks like, what the flow for this thing is, what the architecture looks like for performance and how much it costs to host this thing, A lot of those, like, higher level decisions of, like, steering and is is going to be super important in order to make something that is genuinely very good. You know? We're not so much worried about, like, what functions to write and how to, like, to, like, organize your files anymore, but we certainly are very much like, I I even think about, like, this app that we're using right now, like, Riverside. Right? They just redid the whole thing, a whole bunch of performance. There's, like, so many hard problems in real time video that also records to the browser. Right? It's problems all the way down with, like, frame jitter and drop frames and, slow Internet connections and echo cancellation. Right? It's just problems all the way down.

And it's it like, writing the actual code to, like, make these buttons and and whatnot is Scott the hard part anymore, but it's more about, like, how do we build something that's, like, very good that people actually want at the end of the day? Because there's certainly a lot of very crappy software out there. And there's only gonna get more. There's only gonna be more. Yes. I have a hard time answering these questions for people who are new.

The answer, like, hey. I'm new to coding. What should I do? Like, it used to just be, like, spend some time on the fundamentals, and also spend some time getting very good at the things that are popular right now. Right? Spend a whole bunch of time on React. Understand how databases work. Build a full stack application so you can understand how all of these things these click together. And I think that that certainly still is important, but it's it's less so.

And then there are all these newbies, like, having a hard time finding jobs as well. Right? Because we're in kind of a slump in the market right now. A lot of people are firing because they think they can kick it off to AI. So I'm not really sure what I would tell somebody who's brand new to this, because it's hard to be like, well, welcome to coding.

Scott really thinking about your, like, WebSocket performance when it spanned across the globe. Because, like, you can't do that as as, like, as a newbie. Right? It's that's that's stuff that's gained over years and years, and I don't I don't know, man. That's hard. Yeah. I I mean,

it's so funny. We used to lament how often we got the Wes. That was like, we can't answer this question again because we've answered it a thousand times.

And it feels like now is, like, the time where, like, I feel like I need to answer this question every other month to give you a different answer on, you know, what what new people should learn here because I feel like it's changing that rapidly. I I think, like, the only thing that hasn't changed is simply building stuff is going to help you learn.

Yeah. And if you you are able to build way more and way larger stuff now that you have AI and the lessons that you have. Like, you're gonna go down so many rabbit holes, and I will tell you, please go down those rabbit holes and deeply understand the problems that you hit rather than just swearing into the box to for the AI to figure it out. Because when you fully, deeply understand what these problems are and and how you could possibly tackle and and solve them, that is going to make you a better developer, but the better person who makes things, whatever we're called right now. Yeah. I you know, it's funny. I don't love

skills. I mean, I like skills, but I don't love skills in general in AI. But the grill me skills in that style of, like, go back and forth with me until every question Yeah. Been answered, like, forces you to be involved in the process so much more where you are answering all the questions, and then it's, like, presenting you with conflict ideas, conflicting ideas. Like, you say you want this, but this is also a problem in these ways. Like, it can get you really thinking.

So I I like having, an AI QA me on many things. I I did that for our, JS Nate or for my React Summit talk where they have to do the live q and a on stage. I said, here's my talk. Grill me on every single question that's gonna be asked of me, and then it just went back and forth. And I had to come up with the answers myself. It's not like I'm using the a AI to get the answers. It's like, let me understand this more deeply. So, yeah, last question here from Bob.

No question. Just wanted to add to your recent answer about scammers and them trying to make you run malicious repos. They have another level. Please tell your listeners not to even open the repos with cursor or Versus Node. They are now adding scripts to run on IDE open to swoop your global ENV and send it out. Also, the interviews seem almost legit. They even go on Google to meet you dressed up nicely and talk about the fake job and your experience and then slip the part of them wanting to do some technical coding challenge and try to make you open the repo with an IDE right there on the call. Man, the balls on some of these people. My god.

Yeah. For anyone who didn't hear that one, there was some people who had going been going through interviews. And and part of the interview was you had to, do, like, a coding challenge. And they said, alright. Just clone this repo and whatever.

And he thought, that seems a bit odd. Let me just ask Claude if there's anything weird in this repo. And there was, like, all kinds of malicious stuff that was trying to steal your your secrets.

And it looks like simply you know, when you open up a new folder in, like, a Versus Node or cursor, it's like, do you trust this folder? I'm assuming that is because, Versus Code has the ability it has these, like, tasks. Right? And I didn't even realize this, but they could probably run automatically, like, on Lint or on something like that. I didn't realize I always wondered that. Like, why you asked me if I trust this code? Like, what are you doing with this code? But I, like, I guess, yeah, there could be tasks that automatically spin up, like, Docker images or whatever and and or just, like, CLI scripts that will try to steal everything. So if you are interviewing, not to say that it's it's a brutal, brutal space. I would be so pissed if somebody wasted my time thinking, like, oh, I took time off work. Now I'm having this interview, and you're simply just trying to screw me and steal my, like, AWS keys. Bad, bad world. There's a lot of lot of awful people out there right now that are surfacing with this newfound tech JS these bad people can now actually build stuff.

Yeah. Yeah. Sit down. Right? At least before bad people were like, how do I computer? Yeah. I know. You know? I gotta go somewhere and install a physical credit card,

critical Credit card skimmers? Credit Yarn.

Yes. GMR. I was like, credit card scammer. Yes. I gotta go install a credit card scammer. Do you still swipe your card in The States? We were talking about this in Europe, how, like, they take they take the, like, credit card away at at a restaurant in The States. They, like, you pay with your credit card, and they take it away to the machine. We were saying how, like, I haven't done that in still. Like, yeah. Canada, we haven't we haven't they haven't taken it away in probably

ten, fifteen years. I was just at a restaurant, on Friday that took my credit card away, and I was just thinking, just bring the thing to my table. Like, every good that plays that's not The US does. I don't know. It's most of them. I would say there are a handful of them that have moved to the bringing it to your table, but it's it's few and far between in my mind. And you still do you still chunk at a restaurant? You swipe the the magnetic strip? I don't know what they do. They take it back, and they I think they do the I think they do the thing. You don't see them doing. When I first

signed up for Stripe in, I think it was 2010, maybe 2012, I had to, like, fill out all these forms and, like, Visa literally mailed me those, like, carbon copy papers that you put in the, like, the, in the olden days, your credit card had, like, raised numbers, and you would go to, like, charge somebody's credit card. So when I signed up for Stripe Yep. That's old I am. They sent me those papers, and I was like and they sent me a little sticker that says Visa accepted here. Like, you put it on the door of your business. And it was obviously just like a merchant onboarding thing that they had to had to go through, but I thought that was hilarious.

Yeah. I, I I worked at at Target, and I had to do those

things. Also, I also worked at a ski hill where I had to do those JS well. I never I worked at I worked at Tim Hortons, but at the time, we didn't even it wasn't debit. It was cash only,

which is wild to wild to think. So before we get out of here, let's do some sick picks. These are things that we find to be sick, things that we really like or enjoy that we're having a good time with. Yes.

Sick picks. Man, you know what? I'm going to sick pick, Wes.

My son and I have been getting into Warhammer 40 k, and it's just like painting miniatures.

I played Warhammer when I was in high Scott, but if I know people are, like, often looking for things to do, creative things to do with their kids. I gotta say painting little miniatures, even though it's an expensive hobby, man, it's been a ton of fun to do with them. So, like, it's whether anything whether that is 40 k or Warhammer, whatever, we went into the store. We got to go pick out a box for his birthday, and it had, like, a basic kit in it. And then we're sitting down with the little tiny paintbrushes and painting these little, figurines. And like I said, I used to do it when I was a kid, and my god, it's been a lot of fun to do with him and and see, like, creatively what he wants to do and and, like I don't know.

Our son is he's not the best at focusing. He has, I would say, zero focus. And this is, like, one of the main times I've ever seen him really focus on something, and that has been just a joy to watch. So, little hobbies like that, Warhammer 40 k, lot of fun. I'm going to

sick pick a baby gate or or pet gate if you've got pets.

And I have seen the rise of baby gates getting better and better over the last eleven years of having children. Like, when I first had kids, the baby gates were these, like, pain in the ass of wooden ones where you had to, like, pressure fit it and, like, you touched it and it fell down.

So obnoxious.

And now, babe, I know people like to, like, hate on, like, Amazon Chinese sellers, but, like, the some of these products on Amazon get better every three months.

And we've bought, I don't know, probably six of these baby gates that are, they roll out. So you you basically you bolt it to one side of the door or or, like, the stairs, and then you put the little hooks on one Node, and then you you pull it out.

And they the how easy they are to now undo and, like, just pull out, and then how nice they look when they just roll up beautifully, unbelievable.

Yeah. Yeah. So if you are like Yeah. Thinking, like, I need to keep my silly dog out of here or, like, you got kids coming up. The Amazon baby gates, they're all under these stupid names. But the ones that simply just, like, roll up and pull out, they are fantastic now. The latest iteration of them, they have this, like, big paddle that you just have to slap. They lock, and then you have to, like, push in. And the kids can't figure it out, but adults can, which is always the, like, delicate balance. Yeah. I love that.

I didn't know the world had changed. Good.

Well, that's all I got for you. Alright. Thanks, David, for tuning in. We'll catch you later.