Hosting NextJS × Spicy Sidedishes × Modern Forms × Abandoning TypeScript

You're listening to Syntax, the podcast with the tastiest web development Here is Scott Talinski and Wes Bos.

Welcome to Syntax. We've got a potluck for you today. This is where you submit the questions. We bring the Answers some really good questions today around Netlify and Next. Js and hosting and actually lots of really good JavaScript questions today.

I was surprised at all the great questions we had. So if you have a question, go to syntax. Defam. There's a button that says submit a potluck question.

Send it our way. We love getting these, and, we do 1 a month. So my name is Wes Bos, developer from Canada.

With me as always is mister Scott How are you doing today, Scott? No.

Doing good, man.

Just hanging out. I, yeah. Just just, Yeah. Feeling the vibe. We we had a little, team summit. I was calling it the Syntax Summit Yes. In Toronto. And so we had a meetup, rid. Met a lot of really awesome syntax listeners, a lot of, just really cool people, and had a great time in Toronto feeling Feeling reenergized

and, ready to go for the the remainder of this year and onwards into next year. Yeah. It was it was kinda fun. So it's the first ready. Time that we had the whole like for anyone maybe new or didn't catch it all. So us as a podcast syntax joined Century, ready. Maybe 6 months ago now already.

And we all Yeah, March, end of March. Yeah, we all went to the Sentry office last week And had a bunch of meetings about content. We specifically asked you to submit the survey, re listener survey, which is really cool. So we went through all of that, what types of content you like, what kinds of content you don't like. We're gonna get new intros to the podcast. That seems to One thing people don't like, actually get new intros instead of just talking about it. Yeah. Yeah. I think well, people like them. I think that they're just a little played out by now. You know? Once Once you hear it for the 100th time, you're probably sick of it, which we get it. So Six hundredth time. Yeah. Appreciate you sending all of that feedback our way. We have some really cool stuff coming down the pipe. Rid Excited to share that all with you. And, likewise, since we were just in Toronto, at the Century office, it's a good time to mention that this podcast is presented by Century,

perfect place to track all of your errors and exceptions.

And if you're having software bugs or anything, Century's got your back and, tracks performance, tracks all kinds of stuff. It's incredible. So check it out, Century. Io.

Alright, Wes. You wanna get into it? 1st question from doctor Pupkis. Hi, guys. Long time listener. 2nd time questioner. Since Next. Js is becoming the de facto ready. New create react app, I'm thinking, does it mean vendor locking yourself in? I know Netlify is a reliable alternative to Vercel to host the Next. Js, But surely there are others.

Can you count on them to be able to handle all the Next. Js specific requirements? I'm just wondering if you have tried other hosting services. Thanks. So this is a great question. We talked about it a couple times on the podcast. We'll do a quick rundown of rid. So Next. Js obviously React framework and they all of the special sauce ready. In Next. Js works super well when you host the thing on Vercel, right? Like you can do middleware and that is deployed as an edge function.

You can create like API routes, and those will be deployed as serverless functions and all the good stuff is deployed to Vercel, and it all just works and it works really well, which is it's just great.

But like you said, you don't necessarily always want to have vendor lock in. Ready.

Next. Js itself has like a build output API where they will kick it out to something.

And they've always said, yeah, you can host Next. Js anywhere. But the difference is that when you run Next. Js elsewhere, It's run as just like a Node. Js application, and there's a couple sort of gotchas, that don't Perfectly translate to the experience that you get on Vercel. So, yeah, that's certainly something to think about, and it is a very real concern. I know Netlify has ready. Dedicated staff to make the frameworks work perfectly.

So every time a new Next. Js version comes out, they have to sort of scramble and figure out, All right. How do we make this work the exact same way? Serverless functions, edge functions, all of that good stuff on Netlify as well.

But rid. Have you tried other hosting services as well? So, Scott, have you gone down that route at all? Yeah.

I have not. In fact, I was going to do the SST route very recently and just ended up realizing I didn't need that much, so I just threw it on a a Cloudflare pages instead. I had, for some reason, thought I needed some server side stuff, But I did look into SST quite a bit in terms of, like, the flow of hosting on there, and it all just seemed Incredible.

So if you're the type of person who is worried about the type of luck, and I know SST does a great job for that. They even have Docs for not just Next. Js, but Remix felt Astra Solid. So, you know, it's a platform for hosting, essentially Next JS style stuff on AWS while getting to use all of the secret sauce style things from Vercel, but just not with a Vercel based platform.

In fact, we did an episode on SST with DAX, So you can go back and listen to that one for more information.

And then, like, there's flight control that we also talked about, which is kind of like a very similar concept of Getting you set up on an AWS type of platform.

So there are those very real questions. It is a concern. I think it's by design. It's Probably the reason why they've gone so hard into Next. Js and have invested so much money on in, like, kind of, I don't wanna say taking over the React platform, but really becoming the React platform.

Yeah.

So that way, You know, when you need to host your React site, which a lot of people do, hey. You're gonna pick Vercel because it's the best option.

So if you're the type of person who is afraid of that, there are options out there. Again, SST, I think, is probably the the best of those options, in terms of, like, replicating that functionality, but, yeah, I that I think that's a concern. I think that's a a concern with one of these, like platforms owning owning your platform.

And just to play Devil's advocate as well is like when you go from your application to deploying it.

Like you could also say like that's more of like a infrastructure rid. Problem, you know, and there are hosts out there. Cloudflare Pages allows you to host Next. Js on it.

We said rid. Netlify does and there's lots of hosts out there where they're like, Okay, well, this framework is becoming very popular. Let's have first class ready. Support for this type of thing.

