How to Build a Website or App

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talensky and Wes Boss.

Welcome to Syntax. We got one today for you. How to build a website or an app? We got a really good question From someone. I'll just read it real quick because it gives you kind of an idea of what we're talking about is, hi, guys. Love the show. A question for both of you. What is your actual workflow When developing application, for example, say you're building a list of podcast episodes for a podcast website. Hypothetically, something we've done.

Rid. What are the low level steps you follow? Do you use a design, Figma, pen and paper, something else? Do you wire up the API and first output rid the data or do you use mock dummy data and then wire it up later? Do you work in components in isolation or do you build them in place? I'm keen to hear about the effective work workflows.

So I thought this was awesome. This is the entire show.

Just how do you build a website, right? There's there's so many different moving parts to it. And not only like what do you use, but like, what's your approach? How do you even think about choosing these types of things? So that's what we're going to be talking about today.

With me as always is mister Scott Talinski. How are you doing today, Scott? Hey. I'm doing super good. Hanging out here. It is

Snowing like crazy. We got, like, a foot of snow just out of nowhere.

Yeah. Just That's just shocking to me. Because you like, ready. Your Instagram story is always hilarious. It's like you're sitting in your backyard watching a movie, and then, like, a day later, you've got a foot of snow. We

We had a party, like, last Sunday outside.

I was wearing shorts all evening, shorts at at night, 9 o'clock. So it was, like, Warm enough that you could be just, you know, chilling in shorts, and then a week later, you get dumped on by snow. Of course, rid A couple days right before Halloween, so that means I gotta go trick or treating tonight with

What the Oh, yeah. It is, like,

So cold out, Wes. I'm gonna be Snow gas. Bundled up. It's like the absolute worst. And beside the only way it could get worse for trick or treating is if it was raining right now, but, rid You know, the kids are gonna go nuts, so it doesn't matter. Oh, man. So speaking of building the website, when When you do build your website, you're going to goof it up. You're going to screw something up. You're going to

some sort of bug that you cannot figure out because rid. The user is using the website wrong. You never thought that that would ever possibly happen. And for that, you're going to need Sentry to help you figure out What's going on with that? We had one of the bugs on the new syntax website where I was looking at it and I thought, ready. I don't see how this would ever possibly happen. I don't see how anyone would ever get into the situation where they could click this button And they were not in the state that they were. And we used the century session replay and I was able to see exactly how they did. Also, I got to see them get frustrated and leave the website. So check it out, century. Io, Coupon code tasty treat 2 months for free.

Alright.

So how do you build a website, Scott? Yeah. You know what? For me,

I think this is gonna differ from person to person, and and I think that's an important distinction because we all come with our own I don't wanna say baggage, but our own background of where we learned, what we learned. Baggage.

How yeah. I got baggage. In fact, I need new baggage. I've been shopping for luggage. That's for sure.

Just about what what type of specific background we have.

And if you think about it, it all kind of starts with the very first visual side of things. You know? Some people would Wanna go into wireframing and and really understand the flow of a website before they get into it? Other people wanna get right into that code.

I'm a get right into the code kind of person mostly because I have ADHD, but also because I'm probably the most comfortable prototyping things out quickly in code and seeing it kinda form in a browser.

Other people are gonna go straight to a a tool that allows them to start to See things visually in a way like wireframing tools or, maybe even get right into design tools and skip the wireframing tools.

So, you know, It it all depends on what your background is, but also the best way that you can start to visualize something coming together. Right? Yeah. It's it's

Kind of funny because building a website, much like learning how to do websites, is not linear, meaning that it's not a set of nice, clean, crisp steps where you do one one thing next after another.

And the larger the team you're on, the more that actually does need to be linear. The more you actually need a system that is has rules and is a little bit more rigid so that you can do things a little bit more smoothly rather than sort of just bouncing around from thing to thing. So let's start with the design that you have there. So you can pick up a design tool rid. Or you can just start winging it. Like Scott says, you can start winging it right away in CSS.

I tend myself.

I tend to fiddle around in Figma, to get a sort of look and feel for for all my websites. So I'll get in there. I'll get the color scheme down. I'll get sort of the layout down.

I'll build like the the major things like headings, Text, buttons, cards, all of like kind of those look because I feel like it's a bit faster to do that in a Figma tool to play around with things.

And then once I'm like pretty happy, like If you were to look at any of the designs that I've done for any of my websites, they're nowhere near a polished website layout or a bunch of nice clean components.

Ready. It's just kind of like a alright. I I think I can see what I'm doing there. I do the same thing with recipes when I'm cooking. I'll read 3 or 4 recipes, and then I just go, Alright. I get it. You know? I get it. And I'm just gonna go wing it. And for a lot of people, they don't like that because they'd rather just follow every single step and do it linearly. But I can just kinda rid. Say, alright, I kind of feel like I know what I'm doing here. It'll probably deviate once I get into the code, but at least I'm on the right track, and I have Something that I can work towards because when you're trying to make it look good and fuss with the code, it's a little bit frustrating because then you got 2 things rid paddling against you.

