Potluck: Is Virtual Dom Bad?

Welcome to Syntax. We got a potluck for you today. We're gonna be talking all about, templating libraries, HTMLX, Alpine JS, a whole bunch of stuff around OG images, some React questions, felt kit stuff. We're excited to get on in. Thanks, everybody, for tuning in. How you doing today, Scott?

Oh, yeah. I'm doing good, man, after a long weekend. Let me tell you that.

We We're heading up to the mountains. You know, typical trip up to the mountains is maybe hour 30, depending on which mountain you're going to. Yeah. Our lesson was at 9 o'clock.

We left out the door 5:30, and we did not make it to our lesson. That's how bad the traffic was. We we made it like a you you're just sitting in in traffic in the mountains, which is a hard drive anyways.

But you got the 2 kids in the car. It's, you know, 6 in the morning. You're just not going anywhere. There's a 1,000,000,000 cars, and you're just seeing that ETA climb up, climb up, climb up until it's like, our lesson is out of reach, And there's no chance we're gonna make it. And we had to turn around and drive all the way back to Denver.

We we went and got a fancy pancake breakfast because of it, but, man, that was a rough one. And then the immediate next night, My dog woke me up 3 times in the middle of the night, so I I would I'm like, I I rolled into Monday in total zombie mode. It was, like, Straight up zombie mode.

Let's talk about Sentry real quick. This podcast is brought to you by Sentry. Sentry does error exception, performance, insights, tracking.

Basically, it'll tell you why your website sucks or or what went wrong and where it went wrong and and how to fix it. So you definitely Wanna throw Sanity on your website. You throw it on your back end. It supports all languages out there. It's fantastic. Don't wait until it's too late, to install Sentry because then you're gonna be like, oh, well, there was a major crash or this people are telling me this being slow as heck, and I don't have any insights as to what browser they're using or, where in the world they're coming from or or any of that information. What page they were even on? Like, what clicks did they do? And that's Problem we had on, the Sanity website is people were telling us like, 1 person was being like, it's not working or, like, I I don't know. And then we just went on to the Century Replay, and saw, oh, we can see where they were clicking, and then I tried it myself and go, oh, I forgot that edge case. You can't Click on a time stamp before the audio is playing, so we had to add a check for that. So check it out. Century.ioforward/syntax.

I think you nailed the an ad pitch for them too, Wes. Sanity. It shows you why your code sucks.

Sentry is marketing team. Get at us right there. Yeah.

Let's talk about Randy.

So we have a a new producer on the team here at Syntax.

Randy is here to do everything related to getting us a video podcast, making us sound amazing. You may notice that I changed my camera angle.

It's looking much nicer.

I I made Randy drive all the way down here

and, and fix that all for me. So We're really stoked to have Randy on board. You wanna say hi, Randy? Yeah. Thanks for having me, guys. I'm I'm pumped to be here, pumped to learn from you guys, and to get to listen to all these episodes. So I'm I'm Just so stoked to be here. Yeah. And and, likewise, Randy does some really awesome videos of his own on YouTube. So I'm gonna link up his YouTube channel in here where he reviews microphones and and talks audio stuff.

Awesome, awesome content. So if you wanna get a feel for It's it's nerdy in a good way. If you wanna get a feel for his vibe, it's it's dead on there. So Yeah. We will,

eventually be introducing the Randy Rance segment Wes, Randy just rants about whatever JS going on. It's the name works. So Yeah.

Has Has nothing to do with web development at all.

No. Just it's just a platform.

Not not that you don't have your own YouTube channel to rant on, but,

we'll we'll take it. How much longer until we start getting Randy, can you throw that up on the screen for us right there, whenever we do these video podcasts? And who knows? Maybe that's something, You know, we'll get out of this. Importantly, Randy is

Chili, a Canadian podcast about web development, and we are going to be changing our tagline from a Sanity treats podcast to a Canadian podcast about web development. All All All Wes.

Is that a Canadian thing? Ultra. Oh, that's that's a good name for, like, a ESLint,

all dressed instead of full stack? We don't have that in the States. So

That's good. You you don't have ketchup either, do you? We have some weird chip flavors here in Canada. Oh, yeah. We don't have ketchup. I thought you meant, like, ketchup in general. Yeah. We got ketchup. Oh, no. Ketchup chips. Got ketchup. Ketchup chips. Yeah.

Alright. Let's get into the 1st question we have here from Chumbawamba.

His question is, Is Alpine JS or HTMAS a replacement for Pug or other templating libraries? For instance, could Alpine JS be used in Wes' learned Node course instead of Pug? So Pug was or is a server side templating language. It Used to be called Jade. They had some legal trouble, and they renamed it to Pug.

Any advantages or drawbacks? So Real quick, let's explain what Alpine and JS that you include Alpine very much how you would include, like, a jQuery on your website.

And Instead of writing JavaScript, you write, like, declarative HTML, very similar to how Angular one Wes. So you can do loops, you can do on clicks, and it's all just, like, attributes inside of your HTML tags. And when your HTML loads and parses, it gets picked up, and you add interactivity via that. So we had Caleb Porzio on the show. You can listen to episode 568.

Just go to Spotify, type in syntax 568 or go to syntax.fm forward slash 568.

And we talked to him all about, Alpine JS. HTMX is a server fetching JavaScript framework. So, again, it's it's client side.

However, it's just used for pinging your server and fetching the new refreshed HTML for the portion that you needed. It is also declarative, meaning that instead of writing JavaScript, you just write HTML, attributes for what you're looking for, and it will work with you.

