Potluck - Next vs Gatsby × Headless CMS × Vue.js × Is Ruby on Rails still good? × More!

Welcome to Syntax. This is the tastiest podcast around about web development.

If you're just tuning in, we are doing a potluck episode today. We've got some awesome questions around Gatsby and Next and a new tab, installed components, and Vue and jQuery and Nuxt and Next and some really good JavaScript questions coming at us today.

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

Doing good, man. I just behind the scenes here it's a little behind the scenes when we do our we do a clap to sync the audio. Yeah. Yeah. We do a 123 clap, and it's always off because Wes uses Bluetooth headphones when there's latency. But, we clapped, and when I put my hands down, I did so too aggressively, and it ripped both of the headphone

headphones out of my ears and out of the jack. So I was, like, struggling. Missed your whole intro. I hope it was awesome. Oh, man. I'm sure it was. It's one of my best. One of my best. Today, we are sponsored by 2 awesome companies. First 1 is LogRocket, which does JavaScript session replay for your application. And second 1 is Kyle Prinsloo.

It's back with his freelancing course.

We'll talk about the both of them partway through the episode.

So Scott of questions today. We just went through. We haven't done we do potluck once a month, and we went through today. And there was just tons of good ones in there, so we just kept adding them and adding them. So let's get right into it. You all grab the first one? Sure. 1st one is from Salvatore,

Argenati.

I hope I got that okay. I don't know. I'm sorry, Salvatore. Nailed it.

This may be a crazy question, but I need to build a similar system to level up tutorials Wes people can access content based on a monthly subscription. Okay? So monthly subscription content. Watch out, Scott. Don't answer this. They're coming for me. Okay.

Any recommendations on where to start with either Next JS or Gatsby? How do I check if the person is up to date with payments? Any of your help would be greatly appreciated.

Also a fan that your videos rock, you pay I pay for your content. Thank you, so much, Salvatore. Okay. So the answer to this question okay. This question actually goes along with another one that we're gonna talk about a little bit later with the Next. Js Vercel Gatsby stuff because a lot of that stuff still applies. Specifically, do you get the benefits of a static site if you have the user accounts? We'll we'll talk about that in another question. But so the basics are you need a payment processor that handles reoccurring payments or you need a service like something like Recurly, that will be like a full on service to do it for you. If you use Stripe or Braintree, that's going to handle your payments. You need a database component to all of this, which answers some of the other parts of this question, which would be, how do you check if a person is up to date? Well, chances are you have a user. You have a user record in your database, and you store some sort of role onto that user.

And what happens is when the subscription charges or fails to charge, I should say, or or does anything or is successful, the service, whether that's Stripe or Braintree, sends a message to a route, AKA, a webhook, to your website with a message that says, okay. Customer number, whatever, payment successful.

And then you can do your service to fire off a email saying, hey. Your payment was successful, whatever.

Or they send a message saying, hey. Past due. Or they send a message saying, hey. This account has been canceled.

So, really, your server and your database isn't going to be managing the timing of any of this, but the timing of when people, subscribe or gain access is all done through the payment processor itself, their reoccurring payment system, and your database JS just kept up to date when their messages come in. So no need to worry about, setting up timers or or checking things monthly or whatever.

It's all about webhooks and the message to keep your users up to date with the payment processor.

Beautiful. We'll we'll talk about the next Vercel Gatsby stuff in a a future question, but thanks for sending that in. Next one was from Anan.

What is your favorite new tab page? And this is this is a good one. I actually just went through this myself. My favorite new tab page is about blank, which is just absolutely nothing.

I used to have to install a Chrome extension to even get this, which is weird Yeah. Because I I don't even want, like, your recent or most visited, especially because, when I record tutorials, I don't want that stuff just showing up. No. Even if I use, like, a different profile, and and I don't want any of that. So just blank new page. I know some people have, like, motivational quotes or their to do list or whatever, but I've found over the years that just nothing works best. You know what's nice is in Firefox,

they do have the top sites and highlights pop up. Right? Yeah. But those are both accordions, and they remember your position. So I just I just hide both of those accordions or or collapse them. So now when I create a new tab, it's essentially just a blank page, with a Google bar if you need to search in there. Although, I never seem to use that because I just search in the URL by itself. Yeah. That's my favorite. Firefox does a great job. They just let you uncheck all the boxes. So they have web search, top sites,

recommended by Pocket, highlights. By the way, that, like, recommended, I hate that on everything. Like, my Google Home has that, and it, like I turned that off. Yeah. Yeah. Can you turn off news on Google Home? Because it just shows me, like, the most awful stuff that's going on in the world, and my kids just, like, accidentally tap it. And they're like, bombs Yarn dropped on every country in the world. I know. I know. Layton figured out how to get YouTube going on the Google Home screen. Oh, man. Just like, please stop.

Please stop. Anyways yeah. So Firefox has all these different things. You just take them all off, and, I highly recommend it. It's good. Just, oh, it's sort of a trend. We talk about this with the bookmarks as well. Just, try to keep stuff as minimal as possible, at least for me. I'll it works well for me. It doesn't overwhelm me. I have too many distractions

already. I'm good enough at distracting myself. I don't need Firefox to step in and be like, hey. You know what? Let's actually distract you a little bit more. You know, I had to I had to work at that. So alright. Next question is from Uvarus.

Gosh, man. I'm getting a hard name today. You got Yeah. Anan. I got U verse.

Yeah. And come on. Okay. So this question is CSS Vercel CSS Vercel styled components. When you are developing a React or Next JS application, which styling method do you use and why? Which one is Bos practice in quotes or the most efficient way of going about it? Okay. There's no best practice here. So, you can write excellent CSS using CSS, SCSS, or style components, or emotion, or any of this stuff, it's all going to allow you to write quality CSS.

What matters is that you're following some sort of a system that allows you to write not necessarily the driest code of all time, but write code that is efficient, does what it needs to be, and is updatable and, extendable and all those those wonderful things. So if I'm running CSS or SCSS, I'm always using something like BEM over a system that I have established myself that really follows sort of the same sort of principles. I largely think about things and components now anyways, so it's all very component based in my mind.

But, yeah, I I my thoughts are that you can write amazing CSS with any of these. I use styled components primarily because I just like the way it works, and I like the ease of use of everything.

But, you know, to each their own.