Yeah. And and we kinda touched on this in the episode about the new syntax website itself, but I personally can get right into Building a design system out and then letting the design kind of come together that way. So instead of rid. Designing and then going from design to website. I'm like, I'm working on the system. I'm working on Grabbing a font scale, grabbing some colors, grabbing some palettes, and then just tossing things out. And I think that does limit Limit my designs in a very specific way because you don't necessarily get that playfulness that you can get with Figma, Moving things around, dragging things around, getting that kind of quick feedback loop. You're more or less working on the structure.

And If you were to I'm sure I have some screenshots of this somewhere. But, like, if you were to look at some of the first versions of the syntax site, it is apparent that it is like a system based design and not a, like, creative based design. And I I think that is definitely limiting, which is one of the reasons why I like working with designers so much. But if you can't work with designers, it's kind of about knowing your limitations. Right? You kinda have to know where you're at in that scheme. Okay? I'm building a website.

What is my level of design background? Am I comfortable with design? Alright. If you answer, not at all. I'm not comfortable with design.

You wanna get the most turnkey already predesigned for you thing out there and then just make it look nice.

Designed by engineers is not cute.

That's, like, an aesthetic that, like yeah. I swear. I was on Hacker News the other day, and there was, like, an open source YouTube alternative.

And everybody's like, oh, well, this is so needed, and you click on it, and it looked like dog. Beep. It looked awful.

And I I I just got mad. I was like, you know, They coulda used a design system or premade anything, and it woulda looked a lot better. And they're like, why don't you fork it and do it yourself? It's like, Okay. Well, I'm just you know, that's positive feedback right there.

I think if you if your design if you're an engineer straight up and you don't know design, Always just use a fully it's fully designed premade thing that you can and then elaborate from there. If you are a little bit comfortable, Take that next step. Use something like Tailwind or Open Props, something that gives you more handholding in the Aspects of things to build out a more standardized system.

If you're very comfortable with design, yeah, go just straight up CSS to the dome. You know? Don't add anything else in there and and go nuts with it. Maybe use some post CSS or some helper libraries here or there or whatever.

Rid Me, personally, it it all just depends on on what level of comfort you have in being able to make things look nice yourself. Here. I was just I was Gonna shout out the Brad Frost episode on design systems. So syntax. Fm/682.

Man, I love being able to give out those URLs rid To people? The short ones? Yeah. Yeah. It's it's so nice because you can just say, go to syntax.fmforward/ rid 682. You know, also, another thing, I never we never talked about this when we talked about the new website is if you listen on Spotify or iTunes, ready.

Is that on Itunes as well? No, it's not. It's just Spotify. This is it's a limitation of the thing. But If you often will shout out an episode, and you can go on Spotify and search that number. Like, you could go on on Spotify and search Syntax 682, and that episode will pop up. But now there is a button on the Syntax website for each episode, which will click you through to Spotify.

And there's some sauce we put in the URL that will hopefully in every single case, show you the episode we're talking about in Spotify because that's sometimes it disconnects. Okay, I see it on the website, but, like, I don't want to listen to it on the website. I want to listen to it at Spotify.

So we have that now. So check it out. Yeah, but can we go shorter, Wes?

Can we go shorter? Oh,

Scott just sent me a short domain name that's available.

I don't know, syntax. Fm/6/82.

That's that That's pretty easy to say.

We could. Yeah, I don't know.

That's pretty.

We're not going to say it because a couple of you listeners

Like to jack things once we mention them, so we can't say it. Yeah. I'm I'm sending I'm just sending some links here. It is it's pretty attractive looking. So, that's true. Rid Yeah.

I like it. Yeah. Okay. We'll we'll think about that one, folks. We'll we'll keep you we'll keep you on the loop if we decide to go with it. Yeah. Next Next thing we have here for choosing is like you need to choose what you're gonna build your front end in here. And maybe I should rid. Outline all of the major topics we're hitting on this episode. You have the design. You have your choosing your front end components. You have your data database, possibly CMS.

You have your back end languages, testing, hosting, deployment, and then whatever else we rid.

So let's talk about like choosing a front end, like are you going to template it out in something and Likely, yeah, yeah. Likely you're going to pick something that will aid you in templating out and turning it into HTML at the end of the day because There's very few people that are going to code up a header and then create a new HTML page, and then you have to copy paste the header onto the other one, right? Or maybe put some frames in there. That's what we did in the olden days where you have header HTML and you just have a frame set So you can use the same header on every single website.

We're not going to do that right, so you probably need some sort of way to template it out. And that might look like, either a server side templating language, like like Pug Or what what are the other ones that are really popular? Handlebars? What's the one that

EJS. Blade? Was one. What does Laravel use? Rid Laravel. Blade. Blade. Yep. Yeah. Do you remember EJS? Did you ever use that one? Yeah. I used that one. Yep. EJS was really popular. Ready for I think it was for Django. Right? Is that what it was used? I remember it being used in, like,

JavaScript NVC before Backbone got popular.

Yeah, yeah. There was this thing called JavaScript NVC that used that to template everything out, But you can also choose a front end framework. Probably most if you listen to this podcast due to the type of person that listens to podcast, you're going to reach for rid. Either like React or Svelte or a framework Remix, Next, SvelteKit, Any of the number other frameworks that are out there, and that is going to both aid you in doing all of your routing, handling your image assets, as well as Templating out, making reusable components so that you can use things like your header, your footer, your newsletter.

