864: Durable Objects × Tab State Hacks × Headless CMS Choices + More

Welcome to syntax. Today we've got, first of all, Happy New Year, January 1st. We got the first potluck of the year. Lots of really good questions about what the hell are durable objects and when would you use them? Should I use MDX for my personal blog? It's a new year. Everybody's got the, they want to build up, I'm going to build up, redo my website this year, right? New year, New Year, New Year, New Year, New Year, New website.

That's how it goes along. Is CSS done? That's an interesting question. Frameworks, should we have lots of smaller packages, or should a framework just do everything batteries included, as well as we talk a little bit about hosting providers, which one should you use? Let's get on into it.

Real quick, let's talk, I'm gonna tell you a tale about a bug I had and how sentry saved my bacon. So I rolled out a couple of days ago, I rolled out a new checkout on my core sites that I've been working on for quite a while. And the checkout experience, I did all my testing and whatnot and I released the thing and I just like soft launched it. I put it on one of the core sites and I just wanted to make sure that

there would be some transactions come through and I could see anything. And surprisingly, there was no bugs with that. But there's one bug that broke the whole thing on iOS 15, which is many, many years ago. But the thing about old iOS is that it's on people's iPads. And people tend to keep their iPads around for a long time because they don't use them as much and they just grab them every now and then.

I got this error popped up, cannot access off screen canvas. And I was like, what the hell is off screen canvas? I'm not using off screen canvas anywhere. And you know what it was?

What? What was it? Confetti. It was the confetti library that I was using. So the confetti library that I was using would render the canvas off screen for performance reasons if it was available. And there was some bizarre thing where it was they were testing if off-screen canvas existed. But Safari, as Safari does, there was some weirdness around it. And I was seeing this bug come in a couple of times a day, not a ton, but enough to warrant

wanting to fix it. So I was able to open it up. I fixed it. And then I just set it as resolved in my century. And at that point, you pray it doesn't come back. You hope you fixed it. And it was really great because if I would have probably never have known that it was broken on that device because it was such a low traffic.

and I don't know that I would have known to test a six-year-old iPad or horrible. That's a worry. No kidding. Yeah. Those types of bugs are typically like you toss them like a boomerang and they'll just eventually come right back here. I hope I never see you again. Hopefully. Check it out. Sentry.io for its session text. All right, let's get into the very first question from Bean Harry.

You think that's a joke name or not? I don't know. Believe it or not. What are durable objects? They seem to pop off everywhere recently. It's true. I also have noticed this whole word durable objects pop up. I know CloudFlare is every time they announce a new product, they say, oh, we're just building it on durable objects.

All right, so I'll do my best to sort of explain what I at least think they are. And durable objects, they have this idea from several different vendors, but probably the biggest one out there is CloudFlare. And it sort of solves one of the problems with not having a server running all the time. So if you have a traditional server,

It's up and running all the time. And if you want to do things that are both real time, meaning that like multiple people can connect to something and you can set like a web socket back and forth, or if you want to keep like state like in memory, traditional servers are very good at that. However, with

serverless functions, Cloudflare workers, these things just kind of spin up as they are needed, right? So it's a little bit more tricky. So the idea with a durable object is that you can create a durable object and you can connect to it via web sockets. So if

If you want to do real time on something that doesn't always exist, like a worker doesn't always exist, it spins up, it gets used, and it gets spin down. You reach for a different service like a durable object. They also have the ability to keep memory over time, and you can share that or keep it per user. And they also have a storage API where you can stick stuff. So specifically, CloudFlare also has a SQLite.

API for durable objects. That's in beta right now, which I've used myself. It actually works really well. And you can also like roll it back as well. So I think like durable objects is just like a primitive in which you can build stuff on top of. And it's good for storing data and doing real time. And then people will tend to build stuff on top of it like they're SQLite adapter.

Yeah, not something I've used, but, you know, it's like one of the, I know you said it's not just CloudFlare, but it's one of the hosts of CloudFlare products that I look at all the time and I'm like, ah, that'd be really cool to use sometime. And then just don't. I don't have any need for it. But although it does sound interesting and something that I, you know, probably should dive into at some point here. So thank you for that explanation of durable objects.

Have you heard of PartyKit? I've absolutely heard of PartyKit. I've used PartyKit. Okay, so PartyKit is built on top of durable objects, right? Interesting. Can you explain what PartyKit is?

Yeah, well, it's funny because it does kind of fit into this whole, man, real-time multiplayer world, which is it's oddly enough, very kind of intermingled with the local first world in a way. So you see a lot of the same tech and tools come up. But basically, it's a platform for building multiplayer apps easier, sending messages between users that are currently using something.

