Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks. Brian: Hello. Welcome back, Swyx, for the second time. Swyx: Hey. New Speaker: I'm seeing you. No one else is seeing you, but they're listening to you. Hey. Swyx: It's good to be back. Thanks for having me. Brian: It's my pleasure. It's our pleasure. So we had you on when? I don't know. Two months ago? Three months ago? Something like that. Swyx: Yeah. Brian: Roughly, and in the intervening time, you've been doing things, which seems reasonable. One of the things that you've been doing has to do with Svelte and the Svelte Society. So I have two questions, and you can decide in which order to address them. One, what is the Svelte Society, and why? So I guess that's 1A and 1B, and the other question is like... I personally have a hard time truly understanding what Svelte is, and why people compare it to React, and what the... I think it would be useful for the audience for somebody who is certainly more knowledgeable than me and perhaps even an expert to be like, "Here's what it is. Here's where you would use it. This is why it exists." Et cetera. Swyx: Sure. I probably should start with what is Svelte first. So Svelte is a framework, a front-end framework comparable to React, Vue, or Angular. I would say it's definitely in the... It's considered one of the big four now, I guess, and it's the smallest of the big four. It does one thing differently from the others, which is it focuses very much on a compiler-first approach compiling in the features that you use and nothing else. So a Svelte project like a "Hello World" with Svelte will be the absolute smallest among the JavaScript compared to all the others because it has no framework footprint. It has a very small runtime, but it essentially compiles to the JavaScript that you would have to write by hand yourself. Swyx: So it's very much a lightweight approach for people who are very sensitive to bundle size, but it also has batteries included by having scope styles, animation, state management. All the features that you would typically expect out of a proper frontend... full-feature fronted framework. Because it only compiles in the things that you use, it can offer that kind of thing without actually compromising on the bundle size. So that's Svelte. It was created by Rich Harris at the New York Times. He's had several runs at this. The predecessor framework was called Reactive, and when he realized that he wanted a completely different syntax, instead of hard forking Reactive and taking the community in a different way, he just let it go on its own and created a new framework to serve his needs at the New York Times, and obviously... Brian: As one does. Sure, you'd make your own framework. Swyx: As one does. He's the sort of guy, and there's a small group of performance-focused JavaScript people who are very, very particular about their dependencies. So they don't just randomly import a billion things in your known modules. They actually care about what goes in there and the speed of all these things. So he's also the guy that made Rollup, which is the number one competitor to Webpack, but also, a bunch of other utilities for testing, and for string manipulation, and so on and so forth. So Svelte serves the needs at New York Times. Any time you interact with a New York Times article, particularly anything in a data viz sphere, it's made with Svelte and D3, which are all New York Times' technologies. Swyx: You can see that the need for performance as well as the need for rapid development because usually, it's just one or two people working on those things that are viewed by millions, and you need the full feature. You can really see the decisions that arise over there, the conditions that have been made. So there's a decent amount of adoption, bySvelte... We can talk about the companies, but actually, a lot of news organizations have followed suit, so. I think it's called Le Monde in France has adopted it. Brian: Yeah, yeah. Swyx: The Economist has adopted it. There's a lot of news organizations that they really tend towards it because they all had the same needs, which is data journalism, interactivity on a site where performance really, really matters, especially if you're dealing with a media site, and then also, it's starting to seep into some other companies. So I think it's Alaska Airlines that uses it for all their mobile onboarding applications, again, because of speed. Apple uses it for some of their internal sites. Disney, Square Enix, IKEA.com. There's a decent amount of adoption from well-known companies. So I think that's a rough explainer of Svelte itself. There is a metaframework that's called SvelteKit. So just like React has Gatsby and Next.js, or Vue has VuePress, Svelte has its own... It takes care of the service side rendering, and the static rendering, and all that. We can talk about SvelteKit and what it does, but yeah, that's the overview of Svelte as a framework. Brian: Well, my question was the adoption process, right? Swyx: Yes. Brian: I understand intuitively like, "Okay. If you are at The Economist, or Le Monde, or any other giant news site and the New York Times uses Svelte, you're like, 'Well, if it's good enough for the New York Times, perhaps we should give it a shot.'" So that makes sense to me. I'm interested though in how other... like disparate, but other different types of organizations, which I guess maybe their apps have similar needs like if a giant like IKEA probably has... Well, not probably. For sure has the same kinds of like speed is important, tons of media. That's a big deal, which is understating it, right? Will you go from like... I don't know whatever they were using before. But then, somebody at IKEA had to be like, "Listen. We're going to use Svelte now. Here's how I want to test it." Do you have any insight into how that process works? Is that any different than really any other framework change? Swyx: No. I think people just evaluate based on their needs and I guess their willingness to try new things because I think it's totally valid to hear about something cool and not use it because you already know the tools you do well. Some people are more adventurous than others, and they try it, and they really like it. I will say that it's interesting following along Scott Tolinski's work because Scott is part of the Syntax.fm podcast. He runs his own site called Level Up Tutorials with a small team of three or four people, and he tried Svelte, really liked it, and actually was like, "Yeah, I'm not going to do anything with that because my site is already written in React." Swyx: Then, I think on just a random whim, he decided to do a prototype of OnePage. Now, flash forward to about three weeks later, he's actually in the middle of rewriting the entire site and seeing the performance and the development speed benefits particularly in... Typically, when you rewrite from React to Svelte, you get something on the order of 20%, 30% less lines of code. But then, it also exposes opportunities to progressively add animations and styling because it's just built-in. It's part of the framework instead of completely alienating to React. So even a guy like Scott who has a fair amount of experience teaching other people to do animations in React finds it easier. Swyx: The other thing I'll highlight is also that Svelte also builds in CSS transitions and animations as part of the framework, so you don't resort to JS as much. You tend to use the platform more, and that's just because React tends to translate everything for you into JS. The final thing I'll point out, which actually has been a huge help, which is that critics of Svelte, people who say like it's not that big of a difference, paradigm change because it still uses components, because Svelte 3 has an API that's very strongly inspired by Hooks. They're like, "It's not that different from React," and that's... They think that's a dis, and actually, it's a benefit because you can learn it. If you already know React, you can learn Svelte in a day and be productive with it. It just has the features that you have been missing all this while. Swyx: So that's part of my conversion to Svelte from being a hardcore React person, and I think a lot of companies are moving along that path. Just to bring in a little bit of my own company, I work at Temporal.io, and we are spinning up a new frontend team, and the framework discussion was on the table. I was comfortable with both React and Svelte, and then I didn't... I tried not to influence it, and the team independently picked Svelte after building some of the prototypes. So the adoption conversation is going to happen in a bunch of different spaces. Swyx: I guess one of the big concerns is the size of the ecosystem, right? Like I just said, it's one of the smallest. It's the smallest one of the big four frameworks, and so there's this concern about hiring, and there's a concern about libraries. So hiring is easier because... Well, hiring is not as big of a deal as people think because people can convert very easily from React. Then, the second part about libraries. That's a more contentious bit because it is smaller, but the thing... The contention by the Svelte community is that you don't need as much. Swyx: React, because it's a very strongly functional paradigm, everything has to be translated to React dash the thing that you wanted because you have to write React adapters to everything. Svelte's native language is HTML. The view is that the first language of the web is HTML not JavaScript. So everything that works in HTML works in Svelte. So you can generally tend to plug in things like D3 better into Svelte than with React, and that's generally true for a lot of other framework agnostic libraries. Brian: Yeah. I mean, I think that's a great point to highlight earlier. You were known as a React champion for a long time. Swyx: Yeah. Brian: Now, you've converted. Swyx: I've gone to the dark side. Brian: Oh, I'm not sure if it's the dark side. I don't really know. I guess the question that popped in my head immediately was like, "Okay. So let's say, now that there's a big four, is there a big five? Will there be a big six?" So on and so forth, which is I'm not... I didn't come up with this idea. Swyx: Yeah. There's a meme of there's a new frontend framework every month. Why bother betting on anything? This will just come and go. Brian: That's a slippery slope. Why bother? Why get out of bed? Why? I don't know if that's too dark for PodRocket. Listen. If it's upsetting, everyone forget it. Sorry, guys. Swyx: No. I love addressing the top concerns head-on. There's no point pretending that these concerns don't pop up every single time a framework is discussed on Hacker News. So it's worth addressing that head-on, and I think the rationale for me is just simply that the Angular, Vue, and React just simply have not addressed my needs as much as Svelte does. I'm willing to try new things until I find something where I'm as productive as I want to be, and so far, that has been Svelte. I have proposed bringing back some of the changes from the things I find great from Svelte to React. I've done prototype for the React community to pick up on. But since the core team at Facebook is not that interested in it, I don't see a particular need to sacrifice my own time and effort on this project when there's an existing community that already shares my values and I can just join. So I'll put it out there. Brian: Yeah. Swyx: I'll talk a little bit about the... It's an interesting career bet, right? So I spent two years going really hard on React, and getting to know everybody who's anybody in React, and speaking at the top React conferences all over the world, and building a good, decent name for myself. It's the top framework. It's very highly in demand. So why did I walk away? That's a really fascinating thing, which I'm not really sure myself on why. I'll say that at some point, the reputation with the money doesn't matter anymore, and you have to focus on like, what is still bothering you at the core? Swyx: When you have job security, when you have a fundamental understanding of like, "Okay. Any time I need to, I can still use React, but what's next?" Then, you really start thinking about five years ahead, 10 years ahead, and understanding that the things as they are now may not be that way forever, and starting to try to really look ahead and position yourself that way. So that's where right about where I am right now. Swyx: People often point to this fact. React is as old as jQuery was when React was released, right? If you think about the evolution of JavaScript in terms of ages, there's the age of no frameworks, which is the formation of JavaScript. It's the first age of JavaScript. Second age of JavaScript was libraries modifying the behavior of JavaScript, which is jQuery. Third age was frameworks, and that was the age of React. What's next? Right? So very much thinking about what the future holds, and I think for now, Svelte is my bet, and I think it's been a decent one so far. Brian: Can you think of examples where Svelte is maybe not a great fit currently? What are the things that you're working on or not working on, or thinking like, "Well, that just is... You shouldn't use Svelte. You should use Angular because it's good for this?" Swyx: Well, my problem is I don't know Angular, so that's why. That's definitely a weak spot for me. Yeah. So I actually have written a blog post that covers this opinion that I call Svelte for Sites, React for Apps, and it just nicely pisses off everyone whether you like Svelte or React. Brian: That's not that hard to do, but yeah, yeah. Swyx: So React has the best cross-platform story right now, right? If you want to write one app, one code base that also runs on mobile, or TV, or what have you, React Native is really, really good. It's funded, and it's well-supported. No one else has anywhere close to that among the support, except maybe for Flutter, which is on its way up. We can talk about that one. The React Native story is really good, and then the accessibility for React is actually surprisingly good. So people ding React developers a lot because they tend to not know accessibility basics. Swyx: That is often true, but at the same time, because React is so big, it's getting the most investment from Chrome, from Adobe, from whoever else is working on accessibility to build in really good libraries for common controls that you might need in an app like Adobe Cloud or whatever they call that, the Creative Cloud. Yeah, and so I think the problem is it's not done. A lot of these are in process or not super well-adopted elsewhere. It's still being worked on, and you have to piece all these things together yourself. But if you really care about app accessibility, which is a different thing from site accessibility, if you really care about app accessibility, I would definitely look into that. Brian: I'm sorry to interrupt. Swyx: Okay. Brian: Can you explain the difference between app and site accessibility? Swyx: Sure. Yeah. Yeah, yeah. Look, again, I'm not a huge expert. Site accessibility is pretty much built into HTML. Use the right tags. When you need a button, use the button, not a div with an on-click, and then most things will be built-in. Use the in-built date field, date, time fields. Use the in-built inputs. All good. The problem with saying, "Just use Semantic HTML. You guys are idiots. Just use [HT paths 00:18:02]. Use the platform, and then all your accessibility issues will go away." The problem of doing that is that it ignores the harder parts of accessibility when it comes to apps and novel interactions that you're doing with your phone or your website when someone isn't actually using their eyes to browse it, and you need to work on things like focus control or things like styling with proper focus and active states. Swyx: Yeah. There's a long list of hard things that are being worked on in accessibility, which I can't really speak to. I'll point people to a couple of projects. So check out React Aria by Devon Govett from Adobe, and then check out Touching the Web. Something like that. Making the Web Untouchable by Rick Hanlon, who now is working on the React core team, and you can see how much there is to go for app accessibility. Swyx: The problem, part of their problem with the open web competing against native apps because really, the story of the web versus mobile apps is the story of mobile, right? It's the story of like, "Why is it that people still prefer the user experience of native apps on mobile? They'd rather go to the App Store and download the native app than to just go to a website when on the desktop, we're perfectly happy to browse a website, like where you're seeing Zencastr through a browser rather than downloading the Zencastr native app and using that." Swyx: That's simply because app accessibility isn't there yet. When I say accessibility, I also mean UX. It's very hard to distinguish the two because accessibility is basically UX for everyone. So that's part of it. The other part is performance, and some APIs are not available. All that is being worked on, but it's definitely a big topic, which I probably can't do service to, but you should talk to these people. Brian: No, I agree. I believe, and we could do... and we should. I mean, there's a... We could do episodes on accessibility and bring in lots of folks. I do want to ask one last question about Svelte because then I want to get into Svelte Society because I think that's cool too. So let's just say it's hypothetical. I'll propose. Let's say you're either an individual contributor dev or maybe even a manager of a reasonably-size team and you're interested in Svelte, but you've got to convince somebody. Swyx: Oh, yeah. Brian: They're not that... I mean, whoever that somebody is, is not convinced solely by what we talked about in the beginning of the episode was that it's faster, it has to do with bundle size, so on and so forth. How would you make that argument? Swyx: Well, it depends what they care about. So I can't really make a blanket proposition to everybody. I'll say just try it out and really try to look for the developer experience and productivity gains because it really is true that you write a few lines of code, and it really is true that because it uses HTML as its base, not JavaScript, you tend to be able to plug in other libraries easier as opposed to having to write a React translation later for everything. It really is true that you start using the platform where it's just CSS and native... and styling and animation. I think that's always a win in terms of performance. You start bringing in a library just to solve every little problem that you have. So that's one thing. Swyx: I think the other thing, which I really enjoy actually is... So, one time, someone on one of the podcasts that I've done said to me that, "Hey, React is open-source. One of the benefits of open-source is you can fork and take it over if the core team actually ever drops it or you disagree and want to go in a different direction." Try it. Try taking over React and try understanding the code base. Brian: Yeah. Swyx: You cannot, but then, go through that experience. Actually, go read the React source code, right? See how convoluted it is, and then come over to Svelte and look at the source code of that. I've had multiple people now go to the source code and understand it's really simple fundamentals as a compiler. Yes, compilers are complex, but they're not as complex as a runtime, essentially, operating system, which React is. I really appreciate it. I've done tons of React that is doing that. It's doing awesome things with React's expense because of that, and it's innovating on truly new stuff that is genuinely great for Facebook's needs, but you are not Facebook. Brian: No, I'm not. Swyx: Most people are not Facebook, and they should think about their needs compared to the frameworks that are on offer out there. So what I'm really saying is there's a credible framework that is better suited, probably better suited to your needs. It has a different set of priorities like having styling. What really sold me out of choice was that Rich Harris was giving a talk, and I was in the audience. He was like, "It seems to me like if you have a frontend framework, styling should be a first class citizen." I was like, "Shit, you're right." "Animation is like you should try the default of CSS if you can because CSS has a perfectly good animation." I was like, "Yeah, you're right." Swyx: You can't just ignore this for too long before you're like, "Okay. I'll try this out," and then you can see how responsible... The responsible thing to do is try to ship the features that you want with the minimum amount of JavaScript, and I think that both React and Svelte tackled it in different ways. So React says, "All right. We'll take the React runtime as a base." So that's 100 and 220 kilobytes of raw runtime that you have to download every single time you visit a React site, but let's try to do the most that we can with that single runtime. Whereas Svelte says, "I put all my stuff in the compiler code base, and you pick out from that what you need." Swyx: Most of the time, when I rewrote my own site, I think I... Well, my guess. At least I was 140, 150 kilobytes, and that went down to 9 kilobytes when I ported everything to Svelte, and you just realize how much you don't use of React. Can you list all the features of React? A lot of people cannot, but when you do, you actually realize that you don't use most of it, and the features that it lacks are the things that you actually need. So it's such a weird like red pill moment of like, "Oh, actually..." The main reason why a lot of people use React is just because it seems to... most popular favorite right now, and that's fine. Perfectly valid safe choice, but when you start talking about technology in the terms... and this is what Kent C Dodds has been saying, "You never get fired for choosing React." That's a bit of an uninspiring way. It's like saying like React is IBM now. Brian: I was just going to say that's like the old IBM. Yeah. Okay. So final question because you did say... Earlier, you were like -- and I know I already said final question, so if you're listening you're like will you shut up and get to Svelte Society. Yes, I will. We're not going anywhere. So we're talking about the source code between React and Svelte. I don't remember exactly what you said, but the gist was perhaps React is more complex versus looking at the Svelte source code. Do you think that's a function of how either framework is created or just one has been around longer and therefore has had many opportunities to be manipulated, or added, or whatever? Swyx: You're saying because React is older, it just has naturally a bigger source code? Brian: Yeah. Is it possible for Svelte to be like React in terms of complexity in whenever, 5 or 10 years? Could that be? Swyx: I mean, never say never. But fundamentally, because Svelte rejects the idea of a virtual DOM, there's just less between it and the ultimate layer that you are running, which is the JavaScript on the browser, and whereas React is fundamentally... with React Fiber, has a significant amount of tooling that it needs to support that. So I will also say that React has gone through its own complete rewrite, right, with React Fiber. As of React 15, they basically threw away their old code base. So there's a lot of baggage that comes with supporting as large of a user base as Facebook does. Swyx: That's fine. I think... Yeah. It's possible for Svelte to get there, but I definitely say that the people involved will probably fight it very hard. Again, it's very much about the culture, right? This is something I talked about in maybe the last episode or in my book, which is that when you choose open-source projects, nominally, you're choosing the technology as it is today. Look at the docs, look at the features, and make a decision yourself. You want to get in bed, and you get like business married to technologies. You're really choosing the culture. You're really choosing the values of the company. Swyx: Brian Cantrill from the... I think he's at Oxide Computer Company now, but he used to be a major, major, no-JS Unix ecosystem speaker. He's a fantastic speaker. You should have him on at some point. He had this talk about the importance of values in open-source. It's like, "Ah, this is waffly like human stuff," but it really matters when people make decisions that you don't agree with them because over time, the project will diverge in ways which you really don't like. So you really have to evaluate the values of the community that you're opting into. Swyx: I will say that the values of Svelte is always for simpler code, and simpler code bases, and fast development, and all that, whereas React... I'll speak the React point of view. Dan Abramov is a very good friend of mine, and he says that as long as they present to you a small API surface area, React has to... It's maybe doing the right thing by absorbing all the complexity into one dependency that's professionally managed by a well-funded team and tested at scale by 2 billion users at Facebook before it's ever released to you. That's always true. It's just that you may not need all of it. Brian: Yeah. Do you think Rich Harris should come on this podcast? Swyx: Yeah. Sure. Yeah. Absolutely. He's a fantastic speaker. I mean, I'm definitely downstream of him in terms of a lot of my ideas. I was friends with him. I am friends with him, and basically ignored him for a year, and basically saw him give two talks and converted on the spot. I think he's a very convincing and interesting speaker himself. Brian: Me too. Rich, come on. We need to send him an email, and I suspect he gets more than a single email. So nothing personal, but I'm just lobbying. All right. So let's move to Svelte Society. What is that? Swyx: Yes. Brian: What is it? Go. Swyx: My perception of Svelte when I joined was that it was a mature-enough framework, and simply not enough people had heard about it, or there was not enough focus on the community aspect. So there's a concept in technology adoption called the Rogers Curve, which is the adoption... or the other familiar framing of this is Crossing the Chasm. When a technology goes from early adopters into some kind of early and late majority, and finally, there's the laggards. Svelte as... Brian: We should cite Clayton Christensen. Swyx: Yes. Brian: You can read the book. Swyx: Yeah. Brian: It's been around. Swyx: Well, he's not the only one. The reason I call it Rogers Curve is to bring attention to Rogers, who was the first guy to actually publish the curve that... thinking about with the bell curve. Crossing the Chasm was the one where they actually identified a difference between stages two and three or that bell curve where it says the reason the early adopters adopt a technology, they don't look for like, "Okay. What well-known company has adopted this thing?" They don't look for like... They maybe don't even care about docs. they just care about, "Does the technology do the thing that I've been missing from everything else that I've tried?" and they're happy to work on it nights and weekends. They're happy to work on it as... in hobby projects, and they're willing to bet on new things. Swyx: Not everyone is like that nor should everyone be, but I definitely saw Svelte in that early adopter phase of like, "Okay. There's not a single conference dedicated to this thing, and there's no meet-ups dedicated to this thing." I saw that technology-wise, it was ready, and I was... I had some experience. I think we talked about this last time. I helped to build the React Reddit community from 30,000 to 220,000 people, and I was like, "Okay. I've seen that phase of like a mature project, and it's easy to sing the praises of things that are already doing well. What would it take to start a community from zero?" Swyx: So that's when I got interested in it. Quite honestly, the motivating factor for me was really that I was in New York City with Rich Harris, and there was going to be the world's first very first Svelte meet-up that was going to happen in London. I was like, "Shit, we're in New York City, and the creative framework is here, but there's no meet-up for this thing," and we got to be in London. So I just randomly announced one day. I was like, "Hey, everyone. We're holding a Svelte meet-up a week from now. I don't have a venue. I don't have speakers. I don't have an attendee list, but let's do this." We named it Svelte Society. We got a venue from Microsoft, and 50 people showed up. That was the start. It's my experiment, really, of seeing like how far I can start from zero, and then we just crossed 10,000 members last week. Brian: How long did that take? Swyx: Two years. Brian: Two. Okay. Swyx: 1.7, 1.6 years. Brian: I'll give it to you. Yeah. Swyx: Three conferences. A bunch of small meet-ups. Svelte Society is around the world from Brazil to France to India. It's pretty interesting starting a community from scratch, and I definitely do not take credit for all of it. I definitely named it. I named Svelte Summit. That's my role, it seems, in this community. We have a podcast as well, a YouTube channel, newsletter. It's all of the paraphernalia around the community, and I think this is something I learned from observing React itself, right? When React started, they definitely focused on going to community a lot. Swyx: I think that Svelte is in that phase right now. So this is I guess my opportunity to test out my theories, test out what I can do with this thing, and so we're the de facto global community for Svelte. There is no one Svelte community though. There's no one central authority, which I think is a healthy thing whenever it comes to framework communities because there's going to be some people who are toxic. There's going to be things that you can't control, and I don't want the whole... my framework to be blamed when someone just goes rouge or whatever. So I called it a loose federation rather than centrally commands or centrally organized. No one reports to anyone. Everyone volunteers... It's one of those loose communities, but I do think that it's important to have a community so that people can go for support, to hire each other, to develop libraries and share them. Those kinds of things make sense to me as the natural next step in the evolution of Svelte. Swyx: The last thing I'll point you to is... I was very influenced by this other talk by Cheng Lou, also from the React core team, and then he went to Reason, and then he recently left Facebook called Taming the Meta Language. He was actually arguing for less meta language. So there's the language, which is the framework itself, and then the middle language is just everything around the framework, which tends to be like... So there's the code, and there's the documentation for the code, and then there's tests for the code. There's tutorials. There's conferences. There's meet-ups and all the crafts that builds up around it. So he was really arguing for less meta language, right? As long as the code and the docs are well-explained and well-documented, then you don't need a whole host of people teaching you React. So I'm not sure that exactly worked out for React. Brian: Sure. Swyx: I do think that it's important to develop the meta language. At some point, the technology stops developing as a core technology because then you basically just need to fix bugs and make it stable. Then, you need to start growing the meta language around it, and that's essentially what Svelte Society is because that was the thing that I perceived was lacking. Brian: What do you think the most important, and this is... It might even be specifically about Svelte Society, though I expect it would manifest that way. If you're starting a community or at least a framework community, given that you spent some time... I say some time working with React and certainly the subreddit. What are the most important... What should you focus on? What's the first thing? Is it support? Is it hiring? What's job one? Swyx: Interesting. I think events are a surprisingly underrated tool in the community builder's toolkit. If you're serious about building any community at all, you need to get good at events. It can be as simple as a meet-up, as big as a conference, or anything in between from just... Podcasts are also events. Launches of libraries are events. Releases of YouTube videos are events, and doing the marketing before that and after that, and actually concentrating people's attention around a certain flash point where there's a before and there's a after. Do enough of that, and people see the momentum, and they can talk about it amongst themselves with each other. Swyx: I think that's the start of something at least. I would generally tend to say that content is the minimal viable community because at the start, you're just putting stuff out there and nobody gives you feedback. But eventually, someone does. You do enough of it, and then people start to gather around you. I think that's definitely a path that I followed in the communities that I manage because I don't just do this one. I run a community for my book as well as the Finance Discord, and then for my blog as well. Okay. So, yeah. So events are underrated, but also, I think hooking into the fact that like giving people a role to play. People want jobs. Brian: Yeah. Swyx: It's weird. Brian: It's weird. Swyx: If you're just generally like, "Hey, just come help out," people don't really know what to do. But if you assign roles, I think it's a better proposition. I don't necessarily think we've done a perfect job at this, but I definitely... I don't necessarily think we've done a perfect job at this, but we're definitely growing into it. So we have a new set of person. We have a panel of people who come together for our bi-annual conferences. We have our podcast people. I'm the YouTube person. I'm the Twitter person. Everyone has roles that they play, and I think we... Having that limits you, but also sets the expectation of like, "Okay. When this thing comes along, it needs to be handled." We know who to go to, and yeah, having roles gives that. Swyx: I'll say one thing for me. I knew, I could see that Svelte was ready. So plugging into something that is ready... Basically, don't try to force a community where it's not ready to happen because you're just going to have a terrible time. So some amount of timing matters as well, and I definitely work a lot on my timing professionally as well as, essentially, what this is. This is a hobby for me. So far, it's done great, but it's... I think everyone is on a volunteer basis on some level. Brian: So when you were talking about the first meet-up for Svelte, I noticed that the location mattered, like it was... You're talking about a physical event. 50 people showed up. Is there a meaningful difference between physical and virtual meet-ups, especially given the last, whatever, 15, 16 months? Swyx: It's meaningful, but I'm not sure that it's... We'll still do them. Brian: Yeah. Swyx: People really like in-person connection, and for Svelte, in Svelte Society in New York, we met once a month until the pandemic hit, and then we stopped. When it's remote, people are always distracted because everyone is multi-tasking and you can't really see each other as much. So it's very much focused on a topic, and then you leave. You don't get to talk about just how your day went or just random other stuff that... That's chance with serendipity, all the problems that people are talking about with remote work. Swyx: It is true that people have Zoom fatigue, and screen fatigue, and what have you, so it is a challenge. I'm not really sure how we can fix that, but I think we just have to adapt. I think a lot of people, when we did the offline-to-online transition, we just ported the exact same format over like when we organize conferences. We actually did an eight-hour conference online. It was a terrible idea. No one is going to sit around and watch a video online for eight hours. So then, you adapt, and you understand like a native remote online-first world and try to adjust to that. But I think we're all ready for in-person events to come back. I'm looking to start one here in Seattle partially because I like the alliteration. So Svelte Society Seattle would be the name of it. Stockholm and London I think are going to start back up again. Yeah. I mean, there's online, and there's offline, and there's room for both. Brian: The question that I think about a lot is when you're starting a community, you said just now like you've got to give somebody something. You better give them a reason, and the example you used was jobs, and then content is sort of... I agree with you that it is the minimum viable community. Then, I think about like, "What else that wouldn't trite?" It's important to give people roles, but that's on the community management side. I've seen, on the other side, people who are actually members of the community. You give them stuff to do. You give them challenges or you could give them titles like ambassador or some kind of like... Swyx: Yeah. Brian: I don't know if that's just me being jaded and being like, "Well, I'm not really an ambassador. I'm just somebody who logs into this website because I like this technology and I talk about it occasionally." Maybe that's the definition. I don't know. So it's an open-ended meandering. What do you give a community to sustain it beyond facilitating communication? Swyx: Partially, I think jobs really matter, and instead of roles, I'm really talking about jobs. Getting people hired tends to make people loyal to you. Brian: Sure. Yeah. I know how it sounds. Swyx: So it definitely helped to facilitate the jobs conversation and highlight the visibility of people's work, which I think like people do a lot for recognition and just having a central schelling point. A schelling point is where people go to unspoken without coordination, like people just go to a central place, and definitely, the Svelte Society Twitter is the schelling point for Svelte community apart from the Discord. Having those schelling points helped people to gather and get their work recognized, which a lot of times is all they want. Swyx: For me, as a community manager, understanding what each individual player is motivated by and giving them what they need or connecting them with the right people at the appropriate moments, I think it's a big part of it. Ultimately, as a community manager, you want people to start forming connections without you. This is a concept that Alex Hillman from 30x500 calls tumbling or tumbler, which is from some kind of Jewish tradition where... A lot of times, when you start a community, you're pushing the rock up, up the hill, and you're trying to start conversations. It starts, and then you back off, and then the rock falls back down with you, and you have to restart it again. Swyx: Tumbler is really focused on kickstarting conversations and then letting it continue without you. I think it has definitely an aspirational goal. Not everyone is there, but definitely, a successful community... There's two things I focus on in a successful community, people talking amongst each other without needing you to be around, and then people expecting their relationship with the community to outlast any present employment. So their identity is stronger with you than it is with their current job, and that's true for all technology, including the one that I currently work on. Yeah. I mean, I think Svelte is somewhat there. We definitely hang on and talk non-Svelte stuff, and I think it's great because ultimately, Svelte is a perspective on the web and where the web should go. The kind of people who are drawn to Svelte are not the same kind of people that are drawn to React, and I really have been enjoying the qualitative difference. Brian: Well, that's a paradox because you were drawn to React, and now you're drawn to Svelte. Swyx: Mm-hmm (affirmative). Brian: Busted. Swyx: I mean, it's possible to have two loves, right? So when I wrote that Svelte for Sites, React for Apps thing, I actually did the most balanced take I could possibly do, which is that Svelte has all the tooling that you're going to need for interactive sites. It has some really good stuff for apps. But ultimately, if you want some of the paraphernalia that has developed over the last 10 years for apps, you probably want to go to React. Yeah, and that's just jarringly true. Brian: I'm going to start saying paraphernalia more because I noticed... I've heard you say it a couple of times. I really like it. I'm not being sarcastic either. I do. Community paraphernalia. I'm going to start doing it. I encourage listeners to do the same. So you know how it works, plugs and stuff. We didn't get a chance to talk about Temporal at all. We didn't... Swyx: It's cool. We promised last time that I would come back and talk about something more technical. We spent a bunch of time talking about community. Hopefully, people get their technical fix on Svelte, what it is, what it presents as an alternative framework, and these people can check that out. Brian: Yeah. I mean, if you have technical questions that were not answered here, you can tweet Swyx, and he will answer them all. Every single one. Swyx: Yeah. We're also Svelte Society on Twitter. We're Svelte on... We're on Discord and YouTube as well. So you can follow up on our conference there and join our Discord. For those interested backend orchestration technology, check out Temporal.io, which is the company that I work at right now. We can have a whole different conversation on that, but it's more backend-focused. So I don't know how much you are willing to take things in terms of front-end or backend, but I think it's super interesting. It's part of my own migration towards the backend. Brian: I mean, my opinion, especially the longer that I'm here is that that's... The spectrum is fuzzy. It's obviously very different, but sometimes I... especially when fielding pitches from authors, right? You're like, "Oh, well, now I understand why. I guess you want to talk about this front-end part, but it also has to have this backend part, which is not something that, again, I invented, but I'm just starting to understand it." Last thing. What's the name of the podcast that... because I think people who were on a podcast, they're probably like, "I want to listen to other podcasts." We'll put them all in the description and stuff, but yeah. Swyx: Exactly. Svelte Radio. It's basically one of these co-host things. So there's a panel of me, Antony, and Kev, who are the organizers of Svelte New York, London, and Stockholm respectively. Then, sometimes we just talk about Svelte news, and sometimes we interview major figures in Svelte and just to give them the spotlight and talk about their projects. So yeah. It's been going on for over a year now, and we're starting to actually put in some effort into editing, and intros, and transcripts, and even having a picture on with videos and stuff like that. So it's an interesting project. It's led by Kev. So I'm just a panelist. But if you want more of this stuff, come join us. Brian: Nice. Yeah. We'll for sure put that. Go listen after you're done... Swyx: Svelteradio.com Brian: Listen to PodRocket. Then, go listen to Svelte Radio, and spend your technology time accordingly. All right. We're done. Thanks a lot for coming back. I had a nice time. Swyx: Thanks for having me. Always a pleasure. Brian: Hi. Thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try, then it costs money, but yeah. We'll see you next time. Thanks.