Because just like Node. Js, like if I want to host a Node. Js process, I'll go to A host that probably supports Node. Js out of the box instead of like just a straight up Linux box where I have to install Node and run it myself. So rid. This is just kind of like 1 step further in that direction. And I certainly don't blame Purcell for doing it as hard as they have because, Obviously, that's the business. And this is the business movie. Yeah. And they're making an awesome an awesome product on top of that to make it work. But Yeah, certainly like seeing that. And there's also the from DAX, the Open Next. Js project, which again will allow you to the goal of it is to be able to host

Next. Js on in a serverless infrastructure and not just a Node. Js process. Yeah. Yeah. And and you know what? I think there's one thing I really like about The SvelteKit style of adapter, the adapter output, where in SvelteKit and many other modern platforms now, you can essentially would have with a an output adapter. Yeah. Remix is, like as well. Yeah. You can choose, hey. I wanna deploy this as just a node app. Use the adapter node. Hey. Now it's a node app. Oh, I wanna use the Vercel one. So you can use the adapter. I think it's just adapter auto for Vercel, but I believe there is an adapter rid or even just a Cloudflare Workers one or whatever. You can use that adapter and choose where you want to deploy it, And you can make those trade outs yourself relatively.

I mean, super painless depending on, you know, the features that you need. Right? You can't deploy a static site and use server side code That's not during build time. Right? But as long as you're you're doing those things fine, you can pick and choose where you want to deploy this thing. And I like Yeah. I,

Like, I would love to see Next. Js roll that out, but I don't know that they will do that because rid. Then I guarantee they're going to they're going to roll out some like real time amazing feature that works amazingly in Next. Js.

But then then then do you have to support like 8 other runtime platforms, you know, like that that. Also, like The lines between Vercel and Next are are kind of blurred. Like we're working on the Syntax project right now, we're hosting it on Vercel. I was having issues with trying to get a WASM package as part of one of the serverless functions, and it wasn't like bundling it because it was at runtime.

Rid. And I like I asked on Twitter about it and, like, half the responses were Next. Js answers, you know, and it's it's kind of hard to find rid. Just Vercel specific

answers. Yeah. Next question is no name. You guys are awesome. Thanks. Hey. Thank you.

Not a question, but a suggestion.

I was thinking that people could submit hot takes, and you guys could say if you agree or disagree with them. Spicy rid Side dish, if you will, like this. There you can put it in within our brand. Yeah.

These aren't meant to be targeted at you guys or the podcast, but the industry in general. Here's mine. Stop calling Firefox the new IE because you can't use has yet, especially if you're Too young to have maintained files named IE7.CSS, IE8.CSS, etcetera.

In my career, Firefox has been the browser with the most consistent rendering and has been my daily driver for the past 17 years. Read. WES even released a course where it only work in Firefox because Chrome was behind. We're lucky to have 4 browsers that are so compliant now.

Yeah.

Hey. Here's what I think about this take.

I think this is Scott's take. This is not Syntax's take. Yeah. I think you're I I use Firefox now as my daily driver.

I do notice Firefox has more issues than Chrome or Safari these days, performance wise or just in general. I also noticed that most of the APIs that I want are last to come to Firefox. Not all of them, but most of them. So Firefox does feel like it is lagging behind, And that could be for a number of reasons.

With the point about Firefox being, you know, ahead or being consistent for the past 17 years, Sure. Absolutely. But Mozilla and Firefox's development has changed substantially over that time, and I wouldn't necessarily say it's the same browser that once was. That said, I like Firefox.

It's my daily driver. I prefer its dev tools to Chrome's dev tools Or just in general, and there's a lot of things that I do prefer about it. But I wouldn't necessarily say it's the most advanced or most consistent rid. From my own take. Yeah. Also, nothing is the new IE. IE is what it was, and and there was a point in time when IE was like the the rid fancy race car and everything else sucked. So, you know, everything's relative to its time being. Nothing will ever replace rid What we had with IE. Yeah. Here's here's my spicy side dish is Safari's the new Firefox.

Oh.

And and what I mean by that is 5, 6 years ago, Firefox was making major leaps and bounds in a lot of the new CSS stuff, a lot of the new JavaScript stuff.

And Over the past, maybe not even a year, I've been trying to get Jen Simmons on, on the podcast to talk about this. She she works for Safari or for Apple on the rid. Safari team and CSS working group is like Safari has been kicking ass with all of the new CSS features.

They are the rid. Only implementation of part of the new JavaScript temporal API, which is the new data API. It's massive. It'd probably be many years before we get it, but 1st to get relative color syntax. Yeah, relative a lot of times when I'm using all of the color mix, relative color, I always have to fire up Safari.

So there's always going to be that 1 browser that is like dragging their heels to implement these things or taking longer than we hope. And that's frustrating because As soon as all the other browsers have it, we are all just like, well, we point to the one that doesn't have it. Rid. No matter how fast the stuff goes, there's always going to be 1 person that is lost to implement it. And unfortunately, that has been Firefox because of ready. Mozilla's business model doesn't work that well anymore. There have been major cuts on that type of thing.

So rid. Again, I've been using Firefox daily for for a long, long time and I still prefer it. But yeah, they are. They are the one. But on the same, let's also say, like, How amazing is everything? You know, like, oh, yeah. People complain about CSS.

Show me this is a show I want to do is. Yeah. What what other ways Are there to layout UIs? You know, like there's whatever you have on Ios, there's whatever you have on Android.

Ready. What other UI things are there out there? And like, I honestly, I don't know. Like, I don't know how you lay out something on a BlackBerry. Or how do you how do you lay out something in in Android? And is it better than what we have with CSS for complex layouts?