And what's interesting about this is that it's pretty flexible, right? So it's not just like use party kit and that's all you can use party kit with a bunch of CRDTs. You can you can use it to do interesting multiplayer real time stuff. But at the same time, it is a bit lower level than something like

Ooh, live blocks, I believe. Live blocks kind of fits in the same spot of building collaborative multiplayer experiences, but kind of does a little bit more. So, yeah, at the same time, it's doing a lot for you, but it's also very flexible for building multiplayer apps.

And it also does the whole offline syncing thing as well, right? It is a sync engine. I know it does crudetase CRDTs. It uses other CRDTs. So you can use YJS, auto merge, those types of things with it. So again, it's more or less like the

It's more or less the multiplayer part of it than it is the conflict resolution, but it works well with those conflict resolution libraries. It's kind of cool because if you did ever want to build a real-time application,

Uh, you're kind of committing to having a server running. Oh, yeah. Absolutely. Yes. For the life of that thing. And as Clubler does with these types of things, it's like, well, we're not going to let you do that, but we are going to give you this other product that's actually really good at doing this.

Yeah, it's a cool project. And one that when I first started diving into the docs were like nonexistent. So I really had to struggle through it for a bit. But now it looks like the docs are much better. There's a lot of examples. Active user avatars, chat apps with active avatars. Yeah, cool stuff.

Next one here from Rod, loving your podcast. I'm hoping to use a CSS anchor positioning after getting it working beautifully on Chrome. Nice, Rod. I'm desperate for some across browser support. I thought the polyfill would save me, but I think it doesn't work because all of my CSS is dynamic. Do you have any updates or backstage dirt? I went safari will be releasing this major feature.

Yeah, I don't have any, I guess maybe I have talked to folks about this who have said that it is past the stage of fussing anymore because last time we talked about this, there was some talk about maybe perhaps Safari not being

totally on board with the current API. I don't know how that was resolved, but my understanding is that was resolved and that they are implementing it. There was an API for positioning things with keywords and the position area property, which is you can say top left,

bottom right, Y span, span X, span X, and basically you can tell it to go anywhere you want with just these keywords. Or you can, there's a whole nother API where you can specifically calculate where you want it to go. But a lot of the common use cases that you're going to want to cover are simply you can just use position area.

It previously was called inset area and the API was slightly different. That was in Chrome. It's since been scrapped. Hopefully, I'm doing a quick search on Bugzilla on WebKit.org. That's usually where I go to see where they're at. Otherwise, I will go to WebKit GitHub.

And you just do a quick search for some of the common CSS properties, like position area, and see if there's anything there. Let me do a quick search. Yeah, and in the meantime, I found the Mozilla because you mentioned when is this going to be in Safari. I think it's worth noting that this is also not in Firefox just yet in any regard, not in any alpha behind a flag or anything like that. But I do think

This year, this 2025, I feel like we'll have to see some movement on this. This API is so awesome. And for people who don't know, anchor positioning allows you to anchor something to something else. So typically we would have done this with position absolute inside of a position relative container. But the anchor API is more than just saying, hey, pin this to the bottom left.

You can do things like if it's close to the side of the screen, move it to the bottom right. If it's close to the bottom right here, put it to the top left. So you can do some really amazing interactive things and how you position things that let's just say we're, that's a giant pain before you're reaching for JavaScript, you're reaching for all this stuff to be able to do that. You're bringing in a library. As for the polyfill, like you mentioned, I have not also, I don't know if it's just your dynamic stuff. Polyfill for me has also never worked totally well. I don't know.

why that is if I'm doing something wrong as well. But you know, it does exist if you want to give it a try. And yeah, anchor positioning is pretty, pretty dope overall. Yeah, it's probably because like it uses CSS variables. Right. And with polyfill, sometimes there's like an extent to being able to pull out the value of a CSS variable. So that might be it. I just did search on on the WebKit GitHub and there was many

pull request merge going back to September. So four months now around the CSS anchoring. So yeah, it looks like a good chunk of it is in. There's even issues around how it actually handles it. So I bet we'll start to see this. I bet January, 2020 for five, we'll see this hit Safari technical preview. That's my guess.

Yeah, I see even in the Interop web platform test repo, the most recent comment about it on October 11 says it's a good candidate for Interop 2025. And Interop 2025 would mean that all of the browsers would make it a goal to get this in by 2025. Yeah, so

Hopefully that happens. I'd be stoked for it. It's one of the APIs that I feel like is really holding back some things like pop over right now, which got a love pop over, but would be even better with anchor positioning. Can't wait to have that. Next question from producer Randy. I don't know if that's our producer Randy or not. It is our producer Randy because I cut off the part of the question where he says, I could have just asked you guys this in Slack, but I wanted to put it as a question.