Subscribe throughout your entire application.

Yeah. And You can also just use straight up HTML. You know? I mean, HTML is a a language that's made for this type of thing. It's rid Scaffolding out things and whether or not that's being developed on the server side. Let I mean, let's take into account your most basic website. Your most basic website Could straight up just be 5 pages.

Those 5 pages have some information on them that's not going to change. You could be the type of person who says, oh, let me build that in one of these fancy front end frameworks and then spit it out to be a static site. Or you might be the person that says, hey. You know what? I'm just gonna keep it as simple as possible. Use no JavaScript unless I need it for anything. Maybe I'm building I mean, heck, you can build carousels now with CSS. So

You can remain as little JavaScript as possible as you want on this thing. I'll tell you where I'm at with my my course platform right now is so my course platform is Not the actual like, there's a couple parts to it.

The back end is is a a React application. It's all dynamic, and it's Server or client rendered and that's all like a fun React app. But the actual marketing websites, those are rid Vanilla JavaScript and HTML, right? Yeah. And I've been using for many, many years, I've been using Pug to template out those pages because It worked well. I can do things like loop over the videos and render out a list of videos. You can create reusable components I can share throughout all the marketing websites.

And like, I've sort of reached like the end of that being what I want to do for the next one.

And I probably eventually I would like to get the entire thing onto like a framework like Next. Js or SvelteKit or something like that. But it's not really something I want to do just yet. So like I'm kind of in this in between area. So what I did is I am building my next course website in React, But I'm just I'm just using React for the ability to be a template engine.

Meaning that, like like, I'm not using any of the, like, rid Client rendering or whatever. I'm simply just using it so I can write all of my components, and I can compile them in. And then I just use react rid dot render to string on the server HTML. Yeah. And then just spit out HTML because I don't I don't need any of the client side stuff, rid. But I also want to look a little future facing being like, well, I probably will write this in React at some point or write it in some component based framework.

So if I'm going to be doing a little bit of work on a new website, it's much easier to write it in JSX And do all the loops and everything that I'm used to.

And then that way, when it comes time to rewrite this thing, I won't have to change That one from Mhmm.

Hug into React. So it's I wrote a whole template, like Express has this idea of like a template engine. And I wrote my own template engine, which was a React template engine.

Hey. You know what? We did something very similar on level up Before we moved to SvelteKit, when I was moving from Meteor to without Meteor, step 1 rid is what I did is I had the server just straight up returning React render to string. Yep. And then I then took that and was in fact rehydrating it on the client.

But, you know, people look at these frameworks, and they say, I gotta use Next. Js. I gotta you could You could just return that react and then rehydrate it if you want. You can do all that yourself. It's not the most fun.

I think the rehydrating part is where it gets to be less fun. But if you like you're saying, I mean, you can take that code, pipe it through a function essentially, And get HTML out of there. And in fact, that's kind of what you're doing with server side rendering React. You just have a rehydrating step, and you can do it with re You can do it with Vue. You can do it with any of these things, and it works really well.

So definitely definitely an option there if you're the type of person who who doesn't need that client side stuff And you and you do like working in these componentized way. Or, hey. If you like working in componentized manners, you can just straight up use web components as well here.

Either way, we're getting into the weeds here. Basically Yeah. You just need a way of authoring your structure for your page, And you can largely choose to do that whether or not it is in a front end JavaScript framework, In an HTML, any sort of way whatsoever, you need a way to structure your HTML to get it on the page.

Now How do you build and test these components? Well, you could have couple options for building these components. You can just throw them on a page And have them in context, and this works well if you're trying to move fast. Right? I'm maybe already hitting a database. I have the data ready to go, or perhaps it is fake data, or perhaps it is temporary data that is real but not final.

Either way, you're working on these components in context of where of which they will live on the website. I'm designing a header. Hey. It's gonna go in the header of the website, And I'm gonna see it in action.

There's another way of working on components, though, and that's in isolation.

And In isolation is something that you'd see in libraries like Storybook.

Storybook or history are the way that types rid way people do things. And in fact, another way that's kinda underlooked is something that I do sometimes.

I just put them in a div and make that div resizable, And then I can just see that div resizable. Now Storybook offers way more features in terms of, you know, interactively passing props and having all your knobs and widgets and and tests and stuff in there as well. But Mhmm. For the most part, the idea of building them in place versus in isolation means that in isolation, You can see a component, and you can test it in various different ways, different container sizes, different contexts, Making sure it works as long as the data gets passed into it correctly, you can really fine tune that component.

In my experience, Working in isolation works much better on long term big projects.

You're building out a big project. It has a lot of components, Has multiple people working on it. Docu you need to document those things.

You need to make sure that they work in various use cases.

Working in isolation makes a lot of sense. If you are working on a website and it's just a website you and your buddies or just you are gonna be working on, there's there's no need to add Storybook to that thing or rid. That type of flow, it's just gonna slow you down. Totally. I for the Syntax website, we have, like, a show card component.

