Emily: All right. Welcome back to PodRocket. We have an exciting new episode today. This is our first ever panel episode called The Launch Pad. We're going to be covering a wide range of topics trending the world of web development, as well as going through some of our guest's hot takes at the end that they are fired up about, that may or may not have to do with the web development worlds. But before we get into all of this, let's welcome our panel. First, let's introduce and welcome back Cassidy Williams, lover of memes, software, mechanical keyboards. Cassidy is the CTO of Contenda, Portfolio Partner at OSS Capital, author of the newsletter Rendezvous with Cassidoo, and the host of The Dev Morning Show (At Night) podcast. Welcome back and welcome to the panel Cassidy. Cassidy Williams: Hello, thank you for having me. Yay! Emily: Before we move on, what is your favorite dev joke or meme? Cassidy Williams: Oh, there's so many. There's almost too many options. I think the classics are just doing, "I wonder how they're going to react to that? Well, it depends on their point of view," and I love just going down that deep dive. Emily: Good old puns is really good. All right. Next we have Michael Chan also coming back onto the pod. Michael Chan: What's up? Emily: Also known as "Chantastic." Credited as an absolute goober who's written some genuinely helpful articles. Michael Chan: It's true. Emily: Michael is a Developer Experience Engineer at Chromatic. Speaker, YouTuber, creator of the Lunch Dev Discord server, host of the React podcast, and more. Welcome to the panel, Michael. Michael Chan: Thank you for having me. It's delight to be back. Emily: We love having you. Before we get to our next guest, can you tell me about your recent Twitter name change? It's called Chansaw Massacre. You really like puns. Michael Chan: Chansaw Massacre. Yeah. Yeah. So I grew up with three brothers and everyone called us by Chan or whatever and so we had this fun thing of just making up unique Chan names. So like Chanda Bear, Chansaw Massacre, Chanta Claus, Chanmageddon. Chandemic is a recent edition. Good stuff. Good stuff. Emily: I love it. Cassidy Williams: Django Unchanned. If only you were a Python dev. Michael Chan: I might have to switch just for that. Cassidy Williams: Yeah, man. Emily: I love it. I love it. All right. Next we have Alex Trost rejoining us. And Alex is the lead of developer experience at Prismic and creator of Frontend Horse, an amalgamation of a newsletter, articles, Discord, and Twitch streams teaching about front end development. Welcome back Alex. Alex Trost: Hey, thanks for having me. This is quite the panel to be on. Some fantastic folks. Emily: Very excited. Yes, very excited. Before we introduce our last panelist, Alex, can you tell us why Frontend Horse? Alex Trost: Yeah, the horse part in particular, right? Because that's usually - Emily: Right, right. Alex Trost: Yeah, yeah, yeah. Because I wanted a newsletter and Alex's weekly front end fun time was taken and it just, it's a long domain and I always just thought that .horse is the funniest domain name and for a long time, I think it's like a year, I would tell the story of there's no .dog, there's no .cat, it's just .horse. And I told this story a dozen, maybe two dozen times to folks like, "Ha ha isn't horse so funny." One day in the newsletter I write that and I get a reply from Cassidy Williams saying, I hate to be this person, but there is a .dog and a .cat. And I have no idea why the domain name search thing that I was using at the time didn't have those two. Fell out for those high expense domains. But yeah, Cassidy is the one that made me realize that I've been telling people that they don't exist. Cassidy Williams: I felt so bad. Alex Trost: I'm glad you put an end to it because I would be right now, telling that same story, Cassidy. You saved me from figuring out on air here. Cassidy Williams: I'm glad, but I was also just like, "Oh no, I'm telling him that he's been living a lie this whole time." Paul: That's what friends and good friends are for. Emily: Yeah, that is true. Alex Trost: So, I appreciate it. Emily: Going to our last panelist returning, our Pod Rocket host Paul, joining to round out the panel and being on the Log Rocket, Pod rocket side. Paul, unrelated to WebDev, what is your favorite mode of transportation? Paul: I love this question because I like all the modes of transportation, but I'll probably have to highlight a two seater, 2004 beat up Miata as number one and number two would be electric unicycles. Up until a few months ago - Cassidy Williams: Sounds so dangerous. Paul: Was my main mode of transportation and I still love it and I still ride it everyday. Michael Chan: Oh, is that like a one wheel, is it like self-balancing unicycles? Paul: Yeah, so it's like the one wheels that we all know and love, but it's like a 20 inch motorcycle wheel in the middle. Cassidy Williams: Wow. Alex Trost: See I would've went sled dog. I know you're thinking horse for me, but I'm thinking sled dog all the way. Cassidy Williams: Also, Michael, write this down, Chansportation. Michael Chan: Chansportation! Paul: That's a good one. Emily: That is a good one. Paul: I really like that one. Michael Chan: Emily, I'm so glad you invited us to this pun panel. Emily: It's just all puns. The rest of the podcast. I'm really sorry to everyone listening, but it will only be puns from here on forward. Paul: Chansportation. Emily: Well thank you everyone for joining us. We're so excited to get into it. So we're going to go and discuss recent news in web development. And first, our first topic, is it time to break up with React? I know, spicy right? Couple weeks ago, Marmelab CEO Francois Zaninotto, penned a letter called "React I Love You, But You're Bringing Me Down." This tongue in cheek post covers Francois's issues with React forms being too contact sensitive, issues with Use Effect being too convoluted, and many more. Dan Abramov responded in a lengthy point by point thread where he concedes there are some problems, while others can be worked around, or you just need additional context. We're going to link all of that background information in the show notes so you can have a little bit of context. But, is it time to break up with React? I think the first question, do we need to reevaluate our relationship with React and what should we consider about using React moving into 2023 Cassidy Williams: Before we move forward, I would like to acknowledge that you said context, which is a React pun. Emily: That is a React pun, god damn. Michael Chan: Try to get out, Cassidy won't let us. Emily: Yeah, keep me on track. Cassidy Williams: I will say though, for reevaluating our relationship, first of all JQuery is still very, very popular. And the reason why I bring that up is because when something is so popular, it will probably stay around for a very long time. React is not going anywhere anytime soon. React is still popular, still has millions of people using it, and I don't see it going anywhere anytime soon. So even if you are saying like, "I'm going to try leaning into another framework." You can, but React is going to be around for a while I think. As a first point. And then as a next point in general, I know that I'm kind of reevaluating my relationship with it mostly because I do think that there are aspects of React that are becoming too complex for the average user. Where it's really good for library authors and I understand why they're going in certain directions with that. But as a library itself, if I want to teach someone the basics, "Here's how you make a thing with React." It's starting to become more difficult to explain all the different aspects of it and that has been frustrating Paul: When you were saying if it stands for a long time, it's like that trope, if it exists, it exists in JavaScript. I don't care what new language is out there, it exists in JavaScript, and I feel like Reacts going to fall into that same boat in terms of the web development world. There's always an example in React for everything out there, I've at least searched for. Emily: Something you said Cassidy, that it has become more complex than probably what people need to use on a day to day basis, rather than being for library creators. What are the features that you guys find annoying to use and might seem complicated that other frameworks might be able to address better? Michael Chan: I think, if I could take that, I want to step back a little bit on that question because I think the thing that is problematic about React right now is that back in 2018 I think it was, there was this huge shift in the way that we were supposed to write React and the guides and documentation on Reactjs.org did not change until today. They're still the way they were back in 2018. Cassidy Williams: The fact that the docs are the new docs are still in beta is infuriating. It's been years. Michael Chan: I see posts like this all the time and first of all when you shared this post with me, I was like, "This person either owns an agency or is shipping a React library." And then I found out that it's both of them. Paul: It's the library. Oh it's both. Right, right. Michael Chan: Yeah, it's both of them. Yeah. Posts this are really just playing the game of, you find something that's popular and then you say that you don't like it and then you get engagement on it. But I do think that for the last four years React has had this incredible problem of nobody knows how to write it anymore because there's no recommendations. All of the docs are way out of date. And so it has made it impossible to really know what the best way to write React is, unless you click on every response from Dan Abramov on Twitter. And I think that that's really the thing that kind of sucks about React right now and what's left a gaping opening for literally every other library in the space right now. Emily: So how could you see the community or the React team coming and trying to rectify some of these issues? What would you like to see to make it more usable, make it more friendly to devs? Michael Chan: I think part of it is like, it's almost too late I think. And this is what I hear when you're saying that it's too complicated now, is that we've left too much of an opening. Because React wasn't saying, "This is not important, this is not important, these are for libraries, whatever." on the front page. It's left this opening for a bunch of expert React developers with my fingers to come in and talk about what really is important in React. And I think it's just totally ruined the way that people write React. It's not fun anymore because of all of these experts and consultants in the field. They're telling you to do things a certain way that is truly terrible and not fun and not good even. Alex Trost: I've got to say that if you were to show me, if I'm just starting out as a web developer, and you show me the syntax for a handful of different frameworks and say, "Hey, pick which one kind of makes the most sense to you, pick which one you think you might enjoy working with." I'm going with a Svelte, I'm going with a Solid, I'm going with something else. And I think the article kind of pointed that out really well where it's like, "Hey, this is a form in React, this is a form in Svelte." And forms, I mean are kind of a really easy, it's where you can beat up on React kind of easily, right? They've never been fun. To get really deep into forms in React, you kind of want to pull in something, you want to pull in a library. But yeah, I am not going for React if I'm starting out as a web developer right now just based on syntax, based on higher ability, based on how many jobs are out there in the market, all that kind of stuff. I think I'm still going with React. I would still recommend that in terms of someone getting a job. But yeah, I think Michael's right in that there is a gap for nicer syntaxes and just different ways of doing things that is not fun in React anymore. Me, I'm going Astra and Svelt with my personal projects because I enjoy it. It's just a lot more fun. Cassidy Williams: I'm playing around with Astra and Preact because I personally am really comfortable with the React APIs, but I just have not been a fan of the direction where it's going and so I can at least still have those APIs with Preact. And I think what you asked about the React team, I think that there's been kind of a lot of chaos on that end, both with meta and the metaverse end of things and how they're having to serve that type of audience. And then also just the fact that the React team isn't all under that Facebook meta umbrella anymore, now they're also have team members on Vercel. It feels like there isn't as much unity on the team and they haven't been listening to the community concerns. Or at least they haven't been reacting as if they are listening to the community concerns. Because we've been asking, again, for docs forever. We've been asking for adapters and different ways of doing certain things forever. At least that's how it feels. We get news via random Dan Abramov tweets, which I have ranted to the team personally about. A lot. Alex Trost: Do you think that lack of speed is because of the size of React and how many people they need to satisfy? The number of stakeholders starts to slow down things as that grows, right? Do you think that's the issue or do you think it's something else? Cassidy Williams: I think there's some aspects of it. And that's the thing, I don't mind that there's not a lot of speed. I think slow and steady is a good thing. If we talk about really robust Python frameworks or something, some of them don't do releases except every two years, once everything is very steady. I think that's fine. But things like documentation, I think that has pointed out a lot of issues. Not only with how things have been implemented, but also with just how things should be done. Because again, if you want to know how to write React really well, you don't go to the docs, you go to someone else on the internet who is loud, who happens to have content about it. Paul: That's how I learn React. Cassidy Williams: That's how I teach React. Emily: So we're going to wrap up this topic. Are there any, you said Cassidy at the beginning that React is here to stay for a long time because it is popular. And Alex also said, "If you're going to get a job, you should know React." Do you see any other frameworks coming up behind React that could potentially overtake it in the near future or any other frameworks that you're excited about? I know you mentioned Pre-React or Preact? Cassidy Williams: Preact. Emily: Preact. And Astra, any other ones that you guys are interested in? Paul: One thing that I think is interesting I'm seeing as a trend is people are going back to basics. There's a PHP resurgence happening right now and that's cool. Let's bring back some PHP frameworks. I'm not saying if that's a good thing, it's fun. So we should do it. Cassidy Williams: I feel like a grand majority of JavaScript frameworks are just trying to recreate what PHP can do. So for better or for worse. Paul: That could be a hot take, that's awesome. Alex Trost: Literally my hot take. What are you doing? Cassidy Williams: Oh no! Alex Trost: I mean my toes are right here, you're stepping on them. Back off. Cassidy Williams: I'm sorry. PHP. But I do think there's again, there's kind of like the library end and the framework end. I like that for something like Astra and some of the other frameworks that have come out, it feels very comfortable as someone who knows HTML, CSS, JavaScript, it feels like I'm building a plain website with some added things and if I want to add React into it, if I want to add view or something into, it works really well. So I'm currently very much into that right now and I like the javascripty end of making Reactive components. The puns. And so that's why I've been playing more with Preact and I still like React, I'm just annoyed right now. Emily: That's totally fair. We're here to air our grievances I guess. Cassidy Williams: Oh my god. Alex Trost: Oh sorry. I have, I guess a hot take about all that. I think there are a bunch of libraries that are nipping around the edges of what React is and they're making it a little bit better. A little bit better isn't going to displace it the way that React kind of displaced JQuery arguably, at least in the mindset and jobs and stuff. I think that the next thing has to be groundbreaking and I think that that's probably going to be somewhere in the graphical user interface space. I think there's going to be huge advancements there and I think that it's going to be something completely different that will replace React. And I think that would be awesome. I think it'd be amazing to have better tools that are more in that graph, legitimately in that graphical layer that you can connect to APIs and back ends and not have to worry about all of the stuff that we do right now. I think that would be incredible. So I don't know, that's what I'm thinking. Emily: Love it. We love, well all of this. Moving on to our next topic, if we're all done with React. Should we finally stop using web components? So, I noticed last week, so many people on Twitter were just ragging on web components and it wasn't like it was a trending thing. Just people were talking about how much they hated web components. I know Theo Browne from Ping.gg said, "Wow, people still think web components are good." Matthew Phillips of Astra posted an article about where web components went wrong and how we can turn around and Brian Vaughn of Replay also sarcastically tweeted, "Remember web components?" So what's with all the web component hate right now? And maybe before we get into that, can someone just briefly explain what web components are and then we can get into why does everyone hate them and should we hate them? I guess. Cassidy Williams: I don't know why or when they came to be, fully. But long story short, web components are the ability to create custom elements. Paul: Oh, they're like islands. Cassidy Williams: Yeah. They're components. They're custom elements that don't require React or something to work. They were supposed to be just kind of a template that you can create with JavaScript classes. Correct me if I'm wrong. Alex Trost: Yeah, so no, I think I'll just add a little bit to that. Yeah, I think what you said is perfect. My understanding is that basically, allows you to create your own elements kind of the way that the video element exists. And it has a shadow dial, that's where the buttons exist kind of tucked away. You can't inspect a video element and see the buttons that are there, that's tucked into the shadow dom. So these elements, these web components that you can define with a JavaScript API that all the browsers agreed to, you then can tuck that nice little web component into its own little shadow dom. And the nice thing about it is that it's all self-contained in that shadow dom. So if you pop a web component on a webpage, it's not going to break the rest of your webpage because they can't reach out and start just messing with things. It also has scoped styling inside of it. So it's nice and contained so you can pop it anywhere. It's going to look good. It's going to look the way that you expect. That's also kind of its downside, is that it can't affect much else. And web component's, cool. But what about passing data around? That's kind of a bigger problem with making UIs. So web components kind of solve part of it there, but you kind of have these downsides. So they're cool in that they are interoperable, they're interoperable. Cassidy Williams: That was great Alex, good job. Alex Trost: Thanks. I'm learning to talk. And you can use them, you can drop them into a Next Day Site or anywhere because it's just going to work on the web. But you get a few downsides, and so that's kind of like, I don't know, brief overview. Correct me if I'm wrong with any of that because I'm not a big web components guy. Paul: Were they inspired by the ethos that caused the React component or the framework? Alex Trost: Other way around. Paul: Other way around. Okay. Alex Trost: So they were pitched back in 2012 ish, I want to say. You can quote me on that and just yell at me, I'm fine with that. I'm okay with abuse. 2012 on the nose, I don't know. But React I think came out after they were at least announced. I think the issue with web components is that they were like, "Hey!" And I think they is Google in this case, I believe. It's like, "Hey, we've got this idea for components." And then they took a few years to actually launch anything real. Cassidy Williams: And I think that was when they made the Polymer framework, right? Alex Trost: Uh huh. Paul: Yeah. Alex Trost: So that's the thing, it's like, "Hey, don't use frameworks, use web components. And because the web component API is really hard to work with, use Polymer. It's a framework." Cassidy Williams: And Polymer will let you make web components. Alex Trost: Right. That's where we start to see a little bit of a flaw. And then L-I-T, or think you just call it Lit, but I get yelled at by the kids when I say that. Cassidy Williams: Would you like to know a fun fact about Lit? Alex Trost: I do. Cassidy Williams: Because of course I used to own the GitHub organization, Github.com/lit and I put just a bunch of random stuff in there that just really, just boring libraries that I made and I was just like, "Eh, it's kind of fun." And then my friends and I would put sign projects in there as just a placeholder. And then one day Google reaches out and they're like, "We want that." I'm just like, "You have money, pay me!" And then they're like, "You can have some t-shirts." And I was like, "Nah." But then they kept coming back and asking for Lit and I was just like, I wish I knew what to ask Google for because they clearly, this team doesn't have a budget and I feel bad, but also I feel so powerful. But anyway, I got an Android test phone in exchange for the GitHub Lit organization, Paul: A test phone? What did you do with that? Cassidy Williams: Just like what I test UIs on and I placed [inaudible] on it. Paul: Oh okay, it's an Android phone, but you use it to test. Yeah. Okay. I thought they had it laying around. Like, "I don't know, the guy from UA sent this over, here." Cassidy Williams: Experimental hardware. No, it was some random Android phone that they gave me in exchange for the GitHub organization. The end. Alex Trost: Well that's what it's worth. Paul: Do you think it was a boil the ocean thing? Why it didn't work out as well? Alex Trost: My plan to kill all lobster? What's a boil the ocean? I don't know. Paul: The federal government's already doing that to the the poor Maine lobster fisherman. No, I'm talking about- Cassidy Williams: That does not sound lit to me. Alex Trost: This isn't lit. Michael Chan: Now all I want is a lobster roll. Alex Trost: I would love a lobster roll. Paul: No, I mean the web components, they didn't really have a focused direction, so they tried to do a lot while other things were going on so they couldn't say, "Hey, we're really good at doing this one thing really proficiently." And so you got all these dangling strings. Alex Trost: Yeah, I so definitely am not the expert here, but my general overview or understanding is just that things moved kind of slow and so compared to things like React, even things, newer frameworks like Svelte, you name it, you have to... So I think that web frameworks kind of suffer in the same way that governments can suffer with bureaucracy. Where web framework, web components need to get sign off from all the different browsers. Where like, "Hey, we're all going to agree to this API." And at least this is the vibe that I kind of get is that, things are moving slow because we want everyone to agree to how web components are going to work. Where Svelte doesn't really have that issue. Rich Harris was just like, "Yeah, I think it should go this way." And he did it and it just was able to kind of progress. And web components was also using scoped CSS and that was going to be part of browsers and then it got abandoned. So it's just things happened where web components needed more buy-in from all of the browsers and that's just a slow, that's a tough process. Yeah, that's really hard. Michael Chan: And they're like, if I'm not mistaken, they're kind of like without champion right now. And so all of the progress that was being made on them, they're incomplete. One of the things that I was most excited about with web components is they had a proposal for is. This thing is something else. And so you could make a button and then you could say it is, and then give it a web component to enhance it with whatever it was that you wanted, with whichever class you had set up your custom element as. And the cool thing about that is that it is a button, but then you get to do some other stuff to it, which is incredible for design systems, right? Because it's like, "Oh hey, I have a button and I want it to look like this and so I've applied this custom element to it." Which has classes and some IDs or whatever, however you want to style that thing. But all that stuff is just not happening. We have what we have and it's just incomplete and it kind of sucks. And if you're going to use a framework, it was Polymer, Stencil, now Lit. Just use a better one. Just use a better framework. Paul: I do know that Google is trying to be that champion with Lit. If you go on Web.dev, which is a really great resource overall for learning. Cassidy Williams: Yeah, they have good posts. Alex Trost: Yeah. Like HTML, CSS. Yeah, they put out really high quality stuff. They are definitely trying to champion Lit in particular. And what you said about design system, I think is spot on where it's nice for a design system because with that button example, say a company has, we've got a Next.js site over here, we've got an Angular site over here, we've got a Nufts site over here, you can use that button in any of those. So they like that interoperability, hey, for design systems. So it could be nice there. We don't have to write that same component four or five different times for all the different contexts that it's going to be dropped into. Paul: Like native development. Alex Trost: Basically. Paul: And done. Emily: All right, so web components, yay or nay for this year. Yay. Cassidy Williams: Yay. Alex Trost: I mean 2023 maybe, we'll check back in. I'm okay with the others that we've got. Cassidy Williams: Yeah, I'm not against them. If they can solve a problem, great. But I'm also, eh. Alex Trost: Yeah, super meh. Emily: Yeah, love the consensus. Alex Trost: If you're a listener, if you're into them, awesome. Yeah, check them out. If they're your thing, awesome. I love it. I support you fully. Not going to yuck anyone's yum. Go for it. Emily: All right, great. Great wrap on web components. I just want to take one minute as we're kind of in our halfway point. If you are enjoying the episode, please follow us on Apple Podcast. This really helps Pod Rocket tailor the content that you really love to what you want. So definitely follow us. We can get insights, we can bring on more guests like Alex, Cassidy, and Michael. And you'd be doing us a solid, so please follow Pod Rocket on Apple Podcast. All right, last topic for today. Before we get into our hot takes. Should we not use Prettier anymore? Anthony Fu recently published a blog post called "Why I Don't use Prettier." And detailed why he thinks it's not as great as we all thought it was. He says that the fact that it's opinionated has issues with auto wrapping, lynching, and more. So do any of you use Prettier? And if so, is it worth the extra headaches? Cassidy Williams: My code is gorgeous when I type it without any linters or formatting whatsoever. And so, why use Prettier when it's already there? It's already done. Alex Trost: Your fingers have graced the keyboard, blessed the code editor, and just ship it. Michael Chan: It's already prettiest. How can it get prettier? And that's why Cassidy doesn't write tests. She doesn't need any of, it's good to go. Cassidy Williams: I mean, if your code is good, why would you write tests? Paul: Why bother? Cassidy Williams: I am saying this all in jest for all the men out there who are going to- Alex Trost: Your tests are in jest? What are- Cassidy Williams: Hey oh, that was pretty good. I use it just because it's kind of my default formatter in VS code. The end. Paul: I don't like Prettier. Michael Chan: That's good. Oh, Paul, say more. Paul: It actively upsets me. Cassidy Williams: Whoa. Paul: Yeah, because I'm very picky about how I, I want maximum readability. That's what matters to me in the end. And if anything subtracts from that, then I don't want it. And the majority of the time I feel like I've worked in very close knit startup sort of environments. It's like we have really harsh line limits. I mean, of course it depends on the team you're with and stuff, but more often than not, I feel like my readability suffers. And if you go in and you put a little bit of effort and then you can lint the files you want to, if they're really big, sure, I'll just Prettier it. But sometimes I want a big long string. Don't tell me I can't have it. And when you download my file, don't change it. Thank you. Emily: Any rebuttals? Michael Chan: It's so funny. All of these topics kind of make me angry a little bit. When I read this article, I was like, go look at a tree or a river or whatever, something that's actually beautiful. Like code is- Cassidy Williams: Touch grass. Michael Chan: Yeah, touch grass. Paul: Yeah touch grass basically. Michael Chan: Code is not beautiful. The most beautiful file on your system is just an empty text file. As soon as you start typing, you ruin it. What prettier gives you is the ability not to have to think about it. Right? And that goes your point, Cassidy, right? It's just default. It's there. It puts stuff around. That's fine. I will totally admit I chaos mode Prettier. Every one of my projects has a different Prettier setup. Paul: No. Cassidy Williams: Wow. Paul: No. Michael Chan: Just because, just to remind myself how much I don't care. Some have tabs, some have commas, semicolons. Paul: Of your mortality? What are you reminding yourself of? Michael Chan: No, just that it doesn't matter. Right? That is part of the developer experience that truly doesn't matter. You can get used to anything. And so it's just a thing that's formatting it so it's not all over the place. So yeah, touch grass. I mean it's kind of like the Oxford comma where yeah, it doesn't matter, but at the same time, use Oxford commas. Emily: The Oxford comma definitely matters. I will die on that hill. Cassidy Williams: That's right. Michael Chan: But we're still able to, I mean, although, yeah, I go down the Oxford path. Emily: Eats shoots and leaves. Paul: Yeah, Right. Emily: No, Oxford comma means something very different. Paul: Exact. Yeah. [inaudible] Emily: We're getting into my world now. So keep going. Michael Chan: Did someone say commas? Paul: Yeah, okay. Emily hold on. Cassidy Williams: Calm down. Michael Chan: I really like it. And I don't think it's because of any opinion that I agree with. I think I just like code formatting in general. It's not Prettier specifically. I think it's just, one, I don't have to make a decision. That's awesome. I am so okay with just like, "Hey, someone else made a decision. It's a pretty good decision. I'm going to think about other stuff." Cassidy Williams: Pretty good decision? Michael Chan: It's the prettiest decision. No wait, no, Pretty, damn it, I'm going to get- Cassidy Williams: Dang it, so close. Michael Chan: You're were so close, so close. And yeah, it's one more decision I don't have to make, As Cassidy said, it's already set up in VS code. I just run with it. And I love hitting control S and just watching my stuff move around and be nice and perfect. It's just not having to worry about, "Oh, I have to tab over a few times." My muscle memory is gone for that kind of stuff. I just write garbage code all in one line, hit save, and- Cassidy Williams: Then it's pretty. Michael Chan: Pretty darn good at the end of it. Prettier darn good. Cassidy Williams: Well, with my Vim config too, I can just highlight lines and hit the equal sign. Done, format. I don't have to care. It's nice. Paul: Maybe it's like the culture around how we use Prettier. Because in a lot of contexts I've used Prettier where it's very strict and if we're going to use it for the... I just don't want to think for 90% of what needs to be done and hit save. You need a very lenient Prettier configuration and lint configuration. Maybe that's some disconnects happening. Michael Chan: I think that this does go to the point of the article and something that I agree with the intent, but disagree with the outcome. Which is like, okay, for like CSS, there are plenty of times where I will line up my properties just kind of knowing that they're going to be the same length or whatever. I put them all on one line and it's a really nice way to edit them with a multi cursor type of thing. And so I like that. In those handful of files when they show up, I just disable Prettier on that section of code. I think that's the thing that's kind of weird, the all or nothing. If it's 98% good, just disable it the 2% of the time that you're like, "Ah, I don't like the way it formatted this." As opposed to Prettier sucks now. That feels weird to me. Cassidy Williams: So we're all pretty pro Prettier. Paul: I mean, okay, so I'll admit I use Prettier in all my projects, but the thing is I use it- Michael Chan: Did you write this article? Paul: I use it very leniently. I can have a 200 character line and it'll keep it. And there's sometimes that I like that. Yeah. Alex Trost: If I have to scroll horizontally, I close my computer for the day. I refuse. On websites, in code editors, nuh uh. I'm not doing that. Although there is text wrap, that part's fine. But I do agree with what the article said, which is if you're looking at an object and all of a sudden some of the properties are all in one line and some get broke into multiple lines, it just becomes kind of a readability nightmare. So Paul completely agree with that. I think it's just something that, I am willing to try other things, but having to go back and forth. Michael, I'm still haunted by what you said of different setups for each project. Michael Chan: You should try. Give it a try. It's great. It's great. Paul: He looks alive. Alex Trost: He does. He looks fantastic. So I mean maybe that's what keeps him looking young. That might be it. Emily: All right. Well, great to know we're all on the same page about Prettier for the most part. For the most part. Paul: For the most part. Yeah. Emily: That ends our recent news discussion. Thank you all for chiming in and giving your opinions. It was very informative and so many puns. So many puns. So next we're going into our final segment called Hot Takes. And this is where each person is going to get two minutes, they get to rant about whatever they want for two minutes. And I will tell you when your time starts, and I will tell you when your time is up. It should be Webdev related, but you never know what's going to go on. You never know what might happen. So Cassidy, you are up first. I'm going to start the timer. Are you ready? Cassidy Williams: I'm ready. Emily: Perfect. All right. And begin Cassidy Williams: Fricking JavaScript, am I right? Okay. So what annoys me currently in the web development world is the lack of accessibility of understanding how websites are rendered. Because there's server side rendering, aka SSR, There's static site generation, SSG, there's incremental static regeneration, ISR, there's DPR, there's DSG, there's edge rendering. There's all of this stuff where it's all of these different letters that all of these different frameworks and hosts and everything are tossing around without explaining them very well. And so many times people are just like, Oh, well I have to use ISR because I use Next.js. No, you don't. You don't have to. You can, but that's not necessarily what you have to do. You could just build a static website if you want to. There's so many issues that come with this over complication. Because you get websites that could be something pretty simple and then you over complicate them to the max, to the point where they break on the most dumb little things that they shouldn't break on. And there's just this pendulum shift where we went like, "Okay, everything is server rendered." Oh SPAs are a thing. Because that's another one where it's a single page application and suddenly wait, no SPAs are bad. Wait, what if you did just static everything and added dynamic things that you progressively enhance? Sure. Wait, no, the edge. What's the edge? Well, it's kind of like servers. Wait, no. You could use servers but then enhance it with the edge. There's just all of these different things and people have different definitions of it and it's infuriating. I don't like that there are all of these terms without the education around it. And that being said, why are we focusing so much on code when we have moose on this planet that are massive animals? You can't cut me off. They're enormous. Paul: We've got to cut her off. We're sponsored by Big Moose. You have to stop Cassidy. They're going to cut our funding. Cassidy Williams: You good Emily? Emily: Yeah. I was waiting for that to drop. It came so late. Yes, we are sponsored by Big Moose. Paul: Emily, I'm disappointed that you... Was this 10 seconds? Emily: That was 10. Paul: Why wasn't this 10 seconds Emily? Why did you- Emily: For those listening, we're all making moose antlers with our hands. Cassidy Williams: A moose can outrun a human at five days old people. Paul: Wow. That's pretty cool Cassidy Williams: They're born knowing how to swim. Emily: You're intense. Paul: What? Alex Trost: They can dive deep down, honestly, startups are looking in the wrong place. Hire moose, I don't know Cassidy Williams: They are superior beings. They dive so much. I didn't know that they did this, they dive so much to eat vegetation on the bottom of bodies of water that one of their regular predators are orcas. Paul: Wow. Cassidy Williams: Yeah. Isn't that wild? Could you imagine scuba diving and then a moose is in front of you, this gigantic animal where their antlers can be up to six feet wide. They can weigh up to 1800 pounds. Michael Chan: Can I give my two minutes to Cassidy? We all see the Florida Cassidy. Emily: Really. Well thank you for the- Michael Chan: She's just getting warmed up. You know this, you know this. Emily: We're going to come on again and just go into deeper dive of moose. Michael Chan: A deep moose dive. Emily: Well thank you Cassidy. We're now going to move on to Michael. Again, you have two minutes and I'm going to start the timer now. Michael Chan: So this probably shouldn't take too long, but I think it's criminal that we don't use ES modules better and more. There's this one ESlint rule called React no multi-component or multi-comp or something because they couldn't bother to write component all the way out. This is the worst. I think this is the most criminal thing that we've ever done in the React community is allow this to exist at all. Because I think one of the things that actually separates React from all of these other things that use a single component file, is that you can actually put multiple components into a module and then use each of them as named exports. The fact that we're not doing that, it makes no sense to me. It's this beautiful feature that we got in the language and then everybody decided it was worthless because we did it the wrong way with common JS for a really long time. Anyway, I think it's absolutely ridiculous. I don't know why people use this. I have never understood this. I have complained about this ever since ESlint React was made. I try not to complain about things that people have made, but this is just an abomination. Emily: Yes. Love it. Thank you. Alex Trost: The moose of the JavaScript world, would you say? Cassidy Williams: Moose are not an abomination. They're amazing. Michael Chan: Oh, wait, wait, wait. Hold on. Hold on. Can we back up? Are we pro moose or anti moose? I'm so confused. Cassidy Williams: Oh, I'm very pro moose, but I fear them. Michael Chan: Okay. You fear and respect them. Emily: It's a healthy fear. Michael Chan: Oh wait, did you read that as anti moose? I was- Alex Trost: Oh Yeah, I'm angry at moose right now. Cassidy Williams: Because you're inferior to them. They can eat 70 pounds of twigs in the summer. Alex Trost: I think I'm out of time, right Emily? That was my- Emily: No, you've still got to go. Alex Trost: All right. Emily: Which you are next. You are next. Alex Trost: All right. Emily: You can or cannot talk about moose, but I think obviously Cassidy has you beat on that. Alex Trost: Can I make up facts and see if Cassidy wants call me out on them? Cassidy Williams: False. Emily: We don't want to get into a huge fight today. Maybe save that for another. Paul: Yeah. Does moose taste like chicken? Emily: I feel like we're just procrastinating now. Alex Trost: I am now. I mean honestly, how am I going to top this? These moose facts, everyone is going to tune out, say, "All right, moose facts are done, let's get out." Emily: We pepper them through so they keep listening. Paul: That's perfect. Perfect. Emily: All right. Alex Trost: That should be a teaser. Ok, perfect. I can go. I apologize. Emily: Got two seconds on the clock, go. Alex Trost: Two seconds? Emily: Two minutes. Alex Trost: That's all I need. That's all I need. Mine's a little bit like Cassidy's. It might sound like the reverse a little bit, but I agree with Cassidy and not about the moose thing, about the accessibility to how things are rendered and how things come about and all the proliferation of just new technologies and web frameworks and everything. But one criticism that I don't like when people just kind of fling it and dismiss something, is when like, "Oh, isn't this just PHP? Isn't this just something that we've had 20 years ago?" Because things come back to Eleventy. I remember that being dismissed. "Isn't this just Jekyll?" But it's awesome. It's this new thing. It can be a wonderful new technology and be inspired by something else. With design, you don't kind of just dismiss that out of hand, if a design thing comes around, if fashion comes back around, ideas in programming are going to come back around. We're going to reuse things that have been around for 5, 10, 20 years. That's okay. That's okay. It's okay to criticize something, but also let's not just dismiss it because it reminds us of an older thing. But if it's complex and people over complicate what should be a static site. Cassidy, I completely agree. But when we just dismiss something for being kind of like a thing that's been around for a while. Like, "Oh, it's just Objectory programming again. Or this is just Fortran." Tired of hearing that one. Emily: What are you building? Alex Trost: Yeah, complex. Yeah. So I don't know, just, yeah, let's let the old become new again. But also let's keep it simple. Emily: Paul, you are up and you have not two seconds but two minutes on the clock starting now. Paul: Mine is writing cloud native serverless architectures is analogous to taking an Uber everywhere we go for the rest of your life and it's pointless and stupid. So it works if you're a CEO and you have a chauffer and you're like, I can just burn through this pile of money and it doesn't matter, just drive me everywhere. But if you know how to do something, I think we're bleeding into this era of computer science and capitalism that is uncomfortable. And I would like any time you have an effort or time as a team to be brought back to using open source technologies, it's good. We're getting to a point in open source communities where you can find support. There's a Discord server. There are probably a thousand Reddits, Discord servers. Don't ever tell me to not use Reddits. There's a way that you can make it work. So I urge people to step outside of the easy solutions that the big companies might provide because our open source communities are always growing and they're really good. Emily: Beautiful, right under time. Alex Trost: I like it. Emily: Cassidy, any more moose facts before we head out? Cassidy Williams: Their hair, similar to a polar bear. Their hair is hollow and it gets darker over time. So you can kind of tell how old a moose is by how dark their hair is. They live for up to 25 years and don't get me started on- Alex Trost: They keep their hatred in their hair. That's what it is. Michael Chan: That's it? Cassidy Williams: Yeah, 25. But they're so big, it makes sense. They're the tallest- Paul: That makes no sense. Cassidy Williams: The tallest animal in North America. They're huge. Emily: Well with that, thank you all for joining us today. Honestly, this has been so fun. You guys have amazing moose facts, puns, actual web development discourse. Alex Trost: The last part was an accident. We apologize. Moose, I mean it feels like that needs to be a new framework, like a competing JavaScript framework at this point. Right? Cassidy Williams: I've thought about it deeply. Emily: Cassidy is on it. Michael Chan: At least get the GitHub so that you can sell it to someone. You can sell it to Apple for an iPhone in a couple years. Cassidy Williams: That's true. That's true. Because they are apparently giving away test iPhones. Emily: Thank you all for joining us. If you don't mind just going around and telling everyone where they can find you online. Cassidy. Cassidy Williams: I've been Cassidy Williams. You can find me at Cassidoo. C-A-S-S-I-D-O-O on most things. Michael Chan: I am Chan or Chantastic. Yeah, Chantastic most places. And then Chan.dev is my site right now. Emily: Alex? Alex Trost: Yeah, Twitter, I'm @Trostcodes. That's T-R-O-S-T codes. And then my site is Frontend.horse Emily: And Paul. Paul: I'm mostly just on Twitter @Pinealytica. P-I-N-E-A-L-Y-T-I-C-A. Emily: Perfect. Well, thank you everyone again for joining us. Also, thank you for listening to Pod Rocket. You can find us at PodRocketpod on Twitter and stay tuned for hopefully more Launch Pad panel episodes. Thank you again everyone for joining us and have a great day. Paul: Thanks Emily. Cassidy Williams: Bye. Alex Trost: Thanks for having us.