viewSource

## [00:00:00] Introduction

[00:00:00] **Brian Coords:** You are listening to viewSource, conversations around WordPress and adjacent tech with hosts, Aurooba Ahmed and me, Brian Coords.

[00:00:08] Aurooba, welcome to part two of our series in Next.js, where let's be honest, you're just cramming information to my brain, teaching me about Next.js. Um, because for a little context I have, I would say like surface level cocktail party communication knowledge of Next.js. I can talk about it. I've dappled in it, but you're in the deep dive world.

[00:00:34] And so we're ready to dive even deeper with part two of our Next.js series. Does that sound, do I have the framing right? Or would you disagree with that?

[00:00:43] **Aurooba Ahmed:** I think in my head this is part 1.5 and not part 2.

[00:00:47] **Brian Coords:** Okay.

[00:00:48] **Aurooba Ahmed:** And we'll get into a little bit of why. And also, I love how you say that it's like you have cocktail level knowledge. Says the man who has co created an entire application in Next.js already.

[00:00:59] **Brian Coords:** That's true. And I, you know what? I stole that phrase from when I was in like grad school and I had to like pass all these tests. And of course this was not about computers. It was like English literature, which is what was studying, but it was like. You had to have, they called it cocktail party knowledge of every like genre of literature in every era like, you know, whatever enough to where you could have a conversation about it and feel knowledgeable, but like you're not an expert on it.

[00:01:25] And that's, that's how I feel about it. Like, I would not say that I'm an expert in it. I still feel very shaky.

[00:01:34] **Aurooba Ahmed:** Fair enough. For the record, I wouldn't say that I'm an expert either. But I also wouldn't say that I feel shaky in it. So. I guess it kind of makes sense that I'm leading this.

[00:01:45] **Brian Coords:** There's an unrelated article somebody just posted somebody that's deep in react and was like. I've been react forever and I've now it's confusing me. You know, it's what I'm talking about. We'll put that in the show notes. Cause I didn't get to like understand the full context of what the post was talking about, but it was very intriguing.

[00:02:02] **Aurooba Ahmed:** Yes, it was really great. I saw it come through in the weekend. We'll definitely pop that in the show notes as an interesting thing that we can like a look at.

## [00:02:09] The Decisions You have to make in Next.js projects

[00:02:10] **Brian Coords:** So what do you have on tap for us today? What, why is this 1.5? Why are we not just writing code?.

[00:02:17] **Aurooba Ahmed:** Yes, so it's 1.5 because unlike a lot of other things that we've explored. The last series that we did was Laravel. A lot of things in the world of JavaScript are decoupled. Everything, a lot of it is decoupled. It makes sense that the world of headless, for example, is also in JavaScript and is also decoupled.

[00:02:39] And when you choose to create something in JavaScript, you have a lot of other design decisions that you have to make, especially when it's an application and not just a static site. Which, in other frameworks, you often don't need to because there's already sort of a built in decision you can go with.

[00:02:55] You could change it but there is a built in decision already made. With JavaScript and Next.js that's not the case. So we need to make a couple, a few maybe, a few decisions first and foremost that's going to affect and cascade into all the other tiny little decisions that will happen throughout our application.

[00:03:14] And Of them. I would say the two biggest decisions are how are you gonna style things and how are you going to store things? There are two other decisions we can make, but one of them is really a simple decision that most of us already have some sort of opinion on. How do you on, which is how do you communicate?

[00:03:34] And the other one is how do you authenticate, which is often rolled into how do you store things and we'll get into why. Do you have a preference on which order we go in?

[00:03:44] **Brian Coords:** How do you, let me get my head around this. How do you style things? Cause I think we did, we said no to tailwind on our

[00:03:50] **Aurooba Ahmed:** Yes,

[00:03:51] **Brian Coords:** just the, that's just a framework. Like that's not even, you know, like there's so much deep, deeper into that. Where are we going to store, you know, database, where are we gonna put our users, how are we gonna handle user authentication and then how will we communicate, you mean, like, how are we going to send password, reset emails, alerts, notifications, all that sort of stuff.

[00:04:10] **Aurooba Ahmed:** Yes.

## [00:04:11] How should we style things?

[00:04:11] **Brian Coords:** Oh, you know what, it's a slow morning. Let's start with CSS and work our way from there.