Do freelance developers with skills in graphic and UX design often win the work over the competition? My hypothesis is freelancers who are good at making nice looking sites would always win based on portfolios because clients likely have no idea what makes a good site when a client is comparing two developers one functionally perfect site and the other one of the amazing visual appeal I feel like the good looking one will almost always win thoughts absolutely How it looks

plays into this quite a bit. In fact, I saw people were talking about this on HTMLX the other day, where people were saying, do you think more people would use HTMLX if the website didn't look so crappy? And the answer to that is yes, I think so. And as much as it doesn't need to, because HTMLX has absolutely nothing to do with how it looks.

When you visit a project website that looks nice, even when we're interviewing people, when you visit somebody's website and it is nice and polished, even though that, again, that's not what you're hiring them for, you just say, oh, this person has good taste. And they have figured out how to make it look good, right? Whenever you see someone do something that is visually beautiful, you think, wow, this person really knows what's going on.

I think it's worth learning a few things that make a website look nice. It's unfortunate that that's the case because your technical prowess in some ways, whether that is performance or the training that you have for doing things programmatically, doesn't always necessarily require things to look nice.

It's I think it's just an eight part of human psychology. If something's looking nice, looking well produced, well put together, I think you're inherently going to feel like it's of higher quality. Just because it shows that they do care about those little things. It's another thing even like with pixel perfect design, right? You ask somebody to implement a design. And if somebody has a good looking portfolio, a good looking web property that is,

organized and very structured design-wise. I feel like you have a much better idea that that person is going to be able to implement something that has very tight design requirements. I think that pixel-perfect design is a skill that a lot of front-end developers should make sure that they are always staying in touch with it. Your implementation of the design must look like the design if a third-party designer designed it.

Totally. Even look at something like Veet. Veet is a JavaScript bundling tool, right? Yeah. And it's like competitor at the time was Webpack dev server. And the Veet console log to show you where your URL is. It's nicely indented. There's little arrows. They use emojis where possible. Nice line spacing.

That shows me that the developer behind this avenue cares a lot about it, right? He's just, he's an actual developer, but the V Docs, all of that, it's the same way as well, right? It just, it looks beautiful as well.

Yeah, totally. I agree. And even as far as like you mentioned with the command line stuff, that's something that Astro does super well. Their CLI tool is like one of the coolest looking CLI tools. And there's something about that. It just makes you think somebody actually cared about making this instead of just threw it together, which I think kind of impacts how you look at the rest of it. I know it probably shouldn't.

Nerds online will be like, that doesn't matter. Designed by engineers is fine. But hey, man, I do think it actually does matter and how you feel about things. Next question here from Anan. I'm curious about your opinions, West Sky and CJ. CJ is not here, but I will pretend to give CJ opinions.

on the different deployment platforms out there. Netlify, CloudFlare, fly.io, AWS, et cetera. I would love to hear your preferences are for professional and personal stuff. I'm gonna say I host all of my things in a couple of places. I host it either on my own Coolify server, it's on headsnare, it's an ARM server, and that's where I just dump a lot of stuff. Typically, fun projects, side projects, whatever.

If it's something that I really want to just set and forget about it or something, I want to make sure it's always up and always working. I pretty much always use CloudFlare for that. I throw everything on CloudFlare workers since these felt CloudFlare workers adapter is so smooth and easy. You just drop in the adapter, push up and go.

So for me, it's either in CloudFlare or my own Coolify server, and I got to say that's pretty much it. We host the syntax site on Vercel, but none of my projects, I don't put any of my personal projects there. I would be interested in learning about fly.io, it seems nice, it seems great. I would be learning more about, interested in learning more about SST, looks nice.

would be nice to be able to host things on AWS without having to become an AWS certified expert or something. So yeah, that's pretty much what I do. We did a whole show. If you go to syntax.fm.4 slash 615 on where should your host your app hosting providers compare where we went deep on every single, not every single one, but like all of the options out there. And I just made a quick list of the ones I personally

I think currently I'm running code on Netlify, Versal, Render. Digital, not on DigitalOcean anymore, it was for a long time. Quite a bit of stuff on CloudFlare. I've tried Railway and Fly. Those are both kind of interesting. Fly.io is kind of interesting because it's not serverless, but you still can scale up and down as needed. Flight control is another kind of interesting one, kind of in the same area as SST for

deploying your apps to AWS, just straight up. I have a coolify server running in my house here. I have a couple of projects on as well. There's a lot of them out there. Maybe we should do an updated show. It's been a year and a half since we did the show. I don't know that too much has changed in this arena.