Doubt it. Is it? You know what? You know, the what the big difference is, Wes, is that you're hitting multiple different rendering engines.

And how many other layout tools have to hit so many different rendering engines? Read. I you know, you're building iOS apps. You're targeting iOS. You're building macOS apps. You're targeting macOS. So we're we're targeting multiple different rendering things. And, typically, like, when people have, Like, when people have, like, mean things to say about CSS, it's because, hey. Something's not working in one browser as you'd ridged. Or there was the LOL, you know, how do you center things even though it was never really that hard.

Yeah.

I, re Yeah. I I think I think some of it is the cascade. Some of it is the the rendering targets and things. But yeah. No. CSS is is, in my mind, Very logical to reason about and something that I've never really purse I don't wanna say I've never struggled with it, but it's it's never been something I've ever felt like is is the worst implementation of a layout system ever or something like that, especially Grid and Flexbox.

Really change the game there in terms of making that stuff easier.

I mean, sure, with floats and and collapsing, rid zones and and, you know, pulling things out of the document flow.

I think those things are all valid concerns, but they're not concerns really anymore. Rid. I've I've never I haven't done a float in years, many years. So, hey, before we move on, I do wanna say you you mentioned that, you know, rid. Safari is the new Firefox, and Firefox back in the day was was or even, you know, years ago It was great. I think the common denominator there is, as you mentioned, Jen sim Simmons. I mean, she worked at Mozilla for a long time and then went from Mozilla to work at Safari, and rid. It it seems like it's no surprise that now Yeah. That sent it is it is actually a direct line. A direct correlation.

When she joined Safari, they changed substantially. They've become more developer focused. They're shipping rid. Features left and right, and it's a wonderful thing. So if if if you, don't follow Jen Simmons or her work or Yeah. You know, are familiar with her, look her up. She's, incredible. Next one from ready. So, Mil, can you compare database as a service and provide your recommendation suggestions?

Or can you do an episode comparing the different options rid. Like Supabase, PlanetScale, Neon and others. I would love to hear your perspective on these. Also, thank you. Syntax is my favorite podcast. Yeah. We did a show episode 551. You can go to syntax. Fmfive 51 to listen to that one on serverless databases, and we sort of like talked about rid. Why what you need to think about versus a traditional database. And we sort of went through a bunch of the options rid. That are out there.

But this one specifically asking about the services, right? And a lot of these services, Supabase, PlanetScale, Neon and others, they are hosted either something traditional like a MySQL or rid. Or a SQLite API or their own.

They don't say that they're specifically a database, but they're set of APIs you can use to sort of interact with it. So, my suggestion with these types of things is figure out, do you want A standard database type like MySQL, and if that's the case, then something like PlanetScale or Neon is probably ideal because You can use your traditional SQL functions, but the limitations of scaling up on serverless are not necessarily there as they add a bunch of special sauce on top connection, pooling, things like that.

Or do you want something That is you're more locked into it, but you get more nice features like real time and whatnot and Supabase Firebase. Those are Probably a better choice there. What do you think, Scott?

Yeah. I think, one of the the big things here is yeah. Like you said, like knowing What what these types of services specifically are like, we have different classes of tools here. Right? Supabase has a much larger footprint rid in a much larger platform than something like a Neon or even a PlanetScale. Right? Those are rid. Serverless database is hosted somewhere where Supabase includes auth. It includes even, like, emailing you one time magic, rid logins. It includes, serverless functions. It includes a a a GUI for your database, but also, like, a full platform for working with data.

And it's awesome. It even has JavaScript libraries to connect to that data. So, you know, they're very different classes of tools, and I think really, taking the time to dive into what those are is going to be well worth your time, but I do think that could be an additional episode for us here, Wes. I think we could say Yeah. But, truly, let's separate all of these tools into different classes. We have things like Hasura, which is you know, allows you to have an, You know, basically, a GraphQL a GraphQL API directly from your database, Supabase or Neon, any of this stuff. So I think that's a good idea. I think It's probably too much to get really deep into in the answer for this question, but we can definitely take our time to, classify those out into different categories in another episode.

Alright. Next question is from, Jop Strongs.

Yeah. Strongs.

Yeah. Name. Yeah. Jop rid Oh, okay. I got the I I needed that, Wes. Thank you. I don't know any any, Dutch names.

Although I love modern tech stacks with headless CMSs and blazing fast front ends running React or similar, I'm at a loss when it comes to Implementing forms.

For many years, I've been spoiled by WordPress and its ecosystem of forms, plug ins like Gravity Forms, re WP forms and let the CMS editors create any type of form you can think of that also connects The third party systems, complex conditional email notifications, confirmation flows, etcetera.

Currently, I hard code important forms into a website install WordPress on a subdomain just to allow editors to create new forms. I want to use a native form, something like Next. Js, that are part of the regular UI. Rid. I want editors to set up forms that control the logic. I understand this should perhaps no longer be organized by the CMS service where the website content is stored. Rid. Is there a dedicated forms service self hosted or as a SaaS that lets you create forms that you can reference in your CMS that You can handle the data processing and email notification stuff, but allow you to use your own UI elements. Yeah.

This feels like a good a good like opening for A service, a dedicated service. Right? There are plenty of these form services that will do like an iframe rid. Experiences, like, they're the type of thing I would use if I didn't have access to a back end, whatsoever or any sort of serverless functions. Let's let's call out a awful service. We use

type form for the syntax, the listener survey.

And holy hell. Like, So Caitlyn, marketing. Did you call out an awful service? She went and made the form and I was like, all right, let me jump in there and like, just tweak the The design and whatnot. And like we had we had 1 question, which was like, which of these episodes do you and do you not like? And it's a lot, right? So I wanted to make the UI as as nice as possible.