So many people use You use HTMLX for, like, the server fetching refresh and Alpine JS for the client side interactivity, things like clicking and looping over if data that has possibly been fetched from an API, that doesn't replace what a templating language is. Is even though HTMLX and Alpine JS have the ability to do loops and things like that, they're not templating languages. Mhmm. So you still need some way to render out HTML. So whether that's using Pug, whether it's using, what, handlebars, mustache,

you can use JSX.

I'm using that on on my, Node site. It's I'm just I'm just rendering it all clients or server Node, and just sending it. I don't use any React in the actual browser. I don't need it. What what are some of the other templating languages?

JS? Is that one of them? Yeah. That was a big one. You said handlebars,

mustache. But, like, obviously, the other ones are, like, Blade if you're in PHP.

Every language has their own, like, templating Svelte layout. Liquid is a big one. Yeah. Like, could can you just use Svelte only for Templating?

Probably. I mean, you can run it as a function and and get the output directly from there. Yeah. I've I've used it before for that. To answer your question,

No. It's not a replacement for that. You still need a templating language.

HTMLX and Alpine JS are just added on top of your templating language.

Word. Next Node from KJ.

What powers in app browsers, and how can we test our sites on it? I'm curious to know How they affect loading speeds, unexpected layout shifts, and accessibility, if there's anything we can do about it from our side of things. So In app browsers. You may have seen this on your phone.

You're sometimes you click a link on something, and instead of taking you to the browser, it opens up the website In a mini browser that's essentially within the app. That's the in app browser.

And on Bos, It is the in app browser is Safari.

On Android, the in app browser is Chrome.

It's whatever the browser that is shipped with the OS. And in fact, we we kind of have that same thing going on macOS as well Or, Windows, even though you don't see that same in that browser flow typically in desktop apps. Either way, typically, an OS Ships with a a web view. So in Bos, it is wkwebview, webkitwebview.

And that is the the, essentially, the wrapper for many things that is not the browser. And it's typically just straight up the rendering engine.

And I've a little even, like, shift in terms of what works and what doesn't in this ESLint the Tori ecosystem because not every feature that's in Safari is in the WKWebView.

Most of them are the rendering engines the same. Chances Yarn, if you're testing your browser or testing your app in Safari, It's gonna work the exact same in the Bos Wes view, so there shouldn't be any issues there. Again, the most of the stuff That doesn't exist is maybe, like, permissions dialogues or, like, things that are very specific to how Safari functions itself.

But, again, if you wanna test on, your normal browsers, whether that's Safari, Chrome, and Firefox, Hey. That's pretty much all you gotta do unless you're getting into some nitty gritty APIs. I wanna say that. It used to be where,

and This is one of those things where, like, it kinda sticks around. People said it once, and it stick has stuck around forever.

They used to use UI WebView on Ios, and that was a there was, like, bugs that were in UI WebView that were not in Safari, and that was extremely frustrating, and, apparently, it was slower.

Now, like Scott says, w k, Wes view is what they use, and Bos also provides a entire Safari embedded experience. So if you are trying to embed a in app browser, you can either build your own with a a web view, and you have to recreate tabs and the input bar and the refresh button. You have to implement everything. Or you can use the Safari view controller, which I love when apps do that because it shares, like, login data. Yeah. So if you're, like, logged ESLint as something on Safari, then you're also logged in when you're inside the app. The one sort of gotcha that you you should think about. And I honestly, I've never once in my life tested a website inside of a in app browser. It's I've never had that issue before, and it's it's never popped up for me. But these custom in app browsers can inject their own JavaScript code. So there's this website called in app browser.com.

I just sent a link to the syntax, Instagram account, and then I went into the Instagram app and clicked it. And it shows you that Facebook is injecting JavaScript code onto into your website.

And I never Try to, like especially logging in. Oh, yeah. That's But I never browse inside of inside of the in app browser because you know they're They're scraping all that data and, like, oh, what are you what are you looking at? What do you what are you logging in with? What what products are you looking at? So Not to say that every other website that embeds a Facebook like button doesn't do that already. But Yeah. Yeah. I run, blockers on that. So that's one thing to think about. I tend to always open up in

the browser if I can, but I I think normal folks are just opening up in WebView and Typing in their password that's equal to password and calling it a day and not thinking about it too much.

But, this actually is the principle in which The entirety of Tori, which is the Rust based Elektron competitor, tauri.app JS based. And so much to this, to point that they're they're now going to be shipping the ability to do mobile apps with Tori as well. So you could ship a desktop app on Mac, the Safari Wes view that's baked in Linux or or Windows, but also soon to be Android and Bos just based on the fact That they all ship with a Wes view, and you don't need to ship that with your app.

Next question or or not maybe not even a question, but a nice blog post by, written by Danny Jimenez.

I said, this isn't a question, but I was walking to the auto mechanic to pick up my car while listening to Node 709.

The discussion about what generators are good for stuck in my head, and I didn't quite follow the example. I was inspired to do a deep dive, and I even wrote an article about it. So I love this. We've had we've this has come up on the podcast maybe, like, 7 or 8 times now, and it's just us being like, okay. We understand what generators in JavaScript are for, but, like, when are they actually useful? And every time we come back to this, I've I have stumbled upon a couple new use cases myself as well. So Danny goes on to say, iterators are everywhere, and they are what make syntaxes like for each loops and array destructuring possible.

When things aren't iterable, you can easily create an iterator with a generator function. So this is kinda interesting. So you have a regular JavaScript for loop. Right? Like, for blah blah blah of.

And If something is iterable, like an array or a node list, then you can loop over those items. But if something is not in iterator, then you can make something iterable. You can loop over them, by making it into a generator function.

Observables, streams,