[00:04:17] **Aurooba Ahmed:** That's your slow morning?

[00:04:19] **Brian Coords:** I think, I think it's a little slower than how do you authenticate users? Yeah. think, uh, I think, I think I'll take display:flex over, uh, user authentication right now.

[00:04:31] **Aurooba Ahmed:** That's funny. So, yes. So, in terms of styling, in the world of JavaScript, there's something called CSS-in-JS, which everyone has a lot of strong opinions about. And also, it's If you're new to it, it's a little hard to wrap your head around because why would you want to do CSS in JS, you know? CSS is its own language, it's fully fleshed out, it has its own stuff.

[00:04:54] Why would you want, what advantage is there to CSS in JS? So if you were hearing about this, what would be the first thing you kind of start thinking about?

[00:05:04] **Brian Coords:** Well, I'd have to. put aside my WordPress focus that I've been in on my day to day, which is like CSS in JSON, which is like driving me crazy is unrelated, but like my mind went there immediately. Um, don't know what it is about us wanting to put CSS, not just, can we just all write CSS? Like, is something wrong with CSS?

[00:05:23] Why, you know, the class utility libraries, the CSS-in-JS. Yeah, I, what is it with JavaScript where everything is like an argument, you know what I mean? Like TypeScript's an argument. This is an argument. It's like all of that, but, but no, to go back to what you were saying, like in the previous episode, I used to really struggle with a lot of let's stuff, everything inside of JavaScript, um, JSX, that kind of like HTML stuffed in JavaScript and stuff.

[00:05:48] But, um, you know, at the end of the day, I, I kind of like it. And I actually, I, my favorite is Vue. And it's like little vue files where you have like a style area and a script area and a, you know, an HTML and it's all these nice little component files and stuff like that. Um, what are you doing? What are you, what are you thinking?

[00:06:08] Are you going to put your CSS in JS or are you going to just have like a nice little side build process or, or CSS modules or what are you, what are you feeling? Mm

[00:06:15] **Aurooba Ahmed:** So, I think. In the world of JavaScript, like you just brought up with Vue as well, and in React as well, there's this idea of co location, which is pretty popular, where you put everything related to a particular component together, and that's how you get, you know, your CSS and JavaScript and any other HTML all in one file.

[00:06:35] So you can read one file and say, Okay, this is what it's styled with, this is what it's doing, and this is what it's gonna, you know, semantically look like. And I think, like you said, I think it's really nice to be able to consider something instead of having to jump in between different files to do that.

## [00:06:50] CSS-in-JS

[00:06:50] **Aurooba Ahmed:** And I think that was one of the first things that started the evolution of CSS-in-JS. And the other thing is you get a lot of interesting power with CSS in JS, because now you can take properties in JavaScript and you can use them in your CSS to compute it or to do stuff to it. In WordPress, when we want to do something like that, we often inject a style attribute with like a variable or a property or something in our PHP, right?

[00:07:19] And, What if you didn't have to do that because your styles already had access to your PHP properties?

[00:07:27] **Brian Coords:** Okay. If you've ever written, like, a little, like, PHP, like, CSS walker in WordPress where you take, like, your ACF things and you make it generate a bunch of CSS on the page and stuff, that sounds really appealing.

[00:07:42] **Aurooba Ahmed:** Yes, exactly. So That's the other advantage of CSS-in-JS.

[00:07:48] **Brian Coords:** What would you need that for in this context? Like, when in this application that we're imagining, are we ever going to really need to, like, You know, because like when we do it in WordPress, it's because we have a place where users are adding and modifying content and modifying design and they're picking a color and we need that color on the front end.

[00:08:09] But like, why would I need that?

[00:08:12] **Aurooba Ahmed:** Well, One, you might have an application where people can make edits as users, but let's say in this application, users can't make any kind of content edits at all, right? Then why would you need it? In React, specifically, state for inputs is managed. Most often, which means it's managed by react and it's the it's typical HTML APIs and web APIs are not exposed. So if you wanted to affect change of some kind in your style based on a state change It's easier to connect it to the JavaScript state rather than to say.