Yeah. I I think you nailed it JS that as long whatever you're doing, just make sure you're using some sort of system, whether that's BEM and you you figure that out on your own or or whether that's styled components where you create a new component for that. So my approach I've said this before, but my approach to writing CSS in a React application would be I I do my sort of global styles first.

And I think, like, a lot of people are a little bit afraid to, like, use global because they are bad. So, like, go nuts. Do your do your base stuff first. So fonts and sizes and, background colors, all of that sort of, like, base stuff, go ahead and do that and then go go component by component. And the other thing that I do is that, like, if I've got a div and that div has, some text in it and it has an unordered list and and a list item, some people will go bananas and make, like, a new component for the paragraph, for the unordered list, for the list item, and for a button inside of that thing. And then all of a sudden, you got, like, 6 different components. So what I do is I'll just create a component for that thing that I'm styling, and I'll sort of, like, eyeball and say, like, ah, this is this is like a this is a one thing. This is a component.

And then I'll just use descendant selectors inside of that. So maybe I'll grab the div that wraps the entire component. And then inside of that, I'll use my paragraph selector, list item selector, unordered list selector, button selector. And then if I find myself saying, I need to take this unordered ESLint, and I wanna be able to reuse this somewhere else, then I'll just refactor it out into its own component. And I won't really stress all that much out about it. Don't go bananas on creating a new style component for absolutely everything because that that seems hard, and that seems like, I don't know, I I always just found myself being able to to do it much easier. So Node. Totally. That's kinda where I go. There's there's no, like, real best practice or efficient way. You'll certainly hear people spout opinions and write huge medium blog posts on either side, but who cares at the end of the day as long as you feel confident in the approach that you're taking. Do you use the CSS prop in the style components?

Is that when you're doing, like, nested stuff? It's when you just want to write some string CSS as a prop on a component.

Oh. Oh, like just like ESLint, you mean? It's like inline styles Yeah. With straight up string CSS.

I haven't. But when I do need to write inline CSS, I just you'd use, like, the object syntax.

So I could imagine the CSS being nice. Yeah. It's basically the object syntax without an object.

Yeah. That's nice, actually. I don't like writing the object syntax.

Yeah. I do it for prototyping, especially when I'm just, like, still dreaming of what the component's gonna look like. I just start throwing string CSS into everything.

And then because it's a string, you can just copy and paste it directly into your style component if you do want to merge or move it there anyway. So, I find that to be a really handy tool within styled components.

Yeah. That's great. Maybe I will start using that. I will say the one thing I do love about these style components and emotion and all these things is that it doesn't make you think of names and classes for absolutely everything. Like like, the big no no is don't use element selectors. Meaning, like, don't say h two and style all of your h twos, and don't don't say paragraph tag. And but with style components, you can because It's all Scott. It's scoped to that component. And you know there's, like, 1 paragraph tag in that component, so that's totally fine. Yeah. I like that too. Alright. Next question is from Rob. He links to lit html.polymerproject.org.

What do you think of lit html? So this, like, lit html, somebody recommended this to me at Node point because I do a lot of vanilla JavaScript, and I do a lot of templating vanilla JavaScript with just back ticks.

And there's there's a little bit missing there in terms of, like, sanitization, and they're not actually doing document dot create element. They're they're just grabbing a huge string of HTML and dumping that into an element, with dot inner HTML.

So this lit HTML looks very similar to template tags in JavaScript, but also sort of like JSX.

So what what is the difference between what what is the benefit of this, Scott? I'm just looking at it right now. I forget. This seems more like a framework

where you're doing more than just a little bit of, like, templates. It seems like they're trying to do a little bit more React y kind of things with it. Oh, it's like like you can put variables in your HTML string, and they will be rerendered

Yeah. When that data changes very much like React will do. And that's good because I see that all time with vanilla JavaScript. People are like, hey. I put a variable into the string, and I changed the variable, and it didn't update string. And it's like, well, yeah, once once it hits a string, it doesn't know about those variables in the future, which is pretty cool.

Yeah. It does it does talk specifically about how it doesn't use the virtual DOM. And it's efficient.

It's expressive. It's extendable. Extensible? I wonder.

I don't know the difference between the word extensible and extendable. So, should Google that extensible to able to be extended.

Extendable. Oh, why not just use the word expendable? If you know why you would use the word extensible Vercel extendable, let me know because it cited them as synonyms.

This is cool. Like, it's a it's a lightweight way to put data into HTML, the template out data. And then when that data changes, it will be rerendered Yeah. Without the. We we should explain what or virtual DOM is real quick.

So the whole idea behind React and I think Vue and a lot of the these places have this idea of the virtual dom is that they they have the real DOM, which is your your page, and then they have a virtual DOM, which is in memory. They they keep a sort of a similar tree structure to what your what the DOM looks like. And then when data changes, the virtual DOM will update itself, and then it will know which pieces of the actual DOM to update.

And that's why React is so fast versus, like, some like, in my vanilla JavaScript course, sometimes I say, like, hey. We just Scott rerender this entire to do list because Wes there's Node nothing built into vanilla JavaScript that allows you to figure out which part of the DOM has been updated.

And it looks like that this does something similar to that. So pretty cool. I would definitely reach for this. It is pretty cool. Yeah. I'm gonna check it out just to just to goof around with it. I use, like, handlebars or some of those templating languages.

This seems like it's a little bit more I don't know. This seems pretty cool.

Yeah. Well, it's it's just backticks. Right? So it's it's everything you're used to from writing vanilla JavaScript except it's

live. Yeah.

Live.

Yeah. Node. It looks interesting. I think this is one of those ones that you wanna check out a little bit, and it does work with web components. So I, yeah, Polymer Polymer project seems to be alive and well with ESLint html. I I have not used Polymer in a little bit. So, this was exciting to see. Well, actually because I had heard of lit html,

but what I didn't realize is that it was part of Polymer. Oh, yeah. When people recommended it to me, I was like, well, I'm not using Polymer, but they're like, no. It runs on its own. Yeah. Just cool. Like, imagine JSX.

You could just use JSX. I guess it is its own project, but I've never heard of anyone using JSX outside of React world. So it looks like this lit html does do that. You can use it in view. Yeah. You Node to write in view. Alright. Next question here comes from Daniel Bossman.

It's Scott. Sick last name, Bossman.

Sick last name, Bossman.