And like you can't.

There's no control over literally anything. And it looks like garbage on mobile. You can't like even put a little bit of CSS in or like have there's no knobs or anything to even just turn the different layouts and like It's amazing. They have like like 20 different inputs, and that's it. This entire business probably worth 1,000,000,000 of dollars and rid. Garbage. So I talked to Sasha, who runs like State of JS, and I was like, like, dude, like your your form taking UI

is a 1,000 times better than this, like, major corporation. You know? Golden. It's great. Anyways, I I've used services. I've used Formsbury. I don't like it.

I used Woofoo from SurveyMonkey.

I didn't like it.

So I I don't know. I'm not saying that there isn't anything out there because there very well could be something I don't know. But the big problem here is the connection to the CMS If you need a connection in the CMS, you need people to be able to easily build forms, yet you need to integrate them somehow into the JavaScript app if you're using something like Next. Js or React.

And that, my friend, I think is a perfect encapsulation rid of where we're at today in web development with these things.

There is no service as far as I know that bridges that gap.

I think, Is it, builder.io is is is probably one of the closest things where you're getting into being able To have editors essentially create components and utilize created components, I don't know if that works well in this form's context, rid But then you get into the whole aspect of handling the form.

And so, really, what ends up happening is anytime you need to have a form in a modern JavaScript like this, you just end up hard coding it into your site. It just does not work super well in a WordPress type of situation, allowing editors To click and create their own forms, I think about making this I used to make this stuff in Drupal all the time, and you could train somebody to do that in no time.

If if I was tasked given that task today, say, hey. You need to have a part of the website where people can create a custom form. Hey. I don't. I might have to build that myself. I I honestly have no idea what I would tell them to do, or I would pick up WordPress. So I think you're rightfully rid Stuck at this point.

I it it's a hard problem to solve. I'd be interested if you're out there and you have the perfect solution for Yap here. Rid Let us know. I would love to see something like this because I think it's an interesting topic and definitely one of those pain points that you get when you move from, You know, a CMS solution to a custom app solution. Yeah. It's it's a tricky thing because, like, like, WordPress has us nailed. It's You pay once for, like, the plug in. Yeah. You're not paying through the nose. Like, we had an upgrade. We got a 100 people submit

Forms and also we have to pay more money because we want more than 100 submits like like what a somebody listening to this right now. Go make a better form SaaS and make it open source so that we can host it ourselves because this this is a problem, right? You're either paying through the nose to be able to use your form or you have to, like, code it yourself every single time and and use, like, a a library for it. And let me elaborate, sorry, to to interrupt rid you here. In addition to that,

let's say when I went to upgrade how many submissions we could have on our form, even though we were selected to pay monthly, Typeform decided to automatically move it over to a yearly subscription Of course. When I did as a as a like, the there was no toggle for We just did it automatically. Type 1, a big old middle finger emoji for that.

I think that is, like, dastardly. It's because, Like the reason why WordPress has it so nailed is because they control the back end. They control your data layer and they control your front end for this type of thing. And you're able to get ready. Really nice editor experience for someone who's making the forms on the back end. You get conditional data. You can have ready. Nice GUI implementation. You can create custom inputs. You can have the spam fighting, which is absolutely something you need these days. You Can't just throw a form on a page and, expect that not to get abused by bots. And then you obviously have the front end, all the JavaScript with that type of thing. So, Yeah.

Sorry, Yap. I don't know.

I'm as frustrated as you.

This is one of those rid Problems that like, I remember hitting stuff like this moving over to custom app AppFlow, and the answer ends up just being code it yourself, but then you lose all of that rid Editor functionality that you you know you know and love with this. Yeah. Look look at us. Our potluck I I took the time and actually embedded rid The potluck

form, but it's still a Google. It's still a Google form. It's still a Google form. Even though we could code that as far. We definitely need to put that in the Like, yeah, that's one thing we should do is make the submissions go into the database so that we can just, like, click which ones we want, And we can have a bit better formatting.

But yeah, that's why so many people reach for like a Google form is like is saying that your rid. Your framework has failed you or your your thing. You know? People that's why people use Google Forms or Typeform. You know? They're like, there's not something rid It's giving up. It's giving up. Yeah. I'm gonna throw this ugly ass form on here.

So we have a Didn't know I was so upset about forms. Yeah. Rid. Yeah.

I agree. Next question from Guha. Hey, Wes and Scott. Love the podcast. Can you please talk about Svelte and turbo abandoning TypeScript.

And what and about some big companies are hesitant to migrate their React app to next, given that has been rising popularity and being easier when the entry moved into world into the React world for many, including myself. So ready. I didn't really I didn't hear that turbo abandoned TypeScript as well. I'm assuming that's like turbo repo. Is that what they're talking about? No. Turbo is is the DDH thing, when DDH was like, oh, yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. They got rid of it. So Svelte, We talked about the Svelte one, but they specifically got rid of TypeScript because Svelte is compiled And in TypeScript. So when they are working on Svelte themselves, there was like this two layer of you had to compile it and you had to go from TypeScript, and it was apparently too slow and too hard to follow the source maps and the bugs and all that stuff. So it was too frustrating.

So they moved to using JSDoc for that type of thing.

Not that you can't use TypeScript in Svelte, but Svelte itself rid is, is still using types, but they are using JSDoc for that type of thing.

Ready. And then the turbo stuff, I didn't really pay attention.

Whenever any of that DHH stuff comes up, I don't really get into it too much because people get really riled up about it.