[00:08:50] Oh, this is checked, you know, that's Sometimes feels a little bit more natural in the world of React. I'm not necessarily saying that's always the right thing to do, but it is a common sort of situation that you can encounter. The other thing is, you know, let's say you have different things showing up on different screen sizes.

[00:09:10] Uh, you can connect that. You can connect that logic in your CSS as well, rather than rely on yet another logic around screen sizes, particularly in another place. So your screen size management might be happening in your component on the logic and business logic side of it. And you can use that to affect the CSS, rather than also replicate that logic in your CSS.

## [00:09:35] The problem with CSS-in-JS

[00:09:35] **Brian:** Okay. So then what's the problem with it?

[00:09:37] **Aurooba Ahmed:** The problem is the first few CSS in JS libraries that came out had a runtime, which means they're dynamically inserting and calculating and figuring all of this out on the client side, which makes things slower, which makes it harder And it just, it balloons the size of your final compiled application and how fast it can be and that is not great.

[00:10:04] **Brian:** Yeah. I definitely don't like that idea. Yeah.

[00:10:07] **Aurooba Ahmed:** Yes, but that's how it was first done. And not only is it that it's not a great idea. It makes it really difficult to follow the ethos of CSS, the cascade. A lot of the times the cascade is something people don't like, right? People want very isolated components that are not affected by anything else, and that's cool.

[00:10:28] But there are still other things of CSS, other parts of Cascade you want to take advantage of, and it's difficult to do that with CSS-in-JS that's happening at runtime. So How do we get the advantages of having our business logic in one place that can affect both the function and the style? How do we co locate everything to make it easier to understand?

[00:10:53] How do we also take advantage of CSS magic and power and properties that we want to take advantage of? And how do we still maintain good performance? That seems more complicated than you first realize, right?

[00:11:08] **Brian:** Yeah. It makes me really, uh, miss the, the decisions, not options, like mindset of WordPress where, you know, like, I think we've just talked about this a lot. There's just so many decisions that you have to make. Um, and it's very scary because what if you make the wrong decision? You really don't want to like refactor everything after the, after the fact.

[00:11:26] So all right. So what are you, so what are we, what are we doing? What's our strategy?

## [00:11:31] Styling Approach Options

[00:11:31] **Aurooba Ahmed:** So, there's two options that I want to share and one is an option that does have a runtime, kind of, and one that doesn't have a runtime. The first option is you can use just SASS modules, SCSS modules. They're not going to be colocated, right? It's there, it's just using SASS. It's using, you can include the compiling of SASS and it happens during the build time and put that in Webpack and just go, go like that.

[00:12:00] **Brian:** So you

[00:12:00] **Aurooba Ahmed:** But now you don't have the advantages of JavaScript?

[00:12:03] **Brian:** You're just loading a full style sheet. Like one style sheet?

[00:12:06] **Aurooba Ahmed:** No, you can have stylesheets that are connected just to that component, and then you insert that into the component. So it only gets loaded. Just the way blocks and WordPress do it, you know? Um, yeah. So you can do that with SASS modules. You can also go the way of, yes, you have little partials, and then they get loaded into one ginormous, uh, stylesheet.

[00:12:25] **Brian:** An old school CSS style sheet. If you really wanted to, you could.

[00:12:28] **Aurooba Ahmed:** exactly. You totally could do it. The advantage, of course, of modules is the performance benefits is only, only loading the CSS that you need, right? So you could do that. If you wanted something that is like that but doesn't have a runtime at all but still gives you the advantages of CSS, there are a bunch of no runtime or almost zero runtime libraries that exist in the JavaScript world.

[00:12:53] The two The three most popular ones are Stitches, Vanilla Extract, and Compiled. Uh, all very fascinating and weird names, uh, that you can use. And I'm gonna share my screen and we're gonna look at, uh, Vanilla Extract, because that's one that I've been working with quite a bit recently. Okay, so this is Zero Runtime Style Sheets in TypeScript, and it gives you the advantage of being able to use JavaScript information, variables, and states in your CSS, but it's close to the kind of CSS you might be used to using. For example, everything is CamelCase, so it's like background color with a capital C instead of background hyphen color, so it feels JavaScripty, but you write all of your styles in a separate file, so it's still not colocated, but it's a separate file, and then you can insert it into, let's see, where is it going to show?. Okay, so you can have your styles and then you insert them into the JSX by just adding the class Inside the class name area and it will just create the correct class That'll be dynamic won't conflict with any other classes when it's built

