Do We Need JS Frameworks × Are You Over-Engineering? × Webview vs Native

Welcome to Sanity. Thanks for tuning in today. We got a potluck for you today, which is you bring the questions, we bring the answers. Please keep submitting your questions. Go to syntax.fm.

There's a button that says ask a potluck question. Click it and throw your question in the Google Form, which I'm laughing about because our first question JS, why do we use a Google Form? Got all kinds of interesting questions today for you, about overengineering, JavaScript, generative AI, workspaces, etcetera, etcetera. So let's get on into it. My name is Wes. I'm a developer from Canada. With me, as always, is mister Scott Tolinski. How are you doing today, Scott? Hey. I'm doing good. Feeling great. Ready to get into it.

Right on. Right on.

Let's talk real quick about Sentry at Sentry Scott I o. This podcast is brought to you by Sentry. The tagline is code breaks, fix it faster. That's what Sentry is the tool for figuring out why your code is broken or slow or who's using it on what browser as to what went wrong. It's it just gives you all the information as to when something goes wrong, how to fix it in and all the little bits and pieces. Yesterday, Scott and I had, had Node ourselves. Right? We deployed a new feature. Scott did a whole bunch of work on what what was the feature? It was

resuming a podcast episode. Right? Yeah. So it all the the podcast player on the site will now resume any episode where you last left off. So if you come back if you were listening to episode 791, you got halfway through and then come back to the site later, it will put you at the exact same spot of episode 791.

Also, by default, the podcast player is now open by default from the start, and it will it, like, has the 1st episode queued up all already. And there's a neat little CD animation that comes in. Love I love the CD animation. It feels so good. Just go to syntax.fem and play an episode because it's like, whew. Yeah. Play play play a different episode. And by the way, Wes Yeah. We we learned from Codecov, which is a century company, actually. We learned from Codecov that my CD player that I had before was too massive of an SVG, and it was taking up a lot of loading space. So we learned that through Codecov in our, CICD, and then I replaced that whole SVG with an emoji of a CD.

So now it just uses the emoji. It's great.

That that's they often tell you not don't ESLint your SVGs, and that's why. Because Yeah. It Wes, like, like, a 100 k of of SVG.

It was a big old SVT. Yeah. Being loaded on the home page for an Easter egg.

Worth it. Worth it. Oh, no way. Like, as soon as we so Codecaf flipped on, a new feature for SvelteKit the other day where it will then it'll it'll break out the back end and the front end code.

And as soon as they did that, I was like, that seems large. You know? And I did a I I did a quick look into it, and I was like, oh, why is this Easter egg, like, a 120 k or something like that?

What's funny, Wes? Sorry. Even the sidebar that sidebar.

Alright. It's related.

I had noticed that that was super large at one point, and I took that code out of the code base. And then at some point, I was like, why didn't I take my Easter egg out and then brought it back in without even think I should have left a comment. That would have been a perfect place to her comment saying, hey. I took this out. It was giant.

There you go. But, anyways, I was trying to come back to the the century read here was we deployed that sucker. Scott tested the crap out of it. I reviewed it. I tested it. I'm pretty sure CJ went through it as well. Everything worked. Bing bong. Boom. And then, I don't know, half an hour after launching, inbox starts popping up. We're getting all these century things.

We missed something. I don't know. Did you end up figuring out what it was? It was like Scott a number was a number?

Yeah. So it's there there's 2 places in which a method is called to set the time of the player. Yeah. One of which is when it initially loads, and the other of which is when it's being clicked from a time stamp. Now everything is pretty firmly typed, so there must be a cast somewhere that is, like, misrepresenting what the type actually is because TypeScript should have caught that. Right? But, it didn't. So no. I haven't found out exactly. It's either when you click on a transcript to change the time or when you click on the time stamp

within the show notes to change the time. It's one of those 2. Oh, it's probably after we report. I think I think what's happening, and and I don't TypeScript wouldn't have caught this, is when you are parsing that time stamp either from local storage or from a URL click, like a hash, when you parse float or whatever, it if it's not a number, it parse float gives you n a n, and type of Scott a number JS, thank you, JavaScript, a number. Right? So Yeah. It's Yeah. I've I've I've had that exact error before where you're trying to set a a number, which is but but not a finite number, meaning that, like, there's there's a couple numbers in JavaScript that are nonfinite, which can you can you name them all? Let me go a little stumped here. Infinity

Infinity, not a number.

How many are there? I don't know. I'm let me, let me look them up. There's there's only 3. You got 2 of them. Infinity, not a number.

Oh,

gosh. I know that's something. 1. It's negative infinity.

Come on. Which sounds like you're you're talking to my kids. I know. Deno. Gonna say the same thing. What's the lowest number in the world? Negative infinity. Yes.

Oh, alright. Let's get into the 1st question from Jonathan Land here.

I only asked this out of deep curiosity, which is a very nice way to to to call us out on this. Why do you use Google Forms for potluck questions? I'd guess it would be the easiest thing on the site to build yourselves. Is it just a matter of being, we'll never get to this zone, at the bottom of the Kanban, or does Google Drive workflow useful for something else that would be hard to replicate? That's a fantastic question because Google Forms for text sucks. It's good for input, but it goes into a spreadsheet. And, you know, like, trying to read long forms of of a spreadsheet is is really frustrating. So why do we do it? That's like, a failure of engineering is defaulting to a Google Form, isn't it?

Yeah. Yeah. Well, what the reason why we did it in the 1st place is the site never had a database. So the initial site didn't have a database. Bos So we weren't gonna bring a database in just for the the forms. So it was like, we'll just throw a form up and call it a day. Right? But that was, you know, many a year ago, and now we have a database.

I I wonder if a next gen version of the potluck question could be,