Ready. And that's when you visit the Syntax website, there's like a big one for the latest episode and it's black. And then you have a grid of 2 by 5 or whatever of the latest show cards. And then when you go to the show's page, that's also the show card, right? Because they look a little bit different and they act a little bit different, But they are primarily the same card. So when I was working on those cards, it was nice to be able to have All of them on a single page and say, okay, well, I'm making a change to the card and I want to be I want to make sure that I'm not goofing it up or light or dark mode or these different situations where they might be right, like where it's really wide or really small, especially because we are using container queries.

So you're trying to size that big number. You want to make sure, oh, make sure it doesn't go too big and make sure it doesn't go too small. And There's a lot of tricky trickiness when you get into those components that can literally live anywhere.

And if that's the case, rid. Building them in isolation or at least just having a page where you dump every possible instance of them. Yes. So you can see them all at once, and you you're not, like, playing whack a mole where you change one thing and you go, oh, shoot. That that broke it on this instance.

Yeah. And and that's a whole thing. And people often feel like if I wanna test these things or look at them in isolation, I now have to bring in some other dependency or and that's the whole thing with Storybook. It it's its own process. Rid its own whole entire app that runs within your app. You don't gotta do that if you don't want to. We have 2 pages on the the syntax website that are live that you can see, and they're sloppy because we're they're just there for our own personal use, but we made this stuff public. Right? Forward slash syntax. Rid. F m forward slash components and forward slash theme are 2 kind of dumping grounds that I made to dump things in to test them. The the forward slash components is a page where I just can throw any single component in, and it will show it Narrow. It will show it wide. It will show it extra wide and then show it in a movable container that even outputs the width of the container so I can see and test directly. And this these are just, like, quick little things. I also have, like, an inverse section as well. And then the forward slash themes allows me to see a component in all the different read. Themes. So that way, if you wanna test something out and see how it adapts to different themes. Yeah. Yeah. I use this stuff all the time, but you don't need fancy tooling for this. You can just go ham with it. Yeah. Yeah, it's pretty

nifty. I also on the colors page, I need to fix this because it's slammed up against your colors. But I I wrote a component that pulled the computed variables off the Ishmael document. So like any variables you put on Root, I was having trouble trying to figure out what they actually were computed wise, you know, if you use calc or clamp or anything like that.

Rid so I wrote a little component that grabbed them all off of the HTML document and then just dumped them in here, and it was nice to be able to see it. It's kind of interesting. Some of them, when you use calc on a number, the value is computed.

But when you use calc rid. Like sometimes when you use Calcutta with a percentage, it's not all the way computed. I don't know what the like, where is the line where the browser Will give you the computed value of actually what it's implementing.

And where does it just give you the the actual calc? Rid sometimes sometimes you get 1, and sometimes you get another. I wonder if at property,

the, CSS re Typing per, like Houdini aspect of CSS came into play. I wonder if that changes things at all because that allows you to define a variable as a type. I wonder if that affects how it's calculated. We need better dev tools for CSS variables

because there's because it's a mess. Yeah, it's a mess. And like Chromes are slightly better. Like if you hover over a variable in Chrome, they will often tell you the computed value, whereas Firefox will often just show you what it points to. Like if we have primary pointing to yellow and yellow points to yellow 3, That's a lot of work to figure out what actually is it, though.

And I would love some better dev tools that would follow these values a little bit further

and show you where they were defined and what they're pointing to and how they're calculated. Yeah. Imagine you hover over 1, and it would show you, like, like, a tree or something. This connects to this, connects to this.

I don't know.

Come on. It's funny. Like, you see, the DevTools went all out on Flexbox and Grid DevTools, but CSS variables are kind of rid. Not a whole lot of data. Anyways, we're just complaining here. Let's keep talking about building stuff.

Real data or fake data is a really good question. I like to go with real data as much as possible.

Yes. If you have it available. Right.

And that's nice because you can use the actual data that's coming in. But sometimes, like, I even know Polypane has a feature for this is Sometimes you don't think about German last names or other things like that. So it can be useful to have some data that is outside of what you think. What happens when you have a really short title? What happens when you have extremely long last name that cannot break In between, all those little edge cases are helpful to hit as well. I also find with GitHub Copilot Or any of these AI things, they are very good at generating a bunch of random data, and that will often make your dev experience when you don't have the back end hooked up just yet. Much better because you don't have to like, I always use ready. Wes, Scott, and all of our dogs' names as examples, and, like, I'm sick of that. You know? Like, I want some other examples, but I I can't possibly think of other people's names.

Yeah. Yeah. I started going to kids and family members. Yeah. I you know, but If you have a data schema, that's a good point. If you even have your data schema or you have a general idea of your data schema or you can just even write, like, a, Like a really quick rough data schema, copy and paste that, send it into an AI tool, and say, hey. Give me a 100 of these things.

If you have that if you have that structure for it to output, it's pretty reliable in getting you something like that. If not, you can, do some work to get you some fake data really quickly. There's also tools like re Faker are some of these things that that get you data fast, but, you know, you don't need to install a dependency to get some fake data, especially if it's just temporary. But I a 100% agree. If you have rid. The ability to have real data, get that real data, or at least if it's temporary or short data, get that in there. Making a Fake data entirely only works if that fake data has variety.