Hi, guys. I'm relatively new to React and primarily learning the create react app way. When you go for the create react app approach Wes building an application and when do you customize the config? It is not like React comes with so much magic compared to the others, but I'm uncertain to when it is time to escape the whole create React app approach.

And also when escaping it. Which main configurations are you grabbing? All right. In my mind, if you're really needing to get into the babel config, you Node to do some server side rendering, you're needing to, just really customize beyond what's there, then that's when you go for beyond create react app. That said, I'm probably not reaching for create react app for too many of my projects to go into production. Not because create react app isn't great, but because I think that, typically, if I'm doing another project, like a big project, I'm gonna want things like either static generation or server side rendering, of which then you're getting into all these custom configs. So I'm going to primarily reach for something like Gatsby Next. Js or, in my case, Meteor to do those those aspects.

Yeah. I I agree as well. I think in most cases, you probably won't have to eject from create React app. Yeah. Like, what are the reasons you might wanna eject from create react app? The one of the biggest ones was no SaaS support, but I think that's that's been added now.

And I guess, like, another reason would be, like, oh, I wanna use that new what's the new question mark thing in objects? Oh, optional chaining.

Optional chaining. So, like, let's say you you needed to add that to your your webpack config, and you Scott you you wanna try that out. Although it's in Chrome now, which is really cool, but, obviously, not every browser has it, so you might have to escape for that. I think I would go as far to say don't ever eject from the create react app. That's so much homework that you have to do to babysit this thing. You get 1,000,000 files. You can't go you can't ever un un eject. Well, you can unaject. You just have to scrap the thing and copy paste your files into your old one or into a new create react app. But I wouldn't recommend it. I personally have not written any more than a couple lines of babble or webpack config in my thing. And and in most cases, Gatsby and Next. Js, they will allow you to just extend the one. So if you need to add something specific like server side styled components, you can just add it to your babel config, and it will fold it into to what they have. So, yeah, I would just say try not to. And if you really, really, really need to, you probably will reach for one of these more batteries included frameworks that is like Next. Js, Gatsby, whatever is out there. Totally. Yeah. 100% agree.

Next question is from John.

Is there a reason the Hasty Tree intros are 2 and a half times the length of normal episodes? Now that Overcast has intro skipping, it'd be nice if they were uniform in length. I didn't know that Overcast added this, but there's no Pocket cast has it too, and it's sick.

Really? Yeah. I use it. I would like that because, like, I'm so good at skipping the, like, 14 teen minutes of Joe Rogan intros of, like, talking about underwear or something like that. So, yeah, there's there's obviously no reason. We don't have reason behind much on this podcast, but we are talking about getting some new intros Deno. So it would be awesome if they were all the same length. Yeah. We should do we should specify

they're this long. I don't know what people like. 6 minutes. Yeah.

6 minute long intros. I feel like that's probably pretty good. Like, we could we could tell a little bit of our life story in 6 minutes before the podcast starts every time. Oh, no. I think they're talking about, like, the, like, the, like, warp under syntax. No. No. They are. No. They are. Yeah. That's what they're talking about. Talking about us shooting the Scott because that's genuine content. But what I'm I'm talking about is, like, what if our life stories were just part of that intro? Out of Ann Arbor, Michigan by way of Denver, Colorado, here is Scott Tolinski, who spent most of his career doing this.

That'd be pretty Scott. You tell the whole thing here. That'd be pretty funny. Yeah. You could have a dynamic service that automatically inserted

what the current forecast is in Denver and in Toronto. Sure. Just get that over with. Yeah. That would be funny.

Yeah. So I don't know. We're we're gonna do some new intros. We got some really funny ideas for some some new intros. Maybe we'll try to keep them the same length, but if it's funny, then maybe we'll go longer or shorter. So Yeah. We'll specify. We should we should tell whoever's creating it. Okay. Make it 30 seconds or whatever Yeah. Wes seconds. Yeah. 15, whatever. Yeah. But thank you, John. Yeah. Thank you. So it's dope that Overcast added that skipping feature, but you don't wanna skip

our ad reads because, then you wouldn't get to hear us talk about why you can save so much time with LogRocket.

Now LogRocket is the best place to visualize the errors and bugs that are happening on your site. You wanna check it out logrocket.comforward/syntax.

You'll get 14 days for free. LogRocket gives you a session replay that allows you to see your bugs in action while they're happening. You can click and drag. If you like to click and drag and see these things happen, you can see the user click that thing and have your whole website turn into a giant tomato. I don't know how they did that, but you'll be able to find out and see the network Wes, the error logs, the Redux store, all that and more. And it works with all of the platforms that you know and love, React, Angular, just JavaScript, Ember, Vue, Redux.

And it connects to a lot of the services that you might already be using, such as, you know, Century, Rollbar, New Relic, Jira, Zendesk, all that good stuff, the stuff that we know and love. So check it out at logrocket.comforward/zendags.

Alright.

Next question is from Daniel Bro.

Hello there. I see Kyle Matthews, who created Gatsby, coming out with a lot of input on how Gatsby can be used for web applications.

After listening to several of your podcast, you talk about Gatsby. It doesn't seem like you agree and would go for Next. Js instead. In your opinion, is it still the same, or is the development at Gatsby really heading in the direction where it is SSG and web applications? Thanks for a great show, and keep the good spirit going. I'm usually walking my dog at night listening to you, and people stare because I laugh out loud

from time to time. Yeah. I do that too. Say SSG means server side generated. Yes. So, like, that's a Gatsby.

By default, is a server side generated, meaning that there it's all generated beforehand and and generated out to HTML files, which then are rehydrated and then picked up as a React application when you visit the website. Yes. So okay. So this is the question that we,

we referred to when we were talking about answering some of that other stuff later on in the episode because, specifically, it really depends on what your needs are. Because with a static site or an SSG, it's really difficult if you have user accounts. You have to imagine that you cannot server side render, like a customer account page for you know, if you have 10,000 user accounts, you're gonna have 10,000 statically generated pages for each of those experiences, not to mention whatever you have, the header being different. There's just not a whole lot of good ways for that to happen, so then what you end up having is dynamic bits.

So not to say that you cannot do it with Gatsby because you absolutely can. User account based sites, all that stuff JS just going to be dynamic and not statically generated.

Where with a Next Wes site, the server can render that information because it has that cookie when it's building the site. Right? It's building the site Wes the user hits the site.