like, questions warp even maybe public and Yeah. Because people voted on by users. Yes. Yeah. We could build that in no time. We could build that on stream. Because our we should build that because our process right now is Scott and I go through it. We have a column that's called coming, and then we type that, and it changes the color of the row. Yeah.

Like, wouldn't it be nice to be able to, like, to search them, filter them, tag them,

reorder them? There's so many cool things we could do. You could use AI AI to tag them as well. Yeah. So that way we could say, give me a Svelte question. Give me a React question. You mean yeah. We should build we should do that on stream. I think that would be pretty fun. That'd be a lot of fun. Yeah. But that's that's the the reason why. Basically, it didn't have a database. Now we have a database. Now there's no excuse. Now we should just build this. That'd be easy. Alright. Raffle. Hey, gang. What is overengineering, and how might I avoid this? As a novice programmer, abstractions are attractive, but I always Node that occasionally, they backfire.

I'm wondering how besides experience might I start learning how to avoid overengineering my solutions. I work mostly in SvelteKit, but recently been looking at Astro, and it made me wonder. Niche example, if you find it helpful, since 2020, I spent a long time learning web dev, web design, and branding. I want to build a business. During my planning stages, I realized I could build something similar to a low or no code solution via the application of SvelteKit and Storyblock.

In Storyblock, I can select a block section, which then has layout options.

So, ultimately, I ended up creating a sort of Wes flow that I could completely control with my own code is this overengineering.

I found Vercel solution to be kind of cool. And during a project, I could go into the code and change some assumptions parameters. It essentially remains customizable. Okay. So is this over engineering? Sure. But did you get something out of it at the end? It sounds like it. You got the experience of building something like that, and it was, seemed like it was a neat experience for you.

So is it over engineering? Sure. But, you know, is it a problem? I don't know. Yeah. I I for me, I think But Sorry. Go ahead. The last point of that is, did you ship in time? If you shipped in time, all's well that ends well. Right? To me, overengineering

is all about adding unnecessary complexity, because the complexity in an application is fine when it is good, when you when you want to make things reusable, when you want to make things, like, speed up dev time. Right? But when you add unnecessary complexity, it may seem like something is better, but it can be harder to implement, harder to maintain, harder to deploy.

All of a sudden, you're like, like, now we have this thing to sort of deal with whenever we wanna edit it, and now I have to, like, deploy this in a funny way, or I'm not totally sure how it works. It often comes at a level where abstractions are too tricky for other people to implement. And we've all worked on code bases like that. We're like, what the hell Wes this guy thinking when when they built this type of thing? Right? And, like, I just came up with some some things I've said Wes you could say this would be over engineering JS I can't call this function from this part of the application. You Node? Like, sometimes there's you are in an app. You're like, why is it built in this odd way? And sometimes it's just simply because it would be too complex to be able to surface that data or that functionality somewhere else in the application. Or, another one is I just want to add a class or I just wanna add a border to this thing, and the system that they have in place for this is is not good. Now on the flip side, if you were just to willy nilly, have no overengineering in it, right, if you made it not not overengineered at all, then it would be hard to maintain, and it would just be sort of a mess. And then we all know messy code Bos is sort of just eek and creak and break over time. Mhmm. The other thing for me is, like, I can't figure out what the equivalent of x, y, and z is in this implementation. Right? So we've talked about this in the past. We're, like, you have a component system, and instead of adding, like, a border 1 pixel solid red, you have to figure out what their equivalent is in the design system to add a border. And the benefit to that is that you have a strict way of doing things, and Deno nobody deviates from that. But the downside is, like, now I have to learn your own way. So there is a sweet spot. I know that you said, how do I figure it out without experience? But experience really is, something that you learn over time with this over engineering. My rule of thumb is to I air on the side of keeping things together and not over engineering, but making it so that if you did want to abstract it in the future, I'm always thinking, I'm not gonna do this now, but at some point, I might want to use this for x, y, and z. So I'm gonna write it in such a way where I could break this up into multiple pieces.

Yeah. It's it's an interesting thing. And and, Wes, my brain's been on this a lot lately.

I'm listening to fundamentals of software architecture right now, and it's, like, really it's really changing the way I think about how I design things. Because many of the time many of the the ways I I design, the way my systems work is is based off of entirely my own experience and what works and what doesn't and what I've seen, but it's not based in any sort of firm software principles. And so I'm I'm learning a lot about the things that I do and why the I do them the way that they, you know, I do them and why that's successful.

I think it's an interesting book that maybe you might be interested in, dear listener. But other than that, you know, I do think it is it's a feel thing.

Complexity can come from all sorts of ways over engineering can come from all sorts of things, whether it's using, specific libraries and frameworks when you don't use them. Granted, we all have our tools. Those tools work really well. But, like, are those tools always appropriate for everything? Depends on what you're making, and you gotta kinda look at things. I I think we can all get a little bit ESLint, a mode where we're like, I'm gonna build it this way because that's the way I build everything. And next thing you know, you're putting Redux on a blog when you don't need that. That's over engineered. Right? So we we have to be cognizant of the the tech we're using and why we're using it and just keep that in mind.

Next question from ESLint View. I appreciate bringing some love to View. I am a convert from React. Speaking of framework wars, what are your guys' thoughts on web view based mobile apps, or are native components king? I think so what they're talking about here is that when you're in a native application and you you tap on something, sometimes you you can tell that they're quickly like, the screen goes blank for a second, and they're loading a a web view. Yep. That's not what they're talking about. Oh, what are they talking about? Well, they're talking about, like, an app that's built with a Wes view, like, like Electron, but, like, for mobile. Like Yeah. But I'm I'm talking about native apps often will have part of their application as a web view, and and you can see it because you like, you know, like the Twitter app, for example, if you click on, like I think if you manage your profile or there is some stats, if you click on that, it'll go blank for a second, and then it'll load it up. Or or so is that what you think of, or are you thinking they're just talking about, like, building ESLint I think that's what you're building an entire app, but not even necessarily a PWA. Like, Missive is an app shipped with whatever Cordova the modern Cordova equivalent is. Yeah. And that's just a straight up Wes view. So, like, apps that are built as a web view is really just it's loading up a browser and loading up everything using HTML, CSS, and JavaScript, and set of native components compared