Let's go ahead and try to use some of these that we haven't used. Let's do that. We'll do a deep usage on some of these that we haven't used. We'll give a personal experiences. I feel like I've used every single one. Oh, I have a couple on Dino deploy as well. Oh, yeah, you can use fly I've used. I've used railway. Yeah. Linode, digital ocean, Heroku, Vercel, Render, Azure, Google Cloud, AWS, flight control.

I've used them all. You have. Maybe we should take one app and try to deploy them all. Yes. That actually would be a fun exercise, especially maybe we could even do it live to see what kind of pain points you hit. Because that's where you hit the pain points. You hit something and you get some weird node version is not correct error and then you got to figure it out.

Yeah. Yeah. Like, what would be a good app that would test it at all? You know, it would have to have some backend, front end, a build step. I think that would be good, you know, like, like a build step that does HTML, CSS, JavaScript, a front end. Probably not the syntax site because we know like, yeah, I don't know that that would run absolutely everywhere because a lot of these are not made.

for all of that, but like just a simple like three back end routes, couple client side things, images, CSS. I got apps for that. Yeah, that'd be good. All right, I'll do it. Sick. Cool. Next one from Anon, what process do you use to make sure your website is WCAG compliance? We've answered this quite a bit. Specifically, I will tell you to go back to the Mercy Sutton show.

which is episode 836 syntax.fm.4-836. And there's a lot of automation you can do in terms of the browser will run a bunch of tests in Chrome DevTools. So you open up your DevTools, you go to the Accessibility tab, you can run some tests. That'll catch quite a bit of it. There's also a whole bunch of ESLint things you can turn on. So I have one for React A11Y.

And it will slap your hand as soon as you forget to do things like add an alt text or don't specify a button or if you have a click handler on a Unfocusable element like for example, if you put a click handler on a div, it's going to slap your hand and be like, hey, there's you can't there's no way to possibly reach this with the browser. So please add

like a tab index or something to it so that you can focus it or use the proper element for this. Maybe you meant to use something different. So those are big ones as well as we go through the episode with Marcia of how to actually run screen readers and test these types of things.

word. Yeah, I just the only tool I really use is polypane does a really great job of letting you know what there's all sorts of accessibility audits. Polypane is a browser for testing stuff does a great job of visually testing stuff for mobile, whatever. But I also pretty much straight up use it for testing accessibility as well. So that's what I do polypane. What's up?

Next one here from Saidyether, hey, fan of your content, thanks for reading my question. My question is about holding state on the URL. Here's a scenario. Let's say you have an e-commerce app. I'm going to do my best to read this, by the way. This is an interesting scenario. On the product page, you hold the size and color in the URL.

Let's say you have a URL that URL is a typical URL, you know, site.com forward slash product ID, then you have your query params, like so, question mark size equals small, color equals blue, right? Pretty typical. That way you could share the product in the individual product type.

So below the product, there are some suggestions about similar products. So here's the question. Let's say you want to implement tab functionality to this app. In one tab, product ID is five, size is large, and color is red. In tab two, product ID is 23, size is large, and color is green. How do you store the tab state?

In the client state, if I store the URL and I share that URL, the person who clicked this link might not have tab four or tab four is used by another product. On the other hand, let's say I have five tabs and I am at third tab. When I click the suggested item, it should be the third tab.

it should not update the first tab. Obviously using the browser tab would be much better. How would you approach this? This is some complex state. So basically what they're saying is like you have an interface where the user has the ability to essentially

whether that is like have different products in different places here and whether or not they're comparing them either way those tabs all have a very specific product information and the location of them all that stuff man that sounds like a crazy use case to have as a long URL. I think the only way in my mind that you could have this functionality and share it as a URL

would be to just have a long URL with a lot of query parameters. The size limit is pretty big. I've never seen a URL that would be longer than what it would take to do something like this with query parameters. Granted, that gets very complex. At the end of the day,

you're hosting a set amount of things in an order, so the order in which they're, I guess you'd have to have unique query parameters, like tab one color, tab one size, and you just have those unique query parameters for all of your things. That is not something

I've had to do. The interface that this reminds me of is on a product website. Let's say I was working on Ford.com. We had an interface where you could compare different models of cars. So you'd say, I want to compare this version of the Mustang to this version of the Mustang. And it would put them in a big table. So yes, you're having multiple ones up and you'd want to be able to share that. Say to me,

I would just make it a long, long-ass URL. That's what I would do if you need to have that be shareable in state. But what would you do, Wes? Because this is an interesting question.

shareable URL state is for things that are publicly accessible. And what he's describing here is the fact that a page can look different for absolutely everyone, right? And if that's not shareable, then it's maybe not some state that needs to go into the URL. However, if you're doing what you're explaining, I thought that was a great one where you're comparing multiple things, then if that's the case, I would