A number one thing that you see with inexperienced designers rid is they'll give you a mock up, and they'll have, like, 9 cards or something. And all 9 cards will have the exact same title that are the same length. Right? They don't go on to 2 lines. None of them go on to 3 lines or whatever. They have no plan.

If you have if you have 2 lines of text, Their entire design goes out the window. They they they just don't have that experience. Right? So being able to set yourself up for success there will make That when you actually do use real data that you don't end up having an oopsie daisy. Now all of a sudden I have to deal with line height and it looks bad. What do I do? Ready. Yeah, when I was doing the,

Open Graph Cards, I was doing a little bit design to the sizing and What I did is I just had a browser open with 15 of them because, like, you need as many possible Podcast titles. Some of the podcast titles are like 400 characters and some of them are 8 characters.

So being able to account for all of those And also, sometimes designers will just, like, make up things like, they'll be like, it's a 6 minute read. Yeah. It's like, well, We don't have the infrastructure to do that. Look where you're getting this data. So don't design things around or or maybe do. Maybe force those lazy back end devs to actually give you that data. But sometimes people are just throwing in, thrown in. Like, for example, on some of our stuff, I wanted to list the number of words that were spoken in every single episode.

Ready. And we could do that because it would have to be done at a database level. But if it wasn't if those words were not queryable by the database and you had to like select them all and then loop over and count them, then

that would be a big pain in the ass. It would probably slow the site down more than it's rid. It's it's worth. Yeah. And that's funny because some designers might look at that and say, it's no big deal you have the words. Why don't you just count them? And they're like, well, let me tell you. Because the Way to do that efficiently would be involved having to write a database process that then we gotta update the schema. Yeah. Yeah. I'll send you're indexing things that you didn't index before. Yeah. Rid. Exactly.

Exactly.

So let's talk about that data. So now that we're talking about fake data or real data, let's talk about database, and your data. Now the big question is, do you need a content management system or not? Hey. A content management system essentially is there in place so rid that nontechnical folks can add and update content without having to get into markdown. Don't ask your nontechnical folks to make a GitHub account and publish markdown changes. Then they gotta learn what a PR is. No. That's not gonna work.

That's never gonna work. So if you have nontechnical folks who need to update your content, rid. You most likely either, 1, will need a CMS or, 2, you will need to be comfortable writing that back end piece. And that back end piece rid Has a lot of moving components to it. Now these types of things are made a lot easier if you're using a system like Django or Rails, these types of things that can scaffold out these pages for you, but Those are, like, kind of 1 step in between a fully custom and a CMS. Right? So if you need a CMS that's full featured, re Hey. That puts you in a very specific territory. Alright. Now I need a CMS. I gotta start thinking what types of things do I need out of my CMS and which CMS do I need? Or, likewise, if I feel comfortable making this all custom myself, which by all accounts, I've done it many times. It works fine if you if you wanna do it that way.

What type of database do you need? And, honestly, the database conversation is interesting. People get really, really passionate about which Databases they choose and which databases they like to work in. Do you even need a database? A database is great if you want to save data and retrieve data, update ready. Have that data be available later.

If you just have straight up static content on a website, you might not need a database at all. Let me tell you.

I will do things to avoid using a database because having a database instantly adds a massive amount of complexity to your app. So you have to consider that as well. Do I really need this database? Should be a question that you ask yourself. I find myself whenever I'm

rid. Just playing around with features like when I was doing the early work for the AI and transcript stuff, I was simply just saving JSON files to disk. And then I wrote a little function that just said.

Like, get or set or you could you could even if If I were to go one step further, I would probably reach for SQLite, SQLite, because that is a database that simply just sits as a text file in your folder. There's no like you don't have to run processes. There's no SQLite server.

It simply just sits. And a lot of the adapters that you might end up using Prisma SQLize.

What's the other one that everyone's talking about? Drizzle. Does Drizzle use SQLite? Rid. Let's see here.

Yep. Yeah. Drizzle does Aesculate, though I might even reach for that because Although you might not use SQLite or Esqulate, you might be able to make use of a ORM like Drizzle or Prisma or Sequelize.

And then you can switch to it without having to rewrite any queries. But honestly, ain't nothing wrong with rid Sticking stuff into

a text file Yeah. On your on your computer. Yeah. I know people often wanna go high-tech for their solutions. Right? Because It feels like, hey. That's how I'm supposed to do it.

But really, do you remember the the static file c CMS was a big thing for a little bit? Rid. Statamic was one of those. Bolt was another one. Do you remember the static file CMS, Wes? Yeah. That was a trend in CMSs for a little bit. Yeah. And

Basically, those would just write to file, right? Tina's U. S. Is similar to that.

It's more than that, but like you can edited via this nice UI and then it will save to like wherever your adapter says that GitHub would be a good example.

Re Hey. A great use case. Thinking of this in the same regard, Wes, I'm gonna ask you to go to this statamic website, which is a static file CMS that we used to use. And let me just look at this design aesthetic.

It is very syntax in a positive way. Oh,

Oh, yeah. This is, yeah, this is, Jack McDade.

He does a bunch of cool stuff, but, yeah, big fan of this design style. Yeah. Rid Yeah. It's, nice and Oh, I just clicked on the deer.