to React Native, which is actually translating it into real native code.

You know, I think I think I the the better I get at front end stuff, the more I realize that a WebView apps are actually, possible to do really, really super well. I know Yeah. We both use Missive for a long time. Missive is built with Wes tech. It's fantastic.

I started using an app that I'm gonna sick pick today, which is tweak.so.

That's built with Webtech. It's built local first, and it when you use the native app, it feels, you know, you cannot tell. When you use the desktop app, it feels like a native app. So when you feel the act the actual native app, it feels like a native app as well. So I I think there are some things that make them possible to do really well. And in the same regard, I think so many of them are done poorly that people equate WebView apps with kind of, like, laziness or not being done well. I think the only way you're gonna get to a true right once deploy everywhere situation is using the WebView way of doing it. Yeah. And I think it can be done well. Just I think most people don't do them well, which is, you know, part of the problem. So how can you do a web view? Well, local data storage, not going off to the web for everything because then that's going to load like a native app loads.

Making sure that you're following design guidelines for Bos or Android. Right? Design is always a big one. The design on WebView apps can tend to be all over the place. So making sure that you're hitting actual design patterns and design guidelines for good mobile apps. And then 3, like measuring for performance and speed. Your animations, need to make sense. They need to be tidy. They need to work well.

Those types of things are are what's gonna make your WebView app actually really good. Because native native components, yeah, all that stuff is great. Those apps can function very well. React native apps are great, but you'll find it is kind of a ball of complexity sometimes. So

I I think to make it work really well for most developers, unless you're like like Missive and you have, like obviously, they have extremely good developers to be able to fool us into that. We are both surprised that it was was a a web app. You have to use a, like, a component library that has interaction, built in. People are expecting to be able to swipe back. People are expecting to be able to, swipe around, and we swipes is not it's it's not an event in in JavaScript. Right? We have we have pointer events, but there is there is no swipe or double tap or things like that. So I think if you are doing that, you have to reach for a component library that is built for mobile that will feel good. Otherwise, it's just gonna like Scott says, kinda, kinda feels a bit crappy. And unless you're a amazing developer,

you can reimplement all that. Yes. Absolutely. You need to make it feel like a native app. I'm working on this with my breakdancing app, right now. Last night, I implemented local data storage so that way it loads instantaneously on native Vercel.

And same thing Wes every single time. I have a drawer, it needs to be swipeable to dismiss. I have little swipers. They need to feel as good as it does when I was using, like, Apollo on Bos. So, like, those types of things are things you need to be cognizant of to make a good WebView based app. Alright. Next question from CJ. Do you have any recommendations for running or managing monorepos? I've had mixed results with things like Nix and NPM workspaces and the like, so I'm wondering if there's an easy way to use with decent documentation.

Yeah. CJ, I think the easiest way that I found to have a nice working monorepo is with Pnpm workspaces because they're more flexible and more simple than NPM workspaces.

So you essentially just have a workspace file that points to all of the different repos in your workspace.

You reference them. It works really Wes, and I haven't had too many issues. Every single time I go to do a Node repo, I reach for Pnpm workspaces.

That said, I know a lot of people have a lot of lot of success using Turborepo with anything considering it handles caching and makes the hard things, with the mono repo a little bit easier. I I tend to stay on the side of less complexity and less tools and typically just reach for p npm workspaces, and that's it. Because I I do find that once especially with Node repos, once you get into the the tooling for it, beyond your package manager, it all it all feels like it's a bigger project at that point. It's a bit it is that's, like, a prime example of overengineering

to me where unless you're, like, at the scale of, like, Facebook, it's probably not worth making it more complex because then you're gonna get this, like, I can't even get this thing to run. You know? The new devs on alright. Just clone this thing, and, oh, did you install this 47 local things? And you can't even npm start the thing, and it's it's so frustrating. So I like to on the side of standard and then sprinkle on if needed. So my personal course platform is it's Npm workspaces, but I use PNPM to run them because, like Scott says, that's it's the best. Like, I'm just gonna say use PNPM. I use, like, the workspaces in the package Scott JSON file, and then I have added Turborepo on top of it for faster builds. And what that does is it gives me basically, I can, like, take it out if I if I don't want it, and I can still run the thing with Pnpm. But when I deploy the thing, I'm I used to be like, if it's if it's totally from scratch, it takes, like, I don't know, 4 or 5 minutes to build. Mhmm. But then when I have turbo repo, it's sometimes I can deploy in 30 seconds or so. So that might be worth adding on top once you've got your monorepo sort of in place.

Yeah. You don't need the extras until you want the extras.

So start with most simple and then work for frustrating. Otherwise yeah. Yeah. Yeah. Yeah. You just add on a bunch of stuff. You have you're adding config file after config file just to make it work. Yeah.