Put the product URL product IDs in the URL and then also pass a highlighted product ID in the URL along with it because you can pass multiple products as an array in query prams you just say.

question mark product equals one, two, three, and then another one and product equals four, five, six. Now, all of a sudden you've passed multiple products to that and then you can pass a third argument that or a third query peram that specifies which one is currently being focused. At a certain point, there's too many possible things and that state doesn't need to either be stored at all because the user can simply just go back and click to where they wanted or

that state needs to be stored in local storage or on the user's profile or something like that at a certain point it doesn't get out of doesn't make sense right if you go to syntax website and you go to click on shows we have filters for the type of show

how many per page and how you'd like to sort them, right? And between those, what, there's four types of shows, three options per page and two options for sorting. That is what is four times three.

times two, that's 24 possible permutations per page. And then we have 86 pages. So that's 24 times 86. The page also goes in Europe. So that's 2064 possible URL combinations. And I'll tell you, we go into our Google

Webmaster search tools and it tells us hey, there are thousands of unindexable pages and it's because I've I've explicitly told Google don't index every possible page like there's some there's some pages that are Not meant to be indexed we know page one page two page three those should be indexed but page 87 of hasty treats while you're putting 14 per page that that doesn't make sense to Actually put on on Google

Yeah, yeah, totally. Interesting problem, though. I think you have to ask yourself, is this something that needs to be shareable as is? And if it is, you got to do what you got to do. But hey. Next question from Austin. The addition of has to CSS seems like it solves a ton of problems. It makes the language much more powerful and flexible. So real quick, CSS has allows you to select an element when it has

a specific child. And that's really handy because you can select a parent given the state or the selector of something that is inside of it. You previously have not been able to do that. I've been thinking recently how CSS these days just does what I want. And it got me thinking, will we ever reach a point where CSS is complete? That is where all the features developers need and doesn't need to be updated anymore? Or will there always be some new refinement that can be added?

That's a great question. I was at a conference in Una who works on Chrome, the Chrome dev relations. She basically was like, all right, well, can we add?

And I was just like, hmm, hmm. Good question. Because it's like customizable select. We're doing that. Mixins, we're working on the functions. We're working on that. You know, like you think about all these things. Flexible layouts, you know, we got Flexbox in grid and being able to vertically align something without Flexbox or grid. Oh, we can do that with block level elements now. And like, I feel like we're getting close to a point where

We have a lot of the things that we want. There will always be new UIs. There always be new form factors. We saw this with mobile. All of a sudden, CSS now has to adapt to fingers and multiple touches and whatnot.

I think as interfaces constantly evolve, as different interfaces become popular, and as we get new things in CSS, those sort of dictate the UIs as well. We don't build certain types of apps simply because they are not possible.

And once we get new CSS has, oh, wow, now we can start doing, you're going to start seeing a lot more common things where you can highlight the parent of something when that item is selected because you don't need any a bunch of JavaScript for that. So will we ever be done? I doubt it, but I do feel like the last five years and probably the next two or three years has had some significant change in CSS. And we're at a point now where a lot of people are pretty happy.

Yeah, well, we're pretty happy for right now, right? Yeah, especially because like we said, a lot of the stuff that we've been getting has been like extreme quality of life stuff stuff that we've been saying wouldn't be great if we could have for so many years. But I do think there is a future world where CSS is going to be taking care of some things that like

perhaps are not on our radar right now, or plate right now. Maybe even by who knows, the end of the year, we'll start thinking about more about this stuff, but like WebXR, man. WebXR, very much firmly the category of JavaScript these days. So I'm talking about being able to place things in

virtual reality and augmented reality in different locations. We think totally in boxes right now. We have our monitor, we have our phone, we have our computer, whatever. They're all boxes and the website is a box in the browser. But if you were to think about it, if you were to take your website and you were to move it outside of a square, what might you have? For the syntax site, you might have

the syntax podcast player as being its own thing, or maybe you have the listing as being its own thing, and these might take different shapes. They might exist different places in 3D space. I wonder if we ever get to the point when WebXR becomes more ubiquitous or XR in general, right? Because XR, people start actually having XR devices, you know, glasses that can project things in 3D space.

I would imagine that we would not like that to be entirely the realm of JavaScript forever, right? I would imagine. So at least me personally, I don't know what that looks like or what that even means. But I do think that the way that we build interfaces or the way which we consume interfaces, maybe I should say,

will change once XR becomes more ubiquitous. I think that might dictate maybe some of these newer things that we're just not even thinking about right now. Because right now, building websites, hell yeah, brother, it's all looking good. There's a lot of great stuff. For me, personally, give me mixins, functions, style queries, and I'm going to be happy camper here. That's where my thoughts are on that.