[00:14:11] **Brian:** I feel like every time we get into a project like this, I always, half of me really likes having these really colocated CSS fIles and then the other half of me is like, well, what happens when I want, like some utilities, what happens when I want some really repeatable things?

[00:14:27] I mean, I got to put a new checkbox or do I need to import those, you know, or do I have to make that a component? Do I have to make every little thing a component? Like there's, I feel like there's like these pros and cons to where sometimes you're like, I just want to pull things in from an overall library and not write.

[00:14:42] You know, every little scoped thing. Does that make sense?

[00:14:46] **Aurooba Ahmed:** Totally and a lot of people who use Components and libraries like this, they will often pull in parts of a different library, or you can actually use Tailwind along with Vanilla Extract if you wanted, or people in larger teams, for example, who might use something like this will come up with their own utilities, utility libraries that they refer to.

[00:15:08] The really nice thing about Vanilla Extract is that it has a theme contract as a feature in it. So think like theme.json in WordPress and you can actually build out an entire contract of here what the spacings should be in here, what the colors are here are the, you know, typography and all of this. And then you can pull that in super easily into any vanilla extract file.

[00:15:29] So I really enjoyed this as a concept. It has cons. Don't get me wrong, it has cons and it doesn't always follow the CSS cascade the way I want but a lot of the features that it has bring it, bring a really good balance between JavaScript and its advantages and CSS-in-JS and also the advantages that CSS in general has that you don't want to lose.

[00:15:54] So I really appreciate that about this particular library.

[00:15:58] The other one that we have is Stylex, which is very brand new, and it's from Meta, so the creators of React, essentially. And this one is also, it tries to not have too much of a runtime, but it is a different paradigm and more closely closer to how traditional CSS-in-JS works. So if people, for the people who come from wanting to be very, very much closer to JS rather than to CSS, they would like this better.

[00:16:25] But it is brand new, so I haven't had a chance to try it out. So those are the decisions when it comes to styling.

[00:16:31] **Brian:** Okay. I, my brain is just thinking about our dependency like tree as it grows. When you, when we first started and you were like, here's our package. json, there's nothing in it. And now it's like, here's three CSS libraries I've never heard of. So let's. Start throwing those in. I hope they're still around.

[00:16:49] Like my default would be to trust the Facebook. I can't believe I'm saying this, but to trust Facebook because they actually have been really good about open source and maintaining for the most part, you know, like they're, they're pretty decent in that area versus some package. That's just like everybody really likes it this month and who knows where it's going to be in six months. Um, it's very interesting. So, um, okay. So where did you go?

[00:17:17] **Aurooba Ahmed:** Uh, I, we're going to choose vanilla extract because I think it chooses the best in both worlds. We get to use CSS-in-JS and we also get to use some of the power of CSS itself and some of its cascade powers. It's not the best ever solution, but I think that this JavaScript power and being able to use that in the application is worth the cost of not having the access to the entire cascade.

[00:17:46] **Brian:** Okay.

[00:17:47] **Aurooba Ahmed:** Yeah, so we'll look at how that plays out specifically, for sure,

[00:17:50] **Brian:** Yeah, and I will have in my mind, like, also just like, what if we went to Tailwind and see, you know, which also gives you like a JSON file to configure it and, uh, you know, some stuff like that. It'll be interesting to see, because I think the other part about a lot of this stuff is they're all so similar, but the part that's hard is like, knowing the language, like basically just getting familiar with it.

[00:18:12] Like that's where I was always struggling with Laravel. I was like, I know I can do this thing. I just got to go dig through documentation because we called it this here. Now we call it this here. And I think. You know, that's sort of the benefit of things becoming very widespread, um, is that you're just onboarded into it already and it's, there's just low, low overhead to find the name of the thing that you want to use.

[00:18:33] So it'll be interesting to see, um, you know, how that affects everything. If you're, you know, having a little more freedom to start naming things and stuff. Uh, I think half of the reason these frameworks exist is because we all hate naming things and you just let somebody else name everything for you.