And I think it is fine You have different opinions on how to do things. Yeah. And if you don't like something like that, or you think that you it is easier for you.

You're probably right for your use case. You're probably right. You're probably a pretty smart guy. You probably know what you're doing.

And,

Yeah. I think that's that's totally fine to do that type of thing. Yeah. I know. DHH gets people fired up. I I really liked his books, so rid. It's hard for me when I disagree so directly with some of the things he says, but it's okay. Yeah. We can all have different opinions.

I I think what the most important thing about this question, Guha, is that, like, these are not the same situation.

Turbo abandoning types And TypeScript entirely is very different than changing how you author types. And so I think that is a, like, a a a clear distinction that we need to make Because so many people have ran with that, and I saw that all over our Twitter during the DHH stuff was Alex. Felt could abandon it. No. They did not. Felt could did not abandon types. They did not abandon TypeScript. They abandoned how they author their TypeScript.

They're authoring it with, JS doc so that they don't have to Run their code through a build step, but they're not abandoning types.

Your code is still completely TypeScript safe and, implements TypeScript read. Just in a different manner.

So these are not the same situation. I should say that there's a proposal to do exactly that in JavaScript. It's called types as comments, which is, It's not actually writing them in comments, but it's part the actual types will be authored similarly to TypeScript. But they get stripped out by the browser So that you don't need to have a builder compile step. That's kind of like our our North Star in JavaScript is. Will we one day not have to run Tooling to and our JavaScript? Maybe.

Maybe. And that's the whole thing they're doing now. They're saying, DHH, and they're they're saying, we don't no more build steps, and that's cool. I mean, JavaScript, you can now we have ES modules, And hopefully, we'll have types as comments that we can use inside of actual JavaScript, and and I'll be very happy to not run my code through a build step, but a build step does not ruin my life. The people act like a build step kicked their dog or something. A build rid Step did not kick my dog. I largely do not care. It's fine.

The build step has never not I wanna say never, but it's not you it's not a huge Problem for me, and I just don't I don't care that much to replace it. That said, it would be cool to not have it, but it's not ruining my life.

Ready. So, yeah.

And the 2nd part of this question was, some big companies are hesitant to migrate the React app to next.

Ready. I think that's completely valid. There's plenty of very fleshed out React applications that are not running on a framework rid. Because they they choose their own routing library.

They have a layout system that works for them. Maybe they don't need the whole server side thing because they have APIs elsewhere.

So I don't think that That is that big of a deal to move to NeXT. It would be pretty big buy in to move your entire application to NeXT because you're buying into all of the You're buying into routing, into layouts and like Nexus had a lot of like thrashing in the different APIs. And Also, now they're going hard on server components, which not everybody is sold on just yet and not everybody necessarily needs.

So I think a lot of people who are hesitant are. That's good. And you just sit on your hands and see how this sort of pans out. There's been a lot of changes in rid. Last year or so.

So who knows? You know, maybe maybe some of those changes won't stick. And it's very expensive to have to Have thrashing like that. Yeah. Totally.

Alright. Next question from Tory not Tory.

Nice little play on Tory's name here.

In your recent Tory verse Elektron podcast, I was surprised to not hear React Native mention.

Rid. Do they not overlap in their goals? Is React Native dead now? No. React Native is not dead. React Native is fine. It's React Native is a hard platform. Re you kinda have to really like, some of the some of the dream with React Native is that you could take all your re React knowledge and build awesome native apps, and you can. But React Native itself is kind of a deep well of a topic, And you end up becoming a React Native developer, more so than just a straight up all around web developer because React Native is very rid in how it does things. It breaks all the time. There's a lot of issues, but React Native is awesome. And, in fact, React Native does something that Tori and Electron aren't doing necessarily. So what React Native is doing is it's physically translating your components to real native code, and it's being able to run native UI elements for both Android and iOS, connecting directly to those APIs, and it's translating that React code into those real native code. It's it's not using web views at all. So re React Native, it's for mobile apps, iOS and Android, not using web views. Now it's almost A very different approach from Tori and Electron, which are using web views. And what a web view is is it's a Browser without all of the browser stuff. It's just the rendering engine and the APIs from the browser in essentially a mini browser.

And so When we talked in that episode, we said Electron ships a browser, and Tori uses the one that's on your machine.

And in Apple, it's, You know, Safari web kit.

On Windows, it's a, edge.

But with Elektron, it it's a Chromium window.

So they're very different in that. Torey and Elektron are using essentially a web browser in running web code in a window where React Native is running a true native app. And that's the big difference.

So there I mean, there there's overlap in the fact that you're building desktop or maybe potentially mobile apps with them, whatever, But that's pretty much it. The approach they take is is very different.

Like right now, I think you can kind of look at it and say, okay, I have a web app.

And if you want this thing to go desktop, you go Tori or Elektron. And if you want this thing to go mobile, you go React Native or one of the other options out there. And Tory is starting to go mobile. But Like I can't I can't imagine anyone would look at Tori and React Native and be like, you know, Tori is what we want because React Native has this massive, rid Massive ecosystem of like what happens if you need maps? What happens if you want to do native NFC tag, like Scanning, you know, like as soon as you hit all of those. Oh, but we need something that's native ish. Native APIs.

Then React Native system is there. It's true. Like it's Generally, when you talk to people that are React Native, it's it's not that they're they're generally React Native developers.

They're not. Obviously, there's some web developers that do both, but it seems to be a specialization in understanding how all of that stuff works, even like layouts You have it's a different way of doing layouts. They have Flexbox, but it's all native layouts