Question from Al Gore Rhythm. What does energy consumption of generative AI, particularly large language model, compare to serving static web content? With a web server, we can serve cached responses for identical requests, meaning the server does not need to generate a new page every single visit. Right? That makes sense. You go somebody goes to syntax.fmforward/796, and then the next person that visits that web page, we don't need to regenerate that. We don't need to do a database call or or to loop over all of the show notes or anything like that. It's all it's all been generated already, and we simply just need to serve up the the cache version of that. Given that AI responses typically cannot be cached due to context and other variables, this does mean even simple queries like what what is 1 plus 1 requires significant computational resources each time they process. Are there any tactics being developed to reduce the energy for generative AI? I guess bringing context and processing closer is one way, but I would love to understand more about the the subject. Yeah. This is kinda interesting. So I think there's a couple things here. First of all, the big energy usage in AI is training the models. Not to say that using them doesn't use energy. I'll talk about that in a second. But actually consuming and training, that's where you need a supercomputer.

Right? You we saw Tesla is installing 3 fans the size of a freaking football field, which they're gonna put on top of all their NVIDIA GPUs while they're training, like, the self driving. Like, that is wild to me that you have to get a freaking jet engine to cool these things. Mhmm. Because, like, that's how much energy they're actually using. Right? So that's the high consumption, and I'm I'm curious. Like, you do that once, and then you release the Node, and now the model has been trained on all of that data. Then actually using the model, that's certainly still does use quite a bit. I I did a little bit of a a deep dive into this, and I'll put some links in the show notes about how much energy they actually use. And it, of course, it depends on CPU and and where it's actually running. So I wouldn't sweat it that much. And I don't know that you can sort of compare it to, like, a static website because you should really can be comparing it to, like, a web application where you do have to have a a new piece of a new database call, a new generation, a new you have a server running that runs your application every single request on there because they are are unique.

Other things I wanna say is that AI models actually are very deterministic, because we had the guy on from OpenAI, and I asked him. I was like, hey. Like, how do you make AI models give us the same thing every single time? And he's like, they're actually that's actually how they're built.

AI models are it's just math at the end of the day, and they are incredibly deterministic, meaning that you give it the same thing. They are pure functions by default, meaning that you give it 1 what is 1 plus 1, and it will always return the same thing to you. The fact that it doesn't do that is because we don't want it to do that. We want it to be a little bit more random, and that's where you give it things like temperature and seed values and and whatnot so that it will give you a bit of a a random value every single time that it it comes back.

What else can be done? I think, like you said, bringing the models closer to you will certainly help as Wes, but I think the big thing is that the models will be able to run on device.

As these models get smaller and, more purpose built for their actual use case, they require a lot less energy to actually run-in there much faster. We've seen it. You can run a lot of these models right in your browser, and they're not using very much energy at all. And if we learn anything from talking to the folks from AWS JS that if somebody can make something faster and cheaper, they will. Because if if somebody has a $10,000,000 AI bill, and they can cut that down to $5,000,000 because the whatever they've done for the energy consumption and still get the same quality,

they're gonna figure that out. Yes. Absolutely. Yeah. I I think I think it's all dead on. Alright. Next question here from Path 6 Designs. Help. I'm a new developer, and I've taken the time to research technologies, especially frameworks.

I Wes, unfortunately, in my opinion, taught code igniter 3 in school and have since tried out Flask and SvelteKit, both of which I love for different reasons. However, I still want to try Vue and Django.

However, as I researched, I have always had a question that the Internet does not answer well.

Well, it does answer it with just about every possible differing opinion shouted out loudly and often with profanity laced proclamations. This is so true.

Why do I need frameworks? What is wrong with creating a website with vanilla everything? HTML, CSS, and, yes, vanilla JavaScript. What does a framework do that makes it better? What does a static page generator do better? I've seen many answers. I've seen many different answers. And a blog post I read today made me want to get your opinion, and a link to a rant about front end web development, a blog post. So here's my my answer here. Do you need all this stuff? I don't know. For a basic blog maybe not even a blog. Right? For a basic website, just a a basic brochure site. Five pages, no dynamic content whatsoever.

You don't need a framework or anything like that. You can set up caching. You can set your HTML pages. Those pages will load extremely fast if they're just straight up HTML CSS.

The the thing is is most of us just aren't building those type of, static brochure sites anymore.

Those things are often being left into the CMS world, like WordPress Yeah. Where they can have a dynamic back end. Anybody can update that, or maybe they're being done in, you know, Wix or Squarespace or one of those. Right? So that type of brochure site doesn't really need to be done with JavaScript frameworks.

The thing that JavaScript frameworks really do well and frameworks ESLint general is they hold on to context really well.

So you change page and you have some data that's already been loaded once. You don't need to make another trip to load some Nord data. That data could just be available, whether that's, like, user account information or, let's take the syntax website. We have the audio player available at all times.

You couldn't have an audio player that stayed on screen while you changed pages without a JavaScript framework.

Why? Because what the framework is doing is it's swapping out the content on the page instead of loading an entirely new HTML document. So if you need things that are persistent, like, audio player or something like that, you need a framework. At least right now, you do.

Animations, those are coming, with the view page transitions for multi page applications. So that's going to be a thing that will actually, shorten the burden here needed.

But, oftentimes, what people are building with frameworks is not these brochure sites. They're building applications that do things that react to user input, change data live on the screen. You could use vanilla JavaScript for these things. It's just gonna be more time consuming.

And oftentimes, you might run into performance issues because you're not doing things optimally.

And and it's a reason why all the JavaScript frameworks kinda differ in their approach. Right? HTML JS just Scott swapping out HTML with the UI.

And that's actually a really interesting approach because it is kind of feeling like the type of thing you would do with vanilla JavaScript. You're taking a section. You're swapping it out with new information when you click on things. Other ones take more control. React takes a lot of control, so much so that the control goes out of the DOM where other ones use the DOM. So in reality, we're building things that are more dynamic, more expressive than a static page with static data. For a static page, static data, you don't need a JavaScript framework, yeah, even today. But the the end result is most of us aren't aren't building those things professionally.

