Kate:
Hello, welcome to PodRocket, the podcast brought to you by LogRocket. I'm Kate, I'm the producer of PodRocket. With me today is Noel Minchow. Noel is one of our engineers here at LogRocket and also our host of PodRocket. You've probably heard his voice many times at this point. Hi, Noel. How's it going?

Noel Minchow:
Good. I'm good. How are you, Kate?

Kate:
I'm doing well. You've heard his voice so many times at this point unless this is like your first episode you're jumping into, then this is the first time you heard his voice. With us today is James Quick. James, how's it going?

James Quick:
Hey, hey, thanks for having me.

Kate:
James is a developer, speaker, teacher. James is also a podcast host and a YouTuber. Thanks for joining us today, James.

James Quick:
Yes.

Kate:
And then also with us is Amy Dutton. Amy is the director of design at ZEAL, podcast host, speaker, and YouTuber. Welcome to the show, Amy.

Amy Dutton:
Boo. Thanks for having me.

Kate:
Thanks for coming on. We actually did a swap post with the Compressed.fm team I think in September as well. So again, this may be some familiar voices, unless of course you're jumping in right now. But yeah, if you guys just maybe want to tell us a little about Compressed.fm a little bit and we can kind of start there.

Amy Dutton:
Sure. So Compressed.fm is a podcast all about web design and development with a little bit of zest. So we cover a lot of topics from front end to back, a lot of JavaScript, a lot of productivity, and a little bit of design.

James Quick:
And recently the format has actually been very similar to this one, where for several months now we've been live streaming them to YouTube and Twitch, but they've been guest episodes. So we actually haven't done an episode with just ourselves in a while, and we've talked about getting back to that some. But we've had some amazing guests on the last several months, and have a really good time bringing people on and hearing about things they're building or working on or projects or companies, or whatever it is that they have to share.

Kate:
So working on content creation kind of means that you are gaining a lot of data points and a lot of research into what is trending and what people are excited about. So I think that's our aim in this episode is we want to talk about 2023, what's trending, what we're excited about. I first wanted to start with Remix, of course. We actually just had Michael Jackson on one of our episodes not too long ago, so we had a Remix in 2023 breakdown. But yeah, I'm curious, your thoughts around Remix?

Amy Dutton:
Yeah, I think the interesting thing about Remix is it's really lenient to the browser API instead of these things that we've abstracted using React. So forms is a perfect example. Forms are notoriously hard in React because you're trying to manage all of this data, you're watching for change. So one of the things that Remix does is it says Why? Because the browser handles all of that for you. Why not lean into that API? And so it's kind of interesting to see that swing not just in Remix, but in other frameworks like SvelteKit is really leaning into that as well.
What's also interesting, I don't know that this will happen, but one of the predictions that I saw for 2023 was someone saying that in an effort for Remix to continue to separate itself from React that it would lean even further into web components. So that'll be interesting to see if that actually happens and what that will mean for that particular framework.

James Quick:
I feel like been a pioneer in a lot of ways. We went through this transition of getting into Jamstack and we were really focused on prerendering content and static sites and static pages, and at some point in the mix in there we realized that's really nice for certain use cases, but we also still need the server. So we came back to incorporate that and we saw hybrid frameworks Next.js being kind of the biggest one I think that did both server side rendering and static site generation.
But then Remix came in and I think sent us all into this kind of new era, which again, to Amy's point goes back to some of the basics that you would've learned in full stack web development 10 years ago like the Ruby on Rails handle things on the servers and minimal JavaScripts to the browser type thing. And you've seen as they've introduced their paradigms, you've seen other frameworks adapt to that.
So Next.js now changing their routing system, them going to a server components, you've seen SvelteKit just go 1.0 a few months ago with very different API changes. I think Remix was a huge part of influencing that. And that's one of the cool things I think about looking across the ecosystem is seeing these trends and seeing them kind of evolve with each other. And I've used this thought a lot, it's a little dramatic, but there's almost like nothing in the world that is that unique. If you look at cars across different models every year or different makes Toyota, Honda, Nissan every five years, they make the same changes. So you can recognize across any model around what year a car is if you pay enough of attention regardless of who actually made it, which is really interesting. And I think we've talked about the rising boats rise all the time-