Next question from Beanie Wanting. When are we gonna get syntax beanies? Took for the Canadian, thank you, I appreciate that. I don't do hats, but I do love a beanie. I do like this as well. We've been talking about it. Scott's wearing a beanie right now. The thing about beanies is that they're all different and I don't know what the best beanie would be. I do, this one right here. Nice one. Nice one. Nice one.

My beanie, it's got to be one that you can unroll so that I can wear it nice and tall if I want to wear it nice and tall, or I can roll it up and still have a little bit of space at the top. I'm not a guy that wants the beanie to the top of my head like this. That's not my look. I need a little bit of a...

A little bit of a, what do you call that? A little bit of a slouchy beanie. Sure, because I also have one that's like oversized, big fan of that. The other thing is that with beanies that are knit, if you put a patch on it, or if you try to embroider on it, it looks like crap as soon as you stretch it.

and then and then the lines don't line up like the one that Scott has right now is is perfectly straight, but if you're it's so something on to that and it's sucked in state and then a little tag. Yeah, I think the tag is probably your our best bet.

I'm a beanie fan. I wear these things all the time for dance, for whatever. I'm constantly wearing a beanie no matter what if it's appropriate to. Even in the summer, sometimes I'll put one on in a problem. In fact, I got made fun of that for once when I used to work at a computer store.

I think you probably told this before it's it's stupid but I was some guy was saying how much he hated apple fans and he's like it's a bunch of kids wearing beanies in the middle of the summer and I was just like look so for me I'm on my apple computer I'm wearing my beanie in the middle of summer. He was trying to say that to hurt my feelings or what but.

We have another one last question here from Fahad, and it says, long time listener, I would like to know what headless CMS I should use for my blog. I am a software engineer who does technical design with mermaid designs. Hold on. What the hell is a mermaid design? Oh mermaid.js.org. I've seen mermaid diagrams. It doesn't say mermaid designs, by the way, does say mermaid diagrams.

Oh, I read that wrong. OK, so mermaid diagrams is a.

library for building beautiful diagram and charting tools, is that right? Yes, correct. Oh, yeah, for things like swim lanes and flow states and Gantt charts, et cetera, et cetera. These are actually really nice looking. I like this a lot. Mermaid is great. I like mermaid a lot. How is this rendered? Because it renders them to images.

You write it in like this like ASCII format and then it renders them kicks out in. Oh, SVG. Yes. That's awesome. That makes sense as SVG. This is cool. And you know what's also really good at mermaid is chat GPT is super good at mermaid. Really? Yes. I have actually asked it somewhat recently to generate a mermaid diagram for me based on my needs and it did it quite well. Is the language that mermaid

runs in, that's their own DSL, right? Yes, I believe so. Wow, that's cool. Anyways, that was not the question, but I don't think I have ever given this a good look. I've seen it mentioned, but this is really cool.

So he says, I would like to include code snippets. Does it make sense to use MDX for this type of blog? Man, these are like the two hardest questions that we get asked. And I put it in here because it's the last one of the year we're recording. And I've been dodging these questions all year because what headless CMS should I use is a very hard question. We've done a show many years ago, but I think we need to do another one. Payload is probably the one that I would reach for right now.

But then when it gets into injecting code into a CMS, you have to make that decision for do you want to write it like.

in your actual code editor, or do you want to use a UI to actually manage your things? Or do you want to do both? Because Tina is kind of, Tina CMS is kind of in the same space as that. I personally have an MDX blog, and I would not choose any other way, but also it's such a pain in the butt to a point where

I need to update it and I had to upgrade MDX version of it and we use MDX for the syntax website and there's a bazillion plugins that you have to get working just all exactly writing. When it works, man, it is good. But when it breaks or doesn't work, it's just like, I want to share this thought.

I want to write a quick blog post, but I don't feel like fussing with it right now, and it's a hard thing. That's mostly the second half is more of a skill issue on my half, I think, but I don't know. MDX is a pain, don't you think? Sometimes I would not use anything else, but

Yeah. It depends on who this blog is for, I suppose, in general. It's for himself. Yeah, but I mean, as a generalized question, like if you're picking a headless CMS, then sure. Oh, yeah. That's what I do. But actually, it's funny, Wes, in true me fashion, my blog and my website is not

MDX it's obviously because it's felt but there is even like a spelt equivalent of that type of thing called MD specs and it is not I have chosen to oddly enough make mine Some stupid custom thing. I don't know why I did this, but let me tell you why I'll tell you why it's a custom thing because I'm obsessed with doing custom things, but no no What I did is I wanted to have I wanted to have a