I clicked the deer on the statamic website. It just says, I promise if that tickle, I would not tell you.

Rid. I'll tell you.

Speaking of CMSs, we haven't talked about CMSs on the show in a while, Mostly because there are so many out there. We did a roundup about a year, year and a half ago.

But And I keep getting emails from literally every single person that works on a CMS.

Strapi, Tina, Payload, Sanity, Prismic, lots of open source ones, lots of paid ones.

If you, the listener, want more CMS content or if you want, like, a rundown or if you want us to have, like, 4 people from these different CMSs on rid. Talk about us. Let us know because I don't know if people are just exhausted by all the CMS's

choices out there or if they're hungry for more. Yeah. The the hard part about CMS is is just like, well, there's all these options, or there's just good old WordPress

that has everything you could possibly want. Exactly. Actually, well, maybe that's a bit of a next one is choosing a back end language or a framework.

Does your back end language and framework also dictate how you will do your front end? In some cases, the answer to that is yes. Like WordPress is a good example. If you are choosing WordPress as a CMS, of course, you can do headless WordPress. But If you're choosing WordPress, you probably want a lot of the plugins and the whole ecosystem that sort of goes along with WordPress, right? And if that's the case, then You sort of have a lot of these decisions already made for you, right? Like how do you make components? Well, you have PHP files that are on there. Like what database are you using? Oh, you're using MySQL. Are you using an ORM? Yeah, you're probably using WP query to pull that rid Sort of stuff out. What back end language are you using? PHP for sure. Mhmm. That's the only language that that runs in. I would go as far as saying

if you are back end experienced, you should probably pick your back end first.

And if you're front end experienced, you should probably pick your front end first, and then let That dick that let that choice dictate where you wanna go. Right? I I'm, like, React React guy. I wanna I wanna use React for this. No doubt. Okay. Well, then your best options are probably Remix, Astro, or Next. Js. Right? So from there, that kinda dictates what you're using.

And, likewise, If I'm, you know, if if I'm primarily a a PHP dev, well, then that is going to dictate, okay. Well, shoot. I guess I'm going to be using WordPress, and I can do so headlessly with JavaScript, or I can do so with WordPress's templating system, or I can do so with Laravel And go straight up Laravel.

And in my mind, I think that is, like, a good way to optimize working on this stuff is to pick The thing that you are most confident and comfortable in and work from there, whether that is a back end or a front end.

Likewise, I I use I like Svelte, so I pick SvelteKit.

Right? Would I would I have picked something else rid. If I wanted to work in Svelte, probably not. Right? It just makes sense to use the thing that's the easiest to use in that regard.

For options, rid Like I mentioned, if you wanna work in JavaScript, there's a lot of different options for back ends. You have, Next. Js, Remix, Astros, FELKIT, Nuxt. I'm sure there's many more. There's solid state, those types of things. PHP, WordPress, Laravel, Ruby. Rails seems like honestly the best option if you're, like, if you wanna work in Ruby and you don't wanna build your website in Rails, you're probably inexperienced Ruby. Right? Yeah.

Rid Python and, there's Flask and Django are, like, the 2 big ones there. Either way, most of the kind of tooling or framework system or back end systems rid. Have kind of, like, happy paths

for the way that you build a site with those paths. I I would say, like, it else if you're listening to this and you're, like, really not sure About any of this type of stuff, I would probably say your go to right now would be pick 1 of the big meta frameworks out there.

In React world, there's Next. Js or Remix.

In Svelte land, there's SvelteKit. In Vue land, there is Nuxt.

And, then you could also look into something like Astro, which is kind of you can use a a bunch of the different ones. I'm pretty bullish on Astro right now, folks. If you wanna

If you wanna go someplace that has a lot of simplicity and you can pick your own front end framework

hey. Astra's where it's at. It's pretty safe. Take a look at it. But basically these you'll hear this word thrown around a lot is a meta framework, and essentially what that means is you're taking your rid. Rendering library, React or Svelte or Vue.

But then you probably also need like a server, right? So they'll give you The ability to create serverless functions that will handle things like API requests and connecting to databases and returning data. A lot of those nice things, sending emails, things like that. And then you probably also want like a router. Right. And then maybe you want like a like an image resizing processor. So those don't generally come with meta frameworks, but there's there's 1 built into every like there's an adapter for all of these Different frameworks out there. So that's probably our go to, especially if you're a big fan of JavaScript. TypeScript is take one of those meta frameworks and run with it and then figure out what CMS do I want to tack onto this? How do I want to write my CSS and How how do I wanna design this type of thing? Word.

Yeah. Yeah. Once you've really kind of nailed down that, you could just pick your tools and start start going with it.

I think the next thing would be, like, you'd actually have some things down to to to code. Right? You you've worked on your rid. You have it working to some degree. You understand what you're using for bits and pieces of it. You you have at least something on the page, And maybe you wanna start testing it. Some people are like crazy about testing where they want to do test driven design. They wanna test each individual function at any given point. Re They wanna test every single unit of your site, and that's called unit testing. Right? You have any individual function. That function is getting tested.

Right? And for unit testing, each of these languages probably have their own happy path for testing.