Yeah. I I did a quick scan of this blog post here, and I understand. I I think the the whole idea behind this blog post is that things are getting way too complex, and the old ways that we used to do it were were much better, and this is my website. But these rants of this is my personal website is like Scott says, it's not the type of stuff we're we're building. Right? This guy's saying, like, I built this with handlebars, and it's a simple website. Like, yeah. If you're just building a content based site, that's probably a good solution. And a lot of people like to overengineer. We're coming back to overengineering every single one of these questions.

But there's a reason why we use a lot of these frameworks, and it's because we are building things that are more complex. And if you choose to not use a framework, you will find yourself building your own framework or at least a whole bunch of libraries and and helper functions around that type of thing. Right? So that's that's why we need frameworks. And often people want to use a framework because, they just wanna be told how to do something and how things work, and they wanna do it in a single way rather than have to approach it in a really frustrating way. If if you're building an app that is like, maybe once we get signals, this will this will change a little bit. But if you're building an app, like Scott said, with all the updating data and live and clicking and changing, that would be quite a bit of vanilla JavaScript to do on your own. And this coming from me. I'm I'm mister vanilla JavaScript. Right? I love it. But I I don't think that I would build any sort of complex application, let alone maybe not even my own blog without a a bunch of it. Yeah. There is really frustrating things. The node modules is is really frustrating.

There's a lot to it. But, like, again, this this blog post keeps going into, like, jQuery JS perfect. We can keep using it.

Like, we've we have much better primitives in the browser. And whenever I read this type of stuff, I often think, like, are you just frustrated that things have changed so much Yeah. And you wanna just go back to what you've known? Because we see a lot of that with developers Wes this is what I know, and I don't want anything else to change. I wanna keep doing this for the rest of my life, and I I agree with that a lot. Right? Just wanna I want I don't want I want stuff to stop changing so I can keep building my stuff. I wanna focus on the actual product and not just continually be churning out, and JavaScript has a lot of that. But there's also a flip side of, yeah, there's a reason why we're building these types of things because we need it. We're not just mashing jQuery into a a whole bunch of random pages to make things work.

Yeah. Yeah. That that is is is truly it. I think that's one of the I know we've had this discussion a few times on this podcast before, but I think that the hard part with discussions in in web development in general in online spaces is that people often talk about complexity and too much this, too much that. Why are you using this? Why are you using that? But they aren't talking about what they're building and how those things are different because we're all building things that are very different. The types of technology you need for building a email client is gonna be very different than the types of tools you need for building an error and exception handling service like Sentry or the types of tools that you're gonna need for building a blog or a personal website or literally anything. So we often talk about, you know, and fight for our tools because they work well for us. But we don't often consider, maybe somebody's building something totally different than what I'm building. They have different Node, different tools for different needs. Imagine that.

Next question we have is from Thomas. I'm wondering how you guys handle ad blockers blocking Sanity, and I'll I'll expand this to ad blockers blocking things that you find useful in your your application.

I'm running internal Wes for an app right now, and I see a lot of issues just don't show up. I'm guessing it's because of ad blockers. So this is the case with a lot of, analytics. This is the case with, obviously, Sentry. This is the case with a lot of third party things that get into your application JS that ad blockers will block them. And that JS, unfortunately the case with a lot of these things because that's people choose to turn on the ESLint, and they they wanna block it. Even if you think, Node. This is good. You know? I want to know information about what's going on. So what can you do? Well, the the way that you get around all of this is and we did this both with our Sentry and with our analytics. What do we use for the analytics again? Plausible.

Plausible is you have to set up what's called a proxy. And almost every single one of these third party solutions will allow you to proxy the data to them. So what you do is instead of sending the data straight to their endpoint, which will often be blocked by ad blockers, is you send the data to your own endpoint, and then you you sort of hot potato it on to the third party service. So if you go to the Syntax website and I'll link up the the 2 files that we use for this. One of them is called 57475, which is CJ came up with that. The reason he named it that is because I believe that's Scott and 3 v three n seven. What's that? I don't know.

And c k leak code. Yeah. C j's demand for stuff like that.

Hold on. We gotta reverse this. I knew it at the time.

B? No. I don't know. B. I'm not good at elite code. I never heard that. V e

n events.

Events.

Oh. Okay.

CJ. So CJ has, what did I say the 5 was?

The s? No. I don't know.

Any This is tuned for me to be bad at it. We had CJ initially didn't name it that. He initially named it events, and it was still being blocked. Because if you look at your dev tools when you're using something, it will it will say blocked by whatever, and you can open up the dev tools and see which requests are being blocked. So you often have to rename them to something that is not that at all. And it's it's a cat and mouse game because as soon as you rename it and if you're a a large website, they're just gonna add that route to to the, the block list as well. So it's it's kind of for the syntax website, we're not that big that someone's gonna add it on to our website, but we have a proxy there that will sort of send the request along. You do have to pay a little bit more because now you're proxying every single request that goes along, but it is a way to to get around it. And it does take a little bit of work to get set up, but you can you can look at our proxies that we've written there. Yeah. It's annoying, but worth it if you need analytics. That's for sure.

Or at least it's it's more annoying than just dropping a script in. I don't run this on the rest of my websites that I have Sentry on. Mhmm. And I must just probably threw enough traffic that it's not ever been an issue. There only was one time it was an issue, and that was because there was an Bos content blocker that was blocking one of our scripts.

Mhmm. What was it called? It was called share Bos Scott svelte, and it was lock it it was blocking the loading of that thing, and it that was breaking the whole website.