a non-components-based thing, but I wanted to have custom components where, let's say, I guess it's called custom Markdown tags. I have just straight up Markdown files and I have front matter. And if I want to drop in a demo,

I do dollar sign, dollar sign, the demo name. And then what it does is it looks up that demo, which is an HTML file, and it I frames it into the site. That's what I do, mostly because I just don't need components in here. So instead of going like something, I decided to do my own thing, which is stupid, but it works. And it actually works pretty nicely, and I don't have to worry about it too much.

Yeah, I don't recommend necessarily doing that. My favorite headless CMS overall is pocket base. Pocket base is great. It works super well. It's in one file. So if you're the type of person who likes to not have clickups and, you know, click to create everything you can type out.

Your pocket based schema and imported and just have it update your pocket base. You can have chat GPT generated. It's great. It actually functions like a real CMS. It has a nice interface. You can even have a WYSIWYG if that's your thing. So you can use the back end of pocket base as a single developer and not give it to a client and feel like, yeah, this feels CMS-like. So for me, I'm picking pocket base. Payload is awesome. It's also a great choice like you mentioned. And that's pretty much where I'm at.

The other thing, and this is also why both my personal website and the syntax website are on in Markdown, is do you want the developer community to be able to submit changes and corrections? Because for me, I have, I think I have something like 900 Markdown files in my repo, because my entire beginner JavaScript course is also in Markdown. It's many hundreds of

and there's thousands of screenshots and I've had hundreds of pull requests to that content. And there's no chance I would have fixed hundreds of things if I got emails about it. And there's no chance people would have emailed me about hundreds of little, oh, you have a typo here or something like that. And it's so nice to be able to have that content up on GitHub and just have everybody fix it for you or add their own things to it.

Totally. Yeah, I do think that's a good point. And there's also a good point strictly that, like you said, if this is a developer blog for a developer, that's a completely different story than a client. Not granted they did say it is for themselves.

Yeah, I would not recommend ever giving your client a markdown. Yes, absolutely. Last one here. I know we said the last one was the last one. We got one more for you. It's from Omar. Bonus. Before, small and mini NPM packages were considered a benefit.

frameworks like Angular were looked down upon because they came batteries included. But now developers want fewer packages with more functionality. Why has that perception changed? Will it change again in the future? Are small packages back in fashion? Or are big packages back in fashion, I should say? I don't know, man. I don't necessarily think that. I think you have

big packages like Angular or Svelte or big libraries that are more batteries included like Svelkit. But oftentimes, they're still made up of much smaller ones. And you're still using these smaller libraries in the way that you had mentioned where you have smaller libraries and you can touch them on to be more batteries included. Now, I think maybe even what you could be thinking about is you have React, but React doesn't include

like proper state management or, you know, proper image stuff, routing, right? And so therefore you are having to staple on a bunch of external libraries and packages to get this thing actually functional.

And yeah, I think there's just war on some people, you know? You even see it now with the amount of things people are bringing into their projects. Now there's a downside to that where like, if you bring in, let me tell you, if you have all of the choices, you can make all of the choices to bring in as many small libraries as you want.

You know what happens? What happens is each of those small libraries have a whole host of dependencies. And then you click, let me actually see what that dependency graph looks like, and it's massive. It's not little, even though you're bringing in all these little packages. These little packages also have dependencies, dependencies, dependencies. Where sometimes if you have a more batteries included thing, they can tune that much more finely. I know this felt team is super good about this. Finding libraries and packages that have a lot of dependencies

And then replacing them with the same alternative that actually is less dependencies or less third party dependencies. Because the further and further you get down that dependency graph, the more likely something becomes unmaintained somewhere down the line, something stops working, something has some sort of injection of who knows what into the code. So I think there are pluses and minuses here. Personally, I don't mind things being batteries included. I came from WordPress land. I came from Drupal land.

that had all the batteries and it was great. So yeah, I don't need to piecemeal everything together myself personally. Yeah, I think it really depends on people like they want the ability to switch to something if they need it. However, they also want to be prescribed how to do something. And I think a lot of these new meta frameworks are sort of getting it right or even like react suspense is a good example where

It just takes a promise, you know? It doesn't matter how you make that promise. It's just a promise. But also, I want some state management, you know? And that's why, like, a meta framework where, like, Tansac Start will be like, yeah, you can use the built-in...

query or you can use tansack query or you can do whatever the hell else you you want as long as his promises and you're awaiting them are turning a promise and then you're good and I think we will forever have this switch of I want to bring all of my own stuff

to, I wish it was a little bit more batteries included and we'll just go back and forth, back and forth. And we probably will never stop that. But also to what Scott said is a lot of the times, like if you look at something like Vinci, which is, so Tanstack Start is built on Vinci. Vinci is built on Nitro. Nitro is built on