Any kind of situation you're gonna find yourself in. You'll find people talking about what is the specific way of testing.

Now my Humble opinion is that unless you're you're working on big time stuff, you probably don't need Lot of unit tests unless you're working on a big, big time app because that can really get in the weeds. Again, you're having to get into rid Really language specific tooling for testing. And maybe you're very comfortable with that stuff, and that's fine. But if you're not, the easiest way if you want to test Anything is to use end to end testing libraries like Cypress or Playwright.

These 2 things are basically, They don't matter. It doesn't matter if you're writing your app in JavaScript, Django, Ruby on Rails, PHP, whatever. These things literally open up your site in a headless browser and then run JavaScript on that page to implement clicks and then test to make sure that things are where they should be, Meaning that they don't care how you built your app, and that to me is extremely valuable.

One time, I rewrote level up tutorials From React JS to Svelte and did not change a single end to end test.

I knew that when my end to end test passed, That I was good, but I didn't have to change my test. Could you, man? I changed Yeah. The language entirely.

So that's the one reason I don't love really, really tightly Scoped testing libraries within the web space. Now it makes sense in other spaces where you're not going to ever do that, and granted most people won't ever change rid Large aspects of your site.

But having something that uses it the same way a user does inside of a browser is extremely

handy. Yeah. It makes a lot of sense if you think about like your user clicking a button, playing a podcast.

With those types of things, you want to make sure that When somebody clicks on a show, they go to that page. When somebody clicks on a play button that the audio loads and when they push a show note time stamp, it skips to that value, right? And if those if if we were to literally change the entire tech stack, the end user probably doesn't care. No, that we change any of the tech stack, but that's why, like you said, testing for the actual features and that it actually works in the browser when it's all put together ready. Makes a lot of sense. There's actually one thing somebody asked on Twitter the other day is how would you test that? And I thought this was really interesting.

The Syntax website I implemented MediaSource, which was when you play a podcast on the Syntax website and then you lock What shows up on your lock screen is is defined. I didn't even know that this was an API.

But it shows up rid. And you can define the album art, the name of the podcast, what happens when somebody presses the skip 10 seconds buttons and back 10 seconds. Rid. You control over quite a bit of that. And I was somebody was asking, like, how do you test that, right? Like once you implement it and You can unit test it really easily, right? You can you can click on a play button and then you check for the metadata that has been set on the window. So I think it's like navigator.

Mediasources.

Metadata.

You can check if the object is what you're expecting, right? That's a unit test. But.

The integration test. How do you test the lock screen? End to end too.

Well, I'm I'm sorry. You couldn't test Specifically, if the lock screen had the information on it. But you could check that metadata because you have access to JavaScript. You're just To the DOM. Yeah. You could do that in end to end test, but you

I guess when things go outside of, I guess, same thing with like a webcam, you know, like when things go outside of the browser into the rid. The actual system that gets a little trickier. So Manually, I tested it there.

Yeah. How do you test it? You play a show, you lock your screen and look at it with your eyeballs.

Ask your friend with an Android to try it, too.

Yes, exactly.

Let's talk about hosting the thing.

Now the question is, where do you host it? How do you host it? Do you want Like hosting itself has sort of ballooned to these services. They're called Passes Platform as a Service, And it involves so much more than the actual server, right? It contains continuous integration.

So you make a git commit, you push the git commit up.

Ready. It's going to run a build, make sure the thing builds. It might run your tests, make sure all your tests pass.

It might run some GitHub actions to fire off a bunch of different things that need to happen.

So that is part of your deployment.

It will also handle scaling so you get a ton of traffic. You. Do you have to handle the load balancer yourself or will your your service do it? So On a lot of my hosting platforms, I'll just set a limit to how high this thing can scale. And if I all sudden get a whole bunch of traffic, it will just scale up to multiple instances.

Ready.

CDN. That's a big one is you've got images or HTML pages on there that you want to cache around the world.

Does it include a CDN or do you have to configure that yourself? So it's kind of interesting blog post the other day from Lee, who is developer relations at Vercel.

And like Vercel gets a lot of flack for Next. Js not doing all the Vercelli things on other hosting platforms, right? And he's kind of like, yeah, like, You can host it and we support all of that. But like Vercel is a lot more than just hosting, right? Like it's a CDN. It's a load balancer.

It's a cache invalidator.

It's a scaler. It scales up and a lot of that is rid Infrastructure.

So I thought that was kind of an interesting take at that whole argument that you hear over and over again. Yeah. And and, honestly,

like, one thing you gotta ask yourself with the entirety of this episode. I'm talking about, tip to tail here. Do do you need all this stuff? Because Yeah. Because you just list out, oh, you got a CDN and a load balancer and server. Like, no. You don't need all this stuff. If you wanna write a website in 2023 and beyond, read. You just need HTML and CSS straight up. It one thing I think gets lost in this conversation about Websites being too complex nowadays or there being too much stuff to do.

Yeah. You don't have to do all that stuff.

People put building a website like Netflix or Facebook in the exact same bucket rid. Sscott.com or, you know, whatever my at to lend to lend dot ski, my website. Right? Those are not Even remotely similar to these same type of projects.