Amy Dutton:
Rising tide.

James Quick:
Yeah, something. And I think Remix has been a big part of fully influencing not only themselves obviously and going acquisition, which is fantastic, but also looking around at the ecosystem of different frameworks and seeing how they're evolving based on what appears to be kind of the consensus of changing best practices in full stack web development.

Amy Dutton:
Another huge thing for me with Remix is I have so much respect for Kent C. Dodds and I mean, he's written this epic React course on React, and for him to come out and say that Remix is the best way to use React and implement it is huge and just really respect his opinion, so for him to say that carries a lot of weight.

Kate:
We had a listener question recently that said I love remix but I am a little concerned about the Shopify acquisition and the future of remix

James Quick:
It was in something recently. I don't know if it was that episode, because I listened to that literally two days ago while I'm working on those big, huge DIY project that's way too big for me to take on, and I don't know if people have seen pictures on Twitter, but they're kind of fun. But anyway, I was listening to this episode and it may or may not have been during the episode, but someone brought up the reference to the creator's SvelteKit works for Vercel.
Vercel also was the owner of Next.js, and now Gatsby just got acquired hot off the press by Netlify. This is not uncommon. It's a natural reaction to say, "Oh, well, this was its own thing, now it's acquired what's going to change?" Totally understandable, but the reality is all the major frameworks that are really heavily being looked at have a backer that's very substantial. So I think in that sense it doesn't scare me or turn me off from it at all.

Amy Dutton:
Yeah, that's a great point because I know that Remix, if you got it with sponsorware, so it was user supported and then they were able to get funding and so then they were able to make that open source truly and make it available to everyone. But if you looked at their path to revenue, at least the last time I had looked at it, it was talking about hosting options and being able to host Remix in their own container to make it the fastest possible. And in my mind, there's so many hosting options that are out there. I mean you mentioned Vercel and Netlify just to name a couple, but I mean you could go on Fly.io, Render, I mean yada, yada, yada.
So I even wondered about the longevity of Remix standing by itself and how it would reach that revenue point where it's net positive. So with Shopify backing it, then you have an entire ecosystem and e-commerce platform supporting it. So if anything, I think it's going to give Remix more legs, plus you have more people working on it. The Remix team has been very, very small, and so to bring an entire team around it, they're going to be able to move faster and release more features.

James Quick:
Talking about these big for-profit entities acquiring these kind of open source tools, especially in regards to Vercel with Next, Netlify with Gatsby now, of those three, it almost feels like fear of ulterior motives here should probably be the least of a concern with Remix Shopify, because it feels like there's not a clear path. It's like, "Oh, we'll make tooling that is specific to this framework that only we can provide as a host and then we'll kind of have a new era of vendor lock-in come to be." I just don't see that happening with Shopify and Remix being set up in the way they are, where I feel like that's going to be the obvious play with Gatsby Cloud is going to just be part of Netlify now, right? That's kind of how it's going to work.
I mean, you'll still be able to use them without it, but you won't get all the cool bells and whistles of these frameworks where you just open it up and you spin up a project and it just works. Especially with how Remix has, I think really tried to spin itself a little more, focus a little bit more on its essential framework. Agnosticism I think has been more of a focus for them. I think the fear is somewhat is valid, but again, if you had to pick one eventually they may be in the safest bubble.

Kate:
Yeah, and I think too, we've seen building a company around a framework is really hard. And then we've seen some recent, everything we just mentioned kind of seems to be a long-term solution for those frameworks.

Amy Dutton:
What's interesting is James and I just spent some time at THAT Conference. It's called THAT Conference, it's a little confusing, but this particular one was in Austin and spent some time with Brandon who is behind Blitz.js and he also runs Flightcontrol. And so it was interesting talking to him about Blitz and how he's supporting that while he's running Flightcontrol. And he said for him it was the biggest marketing tool for Flightcontrol. So I could even see that with these other frameworks with Next and SvelteKit it's a huge marketer for Vercel because if those frameworks run the fastest on Vercel, you're going to lean into Vercel when you get ready to deploy your project because you know it'll be the fastest. Same would be true for Gatsby and it'll be interesting to see what happens with Remix and Shopify, because you don't think of Shopify as a hosting platform, but more of an e-commerce platform.

