Emily Kochanek Ketner: Welcome back to PodRocket. I'm Emily producer for PodRocket and we're back with the launchpad, our monthly panel episode where we cover a wide range of topics trending the world of web development, as well as going through some of our guest hot takes about what they're fired up about in the world of web development right now. But before we get into it, let's introduce our panel. First we have Lindsay Wardell. She is an engineer at NoRedInk and speaks a lot about Elm in view. Welcome back, Lindsay. How are you doing today? Lindsay Wardell: Doing all right. Thanks for having me back. Emily Kochanek Ketner: Great, of course. Next we have Tejas Kumar. He's an international keynote speaker, YouTuber, angel, investor and advisor. We just had you on as well. Thanks for coming back. Tejas Kumar: Yeah, it's great to be here. Emily Kochanek Ketner: Awesome. Then finally, we have our PodRocket host, Paul Mikulskis joining us to round out the panel. Hi, Paul. Paul Mikulskis: Hi, Emily. Thanks for having me. Emily Kochanek Ketner: Of course. All right. Now that we're all here, we can get into the recent news. Let's start with topic number one. On February 1st, Netlify announced that it would be acquiring Gatsby. Its main JAMStack competitor. Netlify, CEO, Mat Biilmann said it in a press release. "The future of the web is composable architectures. The acquisition of Gatsby not only accelerates our product roadmap, but more importantly allows us to provide web developers with increased flexibility and choice in building composable web experiences." Biilmann cited Gatsby's recently released Valhalla platform as providing an area of composable architectures that we've had an eye on for a while. This contrasts with Netlify pioneered JAMStack. So this acquisition leads me to two main points. One is the future native composable architectures, and two, what's the future of JAMStack? Before we answer those two questions, can someone define what composable architectures are and what JAMStack is? Lindsay Wardell: I'll jump in and say my understanding of the two. So for me, JAMStack is a website that is not necessarily running a independent siloed backend. You're going to be relying on services rather than having your own server that you're hosting an AWS or something like that. So when I'm building websites on Netlify, I'm relying on netlify functions. I'm relying on Firebase, I'm relying on GraphQL access to databases or something along those lines. Other services that I am not running myself. That is my understanding of the JAMStack. So things like 11ty provide you a JAMStack site because it is a static site that then can have access to APIs in the background, whether those APIs are accessed on the client's browser or not. That's kind of my understanding of a JAMStack. Composable architecture to me is just an extension of that where it's easier to plug all of these things together. So using 11ty as an example, if you have 11ty and you have Contentful or some other backend for your CMS, those things play well together. But putting it into this term of composable architectures, I believe is supposed to make it. So all of these backend pieces fit together into a single service or graph is one of the other terms I've heard for this. Then 11ty could just talk to that graph rather than talking to the independent services. Tejas Kumar: I agree with that. I also think to extend this idea of composable architecture, because when I think of composition, I think of components and composing them together. When I hear composable architectures, I think of that because Gatsby, if I'm not mistaken, started a enterprise offering where you can deploy functions and things like this. This is growing a lot. Set in Netlify's press release I think. So composing the architecture of Gatsby's cloud offering with Netlify's cloud offering is also architectural composition as I understand. So yeah, that's kind of what I get from that. Paul Mikulskis: Do you feel like JAMStack is accelerating composable architectures? Because when you say composable architecture, I'm thinking, okay, I can do less. I can focus on my little niche right here and I don't have to worry about these other systems. Do they go hand in hand in your mind to just ... Tejas Kumar: Yeah, and no, it's hard to say, but I do think when you think JAMStack, it takes more about to composing because the A and Jam is JavaScript APIs and markup, you tend to think in fragmented APIs and composition as opposed to thinking about one monolithic service somewhere that my team maintains. Right? So yeah, I do agree with you. I think it does lend itself to that. Lindsay Wardell: Another thing that's interesting on the composable architectures is that idea of graphs. So I know Netlify was working on Netlify graph, which was recently kind of soft canceled. I saw some speculation from Fred over at Astro that Netlify graph was soft canceled because of this acquisition or this is what's driving the acquisition of Gatsby. But there's also tools like steps in that are really geared towards combining all of these different APIs, this fragmented ecosystem that we have right now in the JAMStack and bringing those into a centralized location, which I think is really interesting. I've been working on a personal site for a gaming club and I'm having to use Discord APIs, I'm having to use Firebase, I'm using a number of APIs and it'd be nice to just have a single interface to access them all. Paul Mikulskis: I was just going to add on and say, Lindsay, you're totally saying you're not off base with that one because the leader of Netlify fed themselves that Gatsby had a sector of the market that they were eyeing for a while and they were already building in that direction and they were just like, "Oh, well, you know what? You guys really took the torch on this one, so we're just going to acquire you." So your hunch sounds very accurate to what actually happened. Tejas Kumar: Is Netlify graph the evolution of what was once one graph? Lindsay Wardell: I believe it is, yeah. Or was. Tejas Kumar: I see. I didn't make that connection, but yeah, I agree also, Lindsay, with what you said. Paul Mikulskis: Tajas, when you see the netlify graph coming out and you're like, "Oh, yeah. I saw this in the past and I see it now and I agree that it's dying." Do you feel like this is offering a role for Gatsby to sort of die itself or is it going to be its own ... Okay, you're shaking your head, like no, it's going to remain its own player. Tejas Kumar: I doubt they'd make an acquisition for something to die. I think one graph kind of didn't pioneer this composable architecture thing because I still remember the demo before it was even acquired by Netlify. It's author composed GitHub and YouTube and Twitter APIs in one request. I thought that was pretty rad. This was the appeal of Gatsby as well. You build your static site at build time, fetching data from multiple different APIs via graph, right? So the fact that both of them solved the problem leaves less room for Netlify graph. That's what I mean when I say I agree for netlify graph. Paul Mikulskis: Got you. Okay. Tejas Kumar: I think there is room for composable architectures and I think Netlify is hoping that Gasby fills that or the new acquired Gatsby beef fills that need and expands Netlify's offering. Paul Mikulskis: The one fear and you guys please tell me that this is unfounded. But when I'm thinking about developing the composable architecture, my brain feels so good immediately because I'm like, "Oh, I don't have to worry about running this. I don't have to worry about running that. I can just ping my a GraphQL service. I can use Firebase off." But at the same time, I almost feel like I'm removing my power as a developer because I'm giving a lot of these backend margins to big companies that are going to be filling that gap for me. I wonder if either of you have a thought on if that's a good thing or a bad thing for the developer community. Tejas Kumar: For me helped me move faster. There's so many things I don't have to worry about. So it's a good question about dipping into margins to essentially pay for someone at these problems to become someone else's problems. But if it's a solved problem for me, yes, the only time I would be suspicious is if it introduces lock in and if I end up being handcuffed to a vendor, then I'd be suspicious. I just actually spoke to a friend yesterday, they have a bunch of Azure credits with their new startup. They're hesitant to build specifically on Azure functions because the code you write for Azure functions doesn't really translate to other functions providers. So that's the boundary I feel like where I'd start to get uncomfortable with these people solving problems for me. Paul Mikulskis: Right. Tejas Kumar: Yeah, I'm curious what Lindsay has to say about that. Lindsay Wardell: In general, I agree. I think it's something that needs to be watched to make sure that if you need to change what tools you're using in the backend, you're able to do some migration. You don't want to be locked in to any one particular thing. That said, at some point you're probably going to make a decision and you're not going to change the backend, had this discussion at work talking about onion architectures and well, we need to design our database interface so that we can change from Postgres to something else. But odds are we're never actually going to do that. But at the same time, you don't want to get locked in early if you can avoid it. Paul Mikulskis: It's a hard protection to try to keep up for yourself too, because I feel like a lot of services have a sneaky lock-in that you have to be aware of. Maybe this service is a lock-in service. I'm not saying you have to view a service holistically, but there are features and add-on you might become reliant on that quickly put you in that lock-in scenario. Lindsay, in our podcast that we had a few weeks ago that was posted in January, I believe we were going and talking about functional programming a lot, and you're the person I would talk to if I wanted advice on how can I continue to grow in that way of thinking about my code. So composable architectures, it is very functional in a way in my brain at least because I'm using these composable ... I use the word to define it. That's horrible. I hate it when I look up a definition online and it is like it uses the word in definition, please excuse that. But I'm using these little pieces and I'm thinking about them almost as hooks and up, does this for you as my brain being the composable person move in a direction that feels more natural to you when you're putting out an application or scratching something up? Lindsay Wardell: Paul, I'm going to help you compose the composables into a composition. It'll be great. Paul Mikulskis: Oh, my God. I'm going to have it. But yeah. Lindsay Wardell: So from a functional programming perspective, this feels like side effects to some degree. That said, I think it's good. Paul Mikulskis: Interesting. Okay. Lindsay Wardell: There is a place for side effects, even in functional programming there is a place for side effects and having this reach outside of one thing to another, you're not a hundred percent certain what's going to come back. At the end of the day when you're composing external services, whether you're using raw APIs and doing it yourself or you're using a service that combines them for you, there's going to be some, maybe this isn't going to work and I'm going to get an error that's unexpected. So I would say yes with an asterisk. Paul Mikulskis: So it's like yes it does, but in the way you wouldn't expect it to. Lindsay Wardell: Yeah. Paul Mikulskis: Yeah. Again, if you are making a web request, it could be a side effect. That kind of brings me back to thinking about Temporal. I don't know if you've ever messed with Temporal IO, but they have this idea of workflows and activities and workflows are anything that has a side effect cannot go in a workflow. So as a result, you're not making web requests, you're not making DB calls in a workflow and this kind of falls right in line with these guidelines that you just set forth for us. Lindsay Wardell: That's exactly how ELM and the ELM architecture works as well. There are no side effects in the ELM programming language. You have managed effects and a managed effect would be an HTTP request or sending a message to JavaScript or anything that is asynchronous really at the end of the day. So it feels more along those lines, but again, it's not a bad thing. It's used in the correct way in this case. It makes it even better because in your code you can just say, "Get me my data." In the backend it's getting all of the data from multiple sources like we were talking about Twitter to GitHub, Discord, anything could be stitched together in the backend. You don't need to think about it in your code. Tejas Kumar: Yeah, I'd really like this analogy with side effects because when I'm working in a functional way and I have to deal with side effects, I think more carefully about them because I'm interfacing with some form system when we model external architectures or composable architectures into that. I like that way thinking because it enables defensive programming. I'm curious about the distinction. You mentioned, Lindsay, between managing effects and side effect, like definitionally easier if the network request sounds like a side effect, how are they connected? Are they connected? Paul Mikulskis: I'd love to know as well. Yeah. Lindsay Wardell: In actual use case, they're pretty similar. It's basically the same thing. The difference is a side effect to me, and I'm thinking about it from a Vue.js perspective. A side effect is if you're using a watcher and then you make a change to your data based on a trigger where a managed effect is you're calling a function, that function returns the call for your HTTP request. It does the thing and returns the data. That would be a managed request as opposed to a side effect. Tejas Kumar: Right. So the side effect is more like a subscription and the managed effect is more like a one-off operation. Lindsay Wardell: Yeah. You're intentionally calling it saying, "I want to make this HTTP request. I want to change this data, I want to do a thing, I want to send a message, as opposed to this thing changed." Now this other thing is happening over here. Paul Mikulskis: Is the crux of the definition intentionality? Lindsay Wardell: Yes. Paul Mikulskis: Okay, got you. When are you coming out with your book, Lindsay, on functional programming? Because I'll be the first person to buy it. Tejas Kumar: I want it. Paul Mikulskis: Yeah. Lindsay Wardell: I will let you know as soon as I start writing it. Paul Mikulskis: Hey, ChatGPT 4 is coming out. So there's no more excuses. Emily Kochanek Ketner: With the acquisition, what is your hot take on the increasing rate of big platforms acquiring open source software? How do you see this evolving in the future? What does this mean as we're going into? It seems like a new age of big players in tech. Paul Mikulskis: I feel like there's a lot of bent up tension about some of the creators open source frameworks and the behavior of the big companies and how they're being treated. But I know, Tejas, you're very much in this space being an angel investor and having your attention in all these different projects. Tejas Kumar: Yeah, it's such a good question, Emily, because it's something that is, to me, bittersweet. It's nice to see companies stepping in and supporting open source. The fact that Zach gets to work on 11ty full-time at Netlify, that's awesome. The fact that Rich gets to work full-time open source at Marcel, that's great. But the bitter side of it to me is they have to work at Marcel to be funded as open source maintainers. Then that really bothers me because the whole world is built on open source more or less, at least in the web dev world. But it's so underfunded that maintainers have to take jobs because we, I'm talking about myself. I'm not just willing to pay organically for React or Svelte or whatever. That's how I feel about it. It's nice that companies are doing it, but I would prefer if just developers who depended on these things did it organically. Lindsay Wardell: Yeah, I feel like it's an unfortunate side effect of how the economy is set up, especially for software development. When you have somebody who is just open source and working on a thing. I'm going to point to Evan Czaplicki the creator of ELM as my example right now. He works on that as a passion project. It was originally his thesis and it's grown from there. For a while, he was employed by NoRedInk just to work on Elm because NoRedInk was investing heavily in that technology. But at this point, again, he's just working on it because it's something he's interested in and he's passionate about. That gets us really far in software development, especially web development. But at some point you need to be able to pay rent, you need to be able to pay a mortgage, you need to be able to pay for food. Having the dream of being I'm just an open source creator is harder. So we've seen a couple different solutions. Facebook and Google created their own frameworks. Companies like Gatsby were founded on the premise of we created this open source thing and now we need to make money and provide better supports and benefits to paying customers. Then we have companies like Netlify and Vercel that are creating their own platforms and then acquiring to support the open source. So I think we've seen these three different models. I don't know that we've found the best one yet. I don't feel bad about the recent acquisitions like Shopify buying Remix or Netlify acquiring Gatsby because it means that these tools that are open source can remain open source and the entire software development ecosystem benefits from that. That's kind of my view on things. Tejas Kumar: The great thing is I feel like Netlify and Vercel heavily depend on these things. That's why they buy them and pay them. I'm aware of one other way that open source can be supported that is not very well known and this is something I'm excited about. Have you all heard of, thanks.dev? Paul Mikulskis: I have not. Tejas Kumar: It's this small startup by a friend of mine, nothing big. But what they do is they'll scan your dependency graph and show you who you depend on and allow you to literally you're just like, "I'll give thanks that they have a hundred dollars and it'll distribute by weight according to your dependency graph of open source maintainers," whatever amount you pledge automatically monthly just based on what you depend on. So I think that's pretty cool. I've seen a few maintainers get paid by that. Lindsay Wardell: I really like that. That's cool. Emily Kochanek Ketner: Next, I want to talk about Create React App and the recommendation of replacing it with Vite. So we can get through our panel without a little React drama, obviously. A couple of weeks ago, Theo Brown posted a poll request on the React GitHub recommending replacing CRA with Vite. His reasoning behind this was seeing that new devs were running into an unnecessary issues due to the continued recommendation of CRA. Dev Twitter resoundingly agreed. Some mentioned that CRA's inability to support post CSS configurations and were recommending either Vite, Parcel, Next or Remix. Two weeks later, Dan Abramov responded in the most Dan way, giving complete context as to why CRA exists, the current problems with CRA, including its stagnation and how React works as an architecture and how it produces frameworks. He gave a bunch of options, which we're going to link to in the show notes. Currently, React team is leaning towards going towards turning, create React app into a launcher. So before we get into questions, can someone summarize what CRA is and what it does and why it benefits developers? Tejas Kumar: So when I started with the React and when most of us started with React was complicated to set up because it was a whole different programming language. It wasn't JavaScript, it was JSX, which at the time was like, what is this? So we needed code, we needed software to translate that into JavaScript that browsers could understand. So we'd have to set up web pack and all kinds of extensions and just configuration on configuration on configuration. So Dan created Create React app to do all of that for us and just give us a React app like that. Since then, tooling has come a really long way, but Create React App hasn't followed as well. That's not the case Theo made in the poll request and to some degree I agree a little way in which it was created and so on. I'm not so sure. But that's the gist of it. That's Create React App and up to where it is today. I mean now honestly I don't even use it. I just make an XGS app. That's just me. I'm curious if you all do the same or if you all start with Vite. Yeah, exactly. Paul Mikulskis: Yeah. I do, yeah. What is the way in which it was delivered that the number one way that you feel like you felt a little uneasy about, Tejas? Tejas Kumar: I feel like there wasn't enough of a discussion. It was a poll request, not an issue. I think that's maybe one of things like when I started a discussion issue, no, here I changed this, this is why. So it felt very almost confrontational. Paul Mikulskis: Heroic. Tejas Kumar: Yeah, heroic. Exactly. I don't subscribe to that way of working, thinking. Emily Kochanek Ketner: So Tejas, you said you don't even use it anymore. How about Lindsay or Paul? You guys, I don't think you said you're using it either, but for newer devs, Theo was sayings very hard to use. Would you consider using Vite otherwise would you rather Next.js? What do you think is the best way forward or do you think that they can create Create React App as something better? Paul Mikulskis: I'd love to hop in on this one just because I feel like Lindsay is front end professional of leaps and bounds beyond myself. I'm a jack of all trades. I like to do backend and front end stuff. So from my perspective, I just use whatever has the most stack overflow posts about it that are recent because Next.js had such a pull in the field in the past year, two years. As Tejas just mentioned, I just always turn back to the Next.js to create my application and I don't know when I'm going to change until I change Astro Orel. Lindsay Wardell: Hello, my name is Dev Twitter and I resoundingly agree with Vite. I have not used Create React App myself in years. I typically don't write React also just to be honest and upfront. But when I was doing React, the way I looked at it is if I need a single page application, I'm going to use Create React App. If I need something that's going to need a database or need server side, anything, I'm going to reach for something else probably next. That really hasn't changed for me. If I'm building a simple single page application, I'm either going to reach for now I'm going to reach for the Vite template for React or I'm going to reach for something like Astro or 11ty or something like that and inject React into that. Both of which are using Vite if I remember correctly. I don't remember if 11ty is actually using Vite yet, but Astro is. So for me, if I'm approaching it from a teaching perspective of I want to help new developers get into React as quickly as possible and write a component that works, I'm not going to teach them next. I'm going to spin up a basic template. Probably it's going to be the Vite template because it provides the hot module reload. It provides really nice configuration if you need to expand things. If you want to be more advanced you can set up your own server side rendering using Vite and there are templates to do that for you. My personal opinion would be just replace it. I agree with not being confrontational about things. It should be more of a nuanced discussion about what is the value of Create React App. But my feeling is it's especially useful for simple single page applications and new developers. Both of those would be served perfectly fine by a Vite based template. Paul Mikulskis: I'll also add on that I think 11ty does fully integrate with the Vite now, you just need to do three plugin. Yeah, if not natively. Lindsay Wardell: That's what I thought. I just couldn't remember. Tejas Kumar: I was going to say I think it's also worth noting that as a teaching tool it's great because you get to teach new developers the value of server side rendering and like you said, Lindsay, I would start with Vite and then come to the point of like, "Oh, wait. We need to think about SEO and we need HTML markup in the browser. How do we do that?" Then we pivot to server rendering and then we maybe talk about static rendering, all of which can be done with Vite and then we go to next when the student says or understand why, right? I think that's exactly why. I also use Vite. Paul Mikulskis: I would've loved to step in a web development through that path pages. That would have removed a lot of frustration through the self-learning process. What is SSR and client side rendering? Oh, my gosh. Tejas Kumar: What pain did you endure when you ... What path did you step onto? Paul Mikulskis: I stepped into being a dumb to down Gatsby developer where I just kind of followed things. The way they did it, very simple, fast render at times everything worked beautifully because there was uncomplicated websites and then you're like, "Okay, I want to make something real. I want to do databases. Next.js, like I said, stack Overflow, it's everywhere. That's what I'm going to use. You quickly get thrown into this world of what is SSR and you don't understand the point unless you come from that first basic point. If you start with Vite, I'm sure I would've had a much clearer vision of why something with server side props versus not. Tejas Kumar: I'm going to bubble of people who do server side rendering. Quite default. Emily Kochanek Ketner: So thinking of what Dan said about how React is an architecture and it produces frameworks and that I'm kind of seeing, and definitely correct me if I'm wrong, I know everyone is like, "Is React dead?" Every single year. They're like, "React is dead." But think especially with this, do you feel like React is becoming more of a base for everything and then the frameworks are going to keep iterating on it and surpass React? Do you see it kind of becoming JavaScript where it's a very essential thing and then everyone else will build on top of that? Tejas Kumar: Yeah, I think React is not going away. I think it's too late for React to go away because there's even now ... React is no longer a meta thing. It's maintained by Vercel and also it's got to adopt. The Chrome team works with them on making React better for the web. It's this fundamental partner. So I don't think it's going to go away. It's kind of at the stage of JavaScript [inaudible 00:25:22]. So to say a React is going away is to kind of say JavaScript is going away. Which no, I don't think so. But React is severely limited. I don't know if you all know this good friend of mine, his name's Yani, I can't say his last name because it's Finnish and hard to pronounce Yani Avakalia or something like this. He said React is fast approaching its middle age where it has a dad bod and it's mature and stuff like this. So it's not going to go away. But it is very mature and I agree and that's because I'm looking at tools like Quick, I don't know if you all have heard of Quick and SolidJS, which they're faster than React, like measurably faster every single time and in that way better than React. But I don't think they can like dethrone or displace React because one, they're new and not as mature and two, React has a Headstart and React has years and years of iteration that these things don't yet have. When they do have React, you have even more. You know what I'm saying? So I don't know that React will go away anytime. Paul Mikulskis: Quick point, we actually had an episode with the creator of Quick PodRocket. It was a fun episode and [inaudible 00:26:27] was saying that there are things that you're always just still going to turn to React to do. Quick is amazing for what it was built for. Tejas Kumar: Exactly. Paul Mikulskis: That's about as far as it goes. Lindsay Wardell: I also don't think React is going anywhere, but I would throw out the hot take that React is the new jQuery. It's not going to be cool in the coming years is my feeling. Because we have things like Quick because we have things like solid because SvelteKit is doing what it's doing. There's going to be new frameworks, there's going to be new ideas on how to build web applications. At some point, React is going to be that thing and Next is going to be that thing and everyone's like, "Oh, I remember when I worked on Next 10 years ago. I can't believe we did that just like we do today with WordPress and jQuery." It's going to get there and it's definitely not going away. But honestly what frameworks do go away? They're still websites out there using AngularJS. They're still websites using Knockout, Backbone. All of the technology doesn't go anywhere and that's another nice benefit of open source. It just pivots into being less cool and talked about. Paul Mikulskis: That's a really good point. I mean I still have colleagues that are toiling over their Backbone code today as we're doing this panel. How old is Backbone now? Lindsay Wardell: Is that 2010? 2009? I can't remember. Paul Mikulskis: It's been a while. Lindsay Wardell: ELM itself came out I think a year before React was open sourced. So ELM is technically older and it's also not going anywhere. But it's also does not have the reach the that React has. Paul Mikulskis: I like that frameworks don't go away. Yeah. Emily Kochanek Ketner: Moving on. So in January, Astro 2 released to bring in a slew of new features including the content collections API to deal with markdown more easily, hybrid rendering, easier debugging and more. What is Astro and what does it provide its users? Tejas Kumar: I'm so glad you asked because I'm just going to be [inaudible 00:28:26] here, I'm a complete and utter new about Astro too. I know absolutely nothing about it. Not here to learn. Lindsay Wardell: Astro is a ... Actually that's a complicated question now. Astro was originally created as a static site generator that was framework-agnostic. The goal was you could write components in Astro like .astro file. The structure kind of resembles JSX, but it's not. You've got a front matter section where you write your JavaScript to do your imports, exports, data manipulation, and then you write a template. But the template can include JavaScript but it's not JSX. It's interesting, but you don't have to use it. You can just use an integration with something like View or React or Seltz or Solid or whatever. You can use any component that you want. There's even an integration for ELM. You can just use the framework of your choice but render it statically and then get the benefits of Astro on top of that. So that was the original pitch of Astro and from there it's grown into server side rendering. There's an integration with Netlify so that you can do server side rendering on Netlify functions and you don't even have to think about it. You just install the integration and the site does everything on the server for you that you need it to. In many ways it feels like the PHP version of JavaScript where you can just write code and it runs on the server and life is good. That's my high level take of Astro using it for my personal site. I use it for other smaller sites. It's my go-to at this point if I need something static or not running on a server specifically. Tejas Kumar: Would you say Astro allows me to compose different UI libraries together as I need? Lindsay Wardell: Yes. If you want to have React view and Svelte all on the same page, you can do that easily. Tejas Kumar: So this question about React going away and quick being like the cool new kid, I could literally use React and put both in my Astro site and then maybe phase out React one day if I want to phase out Quick, where it gives me that flexibility. Lindsay Wardell: Absolutely, yes. Paul Mikulskis: Then on top of that you can tell if you want it to render default, like Lindsay was saying on the server and now we could do it on the client side as well. You can be very pedantic about that and that's a new thing. Tejas Kumar: That's so awesome. Emily Kochanek Ketner: So Tejas is obviously very excited about Astro, but I want to ask Lindsay and Paul or Tejas, if you've played around with Astro too, what are your first impressions? Paul Mikulskis: The cheating. Cheating a little bit just because I feel like with Next.JS I've put in a lot of effort where it's like I'm going to have this be plain old HTML and CSS and that's the vibe. Or I'm going all out and doing a theme and everything and I have to think about my server side and my client side. With Astro, I love the content collections and the markdown and it's all typed. That felt like cheating. For me, it's less about the hybrid rendering, more about the content collections when I was trying to make a personal site. That felt like cheating. Tejas Kumar: Oh sorry, I don't know what that is. What's content collections? Why is it better than [inaudible 00:31:21]? Paul Mikulskis: I'd love to get into content collections a little bit even though we're on the hybrid rendering topic. But content collections allows you to have these MDX files. They're essentially fancy markdown files and you can type things. I can say this is an author, this is a contributor to my repository. When I want to reference your name, Tejas, I'm never going to misspell it because I'm going to refer to you as sort of like an object, a typed object in my markdown. It really provides dynamic breathing documents on your website that can be statically rendered and cached as needed. Tejas Kumar: That is so awesome. I need to play with Astro. That's what I'm getting from this. That's wild. Paul Mikulskis: Yeah. Lindsay Wardell: Astro is so fun to play with too because of how it works. It's not even just MDX files. You can do MD files too and all of your front matter is strongly typed. Well, strongly typed as type script allows and it's auto generating the types for you so you don't have to think about it. Then when you perform the import to get your file, you can just see all of the keys that are available. You can render the markdown into an Astro component and then just inject that into your page as HTML. I'm a big fan of that. The hybrid rendering is also very fun. I haven't found a personal use case for that yet because my sites are small and don't need it. But having that flexibility is so wonderful. It's one of the nice things that Next.JS has had too. Getting that into Astro is really nice. I'm going to throw out a hot take, and I don't mean to derail us, but my personal opinion is that Astro is on the same trajectory as remix as far as what it's trying to do and what kind of solutions it offers. The difference being you're not locked in to React and you're not locked in to a specific configuration because it provides you access to the Vite config. Paul Mikulskis: I love that. Lindsay Wardell: So you can do what you want, you can extend it the way you want and you can build the site that you want. Paul Mikulskis: I totally agree with you, Lindsay, on your hot take because I had that same feeling after having worked on my first Remix app earlier in the year. I was like, I'm building the same mental model in my head and I'm making the same decisions that Remix is sort of offering me. But yeah, I'm not locked in. I can do whatever I want. Tejas Kumar: Well, would you all say from a business perspective, if there's a company with a big web project, would you all say it's wise for them to invest in Astro and choose Astro to build their app because then they can hire from more diverse developer communities like Svelte and React? Am I way off here? Paul Mikulskis: I feel like I can't answer that question because I haven't led a huge dev team myself, but my initial reaction would be like there is inherent value in having some homogenous framework that you're working off it together. If everything's disparate, that's confusion. But then at the same time, yeah, you could hire more people. I don't know. I'm curious what you think, Lindsay. Lindsay Wardell: My instinct is if you are already looking at building something using a JAMStack structure, then Astro should be in the top three of what you're considering because it gives you access to server side rendering. It gives you access to APIs and integrations with the different frameworks. You can build a marketing site, you can build a shopping site, you can integrate with the things that you need to build the kind of business website that you want. So if you're already looking at that kind of architecture, I would definitely recommend looking at Astro. Tejas Kumar: What's the other two on the top here? Lindsay Wardell: I don't know, I just wanted to give room for something else. Paul Mikulskis: That's awesome. Emily Kochanek Ketner: Love that. Any other thoughts about Astro 2 hybrid rendering? The whole pipe script for markdown before we get onto our hot takes? Tejas Kumar: I just feel like a massive new ... Because Paul, you've built something at Remix and Astro and Lindsay, you've built things with Astro and here I am just like with Next.JS all day every day. You all have motivated me so much to diversify the tools. So thank You all. Lindsay Wardell: My big final point would be as somebody who works with strongly type languages like ELM and Haskell, I really appreciate how much more TypeScript has been adopted by the JavaScript ecosystem. JavaScript is a dynamic language and TypeScript has to provide holes for it and I understand that. So it's not perfect. TypeScript can lie, you can make TypeScript lie, you can lie to TypeScript, but it's still better than it could be and you don't have to maintain the whole model of your application in your head. So extending that into markdown and having it generate automatically for you is really nice. So I'm just really happy with the direction they're going with typing markdown and pushing that as one of the big features of Astro 2. Not just having it as a feature, but it is one of the features. Paul Mikulskis: I totally agree with that. If you're stepping into Astro, Tejas, for the first time or anybody listening, I feel like the strongly typed content collections and MDX markdown files is like that might be the first thing that really you go, "Wow," when you look at Astro because hybrid rendering, how many scenarios in a small personal site might you actually need to make those types of decisions? Not many, but something like having the content collections really could be pervasive in a lot of sites and very clearly add value in a way that you might not have seen earlier. Lindsay Wardell: Actually, just going to circle back real quick because I know what I would've said if I was listening to this podcast if it wasn't mentioned. Coming back to the beginning of our conversation with Gatsby, that was one of the things I really liked about Gatsby with the GraphQL API is that all of the data you're pulling in was strongly typed. While GraphQL, it's debatable whether that was a good interface for a static site, I appreciated it, but I know people didn't. Having it in a simpler interface of just being able to import the file and get all of that typing is so wonderful. You don't have to worry about the complexity of GraphQL or any of those other more advanced technologies. You can just do an import like you normally would and you have your data. Emily Kochanek Ketner: Before we move on to our final portion of the panel, I would love to ask you to follow us on Apple Podcast if you're enjoying this episode. It's tremendously helpful. We can use that data to help tailor content to fit what you want to listen to as well as experiment with new types of content like we are with this panel today. So follow us an Apple Podcast, give us a rating if you really love us and on to our hot takes. All right, that was great guys. Thank you so much for coming on and I want to get into our hot takes. This is the part of the panel where everyone gets two minutes to talk about whatever they like. I'm going to get my timer out and I'll start the clock and I'll let you know when to begin. Tejas, you're up first. I'll let you know when the clock starts and when you have 10 seconds left. Are you ready? All right, ready, set, go. Tejas Kumar: Okay, so my hot take is that developer relations is so easily abused and misunderstood. It will often over in depth for one thing that the other either content creation, public speaking, hyped without fully understanding relationships. My understanding is the hot takes are about anything in the dev world. This is the thing in the dev ... Developer relations is newer and up and coming, and because of that it's very easy to abuse. So I've seen a bunch of abuse happen in DevRel and I hate it. That's my hot take. DevRel can be beautiful when done right, but it is often done wrong. That's the hot take and it's done wrong. What I've seen is in relatively inexperienced people being hired because again, it's a young field and then having to deliver unrealistic things to the point where they've grown out and so on. Because companies try to measure DevRel in ways that I believe ought not be measured. How many email addresses did you get at this conference? No, it's about relationships, not numbers or a lot of DevRel work being public talks that are just marketing, put in marketing pitches for things. No, it's in the name. DevRel, developer relations. It's DevRel and not dev sell. A lot of companies have come to me when I was doing DevRel work and like, "Hey, how do we get our sales number up? Should we do some DevRel work?" I'm like, "No, hire a sales team." If you want good relationships with developers, if you want to teach people how to use your thing, not necessarily for your profit, but also for their good, then DevRel makes sense. I think about DevRel also, docs are not solely a DevRel thing. I believe engineers are responsible for documentation. It's not like let's write the code, give it to the community and good luck. Or give it to the DevRel people in good luck, write on the docs, but the engineers as closer to the code ought to write the docs and DevRel can help refine. I've said a lot, but I have tons of thoughts about DevRel and I'm also thinking about starting a company in this space. So yes, I care a lot about this and my hot takes basically that. Emily Kochanek Ketner: That was great. Lindsay, do you want to go next? Lindsay Wardell: Sure. Emily Kochanek Ketner: All right. And go. Lindsay Wardell: So one of the main conversations that happens on Twitter all the time, is Tailwind good or is Tailwind evil? As somebody who has been using Tailwind prior to 1.0 and been very happy with it, it's just a tool. It's not good, it's not evil, it's a tool and people are able to use it to build websites and that's great. The main thing that I see people talking about is how could you want to do this if you actually know how CSS works? I learned CSS in the early two thousands. I know how CSS works. I really like Tailwind because I don't have to write all of that stuff. I don't have to worry about it. I can just use a tool and then if I need to customize it, this is the best part. I can can customize Tailwind because it offers that flexibility. When I first was getting it reacquainting myself with development and I got into Bootstrap, I was like, "Okay, I've got Bootstrap. This is cool. How do I change it? How do I make it mine?" You really can't easily, you have to understand Bootstrap not just CSS in order to change a Bootstrap template, but if you just know CSS and you're able to use Tailwind, then you're good to go. But again, the main point is it doesn't really matter. What matters is use the tools that are best for you and use the tools that are best for your team. At Work I'm using ELM CSS. People at other jobs use CSS and JS. They use SaaS, they use post CSS, they use whatever they use because that is the tool that lets them build good-looking websites and that's really what matters at the end of the day. So I really wish as a dev community, we can just stop talking about how terrible templates look when they're using Tailwind. When I was first getting into web development, I would judge any website that had generated HTML because it didn't indent properly, but that's not a thing anymore. We're all using generated code. So just chill and let people build websites. We enjoy it and we have fun. Emily Kochanek Ketner: Amazing. Love that. Paul, you're the last one up. Just going to check time. All right. All right, go. Paul Mikulskis: All right. So my hot take is that web development and front end development is just as much backend development as it is front end development. I think my question earlier about are we moving away from having knowledge about how to run these systems and vendor lovk and all that? This touches upon that where you as a web developer, if you want to post a website, even a simple website, it's not out of the question. It's not really hard. It's not rocket science to go run your own server. There's really great frameworks and technology such as Temporal, such as Flight Control. We also did a podcast here on Flight Control. How can you in a more simple, easy mental model, take control of your own infrastructure and really make these decisions for yourself? The margin savings I think are way more profound than a lot of companies or developer groups might initially recognize the sale pitch of you don't need to spend people in time to do it because AWS is running my server and it's always going to be up. It's becoming a little bit harder and harder to sell, I think, as these great technologies are rolling out over the years. Emily Kochanek Ketner: Awesome. Under time and we're under the hour, I just want to thank all of you for coming on today and joining the panel. So happy for you all to come back. If you liked this podcast, definitely follow us, tell us what you want to hear more about and we'll be back with another panel next month. Thank you everyone. Paul Mikulskis: Thank you, Emily. Lindsay Wardell: Thank you. Tejas Kumar: Hey, thanks so much. It was a great time.