[00:18:50] **Aurooba Ahmed:** Yes, I agree with that. Obviously, I have feelings about it that we can get into a little bit more, and we've talked about it before on the podcast as well, but I generally don't like to lean on frameworks for styling. Mm hmm.

[00:19:03] **Brian:** Mm hmm.

[00:19:04] **Aurooba Ahmed:** The next thing we need to talk about, though, is the other big thing. But it's, you know, I think CSS is really the biggest thing.

[00:19:10] That's the most contentious issue always. All other issues are not particularly very contentious.

## [00:19:15] How will we store data?

[00:19:15] **Aurooba Ahmed:** We need to talk about how we want to store things. And that means we're talking about databases. Now what's the first database that comes to your mind?

[00:19:22] **Brian:** It's everybody's favorite that no one ever complains about. Everyone loves it. It's a, just puts smiles on everyone's heart and that's Firebase. Of course. I mean, everyone loves Firebase, right? Everyone just dreams of playing with Firebase.

## [00:19:35] Say no to Firebase

[00:19:35] **Aurooba Ahmed:** Yes. Firebase is the one that a lot of people can think of, especially when you think about the world of JavaScript. Wes Bos uses it in his React course, you know, so everyone's kind of familiar with it, but it's a proprietary solution from Google that is not open source. And it's poorly, very poorly documented.

[00:19:56] **Brian:** And let's be honest, as nice as Facebook is about open source. And I think that's just the benefit of open source is like things just are just more taken care of because the community gets involved and invested in stuff. And obviously like that's helped a lot for react. Um, is that kind of community open source nature?

[00:20:14] And then there's Google who like, let's be honest, like. Will they shut down Firebase in like two years? You have no idea. They definitely could. And it would not surprise anybody. It's honestly a surprise that it's still around. Um, because Google is the opposite and you just can't trust them with anything.

[00:20:30] Like I just, I wouldn't except for Google maps because they make a lot of money on it, but other than that, I don't trust them on any other API APIs.

[00:20:37] **Aurooba Ahmed:** Yeah, I think I'm there with you. We used it in a project and it Firebase has some really random limitations or just random things that are hard to figure out when it works. It's amazing, but when it doesn't work, it's, you don't know how to debug it, it's really hard to just handle and it's very frustrating.

## [00:20:56] Choosing Supabase

[00:20:56] **Aurooba Ahmed:** So I will probably just never vote for Firebase like ever again. And I have now learned in my own frustrations that a lot of people share those feelings. And that's why This other project came about called Supabase and Supabase is open source and it's prettier. Look at how pretty this page is. I know it's dark mode, but it's pretty.

[00:21:18] **Brian:** Yeah. There's no gradient though, right? I, I'm not seeing a gradient, uh, is so it's open source. Is it the kind of traditional, like we have a hosted version and you can self host.

[00:21:30] **Aurooba Ahmed:** Yes. You can self host and it's actually very easy to self host and you can just use their hosted version as well. It has a fantastic API. It has a lot of the features that you might be looking for and. Firebase does not have, it's not, it's a document structure, so it's not actually a proper database.

[00:21:49] It's not Postgres or SQL or anything like that. It's a node based structure where you just have keys and values and then more keys and values inside it. Supabase is Postgres. And I honestly think that no matter how simple or non simple your structure is, just go with like a table based thing, like Postgres or MySQL, because in case you ever have a more complicated structure, you're already far more, far better off already, you know?

[00:22:17] **Brian:** Yeah. I, I found that the, the Firebase, like key value, key value, like sounded really amazing in theory. And then it always felt like, and maybe it's just because of the WordPress background where I was just like, give me some, give me a spreadsheet, give me columns and rows. Like, that's all I want. Um. Yeah, so I, I, having worked with both, I would fully say like, unless there's some real strong reason you need Firebase, uh, Supabase is just going to feel like comforting to you.

[00:22:48] Cause you're just going to like, be like, okay, a database. Thank you.

[00:22:52] **Aurooba Ahmed:** Exactly. And it's, it's just really nice, you know, it looks like a regular database, you know, do you have your tables and your columns and you can and has a fantastic JavaScript API as well. It has real time. So you can communicate and create like even chat based applications with it. It has built an authentication because in a lot of cases you want to pair your authentication with your storage solution.