So I oh, it's called it Wes called share button dot JS. And share button dot j s was on the list because of some third party integrations that implement share buttons. Right? Like, they don't want, I don't know, dig or something. I don't Node. I don't know who makes share buttons anymore, but it's on the block list. So I had to rename that component hair button Node j s. If you go into the the syntax repo and there's a you search for hair button, you'll see that I had to rename it so that it stopped getting blocked by content blockers. And the the the downside to that was the content blocker was blocking that, but I couldn't figure out why it was being blocked because the content blocker was also blocking our sentry. So there was nothing showing up in in our sentry in that case.

But other than that, I've never had something where it didn't eventually show up. Because even our audience, which is extremely, extremely content blocker heavy, web developers that are security minded. Mhmm. Wes still think only about half of people are using ad blockers.

Yeah. It's interesting. And, we should say, you know, feel free to turn that ad blocker off if you want. I don't know. It doesn't matter. We tunnel events anyways. On our site, we don't have any ads anyways, and we don't have any tracking cookies. So yeah.

Alright. Next question from.

What are your thoughts on using websites being able to work without JavaScript? For example, if you have a form, can we implement progressive enhancement where the form works without JS and maybe the user experience wouldn't be the best? I would really like the idea of making the web accessible to everyone, but the lack of JS limits what you can build. Thank you for your answer in advance. Yeah. So, you know, here's how I feel about it. Most people have JavaScript turned on. I would say, you know, just about everyone in 2024 has JavaScript turned on. That not that everybody does, but just about. Right? Because the web just flat out would be an awful experience for you if you didn't. Yeah. But that doesn't mean that you shouldn't try to still progressively enhance because here's the thing. A lot of sites, they load the HTML first, then they hydrate their JavaScript framework. And in between that time, users can still use the website. And if you click on that form and the JavaScript hasn't completely loaded, maybe you're loading way too much JavaScript and that JavaScript hasn't loaded, then that action will fail if you haven't progressively enhanced this.

So this is one of the reasons why I really like what SvelteKit does here.

You write every single time you're you're hitting the database or the back end to do anything. You're writing a form. You're writing a form with an action that goes to a real URL.

And then on top of that, you're just throwing a little a little sprinkle of use enhanced to progressively enhance and do this form with JavaScript.

So that way, every form you write ends up being HTML first, and that way it works without JavaScript.

And this is sincerely the way I think you should be working.

You should write your forms so that they do work without JavaScript.

However, they should work better with JavaScript so you can sprinkle on that progressive enhancement if that JavaScript has loaded.

So, yes, Shivan, I think you're right. I don't think you should necessarily worry about the user not having JavaScript for everything, but I do think you should be writing your apps in a way that the JavaScript is adding a progressive enhancement to the experience.

I agree as well.

This is one thing I'm really excited about with server components because React folks are finally gonna join the rest of the frameworks Wes build your forms with web standards, meaning that you can submit them without JavaScript on the page. And that's just good practice because if you build them with web standards, they are very easy to work with. And then, obviously, you can progressively enhance them with JavaScript once the the JavaScript Node, But I don't people for years have been saying Brian LaRue is is huge on this as well. It was like, you should be able to turn off your JavaScript, and we had them on, on the show as Wes. And the whole website should still just work. I love that idea, but really, really, who's who's really running a website without JavaScript? Try turn off JavaScript on your browser and surf the web for 20 minutes. It it's not gonna work. You know? Like, I I understand the whole idealistic concept behind it, and I realized we're probably loading a lot of JavaScript on the client, but,

really,

you know,

no one's doing that. Yeah. I agree. People probably gonna get mad at me for that, but I don't I don't buy it. I I no. I I I think it's entirely right. I think the people who are living in that that universe where they say, oh, your your whole website needs to work without JavaScript. And because people out there aren't using JavaScript, I don't think those people exist. Because how many websites like, yeah. Turn it off and browse the Internet. It's it's not gonna happen.

Yeah. Your website should I I think the other thing is, like, if JavaScript Totally. Your your the content should Node, and your your style should load without any JavaScript. Right? But in order to use the application, that I think you you gotta you have to have JavaScript on it. You don't have to, but, obviously, you can you can use h t max with a little bit of JavaScript sprinkled on and whatnot. But, at the end of the day, you you do need it turned on.

Man, these are some we got some good questions.

These like, these are really good. Next question from Sad Yeder.

Hey there. I'm a fan of your content. Thanks a lot. You're welcome. I've been doing freelance jobs using Next. Js and React Native for a couple years. I've been hearing Webpack, TurboPack, Babel, Metro, PostCSS, and more tools, but I haven't touched them beyond some configs. So my question is, what are they for, and should I know and learn them deeper for a better developer? This question makes me so happy because this guy's been a developer for a couple years and doesn't know what these things are, which is not a slight, which makes me so happy that we are in a spot where developer tooling is good enough that you don't have to know what these lower level things are.

So said, I'll tell you, you probably are using Webpack, Turbo, Black, Bable, Metro, and PostCSS already.

You just don't know it, and that's because the the higher level tools are taking care of it all for you. And should you learn them? I don't think you should learn them unless you really need to start poking around and, how to use them. These things are very complex to use. And if somebody can take all of that and tuck it under a nice

NPM script for you and it just works, that's what we've been chasing that for years. So I'm really happy to hear this. Yeah. It is funny when you look back at it, Wes, the amount of complexity that we've lost over the years. People act like things have gotten more intense. But I was just talking to Randy, our producer, just yesterday about, like, how we used to deploy websites versus how we deploy websites now. He's like, oh, I just make a change to this, and I I do a git commit. And then all of a sudden, it's live on the website. I don't understand how it works, but it just works. And I said, exactly, man. Here, let me tell you how we used to do this. Yeah. And then, it just made me think like, man, things have gotten a lot easier once they're set up and once you have gotten it, you know, landed.

Last question here from Henry. Hey, Wes and Scott. Love the show. Of course.