That cookie is there for their authentication, whatever. They're able to verify that users authenticated, and then the server responds, the fully server rendered site with that user data. So you have to imagine that some of those things Wes you're getting to user accounts, you have to think about what you need to be present there for the the server side generated bit and what you need to be dynamic.

So that's typically why we say that. We're very aware if you are, like, a pro Gatsby user, if you're, like, super Gatsby person and you don't need user pages to be server side generated, you could, by all means, do any of that stuff with Gatsby. It it's just all about, I think, maybe the right fit for each platform. And me, personally, I probably reach for something like Next. Js for only those reasons specifically.

But at the end of the day, like I said, you can certainly do dynamic things in Gatsby like user accounts.

Yeah. I I I think you hit the nail on the head. So Next. Wes, by default, is server rendered, meaning that when you visit a web page, that thing is generated quickly on the server and then served up to whoever's visiting the website.

And Gatsby by default is statically generated, meaning that it's all done at build time before you push it out to the website.

And then you if you want anything to be dynamic, you have to do that on the ESLint, meaning, like like, let's say you have a lot of people are talking about using Yatsby for, like, online stores. Yep. But, like, if there's something that's dynamic like stock, how much stock is left, and you wanna display how many are left for a specific size, you need to load the page and then go ahead and then fetch that data and then update the page. And that's where you sometimes get the a little spinner on on page load because it has to load entirely, and then it goes, oh, I gotta go figure out if there's any of these left, and it goes off and and comes back. So for that reason, I don't think that Gatsby's a great they they do say, like, of course, you can do static websites with us, but it seems like it's sort of, like, after the fact, which for some websites is is totally fine, but I certainly would not reach for it that way. And I think Next. Js is doing a great job because they've approached it in the opposite way where you can by default, everything is server generated, but now they have this idea of server side generated static pages. So if there are some pages in your application that wanna be statically generated, then you just specify that when you're building the application. And at build time, they will they will generate, though. There there's Gatsby is still way ahead in in terms of what the static site generation looks like, but they're certainly like, they are getting a little bit closer to each other in in what they can do. So it would be cool to see some sort of Gatsby server at some point where you get all the amazing benefits of Gatsby. Like, sometimes I'm almost tempted just to run Gatsby dev on a server or something like that. You know? But, I'm not sure what what the the approach is. They did just roll out this, like, Gatsby builds, which they're saying is 20 times faster build times. I'm not sure how they are doing that. Maybe they are running multiple processes at once. Like, maybe they deploy it to a multithreaded server or something like that, and then they build multiple pages at once, that would be awesome for, like I know some people run stores on Gatsby that have 100,000 products or something like that. I can only imagine that the build for that would be very slow because there's no they're they're working on this thing at Gatsby be called incremental builds, meaning that if you just change 1 page, your build will be faster. And I think Netlify does that as well, actually. But yeah. So it's I I probably wouldn't reach for it now, but I bet that will change in the future as well. Yeah. It's something to keep an eye on it at the very least.

Next question is from Chris f. Hey, Scott and Wes. I hopped on the view train from jQuery Land, and I am loving next Nuxt and Gridsum. So Nuxt and Gridsum are the next and Gatsby of Viewland.

However, I am hearing good things about Gatsby. Would you say that it is worth learning Gatsby and the whole React ecosystem over that matter, over grid sum? This is mostly a small medium ish side projects that connect to a headless CMS. Thanks.

Oh, this is tough because I don't maybe Scott will have something to say on this, but, like, I don't know if the feature set of is Sanity with Gatsby? Gatsby is a force right now. They've got tons of people.

I I would say, not anymore. But at one point, I would say it was close.

Yeah? Yeah. Definitely. So

it's tough because, like, normally, I'd say no. Like, pick your pick your stack and and just go ahead and use that because it's so cool.

But we're in a bit of a interesting spot where it's weird that Gatsby is, like, the thing, and it's only built in

React. I wonder if they ever will, like, roll out, like, a a view Gatsby or something like that. Dude, I I would just think they would take over grid zone. Because if you go to grid zone's website, they got some juice, man. I mean, it JS definitely pretty sweet. And to be honest Yeah. They really solved some of the issues in a better way than Gatsby. Like, the image stuff is better in Gritsum in my mind. So I I think Gridsum has some really great ideas.

Personally, if you're a Vue fan and, you're comfortable with Vue and Gridsum, I wouldn't just jump ship just for Gatsby because, grid sum gives you most of that good stuff, Node to mention it's very fast. So I don't think you'd be gaining a whole lot, and you'd spend a lot of time having to invest in learning React, not to mention that, but learning the Gatsby way of doing things on top of that. I think you're getting just enough with with Gridsum Nuxed in, Vue.

Interesting. And a lot of these, like, Gatsby plug ins, they're just Node plug ins. They're just webpack loaders.

Like, the it's very little of it is actually React specific,

so I would assume that it would be easy to port them over if they've not already been been moved over. So, yeah, I like that. I would say no. Not probably not worth it. Yeah. You might even be frustrated. Like I said, the, like, the image stuff is so much better on good. So I'm sorry, Gethi. I love you. But, yeah. Yeah. Because you instead of you just have a g hyphen image, you pass in the path, and then if you give it something like a width, then it just generates that. You don't have to do the whole query thing. So you're saying loading an image, you shouldn't have to write a, what, 40 lines of GraphQL? Yeah. I'm right. Yes. Yes. I am saying that, and, and and Scott that one right. So shout out to them. Yeah. Absolutely.

Yeah. Okay. Next question. This one's from Mateusz. Hey, guys. Huge congrats on the show. I've been listening since episode 2, and it's fantastic. Thank you, Mateusz.

My questions are Episode 1 wasn't very good anyway, so good job. It was it was fantastic.

What are your thoughts on CSS preprocessors Node a day? With the advanced new c news features in CSS, do you guys really think it is worthy to use all those? Well, the thing about CSS preprocessors JS that you're not shipping them. It's like a preprocessor. Right? So there's really no harm. I still reach for Bos or auto prefixer or post CSS. I I still almost always reach for one of those if I'm writing CSS in that style components myself because I just can't live without that sweet nesting. I love that nesting.

I primarily use CSS variables Node. But if I was building for a site that needed to support older versions of IE, I would be very distraught without having some sort of a variable system in my CSS.