[00:23:16] I just love how easy it is to get set up and how easy it is to migrate and change things. I felt like adding Supabase gives you the same kind of like nice database ease that Laravel had with its Eloquent model a little bit.

[00:23:34] **Brian:** So can you do, cause I guess one of the things that people really like about Firebase is like, you can subscribe to a piece of data, like you said, that real time, can you get that same effect? Because that is a little different than like what, you know, Laravel or WordPress is going to do where it's just that kind of like, you know, PHP, like hit the database, render some stuff.

[00:23:54] So you can do that sort of like subscription kind of model. Okay.

[00:23:58] **Aurooba Ahmed:** Yes, you can listen to data changes over WebSockets and that's where you, if you need that kind of information and features, it's easier to use their hosted version because it's all taken care of for you and you don't have to figure out WebSockets yourself or integrate with a different API in order to create WebSockets, which is a pretty common situation as well.

[00:24:19] It has real time. It works beautifully. It's easy to code. That's it. When I first used Supabase, it took me less than an hour to get up and running and to refactor all of my Firebase code into Supabase. It was magical.

## [00:24:35] How will we authenticate users?

[00:24:35] **Brian:** And so one of the things you mentioned, which could be a separate topic, could be the same topic is like, we need to store our users and we need to handle user authentication, like people need to log in, log out. Um, it seems like it makes sense to me to use Supabase for both of those. It seems like they have like extra features specifically for that user management piece.

[00:24:56] Um, would. Would there be a reason you would separate that or, or some sort of like feature that's different that you would want or, or

[00:25:05] **Aurooba Ahmed:** I think if I'm using Supabase, I just want to use their authentication because it has the ability to authenticate with other like social media platforms as well as well as set passwords or just have that, you know, email me a one time password sort of situation and it takes advantage of Postgres inbuilt row level security system, which means that if you have a user and you want to give them access to very particular pieces of information, you can build that security right into the, that security already exists in the database and you just have to set the policies for it.

[00:25:38] So it's very secure. It's time tested, it's battle tested and you don't have to worry about your security as much, you know, especially when you have a bunch of different users. The only time I wouldn't use it is if you need to integrate with SSO, so single sign on situations with, that are on an enterprise level.

[00:25:56] **Brian:** Okay. So when it comes to taking Supabase and an Next.js application, I'm guessing there is, you know, cause in the, in the Laravel world, it was really nice to say like. Laravel provides you with the like wrapper for this tool. Like if you want to integrate this, like you kind of start at Laravel and they're like, yeah, we have a tool to integrate that.

[00:26:18] We have a tool to integrate that service, whatever. So as far as connecting Supabase to Next.js, do we feel like we're going to have to do a lot of work or is it kind of ready to go?

[00:26:29] **Aurooba Ahmed:** It has a library, a JavaScript library of its own, and it's very easy to use, so you don't need a Next.js specific tool for it. That being said, whenever it comes to databases, you always have the option of working with it natively, using its own SDKs, or using an ORM, sort of an abstracted language that you use to communicate between your application and your database.

[00:26:53] If you saw yourself wanting to maybe situa If you wanted to give yourself more flexibility, you could use an ORM like say Prisma, in order to create that abstraction in case you ever want to switch out Supabase for something else. But if you know that you're pretty set on Supabase, or you're you're, you know, self-hosting it yourself, then you can just use your SDK, which is, it's so stupidly easy that as long as you know, some JavaScript you can get going and their documentation is fantastic, so you can get going like really, really fast.

[00:27:22] And that's the way we're going to go. We're just going to integrate straight with Supabase because why add complications where you don't need to? It's already complicated with all the decisions we have to make

[00:27:32] **Brian:** And I'm a fan of learning, like by digging into other people's code. So I'm guessing there's probably a really good, uh, like sample repo that they have, where you can see. Okay, nice.

[00:27:43] **Aurooba Ahmed:** there's a lot of different boilerplates and also code with Jason. He has a lot of applications and tutorials that he's done with Supabase as well. It has a really good, well supported community. So there's just a lot of examples out there and a lot of help that you can get as well, which I really also appreciate.

[00:28:00] So those are the major decisions we have to make.

## [00:28:05] Choosing an Email service