Kate:
Absolutely.

James Quick:
One interesting additional note that I have that I found very weird is I thought Remix would be this super hot topic from a content creation perspective and so I was doing a sponsor video with Zeta, which is a database that's like regardless of sponsorship is really, really cool. I'm a big fan and so I was doing this tutorial with Remix and Zeta building a New Year's Resolution tracker. So part one was just basic CRUD, and then part two is adding on authentication. Those two videos on my channel where were the lowest viewed videos out of the past couple of years, which I was super, super surprised about. So I don't know this as a broader trend on YouTube specifically, but for me specifically, those two pieces of content were not very well received and I don't have a specific reason as to why, but I wonder if that's a topic that just hasn't gotten to the breadth of people that some of these other frameworks have gotten to.

Kate:
Let's talk about Svelte. I think that's right up there with Remix on topics, knocking everyone's socks off. You guys also just had an episode on Svelte and third party JavaScript in October 2022. So yeah, curious on thoughts on Svelte. We know that SvelteKit recently had their announcement of SvelteKit 1.0.

Amy Dutton:
Yes. Svelte is probably my favorite framework to reach for and some of it is just because I feel like I'm writing pure HTML CSS in JavaScript, I don't feel like I'm having to write a ton of boilerplate code that React forces you to have. So with forms, since I mentioned that earlier, you can just reference the form and bind a value straight to that form field or also with forms when you're processing the form, you can just hand that over to the server and use your standard PUT commands and things like that in order to process your forms. If you're setting state, you can just use let, you don't have to use this useState hook in order to be able to store all that information. So from a purity standpoint, I'm a huge fan.

James Quick:
Yeah, I think we'll definitely have a bunch of similar opinions with Svelte and specifically SvelteKit and maybe it's worth distinguishing Svelte is basically kind of its own equivalent to reactive view and then when you get to SvelteKit, now you're layering on like built-in routing, doing server side rendering, handling form submissions through API endpoints, similar to what you get with Next.js and/or parallels with Remix as well. One of the things I've missed in something like just React and even Next.js For example, is this ability to track state across components. So within a component in React, you can use useState, but if you want to share data between components, you can prop drill and pass props down from component to component or create some sort of store that is accessible between multiple components, which has always been more tricky than it seems like it needs to be.
And so Svelte actually just has a built-in functionality for stores and you can access data from stores, you can read data from stores, you can write data from stores and any component that you want. So something as simple as tracking the state of a dialogue. So if we want to pop up a little info thing, "Hey, your data actually got saved, congratulations," you can have a component that lives in one place and then kind of update that thing through a store and it will react to that data. Like Amy said, like the syntax, it's simpler than anything else that I've used. And then when you get into SvelteKit again, it has kind of all the features that something like Next.js would have. I mean, maybe not quite if you get down to the details, but it's younger and it also has been part of Vercel for several months or a year now. So I think it's just going to get better and better and it's already in an amazing place where it is.

Amy Dutton:
And I know for a lot of people it feels a little gross and I think it's just because it's something that they're not used to seeing. It does make that directory a lot fuller, but as I've worked with it, I've personally come to really appreciate it because I'm not having to drill down through multiple folders to find the components that I'm looking for, for that particular page.

James Quick:
The biggest issue people have is all of those file names are the same between different routes. So if you have an about directory, which equates to /about and you have a /podcast directory, inside each one of those you would have a plus page.Svelte. So that would basically just be the route component and you can have layout.Svelte, and these will have pluses before them. You can have server stuff that only runs on the server. You can have stuff that runs on the server and the client. So part of that problem is as you have all these different directories, now you have a thousand files named plus page.Svelte plus layout.Svelte, et cetera.
So there's some tips and tricks inside of [inaudible 00:14:32] code, which are really neat to help solve that. The simplest of which is you can use Command P on Mac or Control P on Windows to open up the search file that I used to open 95% of files that I work with, and then you can just search by the actual directory name followed by the name of the file and that will do a fuzzy match between directory name and the specific file that you're looking for, make it a lot easier. Like Amy said, you're still not having to go through and look through folders. You can still just pretty easily get access to it and through a shortcut in [inaudible 00:15:03] code.