Could I write my website, personal website, with HTML and CSS straight up? Yes. It will work fine. Could I drag it to a shared hosting plan on FTP and have it work the same way I did in In 2005, yes. You can do that as well. There's nothing stopping you from doing that.

If you have requirements To make these things work faster, work more globally, work in more interactive or Crazy ways.

Then Yeah. You get into situations where you need more of this stuff.

So I can just I I hear people all the time complaining, it's too complex. You got too much stuff. Whatever. Yes.

But, also, you don't need all that stuff. Sometimes you do. Sometimes you don't. There's a there's a whole spectrum of different types of projects we're working on here. So if you're the type of person who's listening to all of this and thinking, gosh, I really don't feel like I need all this stuff. Hey. Perhaps you don't. Yeah. Ready. One thing I love about Netlify as a host is they have this netlify.com/drop,

and you literally drag and drop your HTML, CSS, and JavaScript. That's what I'm talking about. Boom. At the other end, you get a URL for it, which is like the most incredibly simple thing ever, right? Like that's that's even easier than having to pay for an FTP host and then SSH into it and figure out how to drag and drop your files up to it. So ready. Big fan. That's probably the easiest way to get something online or like one of these glitch code sandbox, something like that rid. CodePen, where you can just write the code in the editor and get it going. Yeah.

Easy peasy, right?

Yes.

So that is how you build a website or an app. It's kind of interesting to see what people's approaches to this Type of thing aren't all the different choices that you need. Hopefully you enjoyed that. Let us know what you do. Tweet us out syntaxfm.

Sick. All right, let's move into some rid Sick picks. You got a sick pick for me today? Oh, yeah. I got a sick pick, and,

this thing is kind of a literal pick because it's not like an ice pick, but it's gonna pick Stuff for you. I don't know. I don't know if that even works at all, because what it is is a chip clip it's a chip clip. I guess it doesn't really pick things, but hey.

Rid Chip clips. You know them. You love them. You gotta have them. One thing that Courtney and I are always struggling to do is to find a chip clip when we need a dang chip clip.

So Yeah. I bought a 20 pack of metal chip clips For it was, like, $15 when I got them. Looks like it's $16 now.

These heavy duty chip clips, these things are basically you know, they're they're clamps. They're little metal clamps.

They work really well.

They're they're just you get 20 of them, so you got you got 1 when you need 1. Either way Awesome. Doesn't doesn't matter which one you get. Just mass get a bunch of chip clips, rid Toss them in a Tupperware container in a drawer or something. That way, when you got it, you're not just wrinkling up that bag and hoping that beer doesn't get in. Oh, these look nice. Yeah. We have the, like, IKEA ones that you have to, like, lock.

Not a fan of those. And also plastic chip clips, they don't last rid Straight up, you might think you're going cheap. They they break over time. Every chip plastic chip clip I've ever had is broken over time.

I am going to sick pick ready.

A toilet seat. So hear me out for a second.

There better be some toilet seat, Wes. Yeah. This is going to be the rid. Intersection of good deals and

improved life improvement here. Please don't tell me you got this at a garage sale.

Close enough.

So, our house our house that we moved into rid. Doesn't have soft closed toilet seats. And I our old house did so often.

Ready. I'll just hit the toilet seat to close it and slam.

You know, middle of the night, shake the whole house. Yeah. Super loud. Wake up the dog. Soft close toilet seat is the best.

And I've been wanting to do it for a long time, change all the toilets in our house over. But like our toilets are like this weird Color that is hard to find, right? And I thought, I guess finally, after one day of slamming it, I was like, you know what? I'm going to figure out what ready. Color this toilet actually is. I did the research and I found it. And then, like, I went to look for 1, and they're they're like $80 for toilet seat. I was like, there's no chance I'm going to do it until I discovered the used toilet seat. No.

Rid Do you hear me out? So toilet seats come in hundreds of different colors.

Uh-huh. So Amazon is full of rid. Toilet seats that have been returned because they're not the same color. And who in their right mind would ever buy rid A used toilet seat off of Amazon.

Me. It's not gonna be me. Because I knew It's not gonna be me.

Because I knew that People are buying them on Amazon. It's not the right color. I'm going to return it. So I rolled the dice and said I'm buying a used toilet seat on Amazon For $18 versus 80, ordered 3 of them. They all showed up brand new, still in the package, still sealed. All the people do is they cut it open, they pull it out and they go, Oh, that's not the right color. Put it back in the box, send it back to Amazon.

It ends up as a used toilet See on Amazon. So I go into the warehouse section on Amazon, find the toilet seat.

Boom. Got the nicest soft close Toilet seats for $18.

So hot tip.

Obviously, there's a slight chance you might get a used toilet seat in the mail, which is rid. Maybe wear a pair of gloves, but, like, come on. That's a good deal.

I'm gonna be real with you. Every everything that you've said Makes perfectly fine sense.

It makes I I get it, but the the emotional part of me says, Hell no. I am not buying a, a used toilet seat regardless. Off the Internet?

Yeah.

Rid. Valid.

But for my friends who like a good deal, I put you on to that. So rid Let me know if you if you do that. Okay. Anyways, that's it for today. Thanks, everybody, for tuning in. We will catch you on Friday. Peace. 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.