[00:28:05] **Brian:** It's like, it's kind of a lot, Well, are we going to get into our third one, um, even briefly the kind of communication piece, because this is one where in like WordPress, for example, so the third piece is, okay, we have all this stuff, but we need to like communicate with users. We need to send emails.

[00:28:26] We need to send SMS, whatever you want to do, however you want to notifications. Um, there's different options there, but let's just assume it's email. Like this was a thing that was built into WordPress. And for some reason, in my mind, in the last like five to 10 years has gotten really unreliable because I think WordPress went from like, and we'll just let the server, like send off some emails and it'll mostly work.

[00:28:48] And it's fine to like. Most managed hosts are just not really wanting that to happen anymore. And if you're spinning up your own WordPress on AWS, there is no email server at all, so you really have to integrate it. It's one of those pieces that felt like it used to be easier, but now is a thing that I think everybody who's doing any sort of complicated site, whether it's WordPress, Laravel, Next, whatever, you have to start thinking about, okay, I need a third party tool to handle email.

[00:29:15] Because, you know, email servers with spam and with everything are just way more strict than it used to be in the past. Does that, do you agree with that or?

[00:29:26] **Aurooba Ahmed:** I agree with that 1000%. I think email has become more vital in our ecosystem and has become more complicated while also randomly using, like, 90s HTML in it. It's a really weird combination. Emails are so weird. And letting someone who exclusively deals with email as a service is, I think, a really good call.

[00:29:51] Especially with how complicated it's gotten. So I feel like that's something now we all kind of deal with, like you said, right? So to me, this is a fairly easy decision. You probably, if you're a developer of some kind, you probably have an email service that you kind of lean towards. For example, for me, that's Mailgun.

[00:30:07] So I just, I don't even worry about others. I go straight to Mailgun. I know how to use it. The API is fantastic. I'll integrate it. We'll all be good to go.

[00:30:16] **Brian:** Yeah, it's, I think what's also hard about it too, is that it's one of those things that like requires DNS. So like you can do so much of your work building, especially if you're like developing for a project or something. You can kind of do all of that. But the minute you bring an email, it's like, well, now I need like DNS records because like, that's, that's going to change everything.

[00:30:36] So now I need a real domain. Now I need all, you know, it's like, it just like levels up the thing. And then like, I find that it becomes one of those things you kind of ignore until you totally get to the end of the project and you want to have to deal with all that sort of stuff. You're like, oh, okay, fine.

[00:30:48] All right. Set up some DNS records, get the email delivering all that sort of stuff. Um, cause I'm just using on my local environment, I'm choosing mailhog or whatever. Um, yeah, we'll.

## [00:30:58] Staging environments are becoming more important

[00:30:58] **Aurooba Ahmed:** That's when a staging environment becomes so much more useful, and I really appreciate how a lot more servers and hosting services offer staging environments because they're just, they're becoming a lot more critical, you know?

[00:31:10] **Brian:** Well, yeah, I mean, I think we're kind of at a point now, like if you're making things, you're making complicated things because the simple things to make on the internet, like, don't, you know, anybody can make that, you know? So it's, it's, it's getting a little more complicated, but I'm excited to see how all of these pieces are going to like work together, how we're going to, you know, I'm excited to see where our package.json file goes, like how much longer it's going to get once we start including SDKs and stuff. Uh, it's going to be interesting.

## [00:31:41] What's next?

[00:31:41] **Aurooba Ahmed:** So I think in our next episode, we'll look at two things. We'll look at integrating Supabase as our database of choice and its authentication to create a nice login screen and then build out the scaffold of a theme contract in Vanilla Extract for how we're going to do our styling in general. But then we won't go dig into too much of it, but we'll look at how you would set that up if you don't want to use a framework like Tailwind.

[00:32:09] **Brian:** Yeah, I'm looking forward to it and I'm looking forward to, uh, getting my mind blown with just JavaScript, TypeScript coming at me high.

[00:32:17] **Aurooba Ahmed:** Yes.

[00:32:19] **Brian:** looking

[00:32:19] **Aurooba Ahmed:** I think that, I think it'll be fun. Yeah. See you then.

[00:32:22] **Brian:** to you then.

[00:32:23] **Aurooba Ahmed:** Visit viewSource.fm for the show notes and if you're enjoying the show, we would love a review on iTunes or a comment on YouTube.

[00:32:33]