and you can't just rid. CSS background black, and and it works. You gotta figure out what the equivalent is there. Yeah. And and I do wanna say one last add on here. Tore and Elektron are kind of write once deploy everywhere types of situations, right, where you could write rid A web app that works on the web and then wrap it in a Tori or an Elektron wrapper and deploy it as a desktop app. Lots of desktop apps work that way, Where React Native is not that way at all. You have to be authoring for React Native. So much to the point where there's a React Native web To translate React Native apps to back to the web. Did you know that I I didn't even know this. Microsoft

rid. Maintains React Native Windows and React Native Mac OS.

So like, in that case, like React Native is Like, it depends on what you're doing, but

React Native looks a lot more attractive. You know? I like React Native as a platform. I've built apps in it, and for the most part, it's rid Way nicer for me to get into a mobile app development than anything else. But

Sauce taking over.

Taking over. All right. Next question from MyCodeErrorsalot.

Do I use the new When throwing an error or not, does it matter at all? Throw new error, boom, or throw error, boom.

That's a good question.

Do you know? I it's funny because in some situations I'm used to throwing the new rid. On there whenever I am creating an error or when I have, like, a custom error, I'll say, like, throw new

JSON API error. So I did some research on this when I picked this question because specifically, I was like, wait. Does it matter? And if if you're out there and you're an error expert and and you have any additions onto this, please, again, tweet us. We'll we'll, retweet you. We'll shout you out. My understanding of the situation based on what I researched is that it's a convention and that The new keyword is is creating a new error, but in practice, it ultimately is doing the same thing at the end of the day. Right? It's throwing an error. So whether or not you're throwing a new error or you're just throwing an error is more of a convention than anything else, And people use it to be explicit about when they're creating an error versus when they're, like, passing on an error.

Red. So, sometimes that's it. The other the other bit is is that, like, let's say you're catching an error and then you want to rid. Throw it further down the line.

You can continue to throw that error instead of throwing a new error, and, like, that way, you'll maintain a consistent error type.

So, yeah, for me, I almost always if I'm, like, if I'm saying, oh, here's a new problem that I have, I'm throwing a new error. And And I would say almost always throw a new air because I don't know better otherwise. So if you're a a deep expert on throwing a new air And it's beyond what I've mentioned here. Please let us know because it seems to be it's mostly just a Thing of being, like, explicit and it being a convention. There's a massive

Stack Overflow answer about this. And like the first 2 answers do not answer the question of what's the difference between new error and error. And finally, there is

rid. One little comment here. Error is functional, new error is a constructor. Both both work the same. Yeah. So there you have it. And that's that's largely what I got out of it. Functionally, it all kinds of come it all kinds of ends up being the same. I think we should do a show on

specifically different types of errors as well, because as you get more into to TypeScript, There's

You know who deals in errors really well? Oh, yeah. We know a couple

people that that do some errors.

Century. Century does a lot of errors. They'd be good people to talk to about that. It's amazing, and and I don't I don't want this to ever turn into the century hour. Not that it It is, or is it any danger of that? But, like, there's so many times when we come up with practical issues, And the answer is, I bet someone at Sentry has a good answer for that because they deal in source maps. They deal in errors. They deal in lots of events. They deal in all kinds of big problems.

So tired people at Century that know way much about SoreSmack.

Yeah.

Next question from Josh Collinsworth.

Hey, guys. A little feedback on the recent CSS survey episode.

Sorry. Don't have x. That's okay. No need to apologize for that, Josh.

1st on touch action.

Thought it might be interesting to know a use case.

I've built a couple of word games in the browser.

One of them is Kina and Hondo are their names. Rid. Kiena and Han I was I wanted to say quinoa, and I was like, that's not how you say quinoa.

Kiena and Hondo are their names. So shout out to Kiena and Hondo.

They're both similar to Wordle, and so they both use an on screen keyboard. Anytime somebody would press 1 of the He's in rapid succession to delete a word.

Touch screen devices would zoom in on that key. Rid. So touch action manipulation solve that for me. Josh, you have unlocked touch action for me. That answers the question. Love it. Touch devices.

Okay. Next one. Also, you both expressed skepticism that so many people would have used such a new browser feature like subgrid And the HAZ selector, I think maybe you're forgetting that both of those have acceptable, graceful fallbacks.

I've shipped has to production just because I know that there are browsers that don't support that selector yet. Nothing will happen.

So it's a bit of styling mist, and that's just fine for my use case. You know what? So Josh was one of many people that sent us in saying, Hey. I am using has, and I just use progressive enhancement.

That's great.

I feel like most of the times when I wanna use has, be, like, something I would want to keep. Like, I it was like something I wouldn't want to just not work if I didn't have halves.

So I want I maybe I need to personally dive into the progressive enhancements for HAS to see, like, what is there a compile away solution that gives you a true fallback for it. Because if there is, then that's great. I would I would be going ham on has. It'd be has city over here for me. Rid. There's not. I think what he's saying here is like make it look decent

for all browsers, then make it look awesome rid. Or make an extra feature for for the rest of the thing. So maybe, for example, the transcripts on the syntax website is like if I wanted to change the border color of the current transcript and I could say, like, if it has something with a class of playing, then The parent of that can be colored in a different way, right? It's fine if that doesn't work on all the different browsers, especially because such a small rid portion of it. But in in building the whole syntax website, I probably like 6 or 7 times I hit ready. Nice to use HAZ here, but it's not on all the browsers just yet, and it's not something I want to look crappy on the other one or even just the fallback is not good enough, especially because it's Firefox. Right. That's Probably 30% of our visitors. Yeah. It's a major browser.