Other features, I don't really use functions and stuff like that, but I think they're they're definitely there's definitely still a place in the use for them to make your life easier within writing your CSS.

Yeah. It's it's just like I think of them not as this, like, totally different way of writing CSS like Sass was, but I think of them as just making the future CSS now as much as possible. Yeah. Some things you can't polyfill or or transpile, but a lot of it, you you can. CSS color functions and and whatever. So I think of, like there's this really good plug in now that is sort of like the babble of CSS. It's called post CSS preset env, and you just tell it what browsers you Yarn supporting, and it will figure out which things it needs to transpile and which things it doesn't need to.

And then at a certain point, maybe you won't be transpiling anything. So that's sort of how I look at it, and I don't necessarily reach for SaaS or or Stylus all that much anymore just because I'm I'm much more on the web standards train. Things have been moving really well for the last couple Yarn. Yeah. Totally.

Next question we have here is from Justin.

Scott, can you talk a little bit about why you decided to switch back from METEOR after putting in all the effort to convert Vercel up tots to Next. Wes. Man, this is like the Next. Yes. Show. This is great. I'm about to start a new full stack, and I was considering next until until I heard you switch back. PS, love both of you guys. You're all fantastic. Thank you.

Yes. I'm curious JS this. So Scott spent all this time converting his platform to a NexJazz. Yes. A lot of time. And then, he was, like, not stoked on it. And then it turns out Meteor got bought, and it's looking like that truck is moving again. So why didn't you like Next. Js for your platform? Okay. So let me preface this by saying I I love Next. Js. I really like it. I've worked

fairly a lot in it over the past few months, and I really like Meteor as a platform.

My reasons why I was getting off Meteor in the 1st place is because you could see the progression over so many years of less and less work being put into it of no fault of the Meteor community themselves, Just the investment being put into Meteor was, you know, not happening.

So I could see the writing on the wall that maybe this framework wasn't gonna be around forever and wanting to think about moving over. So what I did is I maintained a meteor branch in the Next. Js branch side by side, which allowed me to do a lot of really cool things. And it was really just like easy merge from one to the other.

And so I was able to run these things side by side and really see them in action next to each other. And for the most part, Next. Js worked really nicely. I used their API routes to power my GraphQL server, which it didn't feel as nice as my Meteor one because my Meteor one was just like, here's a standard Vercel, where with the API routes, you had to think about it a little bit differently, serverless functions every single time they connect, being a serverless function JS we talked about in the the last video. It was just a little bit different. Right? So those aspects were all fine, but the the big rub for me came with how Next. Js establishes pages routing in those aspects.

I am not a fan of the routing where you have 1 route page, where every single route of your entire application is listed in the routes page. I I I would think of that as being, like, how we would have done it, like, React router 3 or something. But me, personally, I'm more of a fan of nesting routes. So I have my route set up, and then let's say on, so, like, forward slash, whatever. My my app page would have a route that would be then take me to the tutorials layout route. And then inside of tutorials layout, I would add to have several more routes. And then inside of there, I have a couple more routes, and I do that throughout the site whether it's for admin or whatever.

And largely, React router was built for you to be able to do that. The problem is when you get into applications like Next. Js that expect you to do everything on a folder basis, it gets a little messy because what you end up creating is a bunch of wrappers. So instead of having nesting with a nesting with a nesting, you end up having to write, here's a wrapper, here's a wrapper, here's a wrapper. All your components are wrapping, whatever, And it was just a different way of doing things. So that said it wasn't worse.

It was just different. What do you mean by a wrapper? So let's say you have forward slash posts Yes. And then you have forward slash posts forward slash 3. Yeah. And then your your forward slash post would show you all of your Bos, and forward slash posts forward slash 3, it would show you post number 3. That's not a good context because I wouldn't use a wrapper for that. So let's think about this. Like, you have an let's say you have an admin layout. Right? Your admin layout includes

the normal stuff, but it also includes an admin navigation and a different layout container, maybe. Right? So you have that admin layout. So now each of your admin pages, and the way I would have done it before JS you have a component that's your admin layout, and there are several routes inside of there, including the navigation. But with Next. Js, what you do is you'd have an admin layout component that would have a children prop, and then any admin page would have to be wrapped in that admin layout component.

And so what happens is the rendering gets kind of messy where every page is getting a full rerender no matter what, sort of like Gatsby. Right? When you go to a new page, every page has a full new rerender because that's just how the the layout system works within Gatsby and Next. You have this 1 page that's a wrapper.

Right? What is it in Next. Js? I think it's like the underscore app dotjs or something. Yeah. So you have 1 page or 1 component that's essentially a wrapper in those platforms. Where with mine, it was much more the React router way of doing things, deeply nested routes.

And it became just less fun to work in and, in my mind, way less organized.

I was having just to Node. I don't wanna say issues, but I was I had to take advantage of things like wrapping components and render props more than I wanted to. At the end of the day, I ran them side by side, and I didn't see a huge benefit to 1 or the other.

And that's when Tiny bought Meteor, and it was going to be essentially a lot less work to get us fine with the Meteor. And the fact that Meteor was going to see new investment and see new growth and see new modifications and things like that, then it became, in my mind, a good idea to just stay with what we have rather than go through the headache of doing this migration and then having to deal with the inevitable bugs and issues that are gonna occur from doing such a major migration to a different platform. So it was definitely a sunk cost thing where I was holding on to the Next. Js branch for a little while saying like, you know what? I spent all this time on it. Maybe I should keep it. But at the end of the day, Meteor has been seeing a ton of advancements.

I'm really happy with where the community is going, and I'm a big fan of the platform. So the fact that future picture has been clarified for me, I I'm more than happy to stay on Meteor now. So that's really just it.

Interesting. Not sure I totally understand all the nested routing stuff. I'd probably have to see an example, but that's good to good to hear that. Yeah. It's it's hard to express because,

it all just comes on comes down to how you write applications, and this is the way that our site's been designed from day 1. So if I was building a new application from day 1 here, I might start with Next. Js. But the fact that I've already had this application written this specific way makes it very difficult for me to migrate there. Awesome.