Amy Dutton:
Yeah, I've found that there's kind of two sets of developers. There's the developer that loves the magic and loves the fact that you have systems and frameworks that do stuff for you. SvelteKit also provides transitions and animations, and I look at that and I just think, "This is awesome. I don't have to do anything. I can just add on an attribute and it works," but other developers, "Oh no, what happened? It just did something. I've got to figure all that out."
And so other people struggle with a system like Svelte that does provide all that stuff out of the box when they would rather write it themselves, or at least have a better understanding of what's happening underneath the hood.

Kate:
Totally. Yeah, purists maybe.

James Quick:
I'm definitely one of the give me all the magic developers though. I'll take everything you have to give.

Amy Dutton:
Me too. Not a control freak when it comes to that stuff.

Kate:
We actually just had Scott Spence on the podcast talk about Svelte. He runs the Svelte meetups in-

James Quick:
Society.

Kate:
... Svelte Society.

James Quick:
Yeah. I listened to four episodes in a row the other night, so I'm like well versed in the recent episode.

Kate:
Thank you. I knew I was missing an S word there. But one of the questions that we had asked was, what's your advice on buy-in? If a developer wants to use Svelte at their work or organization, but maybe you're not currently using it, you have to take it to your manager. And Scott mentioned a talk by one of his colleagues who did this and saying what makes it easier is the developer experience, it's easier to read, easier to learn, as opposed to maybe some stuff that you traditionally thought about with frameworks.

Amy Dutton:
Well, a huge part of that too is what would it take to convert an existing library over? So it's one thing if you're starting a new project and trying to get buy-in, it's another, if you have a legacy project that you're having to support and trying to switch over to a new language or a new framework.

James Quick:
If you're already using kind of a modern react setup and things are working, and your team is comfortable with React if they don't have significant issues, I think that's a tough sell, right? Because companies just really don't move that quickly. I've got a very skewed perspective of the ecosystem because I get to sit around all day and try new frameworks and make videos about it, which is not how it works at real companies with software.
So I think to Amy's point, if they're making a transition from something old and are looking for something new, they can be a little more future focused, future forward. If they have something that is relatively modern that's not holding them back and it's working, I think that's a harder sell, but that's not because of the SvelteKit. That's just because companies just don't move like that. You have to have a really good justification to change over something that already is modern enough and working in the ways that it should.

Noel Minchow:
Yeah, I don't think historic performance has motivated front-end framework shifting for companies in a while. It's just such a large organizational buy-in to justify switching even from Angular to React, right? It's like, well, if performance can be pretty close, I think a lot of business entities are willing to take a 50% performance so they don't have to rebuild all their stuff, kind of redesign their whole paradigm. So I think, yeah, it just takes time to James's point, there needs to be new projects being started and old stuff gets phased out. It's always going to be a little bit slow on the uptick I think, just because there's not large business factors motivating these things outside of ease of hiring and stuff. I think if anything, that might become the thing that motivates companies to switch, right? It's like, "Oh, it's easier to hire Reactive than it is Angular devs anymore." It's a boon to your hiring efforts if you can talk about using new frameworks. So I think that'll end up kind of happening here, but I don't think we're at that stage yet.

Kate:
We covered some big ones. What else are you guys excited about in 2023?