Thank you, Henry. I've heard you both JS well as other podcast hosts mention attending local JS developer groups. How do you go about finding a group and or other events? What advice do you have for attending and meeting people? Thank you.

So meetup.com is really, unfortunately, still the place for this. I don't know why no one's made a better meetup.com yet, but this is still where everything's posted as far as I know, especially the ones local.

You can even check Twitter. But you know what? A way that you could look it for it is your largest region near you. So look for any major city near you, then do JavaScript meetup on Google. Seriously, things will come up. You Node? In Michigan, it was the Southeast Michigan JavaScript Meetup. In Denver, it's the Denver script Meetup. Both of those are on Meetup, I think. But Google, Twitter, Meetup, and once you're there, you just have to show up. You don't have to say anything to anybody. You just show up. Maybe the 2nd time you're there, maybe you wanna talk to people. Maybe there's a rumor in this thing to meet and talk to people.

I I went with a buddy of mine to my very 1st JavaScript meetup, and they were talking about Sass and Haml. It was my very first, time, and everybody was JavaScript developers there or PHP developers.

And they're talking about Sass and Haml. We're all like, woah. This is crazy stuff. And I went with a friend, and it helped that way I went with a friend because I didn't have to worry about, like, how I felt socially. I could just be there and explore the topics and then discuss the topics and then talk about it later. Then maybe, eventually, you Node some other people.

And if you are someone like me where you're extroverted, be the person that, like, sort of stirs up the conversation as well.

Because often Wes you go to a conference or a meetup, there's a lot of people that are so stoked to be there, but they're just so nervous to talk to anybody, and they don't wanna interrupt. So I will often especially, like, in an elevator. Like, it's it's awkward for me, but because I'm somewhat extroverted and because, usually, at least somebody knows who I am, Not to be, like like, pompous, but often, it'll get the conversation going. And then I'll just be like, hey. Did you meet this person? And then later in the conference, you'll see those 2 people, like, hanging out together because they they they get to know each other. So it's your duty as an extrovert to, hopefully, not making people too too anxious, but, try to try to, like, stir it up and and whatnot. Other tips for finding local developer meetups is find developers in your area and just send them a DM on Twitter. The amount of people that send me DMs, hey. I'm moving to Canada. I'm moving to Toronto. I'm moving to Hamilton.

Can I where do we meet up? What what's going on in this thing? You know? Once you're in, it's good. If there's not, start something. You know? Find a couple devs and just go for a coffee, go for a beer. You don't have to, like, make a huge meetup. Some of the best meetups we've had and this is how we found the syntax meetup JS literally just, hey. We're going to a bar to talk about tech. That's true. Yeah. Bunch of people will show up. JS also, people that don't even know who you are will show up. We at the syntax meetup, we had people come up to us, and they go, what's syntax? And I was like deal here. Yeah. What's going on? Yeah. What's going on? And I was like, it's a oh, we're a podcast about about JavaScript. Oh, cool. I'll check it out. And they're just there to crank the free beers because they went on meetup.

And then and then, like, I've heard from many people where there's, like, people that will go to meetups every single night, grab a couple slices of pizza, slam a beer, and then peel.

That's great. Yeah. So if those people can do it, you can do it. Wes, I really appreciate,

the extroverts like you out there. In fact, going to conferences with Wes is great because, Wes will just take you around, and he'll just, like, talk to anybody. And I'm not that kind of person. I you know, it's it's gotten a little bit easier for me the more practice I get at it. But I will say, if you see, like, somebody like Wes or I that you recognize from Twitter or from podcast or anything, we love it when you come up and talk to us about stuff. I personally do. It's really great. In fact, I've met a ton of really awesome developers, especially at that JS nation I was at just recently. A lot of people felt very, you know, cool to come up and say hi and chat with me, and every single person I talked to was awesome and interesting. And, so many interesting people. That's that's also what I love so much about this is that somebody believe really quiet in the corner, and you'd be like,

hey. What's up? I'm Wes. Like, what do you do? And they're like, oh, I I launched rockets with JavaScript and Yeah. Like, it's like, holy smokes. Like, you're really cool. I I wanna hear more about this. You just you learn so much, and I find going to these meetups extremely energizing. I don't go to as many as I I can now that I have a 1000000 kids, but I always leave them. I always go to them telling my wife being like, I don't wanna go to this thing anymore. You know? Like, I just wanna stay home. And then I come home at, like, 11:30, and I'm like, woo. That was so fun. I met so many cool people. Yes. Yeah. It is,

it's it's great. And I I always have a great time, meeting everybody. And then one of the cool things I know to Ted you you said people are so cool. What I find is people are working on the coolest projects.

Yes. People work for, like, the most wild stuff, and it's always just fantastic.

So, yeah, come up and talk to us. It's a lot of fun.

Alright. Let's get into some sick picks. I'm going to sick pick something, for your car. It's called waterless wash, and I just got a new car. I'm really excited about it, and I like to at least keep it looking nice for a a little bit before it starts to get totally destroyed by kids and door dings and and whatever. And I discovered this stuff called waterless wash, which is you just take a spray thing, you spray it on. Obviously, this Sanity when it's totally dirty, but, like, when it's kinda dirty from sunscreen fingerprints or dust from the road, you just spray it on, wipe it around, and then take another microfiber, and then just kinda buff it out. And it makes your car look so good. And it's beautiful because you don't always have the time to do a full wash and dry of the car to make it look awesome, but I found that this is a sort of a great in between.

And a lot of, like, car show guys will use this. A lot of detailers will use this in between doing a a major car wash. So there's all kinds out there. I just went for the RainX Waterless Wash, which like, the the, like, detailing car wash community is one of those communities that's kinda insufferable.