Alright. Let's talk about our next sponsor, which is Kyle Prinsloo's Freelancing Course. It's available at study Wes development.comforward/ freelancing. So this is everything you need to master freelancing. Kyle just told me he just sold his 2000th spot in this thing, so, obviously, people are enjoying it. He's got all these pretty cool reviews of people who have taken it. So if you're thinking like, okay. I'm a web developer. I'd like to make a little bit of extra cash, or I'd like to go totally freelance myself and and go out on my own, this is a course that's going to help you through that, teach you the the ins and outs, the things that you need to know to be a freelance web developer. So what does it come with? Well, this this bundle comes with the Freelancing and Beyond ebook, the Wes Design and Beyond ebook, a bunch of templates, a new thing that was added JS a CSS spice Chrome extension, which is pretty cool. I'm just taking a look at it. You can get it at cssspice.com.

It's just a sort of helpful editing and debugging tool that that has come out. That's pretty nifty to be added in there. That Wes Design and Beyond is a new ebook that got added as well. There's a professional legal contract. It has been written by a commercial lawyer. So if you just need, like, a good contract, that's been written by, an actual lawyer that comes with it. So there's all kinds of stuff in here, questionnaires, checklists, SEO stuff.

You get lifetime updates, which is really cool. I appreciate Wes people do that. I do that with my course as well Wes you just, like, you bought it once, you get the the new stuff that was added to it. So check it out. Studywebdevelopment.comforward/freelancing, and, enjoy. Thanks so much to Kyle for sponsoring.

Next question is from Brandon Next.

Is this another question about Pnpm. Yes? Hey, Wes and Scott. I recently started an internship on my one of my favorite tech companies Wes I'm using Ember. Js and Ruby on Rails. I love the team. People are so nice, but I'm not super passionate about the stack.

I'd much rather be on something like React and Node. Js or Express in my day to day coding. Do you think it's worth staying in the position? And then we got, like, another question that's almost the same question. So this is from my Michelle Keems.

I'm thinking about doing a boot camp that teaches Ruby on Rails for the back end. I hear a lot that Ruby is a dying language, but at the same time, I know it's used by some big timers such as Airbnb and Shopify.

Yeah, man. I I once saw Toby, who JS, like, the creator of Shopify.

He posted their, like, stats for their unit testing. Mhmm. And, like, they've for every line of Node, I think they have 2 lines of unit tests, which is nuts. Like like, I think that is the only way you could have confidence. It's such a huge code base. Anyways, could you please explain the relevance of Ruby and Ruby on Rails we'll have in 2020 going forward? Do you think it's worth learning for new developers? Thank you, by the way. Listen to podcast. Good. So we we see questions like this a lot where something's hot for a while, and then web developers have short attention spans, so something else becomes hot. Mhmm. And, people think that that other thing is not hot anymore and is deprecated and is old and is, is not all that useful.

So I think that a lot of people place too much weight on the tech stack when the reality is this stuff will always be changing, and you JS the developer need to use the tools that you're like, the tools are obviously important. We've talked about them all this show, but these are all good tools that you're talking about. Ember, Ruby on Rails, these are some of the, like, I think, some of the best tools in our industry for creating web apps and websites, so there's absolutely nothing wrong with it. The fact that we don't talk about these things on our podcast or you don't necessarily hear about them all that often doesn't mean that they're not very good. It's just that there's different hotness in the industry right now. It's probably not worth quitting your job unless there's other things that that were hurting. But I don't think a a tech stack is very rarely, I think, a chance to quit your job, especially something that is so modern, like, amber and Ruby on Earth. You're not talking like, this is a 40 year old CakePHP install that Node one has wanted to update forever, and it's just a nightmare. Sounds like it's a decent stack. Yeah. Yeah. Rails power so many of the most popular sites on the Internet still,

and, I would still consider Rails to be an exceedingly modern platform overall and a a great platform. Every time I worked on Rails, I had a really nice time using it. So I think you'd be getting a a lot of, good learning building sites with Ruby on Rails. I don't think you need to to worry too much about that. Yeah. I was I was,

writing a scraper for my bank the other day Fine. Just because, like, I I wanted to, like, I wanted to see over time, and I wanted to be able to chart my daily up and monthly ups and downs of the investments that we have. Yeah. And my bank didn't, like, have that. So I wrote a scraper that would log in for me and download a CSV of the data, and then I have that running every day. And then what I'm able to do is go back, and now I have that that data over time anyways. Have you seen Personal Capital? Does that work in Canada? No. Nothing works in Canada. Okay. Personal Capital JS, like, does exactly that. It's fantastic.

Oh, really? Yeah. It's so good. Yeah. It's very good.

No. Nothing works in Canada. Okay. So we don't have anything good here. It's all awful. So but it's okay. I'm a developer. I can fix my own problems. So I Wes just, like, looking through how it how it's working and trying to figure out, like, what are the API endpoints to log in and what are the API endpoints to download this data. And I was like, oh, this thing is built in Angular and Java Spring, and it was, like, the most wicked app ever. Like, it uses JWT, and it's super fast. The interface is super responsive, and I was like I was just, like, using this app that they had built. It they just rolled out. Like, they had, like, an old one for a long time. But I was like, this is where this is on 2 tech, two pieces of tech, Java and Angular, that people probably wouldn't say are hot, but this is an awesome experience using this thing.

And, also, the fact that I was able to, like, puppet it and Mhmm. Like, be able to scrape it and download the endpoints in, like, a like, a half an hour means that it was obviously built with single page application in mind. So just personal,

antidote there. Yeah. Anc Anc Anc

Anecdote.

Remember when we talked to ATN about Missive? And Missive is a email client we both use, and that's built on backbone, in this fantastic JavaScript. Yeah. Yeah. So, shout out shout out to Missive. Alright. Next question is from Besswas.

Besswas asks, what's the deal with headless CMSs and CMSs? I hear you guys talk about them all the time, Sanity, KeyStone, Prisma. I'm not sure what they're good for. To me, it just seems like a UI to my database.

But isn't that what my application is? It seems like it would be easier to have my front end talk to my back end to talk to the database rather than learning how each CMS wants to do things.

Am I missing the point? Okay. You are missing the point because what it is is it makes all that super easy. It makes it so you don't have to write the code. Tried to code a form that updates data? It sucks. I have my whole level of tutorials, whole admin dashboard JS that. I mean, it's all custom forms and all that stuff. And every single time I create a new anything, I have to create a table. I Scott create forms. I gotta create all the queries and mutations. I have to do all that myself.

And, it would be so easy if the CMS could do that for you. Really, the benefits of using a CMS or a back end is that it just takes care of all that stuff.