James Quick:
One of the things that I have done recently, a few months ago, was migrate my site from what was Gatsby JS to Astro, and Astro is this new framework. They just released their 2.0 actually, which has some really amazing features, but Astro is really focused on kind of pre rendering content, basically having all of your stuff be as fast as possible and shipping, no JavaScript, [inaudible 00:19:10]. In addition to this concept of Astro Islands where you don't need JavaScript for your entire page. There's lots of stuff on your page that just doesn't need it. So Astro Islands allows you to ship JavaScripts specifically in the sections within a page that need the JavaScript, which is pretty neat. They let you bring in your other frameworks. So the things that we've been talking about React and View and other ones you can bring in and actually use inside of Astro, which is really, really wild to me.
The biggest thing for me in moving to them is I was actually looking at migrating my site to Next.js and I was getting into Markdown for my blog posts and how to display code snippets and all these things, and I was spending hours trying to configure it and that's not necessarily a shot at that. I think some of it was just my lack of experience. But doing that in Astro is supported out of the box. Astro just supports Markdown. You just throw it in. You can throw in Markdown as a route in a routes directory. It'll just display it as a website unless you tell it otherwise. It's used to handling Markdown. You can add MDX, which is really easy. It has built-in code highlighting, which is something I spent a ton of time trying to configure and in Next.js. So everything about that type of site with Astro is incredibly smooth and what's really cool, I mentioned they just released 2.0, they now have type definitions for the different types of content that you may have.
So different types of Markdown content would be blog posts or if I have a speaking page and I want to list out all the talks that I've given, I may have a different template for talks that I've given. So now that you have the ability to add type definitions around that and give you feedback to say, "Oh, in this Markdown file you didn't include a title, you need to have a title," and then you can get obviously the types and [inaudible 00:20:50] in the rest of your application. But I think they're a little more niche in targeting specific experiences and use cases, but what they do for those experiences is really topnotch.

Amy Dutton:
Yeah, I'm a huge fan of Astro as well, but I think what you said at the end there is key because it will tell you even in the documentation that if you're trying to create a single page application that does all the things, Astro is not necessarily the best framework to reach for, which I appreciate for them to say we're going all in on say personal sites, blogs, static sites where you want to use Markdown, we are the framework that you want to reach for. But if you're trying to do anything else, maybe look somewhere else. So the fact that they're not trying to be all things to all people allows them to do some really cool things with the group that they are trying to serve.

Kate:
 Is there anything that we wanted to talk about in design specifically for 2023?

Amy Dutton:
Yeah, that's a great call out. I'm not sure I would necessarily say I'm excited about it, but one thing that I am watching is just to see how AI affects design. So I know that's been a big thing even on the tech side with ChatGPT, but just the DALL-E stuff because you could say, "I want a stock photo with a girl smiling on the right side," instead of having to dig through hours of stock photography, could I enter in exactly what I'm looking for and be able to find that? That's kind of an interesting problem that deserves a solution.
So I'm watching that. I heard a quote the other day quoting Marshall McMullen that had a lot of stuff to say about tech like years ago, but a lot of the principles that he said still apply, but what he said was, "Just because you don't like it doesn't mean that you're going to stop it." I'm paraphrasing, but I think that when you have tech people saying, "We don't know what to do with ChatGPT," or "Are they going to write code? Are we still going to be creating websites?" The same would be true for design. Are robots going to design websites now? What's going to happen to our jobs? Just because you don't want it doesn't mean you can stop it. And so to embrace those technologies and get excited about it and figure out how they can leverage the work that you're already doing and enable you to move faster, that is really interesting.

James Quick:
That's basically my opinion on the tech and programming side too. People will kind of quickly with GitHub co-pilot and ChatGPT, are we going to lose jobs? Is AI going to take over programming? And the reality is no. I haven't actually made this piece of content, but I have this idea in my head where we've all been there where we're got to wash our hands with the sensor thing that only does it when your hands are there and it never works. Then you go to the thing that is supposed to dispense paper towels when your hand waves and it never works. And I have this video of doing that and being like, "And people think AI is really going to take over the world and we can't even do this thing." But AI stuff has gotten really, really good and it's exciting, but also understandably is making people really nervous to question that.
But I think it's just any other invention. We have hosting platforms now where we connect to a GitHub repo and they do the rest. Well, that didn't used to be the case. We used to have to go and FTP even before SFTP, like FTP files up manually to a WordPress site or whatever. So I think it's just more and more tools adding to a developer's tool belt. At the end of the day, you still have to have a developer to make the final decision to go through and confirm things are working.
But also if AI is able to do part of the job for us, that just means we have more time to go do other more fun stuff, to be honest, not to mention the benefits of, I think in a teaching aspect of being able to not only generate code snippets to solve a problem, but also to ask for why are we doing this and give feedback as to why and how we do it this way. So I'm actually kind of excited about it. Again, I don't think it takes away jobs. I think it maybe augments some of the things that we do longer term, not in the next couple of years, but I think it's just going to enable us to continue to build more and more cool stuff.

