Fred K. Schott: I connected early on with a story that other people felt. So it was just like pain of modern development has gotten really complicated and slower than it feels like it needs to be. We all knew that, but there wasn't a really easy fix to it because it was ingrained in the technology that you had to do all this work. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open-source projects and the communities that make them, I'm Eric Anderson. We're joined today by Fred Schott, the creator of Snowpack. And I'm super excited to have you on Fred. Fred K. Schott: Yeah. Pleasure to be here. Thanks for having me. Eric Anderson: As is customary, why don't we have you start out by telling us what Snowpack is, and then we'll go into how it came to be. Fred K. Schott: Yeah, happy to. It's been a pretty exciting project, that's been around a lot longer than I think people think. It came out of a more research experimentation project I started called Pika, which some people still know it by was essentially just a way to look at modern JavaScript as a way to speed up dev tooling and dev... Essentially everything that developer touches. Snowpack came out of that as a way to speed up your build tooling. So it's a build tool, somewhat like a webpack or a Rollup, but it leverages these modern advances that have come out over the last five years, but it hadn't really made their way into tooling. We really leaned into those advances and essentially designed the tool for this modern world. Fred K. Schott: And through that, we end up with a much faster dev experience. So you can start off this dev server, build your site, essentially get live in development in less than 50 milliseconds. And every change is essentially instant because we're only rebuilding individual files. So make a change, save it and then we essentially push that update directly to your application. So you see that change live essentially instantly. Eric Anderson: Yeah, I became aware of Snowpack first through the Svelte universe. Svelte has new efforts in place that puts Snowpack the center and stumbled into Snowpack that way. I imagine we'll cover that soon, but I wasn't aware it was so old. That's interesting. Fred K. Schott: Though it's not ancient, but in infinite world of modern dev tooling, it certainly is. Eric Anderson: But it wasn't created yesterday. Fred K. Schott: The Svelte community is really interesting because they are definitely a more modern framework. So they don't have a lot of the legacy that React does where someone building with React you all of a sudden you start to use these older packages of these older dependencies that don't really work as well in the modern world. So you see a little bit more fiddling that you need to do in those ecosystems, but Svelte is just everything is modern. It's a really nice dev workflow, so just from a term of the ecosystem that a community has really been able to connect to this new dev tool and this new story in a really cool way. Eric Anderson: Great, well, I imagine the Snowpack story maybe is in some ways your story, but take us back to Snowpack's beginning, and however far back you need to go. Fred K. Schott: Yes. I really started looking at this back in 2016, 2017. So that's the fun part about this project is that we're using what is modern technology, but it's stuff that actually has been really ironed out even earlier than that. So, back in 2015, and even earlier, there was this idea of standardizing a module format in JavaScript. So a way for the browser itself to actually like, okay, I'm loading this file and okay, this all depends on this file and that depends on this. A native way to load a full application without any extra tooling needed all native. That was an idea that got ironed out and then standardized and finalized around 2015. And everything in the browser takes a while to work its way into the ecosystem. Fred K. Schott: So over those first few years, it was in modern browsers, but most users weren't on those modern browsers. So you ended up with, you can use it sometimes, but your users can't. So we've for the last five years, been in a way of you build this way, but then you have to do all of this tooling to handle it for everyone else, like that backwards compatibility. But I was lucky to be working at Google at the time on a project called Polymer, that was very future looking. So it was within the Chrome team, essentially as a way to look at web components, but we also spent a lot of time thinking about tooling and dev tooling as well and ESM this new native way to load code in the browser. So through that, I got experience with this new format and this new system, I ended up leaving Google around 2016, 2017 and went to go work at a company called Ripple. Fred K. Schott: And through there then got to revisit these technologies now from the outside looking in. So Pika as an experimentation really came out of that, and that was this idea of let's just look at this technology and run some experiments. Let's try new things. So we worked on a code editor for a while, Snowpack came out of this project called Pika Web, which was a way to work with these packages. There was a search catalog, there was all these cool, interesting experiments that have through the years, some of them have gone away and some of them have become what is now Snowpack and the company that I started last year, which was Skypack, which is a way to load code from a global CDN. Fred K. Schott: So that was it, that was what brought me to Snowpack was that early experience with the technology and then the realization that there was a missing part of that technology, just, it was out, it had lived for a few years out in the world, but no one was really taking advantage of it, that we could build better tooling by just leveraging sign that by 2018 actually had lived out in the world for a while now. Eric Anderson: So I have to admit, I'm familiar from the developer experience, NPM installing things and having a whole bunch of stuff in my Node modules. But what you're talking about is at runtime, when the user downloads, pulls up a website, a bunch of JavaScript gets downloaded, help me understand further how Snowpack is changing things. Fred K. Schott: Yeah. So it's taken us a while to get to... What you're describing is essentially what we just released. So it's just our next stance on what the future of what development looks like, which is the idea of, instead of having a lot of stuff that you run locally, just as you're developing and Snowpack fetch the code that you want, that you might be depending on and do that live and invisibly. So you don't need to worry about a big Node modules folder, or a lot of tooling that you need to work on, on top of what you're just trying to build for your application, trying to make an invisible and really seamless and on demand is the goal. Eric Anderson: Okay. So the original or early versions of Snowpack address runtime, and you're saying this newest version also pulls in some of that magic to the development time. Fred K. Schott: Yeah. We've worked our way up to this exactly. So the early stuff was just taking a look at as the webpack or Rollup or create React app, or even Next.js, all of these other tools follow this model where as you're building, a lot of tooling is essentially bundling and processing your entire application and shipping it to the browser, which means that as your project grows and grows, those tools are having to do more and more work. It doesn't actually scale well into a big project, it's more and more upfront work. So splitting that up and focusing on individual files versus entire applications, that was the first vision for Snowpack as the dev tool, this idea that you don't need to do all this processing and bundling, you can just work on individual files, build individual files and ship those to the browser. Fred K. Schott: And that way it scales really nicely, it gets that fast startup time on small projects and large projects because you're only ever building what gets loaded. So if you have a thousand pages on your website, you're still only building the one that you just loaded in development. So it's really efficient that way, this new version through Snowpack takes that same idea where it's, if you're not actually going to load a package, some dependency, why are you doing this upfront work to get those all prepared and ready to go? Why not just pull it in on demand? And at that point then why are you even running NPM install at all? Why not just let, Snowpack pull it in on demand. So by leveraging the CDN that we've built called Skypack, you can essentially get any package as pre bundled, pre-built, ready to go JavaScript. Fred K. Schott: So that whole folder that's within your Node modules and all of its dependencies are just turned into JavaScript. And that's at the end of the day, what we've always really wanted in the front-end application is just giving me JavaScript that I can send to a user. So it gets rid of all this indirection to just give you for React, here's a React.js, here is React fetched from our CDN and then running in your application almost instantly. Eric Anderson: So you're really stealing Apple's business. I no longer needed a terabyte hard drive to do front-end development, is that... Fred K. Schott: If we're stealing from anyone, it's just like the way we did web development, way back in the day, which is this idea of actual scripts. And because there was no Twinner, you had a hundred different script tags that would get loaded and maybe you added some structure to that and the loader, but the idea that React is actually a React.js like a JavaScript file is a really old idea that we just reconfigured for today. No new ideas in the world just constantly reinventing old ones. Eric Anderson: And was this a personal pain point for you? So at Google you were producing tools, you weren't necessarily building sites and running into these issues, maybe at Ripple or... Fred K. Schott: Yeah. This is something that all web developers have felt, I think, I don't want to speak for everyone, but time and time again, you just get used to, well, this is the way a web development is. There's all this slow processing and I make a change and I wait for my... The idea of your Dell or your computer spinning up these fans to cool what is a really intense tooling process. I think combining that with the knowledge that hasn't always been the way it's been. Having worked on projects even before webpack was the thing you had this really snappy everything's a JavaScript file, so there is no work to be done it just gets sent to the browser. So it was like we had this really fast dev experience. Fred K. Schott: We then wanted to unify everything as a community around no JS and NPM. And so to do that, we brought in this tooling, but we had a pretty good setup in terms of speed before that tooling was in place. And so this project has been trying to like, is there a way to square these two ideas, have the great ecosystem that is NPM modern web development but with the same features of an older world where you're just working with JavaScript files already, so you're not having to do all this processing. The idea that you have to like, okay, I made a change. I'm going to wait for this to rebuild and recompile that's such a... JavaScript, never had that problem. It was one of the few things that JavaScript had to look at others and be like, huh, we don't have that problem. And then all of a sudden we did, so it's been a journey back to basics or back to what we used to have and seeing how we could fit that together. Eric Anderson: Now tell us how the rollout or adoption has gone. You've been doing this for a few years. Skypack for, I think it was the last year you mentioned, and I feel like you got a bump from Svelte, but how has this started getting traction? Where are the communities where it sticks? Fred K. Schott: Yeah. So definitely more modern, the more modern that ecosystem and the more modern even the developer, if you'd like to work with modern tools, you already have an advantage here where you're maybe familiar with this idea of ESM and native modules in the browser. So there's a little bit less that will feel unfamiliar. And then Svelte being an ecosystem that's more modern, it all already works out of the box versus having to fiddle with configuration to get older packages and older systems in play. It's really basically, one of the ideas is how to move an ecosystem that is so built up on how webpack works. The first thing you learn when you start to build tools like this, it's like, Oh God, everything in the ecosystem was designed for webpack and the specifics of how this dominant tool did things. Fred K. Schott: People weren't writing and saying it was natively correct. There were [inaudible 00:11:12] and it was like, webpack correct. And that difference is subtle, but ends up then influencing the whole direction of the community. So a lot of this project has been both education of package authors, realizing that there things only work in a certain tool that is now becoming one of many options for developers, webpack versus Rollup versus Snowpack, it's a whole ecosystem now. So we've seen that whole NPM ecosystem really get more modern over the last couple of years in a way that they hadn't really had the previous years, because this was also new. It's now much more better understood, better educated, better documented. They're not necessarily new ideas anymore. Eric Anderson: Maybe you can help us understand who else has helped bring Snowpack into life. I've mentioned Rich at Svelte, are there others? Fred K. Schott: Yes. The Svelte community and Rich's work with SvelteKit, which is their new sapper, their new application, has been really instrumental. Our server side rendering engine that we just released in v3 of Snowpack was actually really heavily, essentially grabbed out of SvelteKit, so Rich build this wildly impressive, very weird, but also super useful way to turn any front-end code into something that could actually be loaded into Node. So instead of rebuilding it, essentially just import it from Node through this pipeline and you get front-end code running on the server. So Rich built that because he needed it in SvelteKit and his work, and then essentially was like, this might make more sense in Snowpack in a more open-ended where anyone could use it [inaudible 00:12:39], so that partnership has been really instrumental. Fred K. Schott: I'm trying to think there's another... There's a really cool project called Microsite, which is using Snowpack to power this really interesting idea called partial hydration. So the idea of building an application and sending it to the user, it can get expensive. And so this project by someone in Nate Moore is looking at what if we could actually just render the site and then get rid of all that code that you're sending. So essentially server render, but now we're actually not even sending anything that is no longer needed, essentially stripping out everything that's already been rendered from the code. So the code you ship to the browser gets really, really minimal compared to what it was originally written to generate the site in the first place, you partially hydrate the site. Eric Anderson: Yeah. Fred K. Schott: So there's all these projects that are building on top of what we've made, where essentially we're just trying to create a new foundation, a faster, more efficient foundation. And then all the same stuff can be moved over, the Next.js could be rewritten for Snowpack. But you could also start to re-imagine new types of tooling that wouldn't be possible without this native module loading that Snowpack really leverages. The analogy I use is, it's the ninth inning of this webpack story, there's a really mature tooling ecosystem around it. And Snowpack, and these ideas of ESM were first ended. There is so much green field, so much stuff that can be built out as we explore and learn what's new and what's possible. Eric Anderson: Yeah. So maybe take us to the beginning of releasing Snowpack, you push this thing out into the world and maybe there's not consumers on day one, you've got to go find the Riches, it's Svelte, or maybe they find you and you find this fellow at Microsite. Is that how it works? So do they come out of the woodwork? Fred K. Schott: Yeah, I was lucky that I connected early on with a story that other people felt. So it was just pain of modern development has gotten really complicated and slower than it feels like it needs to be, we all knew that, but there wasn't a really easy fix to it, because it was ingrained in the technology that you had to do all this work. So part of it was just looking at efficiency as a conceptual thing that should be solved for, but also as a real pain point that developers have. Building this out, it was not like, what is today Snowpack was not the first vision. So the first vision was just, let's take a look at a really small piece of this, which was your packages, so the Reacts and the React to maybe button that you've pulled in, it was this understanding of how to scope it, which really fit in well with the idea of those packages are the only things that are actually holding us back from this modern world. Fred K. Schott: You can write this modern code today that takes advantage of the browser. And then as long as you have modern packages, that's it, you're now in the modern world. Eric Anderson: Okay. Fred K. Schott: So it was this idea of if we could tackle the biggest pain point first and let you do a little bit more of the work, where you had to build a modern tool yourself, but we would fit into that tool. That was our first group of users was we were just a piece of a puzzle that they had to put together themselves. But from there, Snowpack became the full puzzle, the full integration of your packages, your own code, and creating a dev environment that worked across the spectrum of apps. Eric Anderson: And at some point along the way you start thinking maybe there's a business here, Skypack comes into the picture, tell us what's the debate like that. What do I do now that this thing's taking off? Fred K. Schott: Yeah. It's an important clarification to Snowpack is not the business, Snowpack is a really fun tool but it's completely open-source. We're not trying to charge anyone for an open-source build tools, it's very much just something that we really enjoy and see should exist in the world. But Skypack was the other side of Pika, which was what does this new ecosystem look like? And really keeping an open mind of what are the tools, but also what are the services that exist in this new world? What does the NPM of this new ecosystem look like? The Next.js what is hosting, all of these different pieces of a web development puzzle. We really tried to go into that question with open eyes. So the early version of Pika originally, I think we were really looking at what does a GitHub for packages look like? Let's replace GitHub and everything, and create a whole new world, it was really ambitious and really difficult. Eric Anderson: Yeah. Fred K. Schott: But through that work, we realized, well, really it's the modern part of this is the access to those packages. That's what needs to be tackled for instance, I have a package and it's all these different files and maybe it was written seven years ago, so it will never run directly in a modern environment. But because CDN was getting a lot of attraction as a way to up convert those packages in a way that anyone could load from them. So the CDN is the way that you can load any package and get back a single modern file. That was an idea that people really connected to. And both in terms of like, Oh, this is cool, I don't even need a build tool at all. I can just in my application import from URL and I'm now working on code that will run directly in the browser. Fred K. Schott: So we're still figuring out what that means. It's a wide open world, but there's clearly a story here that a CDN provides for, which is, again, it's an old story. The idea of jQuery had a CDN back in the day and it's this point of pride to have your own CDN as a part of you made it. We're seeing how far we can take that idea into the modern world, which is running a CDN, providing code and then trying to connect more and more developers to this more modern way of thinking. Eric Anderson: Got it. So Snowpack got its own life as a modern build tool. And then in the same ecosystem, you found a place for a Skypack to be this CDN to deliver your packages. Fred K. Schott: Yeah. So we're just excited about what people are building with that it's just like, we've seen the future, it all fits together, but who are the players? What does it look like? What are you building that world is still again, it's the first ending of the story. So we're really excited by the progress we're seeing. Eric Anderson: Yeah. Yeah. One question on this future world. I hope I don't derail it's too much of it. Deno is another... When we talk about Skypack that lives also in the Deno universe, where does Deno and Snowpack begin? Do they have complimentary place? Fred K. Schott: Yeah, they're more similar, I think then at least we all realized as the people building these things, I've only chatted briefly with the people behind that project, but that idea of importing things by URL, that's the technical innovation that this modular system provides. So they're leveraging that same technology, but for a different use case, which is server side code. So really same spiritual roots. We share a lot of the same beliefs in how we see JavaScript evolving, but them tackling the server side and I was tackling the front-end. So you can think of Snowpack is giving you a lot of Deno ideas, but in a more traditional Node front-end world, it's like, if you like the things that Deno is doing, you will definitely like Snowpack, you can import by URL and Snowpack if you want to. But I think where the real innovation where these two projects probably collide maybe down the road less today, is there are people experimenting with front-end development in Deno. Fred K. Schott: So the idea of writing a front-end application in a way that can run in Deno and in the browser, it's the same exact code base. I'm blanking on the name of it, but someone is working on a Next.js, essentially a competitor. It's the same, really borrows heavily from what they've done, but for Deno and because it's all browser native, you're writing code that runs in both places. So it's a really interesting idea that they're taking essentially to the extreme of, we now have a runtime called Deno, which can run the same code as your browser. How does that change web development? I think that's a really interesting conversation. Eric Anderson: Yeah. The kind of Node versus browser divide it's an unfortunate situation of our time. Fred K. Schott: It's been a very painful journey for Node to even add this modern ESM support. So that idea of the import export in there no JS code, it's a migration of the entire underlying model of how a framework works. So the fact that they've even gone as far as they have is really impressive, but it's going to be a really tough journey for them because it's so much of the ecos of 10 years of development is built up assuming one thing, and now they've flipped it. They're doing as much as they can to support both, but at the end of the day, it's a really complex problem to solve. It's easy to be the ones that just throw out the old and bring in the new, it's essentially what Snowpack has done, but Deno definitely gets to benefit from just not having to worry about that legacy in the same way, where Node is really having to be intentional. And it's going to be probably a painful journey or at least there's more pain to come in terms of that migration. Eric Anderson: So on this show, we have all kinds of open-source projects and databases, data processing, and among many of those governance becomes a big question. Are you going to be in Apache or Cloud Native Computing Foundation? But in the front-end that doesn't seem to be as big a concern. Maybe help me understand how you think about maturing the project, governance and maybe help us all understand how the front-end works in this question. Fred K. Schott: Yeah. I think the front-end community and JavaScript community has an interesting relationship with companies and that idea of companies, there's plenty of people who just bristle at the idea of it. And I think that there's a lot in open-sources background where it's like companies have always taken advantage of open-source. How many billions of dollars and value has been generated by open-source projects? Even there that's a whole mind shift. Open-source projects within a company taking that value, getting value out of that and not giving back to the community. So definitely, it's not a happy relationship, but it's one where there are still the incentives where open-source tooling is still a great way to get ideas out there. If I'd had to sell Snowpack in the day one to make money, it would have been really tough to get adoption. Fred K. Schott: And I think some people projects are doing that today, but it's a tougher road to climb. You really need to be good at marketing in a way that I certainly wasn't at the time. Eric Anderson: Yeah. Fred K. Schott: And then, so you have this weird relationship where companies are getting value, they're not really giving back the way they should. And then plenty of people I've experimented successfully with building companies around these open-source projects. So you have this weird, the reality is that it's a valuable model, but the reality is also it's one that gets taken advantage of a lot and maintainers like myself and plenty of others get really burnt out as a result. We're trying to do the right thing with this. So Snowpack being a separate project, we're releasing an open governance document and model that we're working to try and follow, really trying to both support the community with the company side of things, as a way to support maintainers, support good work both financially and just with resources, whatever that looks like and whatever people need, but it's tough. Fred K. Schott: I couldn't be working on Snowpack full-time without the company side of it, sustaining my own work and sustaining myself. So it's a problem that really doesn't have a good solution yet. And everyone's trying to figure it out, but it's something we hope we can solve for at least within Snowpack. Eric Anderson: And then take us forward from here. I think I saw somewhere, somebody saying 2021 is the year of Snowpack or some name, [inaudible 00:23:19] obviously making that up. Fred K. Schott: It was probably me. I have my shadow accounts. Eric Anderson: Yeah. There were bots out there [crosstalk 00:23:25]. Tell us what's in store for Snowpack in '21, and then maybe I'll just make a plug, yesterday as of the day, we're recording this, you were speaking with GitHub about the future of the front-end development, I believe. And I imagine Snowpack plays a role in that, but feel free to take us beyond '21 if you want as well. Fred K. Schott: Yeah. That was a really fun talk. If you care about the future of web development, it was less about Snowpack and more like, what are these trends that are going to continue into the decade? Yeah. I got to touch on a lot. Really the core concept of, I think how I have understood the last decade is we have this really nice model, which is a single page application. So you can think of something like a create React app or this idea that I'm building a full website, it's HTML and CSS and JavaScript. I'm the front-end developer and I'm building an application. And then I talked to backend services via a really explicit contract of an API. It's this really nice organizational structure, especially within companies where it's the UI application does this one, then the backend service does this one thing. There's a really explicit communication. Fred K. Schott: And then you can have multiple UI applications, a desktop app, a mobile app, a website, all sharing the same backend code. It's really small, but it has performance issues as we've learned towards the later half of the decade where you're having to ship an entire application to the browser, to the user's device, that they then have to render themselves on a low power device or a poor connection. Eric Anderson: Yeah. Fred K. Schott: You're doing a lot of unnecessary work on the device that is low powered by definition. So it's a model that makes a lot of sense for the developer, but it doesn't make as much sense for the user, especially where did they came from? You come from a world where you go to a website and it streams down exactly what you should be seeing. So it's not streaming on the code to generate what you should be seeing. Fred K. Schott: It's the older model was a lot more efficient, you just gave the user the code to display. I think that's going to be the big question of this decade, which is what does it mean to build a modern application in a way that is as nice to use as the developer, but it's faster for the user? You can think of Next.js as a solution to that problem, or an attempted solution to run more code on the server while still having you think in terms of a single front-end application. So blurring the lines where it's an application that runs on the server and on the device. That's one way, other older Rails, not that it's old, but just went out of fashion with a certain type of JavaScript developer because it wasn't a full JavaScript application. Fred K. Schott: It truly blurred the lines. It was one server on Rails and your front-end application was a part of that. Does that get a second look? Because now we're saying that to solve this performance concern, we need a server. Well, why not use Rails? Why not use something from this model that was built for this model of blurring the line? I don't give any good satisfying answers, but I think it's a really important framing and an [inaudible 00:26:03] just what does the future of that application model look like? Eric Anderson: Yeah. And it sounds like all the exploration that is happening around the tools including Snowpack are right at the heart of that, right? It's between blurring the lines between what's happening in the browser, what's happening on the server and giving developers a UX experience where in some ways they don't have to think about that, or at least they get the portability in the choice. Fred K. Schott: Yeah, there's this dream of Skypack, which is not here yet, but the real vision of Skypack as a CDN as a place where you can look packages from, is this idea that as a user, if you actually are a user browsing the internet and you're downloading things in production, as a user, you're downloading things from Skypack, you're seeing those URLs. It means that sites can start to share common dependencies. So this is idea where, let's say you go to Facebook and Facebook uses React. Eric Anderson: Yeah. Fred K. Schott: And let's say that they have decided to use Skypack as the way that they serve React. That means that every other site around the internet, if a user has been to Facebook and this other site also uses React, that user wouldn't have to re-download it, it would be a shared dependency that both sites leveraged so the phone or whatever device it can understand, Oh, great. I've already seen that I've downloaded. It's already saved, I'll just use that. For a world of all of your dependencies that ends up being 90% of most sites. So there's this vision of the browser getting more efficient with sharing resources that Skypack is like directly tied into exploring. Fred K. Schott: Whether that's us powering all of these different imports, I think that's a little unrealistic, but more, what does it mean? Can the browser be smart enough to see, okay, this is React from here and this is React from there? It's the same file, I don't need to re-download it every time I see it. That's all tied into the vision of Skypack and the vision of this native module, this React.js as a file itself, that we're really interested in exploring. Eric Anderson: That's super fascinating. Yeah, it is. You think about today, every website I go to I'm downloading the same 90% of stuff. Every- Fred K. Schott: Your phone has React saved in 20 different places, probably hundreds of different places. But because of the way we bundle it, it's locked into this larger website. The assets are all bundled together, compressed and compiled, so the browser has no way to share that. So that's a model that really gets me excited about the web as an efficient way to only sync the parts that you need of a site, get the code that this custom to this site, and then share all the common stuff across the internet. That's something that really gets me excited. Eric Anderson: Great. And then back to the question of Snowpack in '21, what do you users look forward to? And maybe if there are listeners here who want to get involved, what do they do? Fred K. Schott: Yeah, it's a great time to get involved. So v3 that we just launched was a lot of experiments that are now been finalized and put into production, ready v3 to use. So that idea of streaming your imports from a CDN like Skypack and skipping the whole NPM install story, that's fairly new. And there's a lot to uncover now that we have that, what comes next? Bundling and how we build your site for production uses a brand new esbuild bundler. So esbuild is this really cool project it's written and go, if you haven't had Evan from that project on the program, you should. Because it's a fascinating look at the other side of this, which is that we don't need to change the ideas of what we're building. We just need to build them in better ways. Fred K. Schott: So it's a native compiled code bundler that is essentially a 100 to 300 times faster than what our pack is doing and what others are doing. It's really, really fast, and so we're lucky we get to leverage that as a more modern tool. We can connect that into our thing. Now if you build a site with Snowpack, you'd get that 300X speed up. There's all these really cool new ideas that works for, and that are still just because they're released, it's still that day one mentality of like, well, what comes next? So there's a lot of improvements we're going to be making on that over the next year of just solidifying these ideas and exploring them even more to build the best dev tool that we can. Eric Anderson: And where does the Snowpack community gather? Do you do events? Is it all Slack? What's the... Fred K. Schott: Discord is our main community. So check out snowpack.dev it has links to all of these things. But we generally use Discord for just the community itself. Shout out to that, that server's a lot of fun and then GitHub is where we do our development. So there're discussions there and issues and pull requests, contributor guidelines, and soon to be a governance model to kind of... We're getting to the point where I can no longer maintain this, it's gotten bigger than just me and so we're really excited about just bringing more people in to help maintain, help grow the project. And I'll set the direction of where this goes from here. Eric Anderson: Fantastic. And then anything you want to say about Skypack? I imagine there's some overlap between the people who are getting excited about Snowpack and those getting excited about Skypack. Fred K. Schott: Yeah. Yeah. If you like the exploration of all this, this is something that it's all fits together conceptually. So even though they're separate projects, we are all people who are excited about this feature. We are hiring for Skypack, so if you're interested and this sounds exciting, please drop me a line on Twitter or anywhere else. We are building the future of the web and it's a really exciting project to be a part of. Eric Anderson: Great. Fred, thanks so much. This is an exciting time and it's awesome that you're in the middle of it and we get to hear your perspective. Good luck with '21. Fred K. Schott: Yeah. Thanks, for you as well. Thanks for having me on. Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time I'm Eric Anderson and this has been Contributor.