The admin forms, the validations, the versioning, the plug ins organization, and it does it all in this spiffy interface that your clients will be able to actually understand rather than some janky form that you threw together.

Yeah. And not to mention the entire a REST API or GraphQL layer or or anything like that. Like, that that takes a lot of work as well where these things sort of just get you up and running. So a headless CMS makes a lot of sense, especially in a website where you're just have data. Well, it's just like saying it's like saying, well, what's the version? What's the deal with using React? Couldn't I just write the framework myself?

Yeah. You could.

You you could, but it just saves you time. Yeah. And, also, like,

the the other the other point that I have here is that, like, a headless CMS sort of decouples where your data lives and and where your data is being displayed. Mhmm. So, like, for example, one of I talked to the folks at Sanity, and one of their biggest customers is, Tim Hortons and Burger King. There's this company that owns them all, and I'm not sure if I was supposed to say that or not, but whatever. I'm gonna Anyways, like, that data like, you think of any company that has a bunch of data, where is that data being pulled into? Well, probably the iPhone app, the Android app pulled into the the, like, the boards. When you're ordering and you're looking at the menu, it's pull being pulled into there. Obviously, on the website, it's being pulled in, in store kiosks. Like, a lot of times, people have data that needs to be pulled in to 7 or 8 different places, and having a sort of decoupled CMS where that data lives is important, and it's not just tied to a website. And it's not just tied to a a single application someone's using. Word.

Next question from JC. Is this RJC?

I don't know. I Wes Oh. I feel like j JC JC would put his last name, but I'm not sure. Yeah. Yeah. I feel like he would do that.

What does Svelte need for each of you to use it instead of React in personal and future developments? Oh, that's a a good question. So I've I've never tried Svelte, so I don't know. But I am pretty on to React because of the momentum it has in our industry, both in terms of, like, what do people want from me in terms of training courses JS well as, like, there's so many resources out there for using React JS. Like, I just look at it like something like Express. I always reach for Express.

Why? Because Express is, like, the dominant one, and there's so many resources out there for it. Is there probably something better out there? Probably.

But I'm I'm pretty happy with it. What about you? Yeah. I mean, for me, for to to use Svelte on one of my own projects, what does it have to do? Nothing. It has to do nothing different because I love Svelte. I think it's fantastic.

Yeah. I wanna, I'm gonna rewrite my own website in Svelte.

Sorry. Hashtag sorry. I'm no. I'm I'm very, I'm very excited to use Svelte on more things. In fact, I'm planning on doing a new Svelte course for Vercel up that I'm thinking about right now with Meteor because I saw a Deno, like, 2 days ago that was an Apollo API with Meteor and Svelte, and it was, like, maybe the most elegant, smallest Node Bos I've seen to do some very powerful stuff. So the amount of things you can get up and running really quickly with that stack and have it be beautiful and, you know, easy to read, nothing, man. I I love I love Svelte. It's it's fantastic. So I would check it out. I think it it it's a great thing to, I mean, like, your reasons are totally valid, and I totally agree with you that the the industry momentum is certainly in React's favor and will most likely stay that way. I can't imagine the entire community hopping on the Svelte train like that, but Svelte's a fantastic platform, and it's not gonna go anywhere. So I think it's,

it'd be it'd be nice to work in. Yeah. Yeah. I I always get the feeling sometimes people think that I don't like things because I don't use them, and there's just too much awesome in the world for me Yeah. To do everything. And it's not like I don't like Svelte. It's just that I've not used it before, and that's all I have. Yeah. Okay. Next question is from Jonathan s. I freelance on the side as well as have a 9 to 5. The other dev I work with

mentioned that he'd help if I ever needed to work on a client project. What are your thoughts on doing freelance work with someone you work with at your job? Okay. Well, is your job at agency? Because that is a little hairy there if you're, you know, skimming some projects on the side with some agency members. That said, I've done it myself, and I don't really think it's a huge problem.

I think it's totally valid. I think, you know, the the depends on how the work came about and what your role is at the agency because some agencies are small enough that every single person is expected to be hunting for projects. And if a project comes into you, it would be ethical for you to send that project onto your managers if that is the climate of the company. If you start skimming stuff on the side here, then that might get a little bit interesting with interpersonal relationships at your business if they find out. That said, if it's a larger agency or the expectation is that many people are doing freelance work on the side and that you can hunt for your own projects, I see no problem with that. But it is I think it's a matter of the temperature within your own agency and and what things are like there.

Yeah. Just don't get sued. Make sure everything is is okay. Wes. That's another legal aspect of it as well.

Next question from Bryce. Boys, my team is currently in the design phase of a rewrite of our biggest product ever. We are switching from a Pearl back end to Node.

But for some reason, our tech lead decided on Happy for the node framework. I ESLint a little time with Happy, and it seems cool, but I'm not sure about its longevity when compared to more established frameworks like Express. How do you feel about Happy, and should I push it? So Happy has been around for a while. Happy came out, what, maybe, like, 6 years ago. I'm trying to look right now. Yeah. The thing with Happy was that Express was always, like, a server rendered framework.

And then when building REST APIs came around, these frameworks like Happy and Koa sort of came around and said, like, hey. It's a little easier to build REST APIs with these things, and that's not that's not all they do. But Express was very much like a server rendered, engine at the Scott. So nothing wrong. I I would definitely say, like, yeah, that would be weird if if they took some, like, brand new framework out there. But Happy and I'm gonna loop Koa in with this as well Yarn certainly fantastic options for it. I think the only thing you might lose out on is there's not as JS many, like, weird, obscure middlewares for it as Express has. But if you are building, like, a huge product, you probably would build those middlewares yourself.

So I don't think it's all that that big of a deal. And I would be totally I know I just said I would always pick Express, but if I were to, like, being, like, thrown into a project where it uses happy, I would be very happy. Yeah. Here's what here's

go you. Okay.

Here's what I here's what I like about happy.

I haven't used it myself personally, but just looking at their GitHub, it well, the last commit was 5 days ago. There's 12,000 stars on it. There is 9 issues and 2 poll requests. That is fantastic.

