Syntax - Tasty Web Development Treats
Hosted by Scott Tolinski and Wes Bos
9,621 words · 2 speakers
Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.
Welcome to Syntax. Today, we've got a Potluck episode for you today. Keep the questions coming. Syntax.fm in the URL bar. You can submit your own question and we'll answer it on a future episode. Today, we're talking about monorepos. Really good explanation or really good question about a problem somebody has that a monorepo is going to solve it. Do you really need a server for a React application? Or is a Cloudflare worker enough for when you need that? A Java developer thinks that the Node.js ecosystem is a mess. A good question about like, how do you possibly use Next.js without Tanstack query? So we're going to go into a lot of the new invalidation APIs on Next.js. Someone transitioning from a musician to an engineer and all kinds of new stuff.
Let's get on into it. I'm wearing a different shirt right now because we forgot to record this intro. So now we're going to cut to me and Scott.
Awesome. And if you would like the best tools to make sure your application is running as smoothly as possible, head on over to Sentry.io. In fact, they just added uptime monitoring, which is something that I use uptime monitoring all the time. And now I don't have to go somewhere else for it. I can have it directly in my Sentry settings. Make sure my applications are up as much as I think they are. In fact, I had an issue, Wes, with my habit path, which was hosted on Coolify. And something happened with my Coolify or my server and it crashed. And I didn't realize that it crashed. But what it didn't do is it didn't restart all of my services. So here, I know that my server's up and running,
but the habit path was down and I didn't know. Because I mean, I use it. I didn't know until I used it. Somebody sent me a message or whatever. But that's exactly the type of issue you don't want with any application, especially if something of other people are using it, right? So uptime monitoring is something that's important to have on just about any web property that you care about people seeing. Because if you're not checking it 24/7 and it goes down, you might not have any clue. So check it out, Sentry.io/SyntaxFM. Get two months for free with the coupon code TASTYTREAT. This podcast is presented by Sentry. Let's get into the Potluck questions, Wes. First question here from Secret Agent. Hello, Wes, Scott, and CJ. Been listening for a few years as I've transitioned from being a musician to software engineer.
Thanks for all of the help over the years, and specifically Scott for showing me a music major can be a developer. That's me. Just got my first full-time job, but I find myself wondering if we are shooting ourselves in the foot. We have a separate repo for each layer of our app. The front-end, REST-STOPPY layer, what, uh, oh, REST-
The REST API. REST-STOPPY? Hereby, for a word, a REST API is gonna be called a REST-STOPPY.
It's a REST-STOPPY. I just read that it's all one word here. The REST API layer. I was like, what's a REST-STOPPY layer? This is fascinating. So their, their front-end, their REST-
You wrote it REST-STOPPY. Okay. Anyway, carry on.
Yeah, let's carry on. Uh, the front-end, the REST API, services layer, the repo layer, workflows and task layer. Each time I make a change that spans more than one layer, I have to do more than one PR, get something reviewed more than once, and then make sure the merge and deploy happens at the same time to make sure everything works together and prod as expected. I get decoupling, but for a small startup, this feels excessive. Is this an instance where a mono repo would help? Or do you have some other advice for me? Thanks for answering. To me, when I read this question, I'm smashing, I'm smashing the mono repo button because I like that and I like that workflow. And there's a lot of mono repo tools out there, some of which are very heavy-handed and feel like they can take over a whole lot.
I use PNPM with PNPM workspaces. Uh, NPM also has workspaces that are a little bit more cumbersome. They exist. Yarn has workspaces. So workspaces are a great way to get mono repo stuff going. I'd also recommend using Turbo Repo, which is something I didn't think I needed for a long time, but then I'm running like five dev processes at once. Turbo Repo makes that so much easier and so much faster. So I highly recommend, you know, my, my workflow for this is PNPM workspaces and Turbo Repo, and that's it. And I, I think personally, that's a, a nice way to be for something like this.
If you are- Hoping that deploying everything at the same time is your approach to making everything work together, it sounds like you need a monorepo. If you are not, then you need to start versioning your APIs, meaning that you leave the old version of whatever API running for a while until enough of your traffic has moved over. And you can do that either by different domain names. API key is another common way where you generate an API key that's attached to a specific version of an API. But like, that's, that's so incredibly complex, especially for a startup where a monorepo is a much better approach to this
type of thing. That, like, you see some of these node modules that are published, like, for example, nextjs has that, but they have nextjs image, they have like six or seven different versions. And every single time they publish one version of something, every other package gets published as well, right? And that way, all of the changes can go out as one, especially if you're trying to update a backend API as well as update like a UI layer and your REST API is also being updated. It's all got to go out at once and it's so much easier in a monorepo.
Just casually throwing the REST API in there.
REST API. Paulo Ricardo says, hello, I'm a Java developer, condolences. For professional reasons, it's taking its first steps in Node.js greetings for Portugal. I'm wondering if it's my impression, if most Node.js libraries are generally poorly maintained, coming from nearly 20 years of Java development, I've noticed at least, at least on the backend for things like ORM's and caching, the latest release of many node libraries seems to be several years behind. They often appear to be maintained as a hobby rather than a structured approach. I'm used to seeing this in Java. What are your experiences in Node.js in this regard? Do you feel like everything is abandoned or generally more well-maintained? That's a good question. I think like there are a whole
slew of packages in the node ecosystem that are sort of, I don't know, like, like I'm thinking of express, I'm thinking of, of mongoose, I'm thinking of some of the more established packages that are maybe not the things that we reach for immediately. And these are maybe the things that you're finding when you Google like web server in, in node or something like that. And you kind of have to be in the know of what's going on. Because if you were to look at the most popular packages in node JS, those are maybe not the things that you would grab right off the, the bat. But I don't know, you're talking about ORMs. We have several really well maintained ORMs, several good approaches to caching.
I, I don't think that this is necessarily the approach, although the node JS and JavaScript ecosystem does tend to change what we like to use much more frequently than a more established, something like, like the Java ecosystem, especially much more corporate, you know?
Yeah, it is interesting, you know, I also, you know, come across this in like the Rust ecosystem where I found a lot of abandoned Rust packages. And people say that they're done, but then I'll find like stuff that just straight up doesn't work. And then you're, you're piling through it and there's like, oh, this hasn't been touched in like two years. And so I think I find less of that with JavaScript and, you know, it could just be ignorance on all parts on my part. So yeah, it, it really depends on, I guess, what you're using, how established it is. There could be abandoned stuff where there could just be like, you know, it's been baked into the, the language now. Or, you know, there's no reason to use X, Y, and Z. But for the most part, I don't necessarily feel like I've had this issue.
One thing I'll also say about that is because JavaScript is kind of bring your own for everything. You gotta like piece together the parts yourself for the most part. It can be often very hard to figure out what do I use for X, Y, and Z? What do I use for an ORM? What do I use for type validation? All of those things. And if you simply are just Googling for that, it's, it's really hard to find out what people are actually being used. I like to use socket.dev when searching my dependencies. And that does give you a little bit of a better idea of, of what's being used. But I would like even something further of like, okay, here's a package. Like what have people switched to or like, what are similar packages in this area?
You know, you're, when you're shopping for something on like Amazon and it's like, well, you might also like this one, which comes with an allen key. You're like, "Yeah, okay."
All right, next one here from Brett Perry. Oh my gosh, Brett, he specifically says, "Not Perry, like P-iri." So, P-iri, Piri.
Sorry, Perry.
Sorry, Perry, I called you Perry, Piri. Brett, "Hey, Syntax Nation, I have ideas for a new collaboration-based product that will start as a micro app and add more micro apps over time to make a suite. I'm wondering if I should do straight-up SvelteKit or go local first with PowerSync, Scott's new hotness. Which would you use? My first question for you all, been following you from pre-Syntax days." Yeah, I've seen Brett online a lot, so shout out to Brett, what's up? So, you know what I would use? I don't know, I'm using pretty much, I'm pretty much using ZeroSync for everything right now. Typically with SvelteKit specifically. I wrote the library bindings for it, I really like it.
I have a few production apps working with it right now. That said, ZeroSync is not shaky, super shaky ground, but things change. You know, there's been changes here and there to the permission system, to the schema definitions, and that stuff's kind of happening as it goes. Now, I don't think it's going to massively change, but it's not the most absolute solid ground today. That said, if you're the type of person who doesn't mind that type of thing, and you want to use something like that, man, ZeroSync's a great option. I have such a good workflow going right now with ZeroSync, Wes, because there's a great Drizzle to ZeroSync schema translator, where essentially you write your schema in Drizzle, like typical.
That way you can take advantage of the migrations, all the Drizzle stuff, whenever you want to use the Drizzle stuff. And then you essentially just take those schemas directly, pipe it into this function, and it gets your zero sync schema automatically configured. So that way it's not like you have to maintain two schemas. You have your Postgres DB is super easy to set up, whatever, run the migrations. And then on the other side, you get zero sync to do all that stuff. I also have my own auth system and stuff like that, which I'm working on. But I think for the most part, I think it's a really great platform. And I've really enjoyed building on it. In fact, I just added some new features to my habit tracker that's built with zero sync.
And it was just a joy, right? To be able to update the schema via migrations with Drizzle, and then just have those changes be available to you on the front end. You're calling essentially what feels like an ORM on the front end, but you're getting that local data saving, you're getting that sync in the backend. So, hey, if that sounds like something that fits the type of project you're building, like that's the one thing you didn't really mention, is that like...
Yeah.
What is it?
Like, micro apps. Can you take a stab at explaining what a micro app would be? And multiple micro apps?
I would imagine just like even like one-page utilities or something like that. I honestly have zero clue what what micro apps mean in this context. Nothing against you, Brett, I just don't know. Yeah.
Some sort of like suite of tools that are used for, I don't know, like for example, in syntax, in the editing side, right? We have so many little tools that we've built for helping us push the podcast out. And I would consider those micro apps. So the kind of nice thing about building micro apps is you could possibly try many things out. And then, and then if they're small enough, you can port them over. They're micro, right? You can try a whole bunch of different stacks. And especially if you're going to go this approach of what Scott said, is use Drizzle for the ORM. And then that way, ducking out of zero or whatever, if you decide it's not for you, it's a very easy thing to do.
Yeah, I think of this like fuel. So we have a site fuel F F F U E L dot co.
Fuel.
Yeah, which is like a full of a bunch of different utilities, command palette, color generators, lines and all kind of like noise generators and all kinds of cool stuff. I think of this when I think about micro apps, but if we're wrong about that, Brett, let us know because that's kind of what I envisioned.
No, I think that's really like sharing utilities across multiple apps, right? Like you're like, ah, I need this thing again. I need to convert to SVG in six of these apps. So I'm going to share the utility across all of them.
Word.
Chat GPT says, many people on Twitter, Reddit and YouTube are a damnet. They don't need tan stack query.
A damnet?
Yes. A damnet. Is that how you say it?
It's adamant, but I'm happy.
Really?
I'm happy that I'm not the only one goofing up today.
I, I think my whole life is a lie. I always sound like a damnet because it's like, oh, I'm damn near sure that it's this way.
Yes. Oh, my God. I love it. Actually, I prefer that. I.
How am I never?
Damn near sure.
I'm damn near sure. Yeah, that's a damnet. Adamant adamant sounds. Yeah, that makes a lot of sense.
I love it.
About it. Man, there's so many parts of my life. No one has ever corrected me.
Oh, my God. You know, speaking of Wes, you know, I don't know if you know holidays, but we all know I don't know any holidays. This is just a part of our brains, right? I, I sat down with my wife the other night and she quizzed me on every single holiday and it was just hilarious. She was like, what month is this holiday in? And I would just like, hmm, what is the day? What is Thanksgiving? What is? It's like all the holiday. I only got two of them right. I got Christmas and Halloween right. I didn't get any of the other, like, I could, you know, I could obviously, I know what. Oh, it was brutal. And I think every single one, she was just in tears because she couldn't believe I didn't know what day Easter was or what day anything was, even Thanksgiving.
Man, I don't, I don't think I could tell you when Easter is. Like, I know it's in April.
Sometimes, I think sometimes it's a march.
Also, in Canada, half of our holidays are named after like the Queen.
Yes.
Victoria Day and things like that. And I could tell you what Canada Day is. That's about it. And I can tell you what the Fourth of July is.
Yeah, Fourth of July. Cinco de Mayo. She said one of them and I was like, that might as well be Boxing Day for me. I have zero concept of what day that holiday is.
Oh, Boxing Day. I know what Boxing Day is. Boxing Day is the day after Christmas. And Boxing Day is like Canada's Black Friday.
Boxing Day.
And we would, like, the morning of after Christmas, we would just go wait outside the stores at like 5:00 a.m. It's just a crazy thing to do the day after Christmas.
It's crazy. Yeah.
And you get all the deals. But now we have Boxing Day as well. Anyways, he's adamant that you don't need tan stat query with NextJS. I don't understand how you can manage caching, revalidation, and optimistic UI without it. So my question is, how does one manage a sync state without tan stat query in NextJS? I'm talking about instant updates to the UI followed by fresh data from the server without affecting the router cache. That's really important because currently, when you call revalidate path, which is the NextJS API for invalidating a cache on a page. So if you, in NextJS, if you've got some like server actions, you have some data loaded,
and you want to, anyone that's on that page, you want to like reload part of that page, right? You just call revalidate path and pass it the string to what path you're on, and it will just refresh all of the queries and data that is on that path. So he says, when you call revalidate path, the entire router cache is purged on the client, which is awful UX, which is true. Like, you're literally nuking the entire page and starting again. The docs say a future version of Next will stop this behavior. The entire router cache is purged when you call router refresh from the client to pull fresh data on a route. Am I missing something or is there really no way to make regular updates on the server that are synced with the client? Yes, you are missing that NextJS has.
A API that is coming. It's it's been in dev for a while and I bet it we'll see it soon. Um, it's the unstable cache API that looks a lot like Tanstack query in NextJS because in my opinion, Tanstack query is is the best API in the world and we need that everywhere else. So the way that this works is you tag your queries and you you tag any action with you can tag them with paths as well as a a timeout. Meaning that this data will be stale after however many ti- ever many milliseconds and then you can refresh it.
But then you can also tag them, which is much more important to me because I much rather tag uh, something as like podcast episodes or shop items versus having to revalidate paths. I don't know what page my items are going to be on. I'm big on component based design. I like when components can fetch their own data. React suspense makes that really nice. But if if you're telling me you I have to pass you a list of pages to revalidate. I don't know. I don't possibly know which pages those are going to be on. So I don't like that API, but the tagging them is really nice because you can tag it as like item six, but then you can also just tag it as an item. And in that case, you can invalidate
all items or a specific item by its tag number. So that API is coming. You can you can use it already in NextJS. I've used it in production several times already. And I'm a big fan of that as well as NextJS is also rolling out this idea of just caching. Not just like fetching resources, but NextJS is also rolling out the idea of just caching a component's output. Um, so rather than like statically generating an entire page, you can statically generate a component or you can cache a component's output multiple times. So for example, I have like a Twitter feed in my footer of my website or the syntax one. I I might want to cache that for like five hours.
Worth of tweets or a full day's worth of podcasts and then have that thing revalidate. So that's, so that's a nice way to cache stuff that is maybe shared between users. And then finally, React 19, all the React suspense, all the server component stuff also has ways to do optimistic UI. Not to say you shouldn't use TANSEC query. I'm a big fan of it, but I think that that's why people are saying that.
Yeah, word. Sick. Thank you for that, Wes. All right, next one here from Famous Potatoes. When starting a project, I often wonder if I really need to use a server in my codebase. I think it's much easier to build a spa, but there are some things you cannot do client-side, at least securely, and need a server like email, some databases or libraries that are only built for servers. But now that workers, Cloudflare workers are more prevalent, do you think it's reasonable to build a client-side app that does not use a server, but pushes all of the server-side stuff to a worker? The benefit being that you could build a spa that benefits from simplicity in the codebase
and the ability to host a static site, but still has the ability to do traditional server-side stuff using a cloud-based worker. Can you think of use cases where this would fall apart? Yes, I do this all the time. And you know, one of the reasons why I do this all the time is because SvelteKit makes it easy to have adapters for where you output. You throw the Cloudflare adapter in there, you post it up, and then you got your workers running as, you know, essentially functions for you, for any server-side stuff you need. And that way, when you're using like .server. ts or whatever as a route, that, that works on the server where it needs to, and then everything else can be spa if you want it to. You could even have server-side rendering that way, too.
But I, a lot of times I'm, I'm building apps that have like dynamic bits in them that don't need server-side rendering for the app piece. Server-side functioning, sending email, all that stuff works great. I've been doing it also too now with AWS and SST. So that's really pretty nice to be able to throw up on SST. You use, again, the same thing, like an adapter for it. And then AWS just runs those as Lambdas instead of having to have a traditional server. So I would say nine times out of 10, like this is exactly how I'm deploying things these days.
What Scott explained is the approach I would take as well. And that's not a totally separate instance. I think like the famous potatoes who asked this question is asking is like, should I just like totally deploy my spa app somewhere? And then if I need to, I can, I can fire up some workers and sort of communicate between the two. That's a great way to approach it, but I would use something like SvelteKit or NextJS or TanSec Start or SolidStar or something that is just puts it all into one. Meaning that you can do your whole app client side, but at that moment where you do need a little sip of server, you know, you do need to do something server side.
It's so incredibly easy to do that on the server because you simply just like, like in SvelteKit, you just name it dot server dot JS and all of a sudden that will, will be running on the server. Or you can throw it like a server action in there and that code will run on the server. Because that Rustapi back and forth of hopping between them can be a bit of a pain. Unless you have a much more mature application where you have a very clear API and a very clear front end and you, you sort of talk back and forth between those. That's pretty common, but if you're building something from scratch and you're doing it all in JavaScript, I would certainly pick something that allows you to do both.
And you don't have to use the server side stuff unless, until you actually need it. And in my opinion, that's the, the best approach. Cause so many times I've, I've whipped up a quick little like VDAP only client side. And then I hit, oh, I need a sip of server side. You need something to run on the server.
Now I'm, I'm opening up a new tab in my console, you know, I'm getting Hono fired up and that. And I'm like, I should have, I should have used something that I just have it all in one.
Word. Totally. Yes.
Max S C says, you've discussed implementing zero with Svelte and Scott has even created the zero Svelte package. How would you load data in SvelteKit though? Would you use plus page JS or stick with loading data in components and go directly and page Svelte files? Yes. Good question. How would you do this, Scott?
Yeah, I pretty much skipped the loaders entirely. The way that it works is like, especially because the way that that the Svelte Zero package works is that it uses it uses Svelte stores to do everything in runes. So it makes more sense to just toss it into a component. I have some, I recently published an AI chatbot that's done with Zero in Svelte as a part of the challenge that the Zero team issued, which was actually a lot of fun because the way that it worked, Wes, was that like, when I send a message and I type in, it's doing the Zero sync stuff, but then it's also firing off a message to the server. The server goes off and does all the AI stuff.
And as the response is coming back from OpenAI, it's streaming into the database and Zero is watching the database and anytime the database updates, it's updating the UI. So the streaming is working by the AI response is streaming into the database and the Zero sync is just recognizing those changes and updating the UI and patching the UI. So it's insanely fast. Basically, you're just tossing it in and if it needs to respond to parameters like page parameters or something, or even like other inputs, you just throw it into a derived. And yeah, I'll have more docs on this, but I'll link that repo up that has a lot of good examples on how to do this. So it's actually been really, really cool to see how many people are utilizing this as Zero Svelte.
Like they issued this challenge for anybody to build this AI chatbot and who could do it. And just to see like people using my library to do all that with has been, it's been pretty great because I use it myself for all kinds of stuff. So I, you know, I feel the pain when there is pain or I know where to fix when things are breaking or whatever. But to have so many other people using it is pretty dope.
So that's interesting to me that you said like you're doing all of the data stuff like in the component, right? You're not doing it in a page, at a page level or in a page loader. Is that right?
Correct, yeah.
That's my like preferred way to do things as well. And the reason why a lot of people say like, don't fetch in the component, but fetch at a page level is because you can get waterfalls, meaning that like you load a component, that fetches data, comes back, renders out some UI. Oh, that UI now renders a different component, realizes that component needs some data, goes off, fetch it, right? That's how you get a waterfall. But with local first. You're not so much worried about the network waterfall. You're not worried about the network waterfall really at all, right?
No, totally.
And that's why you can do that?
Yeah, and also the Zero Svelte package, it saves every query that you do into a or like a map. So if I do a query once and it hashes like what the query actually is. So if I do that query once with one set of parameters, it saves it into a map and then it doesn't have to redo that subscription or anything like that. That will just exist, so it's going to keep reusing that same data source every single time. So and not to mention, the data loading is incredibly fast anyway, so it's pretty shocking. Yeah.
Beautiful, I like it.
Yeah, next question from Ronnie. Do you think nowadays it makes sense to diversify to full stack developer instead of being only front end focused and learn something like PHP, Laravel, Python, Flask, or Java?
No, it says Flash.
I know it says Python Flash.
Probably meant to say Flask, but don't learn Flash.
Yeah, I think it meant to say Flask. And then Java Spring framework, but I don't know if that's supposed to be, it might have been auto.
Spring, probably.
So some autocorrect issues. But Ronnie, I do think that it's probably important to spend some time learning these things. I do also personally feel like front end development is a deep enough well that you should like be able to become a deep expert in some front end development topics in a way that like you just can't if you're spending all your time focusing on full stack stuff. So me personally, I like the challenge of full stack stuff. The thing I like the most about it is that I can build full things myself without anybody else, but I'm not a part of a small, like a team where I'm doing one specific thing. And I do feel like with the advancements to CSS, the advancements to JavaScript, all
that kind of UI code stuff, I think front end focus is still very much a thing, or at very least UI focus. Like I'm building UIs with this or that, more so than just like just straight up client side code. I mean, whether or not you're doing it server side or HTML stuff. This is, there's so much, there's a deep well here. So I personally would pick up full stack stuff. For fun, to understand the process more, to know how these things work better. Uh, but in the same regard, if you're looking to become a, an expert at one topic, then by all means, I think front end is a deep enough well for that.
Yeah, that's, it's interesting. It's a UI focused developer. Um, that's a great way to put it because as much as people want to be like, I only do the CSS.
That's, that's not really a reality unless you are extremely good at CSS and you work at like a very large company where you're absolutely killing it, right? Like you work at Stripe and like you're just focusing in on, on CSS. Even then, I think some of the, the smart people that work out on the next level stuff at Stripe are probably also very good at JavaScript. So.
I would say it makes sense to at least be comfortable with the full stack, especially if you're trying to get a job today. As much as we would love to just sit in our little box and say, I just want to focus on this thing because this is what I love. I don't think that those are where most of the jobs are. Most of the jobs are going to want you to be able to jump in and work on whatever needs to be worked on. And you can be part of a time, a team where someone will say, give that to Scott or give that to Wes because they're going to do the best job at that. They really know the internals of X, Y, and Z. But when something breaks, you gotta be able to jump in and, and figure this type of stuff out.
And as AI is getting better for you to be able to explain how things work and be able to reason about different code bases. I really think being a full stack dev with a focus on one of these areas is, is the way forward. And I don't know that you would get a very good and a well-paying job otherwise.
Yeah, word.
Crispy codes. What do you think is a better way to track backend changes besides web sockets? I have a scenario where I upload a video that is supposed to undergo some processing stages. So I need to keep track of whether the video is pending, completed, or failed, since I can upload multiple files. I tried polling mechanisms, but it makes frequent API calls, which is costly. I really need some help or advice. Thank you. So what he's explaining here is that you upload a video, and on the server, you need to wait for, it needs to process it, right? It needs to maybe make captions, and the status of that job needs to constantly be sent back to the client side. And there are several ways you can do this, right?
You can open up a web socket when you upload it and just send back data as it's needed. You can use server sent events where you ask for a request. You open up like a fetch request, and then that stays open for however long, and then the server can just sort of send data back to you as it's needed. Or you can do polling, which is just like, what's the update? What's the update? What's the update? And in most cases for this type of work, you're going to be using polling. That's what I see most often, because if you need to open multiple tabs, or if you close the tab and reopen it,
it's much easier to simply just ask for the status of job 299 and get it back and update the UI. He's saying it's expensive here, which it shouldn't be expensive, because you're simply doing some sort of like database query, and then sending back a very small amount of text back. If you're doing bazillions of them, maybe, but it shouldn't be very expensive. And he's probably using something where you pay based on the, like the serverless function that has been instantiated. And every single time you run one of those, you have to pay for it. So if that's the case, maybe look at how you can make that a bit cheaper.
I don't think that there's any other way around this, and there are bazillions of apps out there that simply just use this simple polling technique.
Yeah, I know polling always feels like the easiest for me for some reason, even if it's not, for some reason, it just feels like the easiest.
It is, it's because it's like stateless, right?
Yeah, totally.
It's simply just, what's the status? And it comes back with the status and you can recreate that at any time. So unless you actually need real time or like streaming, where like something is like an AI response is simply streaming back the updates in real time and you need to show that to the user. But if it's simply every 10 seconds, you're checking if it's done or not. You can also do things like you can decrease the polling in the first, like if you think, oh, it's going to take at least five minutes. Maybe the first minute or two, you only send a request once. Or if somebody has their tab not focused, then, then don't send the request every two seconds. You know, or if they haven't moved their mouse,
there's a lot of things you can do to decide how frequently you should send that request. So maybe that's an avenue you should go down is how do I, how do I do this less? Or simply just put a refresh button on there for the user, you know? Let the user click on and see if they, if they literally care, you can click on the button and see if there's an update.
Yeah, yeah, word. There's been a lot of talk about the zero sync stuff in this, but that would work really well for something like this. Because again, you're just making changes to the database and it's listening on a web socket that sync process runs or whatever. And that you, that uses web sockets. So I have a lot of experience using web sockets from meteor days and now this. And as a technology, when it works and it's all just set up and whatever, it just feels great to have that real timeness about everything. It's just something I like. Next one here from Anon. This question is for Wes. All right, Wes, you ready? You have so many course sites with different domains. Why don't you use subdomains for each course?
Is this a security purpose or another reason?
I've had this question many, many times, especially in the early days of doing courses. People, everybody was doing it at like a forward slash. So it would be like wesboss.com forward slash JavaScript instead of, instead of on its own domain name. And my whole philosophy in life is make it a thing. Meaning that if you put your hard effort into making something, package it up and ship it out as a thing. Make it a thing, give it a title, you know, give it, make, make some graphics for it. Both because the, the perceived value of it is, is much higher. There can be like SEO aspects to it. That's never been a play for me with my courses, but a lot of people will do separate domain names
because they'll put a lot of specific content on that domain. Also, people like to sell their things. I did it myself. Keycode.info was a little side project that I had. And it simply, you press a code, a key and it will tell you the key code, the location. It's a, everything about the JavaScript event of a key up event. And I put that on a separate domain name rather than forward slash keycode on westboss.com. Simply because I wanted it to be its own thing. And a nice benefit of that is Top Towel, this was a couple of years ago, came along and they bought the whole thing from me.
I sold them a website that shows you data on event, on a JavaScript event, which is a, a bit of a silly thing, but they did it, right? And, and it was, it was a significant amount of money that I made from it. So I'm a big fan of putting everything on its own domain name, simply just from the perceived value and the ability to move things around should you want to. Um, there's no security issue. In fact, the security is a pain in the butt because uh, I have a couple of things where I want to share data between domain names. Auth is not cross domain name, but there's several other things cross domain name, whether I show a banner or not. Uh, if you've bought the course, they don't show the banner.
That's a pain in the butt to try to cross domain, share that info.
Man, I, I have experience with this because of Level Up tutorials. I did kind of the opposite approach where every single one was part of a bigger thing, right?
So instead of each course being its own thing, I did each one as part of Level Up tutorials. And I gotta say, you know, I feel like that was a harder approach because it kind of devalued every single thing I did. Where like, I have a new 24 video course coming out every single month. Why did I do that? There's so, so much material and it all had like less.
Intention or weight given to it, when in reality, it's like I was putting in the work on those, those projects. I was really like hustling on them and like grinding on it, but like, yeah, probably would have been better to make them a thing instead and like, make them bigger because I, I think it was doing my content a disservice, not, not like even like financial reasons, but I think it was doing my content and make, make it more feel like disposable and more YouTube-y by releasing so much all under their one thing. But hey, it's out there and it's free now. Levelup.video if you want to check that out. It's all for free now.
Next one from Object Object. Could you guys talk about the pros and cons of a code-based routing versus file-based routing? Currently experimenting with Next.js, a Tenzac start, and looking for some direction. Thanks. So yeah, the idea with, with the code-based or config-based routing versus file-based is when you want to create a new page in a file-based routing, you simply just, you make a folder called like about, and then inside of that, you might have like an index dot TSX, or you might have a page dot JS, or whatever the, whatever framework you're using. That's a file-based routing. And then there are also
ways to do things like optional params, like if you want to do forward slash blog, but then you also want to do forward slash blog, forward slash one, right? And you want to optionally put in the page number into the params. A config one would simply have you write out the config for your router and, and declare what all the routes are. And say when somebody hits one of these, render out this component. Whereas a file-based one is simply just putting folders. And I've gone back and forth between them. I don't love file-based routing, but it's all I've used in the last probably three years.
Yeah, same.
And I don't love it because I find it hard to navigate through all of my pages. There's, there's ways in VS Code to rename the tabs and whatnot, but I don't know that I've.
I have a favorite of these. What are your thoughts? That's just my approach here is I'm not sure what I like the best.
Yeah, in my mind, it all comes down to like with like programmatic based routing. It makes it way easier to do like conditional routing things. Because you have the full power of JavaScript or that front end framework in your router. Where with file system based routers, I feel like they all struggle when it comes to. All right, I have like this group of routes that has a different like subgroup now. I have this parameter based route that needs to adhere to these guidelines. Like for instance, the SvelteKit routing system is very good, but it's kind of its own thing.
You can like, you have like REST routes, you have routes where the parameter is locked to a specific red jacks. You have like grouped routes, you have nested layouts and all these ways. And if you want to have a nested layout route system that's a part of a different tree or whatever. It just makes it all more complex than it would if you were doing it in a, in a code based routing system. But on the other hand, you gain things like code splitting and that stuff is way easier and less effortful. If you're not having to do it yourself and to tell your application where to split and what to load, when to load dynamically, whatever. The framework just takes care of it for you.
So for me, at the end of the day, I prefer the file based routing for the benefits you get automatically for it. Rather than having to deal with that stuff myself. And then I will learn the syntax for file based routing. I'll learn all that stuff. I will deal with it, even if it's not my favorite thing.
middleware is another kind of pain in the butt one where like I want middleware to apply to these three routes. And they're not like forward slash admin, whatever, then you gotta do it. But also like the syntax website, like our Open Graph images are sort of outside of the syntax layout. And in order for us to do that, we need to have like a parentheses blank and a parentheses site sort of route inside of there. But.
I think that's fine because, I don't know, like, once you understand it, it's a little bit weird, but once you understand what it's doing, I think it's totally fine. I didn't even think about the code splitting. Another one is you visit a page in a new code base. I want to fix something that's on this page. It's very easy to figure out where to edit that code because you simply just go to the page, the file-based route for that page, and then you start clicking through the components until you find what you're looking for. Whereas like, how many times have you opened up a code base before you were like, I have no idea where to even look for this thing? That's why I like, I still have like a fairly big Express app for my course platform.
And I moved almost all of my routes into one file at one point. And that was so nice because then I was able to just open up the routes file. And it's hundreds of lines long, but it's very easy to see what the routes are. And then I can click through to the controllers of each of them and actually see the code that runs when people visit those URLs.
Last one here from Eddie. I'm new to web development, only going into my second year of learning web dev. Do you guys have any advice for new developers that are new in this field? New developers that are new in this field? Absolutely, Eddie. This, I feel like this is something we haven't even touched on in a while. It is a question we've gotten a number of times through Potlucks, but you know, we've been on, we've been on the air in the airwaves since 2017. So definitely want to hit this one again. You know, what do we recommend for people who are new to this stuff? I think the biggest and best advice that I can give you, Eddie, is that your curiosity is your superpower. It's your superpower towards being focused. It's your superpower towards gaining knowledge.
It's your superpower towards building things that you will actually use and enjoy and like advance your learning. So. Let your curiosity drive you, dive into things, explore topics, get deep on some things, get wide on other things. But like, for the most part, find stuff that you enjoy making, try to make it, struggle through it, don't give up, ask questions, all of those things. And, you know, be open-minded. I think a struggle that, maybe not a struggle, but like, a problem that a lot of newer developers have is they might listen to some influencer on YouTube or something, and then build their entire, not just personality, but their entire
developer skill-based, based on what somebody else has said is the way to do it. There are so many different paths that are all valid and all work. And if you like something and something feels nice to you and you're productive with it, and so-and-so influencer says that it's garbage, you don't need to listen to them. You know, I think keeping a very open mind, staying curious, and, you know, working hard to build things for both yourself, for other people, nailing the job requirements, whatever, is the way to go.
Yeah, having that open mind is absolutely key. So my advice here is build lots of things, build lots of little things. Having that success after success will give you crazy momentum in your career. Share what you've built, share what you've learned, those things. Simply just putting it up on GitHub, writing a blog post, making a video about what you've built, is unbelievable. I've had major, major leaps and bounds in my career, simply by showing what people, what I have built. And that's led to conference talks, and paid freelancing jobs, and job offers and stuff, all over the place, right? And the last thing is like,
join the conversation and like, ask lots of questions. So if you are part of this community, right, you're listening to this podcast, you're finding web developers, wherever it is that you like to hang out, that is going to be big for your career.
Word, absolutely.
Yes. Yeah, we should do another. Many years ago, we did one like, advice for new developers, but we'll follow that up as well, especially as like, the job market has changed.
Everything has changed, right? Last time we did that, AI, LLMs weren't a thing. I mean, there was just so much that's changed. So I do think my advice will significantly have changed there in many different ways. So, well, that's it. Let's get into our next section, which is sick picks, shameless plugs, the stuff that we think is great and that you might maybe should be paying attention to. Wes, I have a sick pick that I've sick picked before in the past, but hey, it's a repick, but I'm coming at this from a whole nother year of experience. So maybe about a year-ish ago, I sick picked a financial like tracking app.
If you've ever used Mint or something like that or Personal Capital, there's so many of these now, like Copilot Money, blah, blah, blah. I've been using Monarch for over a year now. And at first, when I started using it, there was a lot of like, wow, this is really great. It all works super well. It looks nice. It feels nice. I can tell I'm going to like this. But now I've been using it for over a year. It's like really part of my general workflow where I'm approving transactions. I'm categorizing them. I'm using like the Sankey flow charts for where my money is going and how much of percentages is going to all of the different things. I'm using all of the budgeting tools, the goals, all of these things.
And I use it every single day. So I can safely say from my perspective, I've used a lot of these things. This has been my favorite one by far. The biggest complaint you will see people have with Monarch is that accounts disconnect. But like, I feel like web developers should know better that the way that works is that many of these are unofficial APIs. And like, for instance, our mortgage lender is like the worst, like 1990s website. And the fact that Monarch works at all with that mortgage provider is shocking to me. So like, if it disconnects every once in a while, no big deal. Yeah.
So behind all of these financial apps is a company called Plaid. And they provide APIs for all of these banks and like. I, I think it's the Wild West. There's probably developers working at Plaid that are just like, "Well, today I wrote a soap API thing that will go around," or I'm sure they have some crazy processes to, to get that data out of your bank. I have it with my FreshBooks. It constantly, constantly disconnects and it's such a pain in the butt. And they, all they do is point the finger at Plaid, which makes me really mad.
Yeah, but at the end of the day, you gotta know that like some of the, they don't have real APIs there and there's so many institutions-
Oh, there's no APIs for a lot of these banks.
On their own stuff, yeah.
There's millions of banks. We have four banks in Canada. What do you got down there? Like bazillion?
I don't even know. I mean, yeah, I mean, we're in a credit union that I've been at for a long time. So on top of that, you have like, "All right, now I'm at a credit union with its own [bleep] software and who knows what." So, yeah. Either way, I, I like this a lot. The reports are really great. It feels nice to like go through this, you know, monthly with my wife and look at where we're at at the budgets and see all the stuff and yeah, it, it's fun and it's a good UI. So, check it out.
Beautiful. I'm gonna stick pick
these like Pelican cases, or whatever they're called. This one's called a SKB case. And these things are awesome. I have a couple of bigger ones. I have one on Wheels. I'm up, I'm up at my cottage right now and when I go to the cottage, I bring all of my recording gear, not all of it. I have, I have doubles of everything, but I bring the expensive camera. I bring my laptop. My wife brings her, her camera and her laptop and stuff like that. And I'm always scared that things are gonna get busted or if you have to bring something on a plane. So, these cases, besides looking like super badass, like they have like nice foam inside of them that you can like cut out to match whatever it is that you're working on.
They're like pressure sealed. If you ever need to get a nice Pelican case, or what's the name for these that is like not the like trade name? Pelican case is the name of it, but many companies make these.
I have no clue.
Rugged case.
Yeah, rugged, yeah, some kind of rugged.
Waterproof case.
Are they waterproof?
Yeah, oh yeah, certainly. They uh, don't buy one that isn't, because that's very important. I'm sure someday my kids are gonna take this out of the car because it's in their way and leave it in the snow or something like that, you know, it's happened many times, so, big fan of these. Alright, that's all we got for today, uh, shameless plugs, let's check out the Syntax YouTube channel, we just posted a banger of a video with uh, the folks behind the typescript Rewrite2Go, that was a lot of fun, today's the day we release it, so we're kinda all hopped up on that.
So, check it out.
Yeah, also, you know, it's so funny, somebody commented about the skateboard that was in the background of CJ's set, if you don't know about it, we have a store of all this kind of stuff, so, if you head to sentry.shop, S-E-N-T-R-Y dot shop, we'll have the link in the show, we have so much cool stuff there, and there's like Sentry swag, obviously, but we have a Syntax skateboard, we have miniature skateboards, we have all kinds of Sick Pick t-shirts and hats, and we got some cool new stuff coming that like, uh, Wes has had access to for way too long that I have not had access to.
I've been testing, I'm the official tester for the merch, so you probably have seen it in a couple of videos, but they're coming.
Yeah, there's a lot of cool stuff coming, so check it out at sentry.shop as well, but yeah, that's all I got.
That's it, thanks for tuning in, peace.
Peace.
Page updated November 3, 2026 · transcript and summary are machine-generated