H3 and it's like all the way down and it doesn't you don't have to know that you're probably thinking like oh my gosh There's so many new things No, you don't have to know what any of those things are because those are just good primitives that library authors work on and And you the developer often just gets to sit at a higher level where that level is Whether it's you absolutely must use everything or here is 80% and you bring your own for the rest of it is it's kind of up to you the developer

Yes, absolutely. Sick. All right, let's move into some sick pics. You got a sick pic for me today? Yeah, I have a sick pic. I don't know how many people out there like hockey, but hey, I'm excited about this, so I'm going to talk about it.

Jeff Merrick, one of my favorite hockey personalities, he's been around in the podcasting game for a long time. One of the best, historically best hockey podcasts, Merrick vs Wachinsky, was beloved and went offline a little while ago, like several years ago. And since then, I've been really bummed out about that. But Jeff Merrick, after being released from SportsNet, is back in his new podcast,

The sheet is out now. And guess what? Every Tuesday, they will be doing Merrick versus Waczynski on this podcast. So if you're a hockey fan and you have not heard that news or you like that podcast in the past,

That podcast is back on the sheet with Jeff Merrick. So I'm stoked about that. I was trying to explain to my wife why that was such a big deal to me the other day. I was like, this is a podcast I used to like a long time ago and then it went away. And then they've never kind of recaptured that magic and other podcasts. And I haven't really liked it. And he was other ventures. And now he's doing it again. And his solo podcast is great. So I'm a happy camper here that this podcast is back just in good time.

Sweet, I'm going to sick pick a monitor. This is one. It was sent to me. It seems like they sent one to literally anyone with a pulse in a YouTube channel. Hey, it's anyone. Oh, well, we'll get them to send you one. Yeah, no, I don't need one. By the way, they've sent me some bunch of stuff in the past. But yes, I'll take one if they get at me, whatever.

So it's the BenQRD280U, which just doesn't make any sense. But the whole idea is that this is a programming monitor and monitor meant for web developers. And there's a whole bunch of like backlight features on it. And you can switch to it will detect when it's dark in the room and change the color profile. And there's a whole bunch of kind of nifty things around around that.

Just coming from a like I don't care that much about those features. I just care about like it is a 3 to monitor aspect ratio. So it's almost a square and it gives you the resolution of 2560 wide by 1707 high or you can even.

even higher if you want, but that's kind of where I'm running it at right now. And I have always had the problem where I want a wider monitor, but I also want the height. I want it greater than 1440 because I felt like at 1440, I could really only be running one thing height-wise. So this is awesome because I'm able to run

like two apps stack or three apps across. Yeah, it's wide enough that I'm happy with it. It's a 28-inch monitor. I'm coming from a 32, and I don't miss it at all, which I was very surprised at. So I can still do two or three horizontal, but I can also stack one or two vertical if I want. I can have Chrome DevTools and the whole website up where I can have my terminal and my code editor open.

And the killer feature for me is not a problem most people have is my camera is not too far off on the side. The hardest problem I have is I want my monitor to be dead nuts in front of me. I don't want it to be off to the side because I did that once and I hurt my back workplace hazard. So it's not as wide as my 32 inch. So now I don't have to worry about my camera being too far off to the side.

I'm really happy about that. So if you're looking for a decent monitor, check out the BenQ programming monitor. And also the color on it's fantastic. Like it's much better than my LG and even better than I have like a very expensive Dell one. And it's really good. People are going to be like, it's not 120 hertz or whatever. It's 60 hertz.

I don't care. I'm not playing. I'm not playing games, you know, I'm not a gamer. And I fear that once I do try a higher refresh rate monitor, I will ruin myself some.

I do like higher refresh rate, man. That is a thing for me. I'm like one of those people, you know, like, you know, we're like, you can't tell the difference between the 90 FPS or 60 FPS. I can't tell the difference. I'm like that with refresh rate where like, I just feels, I know most people are when they feel when they use a high refresh rate device, but like, you're like, oh, that's good. I just feel it. The one thing I heard that someone,

Made so much sense is you can read text while scrolling quickly. Yes. Yeah, is that true? Yeah, that's that's a feature of high refresh rates word word word word. All right, shameless plugs. What do we want to plug as always plug? Let's plug the syntax YouTube channel. We are going hard on YouTube this year. We're doing a lot of new formats. We're trying a lot of new stuff and we're having fun delivering

I would say just really awesome high quality educational content, but like fun stuff. We're not here to bore ya. We're here to make you laugh and have a good time. So check us out at syntax FM on YouTube and we'll have a link in the show notes below. But we're on hot on YouTube this year. So we'll be over there quite a bit. All right. Happy new year, everyone. Happy new year.