Noel Minchow:
Yeah, I totally agree. I think to James's point on like, we have all these cool automated deployments, CICD, you just wire up to a Git repo and it can deploy your front end, but we still have just as many CIS admin infrastructure people as we do before. They're just reasoning over higher level systems now. They can do way more with their time because we have so much more tech that does so much more and systems that are so much more powerful.
On the point of code generation, I think it's also healthy to reflect, and I'm sure it's kind of the same on the design space too, but what amount of a developer's time are they actually writing code? You're probably spending maybe 10% of your time typing characters. The rest of it's like you're thinking, designing, figuring out the problem space and how you want to solve this problem. So if you can make that 10% more efficient, awesome, but I think it's going to be a while before that 90% of engineering work is really meaningfully chipped away at. It'll be there, but I'm not panicking over my 10% of time actually writing code being more efficient.

Amy Dutton:
At Zeal we're a software consultancy and a big part of that is a client will come to us and they'll self-diagnose a problem. They'll say, "This is what we need. We need you to solve this problem. Will you do it?" And as a consultancy, some of the best responses that we can have for that client is to say no. And it's not because we don't want to do it, but it's because we don't believe that's what's best. So we can say, "No, I don't think that's a good idea, but this is what I think is a good idea," and we can help them lean into a better solution.
And at least right now, robots, AI are not at the point what you've asked them to do and what they are going to do. And so you still need a human to help you think through the best business case and the best user experience to be able to reach the solution in the most elegant way.

Kate:
As podcasters, you guys have a unique perspective on what is showing up in the community. What are some things that you have seen floating around lately?

Amy Dutton:
And some of that's an interesting point to bring up is that yes, we're kind of watching the horizon, seeing what tech is coming up, what people are using, but it'll still take me maybe 10 or 15 times of hearing a specific piece of tech brought up before I'll sit down and be like, "Okay, now is the time to figure this out and see if I can implement it within an existing project."

James Quick:
Yeah, I kind of poked fun at this earlier. I get to move a lot quicker than developers that work at a company because I just get to create big content, which is one of the things that I think is really fun about being a content creator is I have the ability to get distracted very easily and go and check out new tools and frameworks, et cetera. And that's part of the mix. You get very mixed emotions in the realm of web development because of how quickly it moves. You get people that are very frustrated that feel like they can never keep up. They feel like job requirements now are getting ridiculous because they're asking for all these things that are new. And then you see the cliché memes that are like, "We want you to have 15 years of React when it's only been out 10 years or whatever."
So it can definitely be overwhelming, but for me that's the exciting part. And where I get inspiration for creating content is all the different places that I'm involved. So in Twitter, in Discord, watching other people's YouTube videos, listening to other people's podcasts as I've alluded to several times. So as content creators, we get so much inspiration from other content creators, and it really is kind of a fun thing when you start to embrace that community.
So Amy and I obviously get to spend a lot of time together. I'm also in a programming YouTuber's Discord where a bunch of technical YouTubers get to hang out and talk, share insights and ideas and trends and feedback and that sort of stuff. It's a fun space to be in if you don't take the overwhelmed approach and just kind of take the time that you have to experiment and try and not get too overwhelmed, which is hard to do. But especially I think embracing the community around it, following content creators, engaging with them, et cetera. For me, it's just been a ton of fun the last couple of years.

Amy Dutton:
Yeah, another place where I hear about new stuff is conferences. And James and I have been traveling around and doing quite a few conferences lately and had some time to speak to Brad Garropy. He's also been a host on the Compressed.fm Podcast, but he is an engineer at Atlassian. And so one of the things that we talked about was the adoption rate at a very large enterprise company. So we talked a little bit about that briefly before, but it's easy for us to talk about adopting new tech when it's these small demo projects. But when you're talking about a large enterprise corporation trying to bring in new tech, what does that look like?
And what I felt was interesting was he described basically a platform team that will vet new technology and then figure out ways to pass that around the company. And so it's the platform team that does a lot of that education component, and they'll also write tools to help migrate some of those scripts over. And I think that also just points to the rise of microservices. And if you can isolate those components, then it makes it easier to update those individual pieces until you're able to update the entire platform.

Kate:
Microservices is only one of the things that I've seen popping up more. I've seen it now 10 times.