Yeah. And in that same regard, Josh, I do think, you need to know that we do Quite a bit of progressive enhancement. In fact, on the new syntax site, we're shipping the Oh, yeah. View transitions API, which we're progressively enhancing. And let me tell you, The progressive enhancement for that is to just not have an animation. It just works fine. And to me, that's a great progressive enhancement because you're not really missing out on that much essential anything. So we are definitely doing progressive enhancement. I just didn't feel like the has progressive enhancement story was that great, and same with subgrid. I don't I don't I don't. Maybe I'm missing something there, but subgrid to me feels like one that, you know, I I guess you could use it, but, like,

that that progressive enhancement story isn't super great for me. No. Because rid. If you need subgrid and it's because you need something to go somewhere.

And like maybe all the columns aren't equal heights on this browser. Nah, that's an okay situation. But again, every single time I've wanted subgrid, I've thought, I need it like I need it everywhere.

Next one from Zeeshan.

Is it okay to be a front end developer and not Be as interested in CSS. I know enough CSS to be dangerous, but I'm not super all into the new properties and ways of doing things. Nothing against CSS.

It's just one of the better app layout mechanisms that I've used, I'm just not interested in it enough to go deep into it.

Ready. I'm much more interested in the JSTS side of things. Is it career suicide for a front end dev? I'm low key having an identity crisis.

Am I not meant to be a front end dev? This is a really interesting question because I get the opposite question all the time. Can I just do CSS and not really get too much into that JavaScript type of thing? And my answer ready.

To that is usually no like.

There probably are like there probably are a couple of jobs out there Where you just do HTML and CSS.

But as things are going and you do a lot of interaction, you're going to need a little bit of JS. Rid. But on the flip side, I think I think Zeeshan, it's fine if you don't want to get super into it.

You probably will skew a little bit more back end and a little bit more like interaction based.

And then I could see somebody coming in and doing a little bit more of the CSS. I don't think you have to be an absolute expert on that type of thing, so So I think you can specialize in it. I would still again listen to this podcast, understand how the things things work, but You don't have to go to a CSS conference to get to it.

And one more thing I'll add to that is like CSS is becoming rid. Even more complex.

There's so much more in CSS.

We got view transitions.

We've got has that we just talked about. We've got all the different touchscreen stuff. So it is becoming a much bigger part of the thing rather than just making things a specific color. Yeah. I this one's tough for me because I think of,

I don't know. I I think at various points in the front end world, you could have said, yes. That is fine. But in 2023, 2024 beyond, I feel like the landscape has changed. CSS has gotten so much I don't wanna say easier because there's more properties, but it's easier to accomplish things with grid and Flexbox than there ever was. So that, like, very specific domain specific knowledge of, oh, when I do gotta do the clear face and this like, those things have gone out the window, so now you learn it once, and you don't have to get as deep. Right? And so I kinda think you have to have at least a a good enough skill set with, I'm gonna say, flexbox, grid, variables, rid Like, to be able to make layouts or invest heavily into a framework. It's true. Because, like, if you're if you're a a bootstrap or a a tailwind or something. If you're like a JavaScript, ready. You're

building components.

Like, good chunk of that is JavaScript. It's also CSS, and it's not like you're just gonna build the JavaScript part read and, like, leave the CSS part. So maybe maybe I'm gonna walk back my my thoughts here. I think you might be right. It's like like, it's just a tool. Like, you're you're building an app.

You got to know the JavaScript part and like, yeah, you're going to have to know the CSS, like the fine detail making style systems, all of that stuff. Yeah, that's probably somebody else. But yeah, yeah, you do need to know that layout stuff. And and even the last question is like how it works.

The interaction is touch action.

That's that's part of CSS, right? So if you're if you're concerned with how your component works, Part of that has to do with clicks.

But the other another good chunk of it is done in the CSS as well. So,

Scott, you just you just made me walk back my answer there. I think you're right. The the tools are tools. Right? You gotta you gotta learn them all. That's part of the job. Yeah. Part of the job. Unfortunately, now we got a lot of tools ready to learn. That's just how it goes. Right? Bunch of big tools over here. Yep. Tool Academy. That's what you're listening to. Do do you ever watch that show? That was a TV show, a reality TV show. Rid Tool Academy? Tool Academy. I believe it was on, like, VH 1 or something. And the the premise of it is that they would have, You know, 15 tools, it's a bunch of dudes who are tools, and they were, like, trying to reform them from being tools.

And it was very funny.

It was definitely there there were tools. 1 guy oh, they they they were on the show with their girlfriends, and 1 guy was such a tool rid That, his girlfriend back home saw the show that he was on and then contacted the show to be like, He's on the show with another girl, and I'm actually his girlfriend.

So he had, like, he had a a 22 woman confrontation on the show. It was a bunch of tools. It

rid was a fantastic show. Classic, 2000 p h one reality TV show right there. Impressive. Never heard of this. Oh, yeah. Ready. Alright. Last question we have here from Westa's Pacificcity.

Could you explain what workers, Processes, jobs, tasks, and daemons or I also I just learned they're called daemons.

I always called them daemons. Are they actually called daemons? Yeah. Well, I think so.

Rid Oh. Oh, wow.

I've always said Damon, and I don't know. Like, Matt Damon, but I I straight up don't know. I've never heard anybody say it out loud. So Alright. I'm gonna I'm gonna hear it. Demons.

All right. So the question here is you hear these words thrown around a lot. Process worker, job task And daemon, what are they? So I'm going to give you the answer in context of building a JavaScript web app.

So both the server and the client, these are just like general computing terms, and often they mean more things than one simple thing. So A process is the first one is an instance of an application, so it's configured and being run-in its environment. It often includes Things like a database connection and whatnot.

So for example, in node world, we have a node process. When you type node myapp .js and it starts running your application.