How many big projects do you go to that end up having, like, a 100 issues and, you know, 20 poll requests? And that, to me, is an interesting sign of of, how the the development is going. So I think, happy seems to be on it. I mean, I have not used it personally, but I I've heard good things, and it seems like it's really nice. So, yeah. No. I I would have no issue with somebody picking Happy over Express. I think from what I've read, it says, Express is closer to Node and less opinionated. So maybe Happy does some stuff for you that Express doesn't. It seems like a good choice either way.

Yeah. Alright. Node more. Last question is from Andrew Waffle.

I'm a dev that recently joined an agency for the first time. What hot tips do you have for living in Devon in the agency life, especially around time management, time estimation, and dealing with clients' peace? Oh, this is this is a good one. So I did quite a bit of freelance work with agencies, and I think my tip would be you have to aggressively manage your own time because project managers, there's certainly lots of good ones out there, but there's in my experience, I've encountered much more super stressed out, super tight timelines from project managers that want you to get everything done much faster and and quicker.

And things like phone calls and emails and whatever, that would just eat up your actual time.

So I would very clearly just say to a lot of my clients, like, look. I can't I'm not gonna reply to these emails. I'm trying to get work done. And, like, it's important that you communicate with them. But at the end of the day, you're the developer. And if you need to get stuff done on time, you need to aggressively rally against phone calls and meetings.

Yeah. And, you know, it depends on the agency size. It, like, really, to me, personally, depends on the size. Because if it's a small agency, you're gonna be expected to interact with clients a lot more.

We didn't have project managers at my 1st agency specifically because there was designers, developers, and, like, the business manager and then the marketing person. So, like, we didn't have project managers checking in. So you were your own project manager. You went to all the meetings. You ESLint out all the emails. You did all the contacts.

And that's something you need to be on top of if that is your role because you can't always push back on that stuff if nobody else is going to be doing it. That said, if you do have project managers and it's a little bit larger of an agency, then, you know, you might be expected to not interact with clients very often. And that, to me, is sweet spot for being able to get a lot of dev done. That said, you do need some of that experience. I became a much better I don't wanna say salesperson because it's I wasn't doing any sales, but I I became a much better speaker talking to clients and expressing why I made these choices. And, here's the stack. And what does that mean for you? And what are the technical aspects of these things? And, what do you need to know without giving you too much? And how does this person like like, if I was able to interact with the client a little bit more, I was able to better craft to the back end CMS for whatever I was doing for them. So it really depends on the agency side. I would recommend upping your your communication skills overall or are going to be, like invest time becoming a better communicator via email calendar, to do ESLint, whatever. Make all of those expectations known, and it will help you out greatly in the agency life.

Alright. Let's move on to some sick picks now. I'm going to sick pick a blog post from Matt Stauffer.

He put together this massive I think it's, like, 8,000 word blog post about how to get really good video and audio from like, if you're doing live streaming or videos or even, like, even just wanna have, like, a good quality webcam, and he went through, like, both all of the, like, budgets. So if you only have $100 to spend or if you've got, like, an old SLR this is what Scott does. You've got the Elgato

4 k HDMI input. Yeah. But it's not an old SLR. Okay. It's a Sony mirrorless.

Yeah.

Scott's got a $2,000

webcam. $3,000 webcam. Thank you very much. Me. Yes.

Jeez.

So there's there's that. I I took my wife's old camera and hooked it up, and it looks freaking amazing.

And and it's great. He just, like, went over, like, the differences and pictures of lighting and not lighting and and things like that, and it's all just in Node spot. So if you ever want to know how do I get better, even, I think, even if you're just, like, a a remote worker, I think having, like, a good quality audio and webcam makes such a difference. So I've been on so many awful conference calls with people where they've just got their Android earbuds in, and they're sitting in, like, a glass box or something like that. And the audio is is just awful. Right? So this is cool. Check it out. It's at mattstauffer, m a t t s t a u f f e r, .com. Just go to his blog. It'll be there. I'll put a link in the show notes as well. Cool. I have a book audiobook that I'm going to,

sick pick here, and this is the book called Caffeine, How Caffeine Created the Modern World by Michael ESLint. Now this author is really super good. If you've read any of his other books, I've really enjoyed some of his work.

However, this this book, I am not good with words. I'm just gonna say that. I'm I'm, you know, I can talk on a podcast, but I'm not a good writer, and I'm I'm certainly not an elegant, wordsmith.

This book is crafted so dang good.

It's craft this book crafted good. Yeah. No. I mean, this book is is fantastic.

The way he talks about the history of caffeine, the way he talks about, you know, he he takes sort of, like, an idea, like, well, this caffeine, how could it, you know, how how is it shaped us as human beings and how are we addicted to it? And it makes sort of no judgments upon you. He really takes the stance of my opinion, like the the curious person without being sort of, like, overbearing or just in general judgy of people who consume a lot of caffeine, such as myself. And it really this book, it's not the its intention isn't to make you drink less coffee or to consume less caffeine, but it is there to make you consider it. And so I had a great time listening to this book. It was 2 minutes. If you have an Audible subscription, it's free.

I I breezed through this thing at 2 x, and I really, really enjoyed it. So if you're an Audible subscriber, get this. If not, I'm so sorry. Maybe find it some other way. I'm not advocating for anything, but maybe.

I really enjoyed this book. And if you consume a lot of caffeine like I do, then it's definitely a worthwhile listen. And if you're a history person, it's a very worthwhile listen. A lot of good history stuff in here. Sweet.

Shamelessly plug, my beginner JavaScript course. Go to beginner JavaScript Scott. It's a fun exercise heavy approach to learning modern JavaScript from scratch.

It's beginner friendly. If you're intermediate, it'll help you brush up, fill in the holes here or there. You just go through it a lot faster than if you were a beginner. Check it out. Use a coupon code syntax for $10 off beginner javascript.com.

Word. Cool.

I'm going to plug my latest course that's gonna be out on leap day, February 29th. It's going to be on Framer Motion, creating really awesome interfaces, animations with Framer Motion, where we build some really great stuff. The cool thing about this course is we teach you, you know, topic, topic, topic, and then we do a couple of projects. So we do a modal accordion, topic, topic, topic. Then we teach you a slide in menu, topic, topic, and then we do something practical.

So everything is is all based on not only teaching you the skills, but really building practical animations that you're going to build in your application. If you want practical animations for React, check it out at level up tutorials .comforward/pro.

Sign up to become a Vercel up pro.

Save 25% if you sign up for the year.

Alright. That's it. Thanks for tuning in. Catch you on Monday.

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.