Amy Dutton:
Yes. Well, and we mentioned Nelify earlier and them acquiring Gatsby, and part of that is they're going all in on this composable architecture, and it's kind of an interesting term. What does that mean to you? How does that actually apply? But in a lot of cases, it's what is the best tech that you want to reach for? And I'm going to compose and put all these small pieces together. And when you think about it in that way, it kind of makes sense why they reached for Gatsby because Gatsby by itself is very limited, but it's their plugin ecosystem that really extends it and allows you to have superpowers when you're working with that particular framework.

James Quick:
It's interesting to me because again, I feel that composability is not always in the best interest of these hosting vendors. It feels like to them, they want to have customers that are stuck on their platform and doing their thing. It's interesting to me when they're like, "Oh, we're buying Gatsby for the compos." I don't want to call it like the acquisition. But it's like it's an interesting space where you have these tools, these hosting companies, and they're the big boon they get, the thing that empowers them is you get all this cool stuff out of the box with us as a hosting provider, and it's like composable.
It's like, well, it's kind of composable, but you're selling me a thing that is inherently less composable than it was before by virtue of wanting performance. I think it'll be interesting to see kind of how to react and what people end up reading for, for fear of vendor block in. Now it's a cool time to be watching stuff either way.

Kate:
For sure. What is up next for Compressed.fm, for Learn Build Teach? Tell us what you guys are working on, what you guys are excited about on your own platforms.

Amy Dutton:
Yeah, so for Compressed, the big thing is we're going to keep going. So we have about, I think 125, 130 episodes now. So next year hopefully we'll have a hundred more. Right now we're doing two a week. So that's been just a really fun project, a great networking opportunity, a great way to learn what's on the horizon and things like that.
One of the things that we're experimenting with, been experimenting with this past year, but really want to be serious about delivering on is a swag store and what that might look like. And we've created a bunch of apparel shirts and stickers and things like that, but actually trying to build the system behind it to be able to deliver those things. So hopefully we'll be able to release that in the coming year.

James Quick:
Last year we did, I guess, two conferences last year and one already this year in person with live episodes, which is a ton of fun and a really incredible experience and really cool exposure for us for the podcast too. So I'm hoping we get to do more of that this year. We're supposed to be doing one at RenderATL in May, which should be a ton of fun too. For Learn Build Teach, this is the Discord community that I started almost around the same time. This may have been 2020, so it may be a little bit older, but it's been a philosophy of mine for years. As we just said, as developers, we spend tons of time learning. You just can't stop learning. The learning never ends. And so then you go through the cycle of you spend a lot of time learning. You use what you learn to build stuff, and then you teach other people for two reasons, one of which can be completely selfish of the more you teach other people, the better you learn the material that you're looking at.
I've started recording YouTube videos in the past and just stopped and gutted the whole thing, because I realized I didn't know the topic as well as I should to be able to explain it to other people. And so it helps you either reinforce things you already learned or then maybe realize you didn't know things as well as you did in the past. And then obviously helping other people out is huge, and we see more and more people creating content, whether it's just tweets or blog posts or videos or whatever. And I think that's a pretty amazing thing. So anyway, this year my big goal is driving engagement and interaction in the server. So there's like 5,000 people, which is a ton, but we have a very, very small subsection of people that are active on a monthly basis, for example.
And so we started, we have our wins of the week session on Friday morning central time. This is basically where everyone goes around and just shares something good from their past week. And the thought process is most of us don't do that. Most of us don't take the time to appreciate what we've done. Most of us finish the week and feel like we should have done more without actually reflecting on the things that we did well. So we want to help encourage people to think through that and share that, and then celebrate it with them. And then we're starting to do a few live coding internal sessions and anything else that we can come up with just to get people more engaged and make sure that we are providing that safe space for people to do those three things, learn, build, and teach with each other, and continue to celebrate all those things with each other as well.

Kate:
Awesome. Well, thank you guys so much for joining us today. Go check out Compressed.fm, Learn Build Teach, all the things. We'll include all those links in our show notes, and yeah. Thank you guys.

Amy Dutton:
Thank you.

James Quick:
Yeah, this was awesome.

Noel Minchow:
Yeah. It was good chatting.