Really? I think it's just Oh, yeah. Yeah. Because they're like, oh, just the best waterless wash is this $80 tiny little 200 milliliter thing that I made myself and, like, here's how to wash your car. I have the 7 bucket system. Don't buy the Costco rags. Those are garbage, you Node? And it's just like, never go through the self washing car washes where you, like, use the scrubber things yourself because those are full of contaminants.

And that's like, regular people just wanna wash their car and have it look okay. You know? Like, I don't this is not a show car. I don't care that much, but I want it to be a little bit shiny. Anyways, that's my rant about car guys. Will probably turn their nose at me using, like, something you can buy at the store, but Rain X Waterless Wash has been awesome for me. Also, Rain X JS a spray for your windows

is is sick, the way it just the water repels. So that that car wash also includes the water repellent in it. So I'm gonna get me some of that. My car cannot go through a car wash, because of it has a matte paint coat ESLint finish. And the Yarn wash will, like, polish the paint coat apparently. So I have to hand wash it all the time. And when it's when it's not actually dirty and just slightly dirty, I'm like, it just never gets washed. So I'm gonna take you up and get some of this just for those times. My my car would, definitely need that. The matte looks so good, though. I It looks so good. Yes. I I've

I've very much considered learning how to wrap a car just to make mine matte. And I I bought a bunch of the the paint protection film, and I I put it on, like, the high traffic areas, like, where the kids step and and where the kids grab and, you know, those areas that get dinged up and scratched. But that is that is not easy.

And and that's coming from someone who learned how to tint his own windows and and whatnot.

And, like, I feel like I'm pretty good at this, but those guys who wrap cars,

is a hard job. Yeah. I I don't I I that's not something I'll ever do. I should have wrecked my car when I first got it, though, because, man, daycare. When you park at daycare,

those parents and kids, they do not care. There's so many little scratches on the side of my car. Oh, yeah. Sucks. Yeah. I should I should have done it right away. So many people are like, are you getting Are you wrapping your car? And I, like, I looked into it. It's, like, $6. Yeah. I know what. Node chance I'm spending $6 to put a plastic wrap on my car. I I was telling my wife, I was like, the most peace you can have in the world is being okay

with your stuff being a little bit rough. Yes. I know. I know. That was actually the best part about my last car being 10 years old JS that it's like, I have to 10 Yarn old. Okay?

Yeah. It will come. It will suck, but as long as you're okay with it, it's it's a good piece. Alright. I'm gonna stick pick an app that I've been using and love. It is tweak dots0tweek.s0.

I like to do apps. I think to do apps are great. I've used many to do apps, things to do with height, all those things. The problem is is that every single to do app is, like, not comfortable with their main function. Every single one of these to do apps is like, oh, we have to add Kanban in planning and teams. And and it's like, I don't need a stinking, project management app. I need to do that for myself. ESLint the point where, like, I was using pen and paper. Pen and paper's great, but it doesn't have things like notifications, and it's, hard to move things around and stuff like that. So I I started using this tweak, which is actually based off of pen and paper style to do systems, and that's what makes it so good. The interface is minimal in all the best possible ways.

It does subtasks.

It does scheduling.

It does, like, week at a glance. It allows you to, like it doesn't even allow you to tag your to dos. It just allows you to to put the a color on them, which is essentially a tag.

And you just drag them in, and it feels really nice and native. It's a local first app. You can download your data at any time. Even the free version is great. The native mobile app or the mobile app is really great. So, you know, as as somebody who doesn't want a complex to do app, who just like I I got ADHD. I'll spend more time on the system than I will completing my to dos if the app is too complex. So tweak. It's simplistic. It's perfect. It's the app of my dreams, and I wish I built it. So shout out to the tweak team. Is it is it free? Is it paid? There is a paid product, which is cheaper than Todoist, but that paid product only gets you a handful of things that you could live without.

So the paid product gives you, like, Google Calendar syncing. It gives you reoccurring tasks. It gives you subtasks and then, like, additional colors, I think.

Okay. And it JS it, like, monthly or a one time?

I did an annual,

but I think you can do monthly. Yeah. Let me check. Sweet. Yeah. That's I did the annual. Thing JS, like, I've been on things for, like, 15 years, and it's just the right amount of, like, complexity for me. And they're not trying to add teams into it. That's what every product is. It's like, oh, we need to make money. How do you make money? Teams. Yeah. You know? Like, you look at higher resources on Teams.

Teams. Everybody wants Teams. That's how you make money.

Yes. I want me a to do app. I don't care. I want simple. You know? Beautiful. Wow. Tweak.s0.

I'll check it out.

Yep. Shameless plugs, check out the updates to the latest syntax.fem.

Scott worked really hard on, building the reimplementing the, the audio player and and putting all those features in, so check it on out.

So, I'm also gonna shamelessly plug the the shop, the the swag store. Syntax.fmforward/shop is the perfect place to find all of these Syntax gear. We have skateboards. We have, like, the coolest basketball in the whole world, and we have a whole bunch of new T shirts that are up right now. In fact, T shirts that are going to support, open source projects as well. So if you wanna check out all the new stuff, it's crazy, including this shirt that I'm wearing right now that says sick pic. It's my my favorite shirt. I'm wearing it all the time.

Head on over to syntax.fmforward/shop.

Show us the back. Oh, that's so cool.

Yeah. That one that one came out really good. I'm really happy about that. It's fantastic. Came out really good, but pretty and we I don't even know if we mentioned this, but you can buy a a Syntax can koozie, like double walled stainless can koozie, $7.

So just store that on your order. Throw that on your order. Yeah. And and we'll have new stuff all the time too. So check it out.

Alright. Thanks, everybody, for tuning in. We will catch you later.