That is a Node. Js process that is running, and it may in turn rid.

Run workers or jobs or tasks or demons. So the next one we have here is a ready. Worker. That sounds awful that that's a demon.

It's great. I actually like it a lot more now. Yeah. Just just it's beautiful that there's just demons on your computer all the time.

A worker is a sub process that computes part of a larger bit of compute. It often runs on a separate thread, so the main compute process that is controlling the worker is not locked up. So again, you might have a process like a node app running or you might have a process which is the JavaScript is running on in your browser because you visited a page.

And then you need to do a little bit of compute. You need to do a little bit of work.

Send and resize an image, send a push notification, Analyze some audio, an audio file.

And often what you'll do is you'll kick that off to another thread rid inside of a worker. And that worker will go off, do its work, and then come back when it's done doing its work and say, hey, rid. That thing you asked me to do, I did it. Here's here's the result that of of the work that I have done. Ready. A job or a task is a unit of work that needs to be completed.

So a job or task is just like To me, that's just like an idea of like, Okay, we've got a we've got a job that goes off and transcribes one of our episodes. We have a task That is importing the latest show and saving it into the database.

So To me, a job or task is a description of a unit of work.

And that could be sent into a worker, A web worker, it could be a subprocess. So that's one that's not here. But in Node. Js or in literally any programming language, A subprocess is okay, well, I'm running node, but let me run another instance of node that will go and do this work for me and come back to it. So that's different than a worker because you're literally running 2 processes of node. But At the end of the day, it kind of does the same thing. Another example is a cron job to fetch transcripts, a subprocess to resize video.

Rid.

Even the Open Graph images on the new syntax website like that that could be called a job, right? So When we run the serverless function that creates the open graph image, that is a piece of work that needs to be done, And it is done in a serverless function.

Last 1 is daemon. Those these are background processes They run continually on your system, usually without any interaction.

So these are like just like lower lower level things that are just always running ready. Listening for something network request, a keyboard input, and then when those things happen, they usually kick off processes or or, jobs or tasks, things that need to be done. Wow.

Yeah.

Wow.

That's a lot of stuff. So some examples of of daemons. I'm just looking up on my computer what's running.

Logitech has a daemon running.

Often applications will run demons separately because if you kill an application, They still need some code running to know to tell you to relaunch that application. Right.

Yeah. Yeah. My VPN has a rid Has a a demon, lot of Apple Demons single sign on. I stats has a demon lower level things that are just always running in the background. Around. Very, very interesting.

Now is the part of the show where we get into sick picks. We pick things that we think are sick. A lot of fun things here could be literally Anything. I'm gonna be sick picking a podcast today. Throw it up my alley. If you've ever listened to any type of podcast that's in, like, heists, Love heists style podcasts, stuff about that stuff. This one is really fantastic. It covers a story that I already know quite a bit about because I'm into this kind of thing in general, but, Wondery does it, and it's a fantastic Wondery podcast. Yeah. So this is called the infamous international or it's called infamous international, the pink panther's story. And this is like a a My high end, like, diamond thieves, they are smashing and grabbing.

They they're showing up in in, you know, fancy diamond stores and Driving a car through it and then just grabbing as much as they can and leaving, and then nobody catches them ever. It's it's amazing. It's like smash and grab heists.

And, if you're the type of person who's intrigued by that kind of world, not that I'm planning a diamond heist or anything, but I I think it's just Incredible. So check it out, the infamous international. It's really fun. I'm going to sick pick something that you probably sick pick, like, rid Or four four and a half years ago? Ago. Yeah. This is, PowerBlocks,

which is a set of adjustable dumbbells.

PowerBlocks has been around for many, many years. In fact, I have a set that is probably 20, 25 years old that I rid.

And these things are awesome. So if you want, you don't have a whole lot of space for set of weights or adjustable or for dumbbells. You can get a set of power blocks And you can adjust them different in different increments.

I think every single increment is £10, and then In the handle itself, you can add 2, 2.5 pound weights, so you can basically get a 10, 12.5, 15 The increments. I did the I had to design a whole sticker for my vintage set, so I understood What the weights are. But PowerBlocks are fantastic.

I'm so happy with them. I found another set and PowerBlock the company, it was missing. I've like I always buy broken stuff, so I found a set that was missing one of the increments for whatever reason. And PowerBlock the company Sent me the missing increment so I could have a whole set again. And it's just an awesome company. Also, I'm part of like a Like a home gym Facebook group. And there's like there's another set of adjustable dumbbells called the Nuo Bells.

And they're really cool because they They're not square. They're like they're circular and you can click the handle in the different increments.

And Every day there's somebody, my power blocks, I drop them or they roll off my bench and the tolerances are so tight that as soon as it gets rid. Jostled around. The whole thing is broken in its landfill.

Power blocks are just like literally hunks of iron that have a little slider rid. In the It's really basic mechanism. It's so basic and they will last forever. They still sell parts for 40 year old ones.

So I highly recommend it. I also had a set of like the Bowflex ones.

Garp.

They're huge. They're way too big. You have to rid. If the dial both sides in, the locking mechanism gets stuck half the time. I had to oil it and I sold them because they're just rid Too annoying. The power blocks are the best. Sick. Yeah. I'm a huge fan, and I found Wes

using the new fuzzy finder on the new syntax website that's about to drop. Rid I thought it was episode 3 that I sick picked episode number 3. 3.

Yep.

So Man, rid Awesome. Yeah. Shameless plugs.comforward/courses.

Check it on out. Shameless plugs syntax

f m on TikTok. Beautiful. TikToking.

Alright. Thanks, everyone, for tuning in. Catch you later.

Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.