Svelte Radio
Svelte Radio
Ben McCann on Sapper and SvelteKit
Ben McCann joins us to talk about the next version of Sapper as well as SvelteKit. We touch on migration from Sapper to SvelteKit, what's going to happen with Sapper as well as some good news for developers using Webpack.
Notes:
Unpopular Opinions:
- Code comments stink!
- Tailwind is hard to read
- Static site generators are becoming obsolete
Picks:
Transcript:
Kevin Åberg Kultalahti 0:00
Hello, everyone. Welcome to another episode of Svelte radio. Today we have another guest for you all, but first introductions. I'm Kevin, I run Svelte radio and Svelte school, and I'm involved in the Svelte community in general.
Shawn 0:18
I'm Shawn, same here, I guess. I don't read anything. But I guess I've been working on recently the Svelte actions package, trying to have a good set of defaults for Svelte to export. So it inspires people to use actions more. That's me.
Antony 0:34
I'm Anthony. I'm a CTO of biank also stopped maintainer along with our guests today, which is Ben McCann, who is also Svelte maintainer, a very, very recent one, in fact, not not recently. It's been a while now. So Ben has come in on the back of a huge amount of prs. And he produces them so fast. And he's really pushed the development of stealth itself, but also sapper significantly forward. And yeah, what else? What else is this? There's a lot to Ben. He's extremely polite, nice. And I really, really like that. It's quite refreshing to find the person. And oh, I have to Ben.
Ben McCann 1:13
Yeah. It's great to be here with you all today. Thanks for for having me on the show. So how I get so much done, I don't have a day job right now. So that gives me a little more time. I started a start up a few years ago. And so I'm an entrepreneur, and I'm in between companies right now trying to figure out my next one. And, you know, I picked up Svelte to kind of refresh my tech skills and our startup, we were using Angular and don't want to do that again. So it's trying to figure out what's new in the landscape, and hadn't been coding for a number of years as a more of a management role. So I just want to kind of get caught up on two things, and really enjoyed been using Svelte these past few months,
Shawn 2:02
I was just just curious how you first heard about it, because you know, it might someone in your position, you might just go for react as sort of the the most popular framework of the day.
Ben McCann 2:13
Yeah. So I mean, one of the ideas that I was experimenting with was for a content based site where I thought that this speed was going to be really important, and performance was going to be really important. And so I really liked that with Svelte, you didn't have to download a runtime, like you do with react. And so, you know, the initial page loads were a lot faster. So that's kind of how I got involved. And then, you know, with snapper, there were a lot of other really nice performance improvements. And those were some of the the first things I started working on when I got involved in sapper. So, you know, one of the things that we did was we added preload headers. So when you first visit a page will fetch all the assets that you need for that page. So instead of having to wait for if one script depends on another script, instead of having to wait for the first script to run and fetch that second script, the page will automatically fetch both of those at the beginning. And so we we kind of crawl your dependency tree and make sure that those are all fetched at the beginning. And then, you know, it's also got CSS code splitting, which is something that, you know, had a few bugs in the past recent releases getting that all worked out. But I think that's really gotten to a very nice place now, where we have, you know, it's always had JavaScript code splitting. And now the CSS is really, I think, a lot easier to manage as well. And so with all that code splitting, you know, it's a really nice performance benefit of using sapper.
Antony 4:00
So what the one thing I want to ask him, as I mentioned, the intro, intro that you you were intrapreneur. But also, I believe, and I could be wrong here. But I think you're also a VC of sorts. Is that right?
Ben McCann 4:10
Yeah, I've been doing a bunch of investing as an angel investor. And so I've invested in probably about two dozen companies at this point.
Antony 4:20
Wow. Very cool.
Ben McCann 4:22
As far as I know, none of them use Svelte but I'll spread.
Kevin Åberg Kultalahti 4:27
I gotta push, you gotta push for for Svelte.
Antony 4:31
Cool. Any, any, any successes? Yeah. Those that Funchal,
Ben McCann 4:35
um, we actually pretty. One of the first companies we invested in pretty interesting company, they're doing water propelled propulsion in space. And they just announced that they're IPL ng, so they announced that late last year and that should happen sometime q1 we think
Antony 4:57
very cool.
Kevin Åberg Kultalahti 4:58
Wow. I wonder how that works. Yeah, that's it. Yeah, that seems crazy. It's,
Ben McCann 5:04
it's got a nice a lot of nice benefits, like a lot of the chemicals that are used for propulsion, traditionally are very toxic. And so that's not not probably not the main benefit of doing this, but it's a nice side benefit. So the idea is basically that, you know, if you're going to launch a satellite into orbit or something on SpaceX, they kind of drop you into a number of like default orbits. But then if you want to get to your own custom orbit fill, fill act is like a shuttle to get you to your final destination.
Kevin Åberg Kultalahti 5:42
That's cool. All right, so sapper. Is that point? 28. Right now, is that that's not the last version. Right?
Ben McCann 5:50
So we've got one more, at least in the works. Zero Point 29 is coming up soon. And, you know, obviously, there's there's been a lot of talk about Svelte kit. And so that's where a lot of the development focuses right now. But in the meantime, there's still a lot of prs that we've been getting for smaller issues in sapper that we wanted to try to get in and get another release out. So I think, you know, probably the biggest highlight is for all our TypeScript users. we've, we've gotten, I think, probably like four or five changes in two separate 29 for TypeScript definition improvements, which will be a really nice quality of life improvement for our TypeScript users. TypeScript supports pretty new within Svelte in general. And so there's there's a lot of other places in the Svelte ecosystem where we've been making a lot of TypeScript improvements as well. But But sapper is definitely one of them. And then, you know, I think the other place in in sapper zero point 29, where we've seen a lot of improvements are in the router. So a lot of fairly minor bug fixes. But But things that that are just kind of nice usability improvements. There's been a couple scroll tracking bug fixes that we've gotten. And actually, you know, seeing those come in, kind of was a motivation. We ended up rewriting the entire scroll tracking in Svelte kit. And so, oh, wow, those bugs are not in Svelte kit. But more importantly, there's there's a couple edge cases that sapper still has, if you like navigate off the site and come back, the scroll might not be exactly where you'd expect it. It works pretty well, in sapper today, but but in Svelte kit, I think we've taken care of all the different edge cases, though, that we knew about.
Shawn 8:05
So, so I'm gonna, I'm going to be the voice of the people who are less in the weeds. And since we have with, you know, with two people deeply involved in this critical week, we have a high level, what is the difference between separate socket? Like just, you know, like a recap, because I think it's helpful for listeners.
Ben McCann 8:24
So I think the biggest difference and you know, feel free to jump in here, Anthony, to with your thoughts. But I think, you know, the, the biggest change in my mind is the developer experience, you know, Svelte kit is built on top of snow pack and ESBuild and so you're gonna see compile times be a lot faster. And that's something that's a problem in larger separate projects. You don't notice it necessarily when you start out as a new user with Sapper. But when you start to grow your projects, some of the compile times with separate can get to be a bit longer. Our hope is to fix all of those issues and make it a really, really smooth experience with Svelte kit.
Antony 9:11
Yeah, I think I think I agree with that entirely. That that's probably the biggest benefit. And it's definitely the one that I'm looking forward to the most, which is so so for sort of context here, we have some pretty big sapper applications. And a 1.1 of them was taken two minutes to build when you're first booted. It just runs the dev environment, which is obviously really bad for local Dev. We low times work 20 seconds or so which also kind of sucks. And I did actually nail that down recently, very recently to I was using Svelte feather icons, which is it is a tree shakable library of icons, and but there's probably like 400 icons in there. Svelte will still compile every single icon every time you use that whole library. So if you've got like other libraries that use it as well or other modules, it's going to come pile all up all the icons few things a couple of milliseconds, but it builds up. And I basically took that library. And I did, I did deep imports as rich Harris. And in fact, the author suggested, I also then made my own little cut down version of that library. And it took it took my build time down to six, a sixth of its original build time. So it's now 20 seconds to start. And it's a big application. So that dev experience that alone has made my whole life a lot easier. Svelte kit, it should be like microseconds, right should be so tiny to get the application up and running. We already seen him in salt kit and snowpack itself, changes you make reload the instant are always you know, you always don't think it's happened because it's so quick. So absolutely 100% that is the biggest benefit. I think the second benefit, which is also the place where kit came from stock it came from other is. So when you build an application sapper, everything is kind of treated the same way, you're building a dynamic application, you can export it as a static site. But you've got these two options. And it's kind of one or the other, right, there's no middle ground. The idea with kids is that it will build the application in a more optimal way. So you'll break up bits that keep well for you break up bits that are static and make them as static as possible, it will take bits of dynamic amount of dynamic as possible. And it will take up bits that sort of in the middle and do the most optimal thing. So you'll end up with application that sets itself up in the most optimal way for your what your application is, we should should make it really, really nice to host and also cheaper to host and also more efficient to run. And I think on top of that, then I suppose the other benefit to kit is the modularity, which we're trying to break into into modules where a sapper is kind of an all in one. And then the final thing as far as the adaptive. So the idea being it's, it's serverless first, but not restricted to serverless. So you can host it any way you like. But it's designed so that you can host it on the serverless platform, which is probably the ideal hosting environment for this very, very easily. The adapter defines your entire deployment layout. So there's a multitude of adapters and you can basically just pick your adapter, run the run the keyword is currently adapt, and it will convert your application into something that's suitable for you want to host it. And I think those are probably the top the top five benefits as to how close you are to the project right now. We're obviously all close. But rich is the one who's currently using it production. And it's very much of course, his project. And so I think that when it when it comes to pizza, which will hopefully be soon then there'll be some really interesting things that probably we didn't even even have that yet.
Kevin Åberg Kultalahti 12:40
Now I've been I've been using socket today actually to to build the new Svelte radio website. And it's it's been great. Except for for like the the issue of no documentation. But I mean, that's expected, right? Yeah, it took me it took me a while to figure out that fetch was actually something that came with a load function, rather than using like a this.fetch thing.
Antony 13:08
So I would say currently it is I think this that's one of the things that sort of, what do you do with fetch and load? how's it gonna work? This is one of those discussions that kind of goes round around a lot. I know Ben's been involved in discussion, actually.
Ben McCann 13:18
Yeah, hopefully, we'll have some documentation coming soon. I actually have drafted a set of documentation, just based off the sapper docs and then updating it, and I'm sure I, I missed some stuff. So we'll need the community to give it a look. And find all the changes that I missed. But so I've sent that out to the other maintainers. And for review, and hopefully, you know, I don't know if we're ready to publish it yet. But at least we're working on docs internally.
Kevin Åberg Kultalahti 13:47
Yeah. That's great.
Shawn 13:49
It might be an interesting step to publish the docs without publishing the code. It just to get like feedback before you actually, you know, 1.0 the code. Yeah. might be an interesting. Yeah, we're
Ben McCann 14:00
definitely I think, gonna need some some feedback on the docs. I think, you know, there's hope there hopefully, pretty close. But there's, there's enough of them that I'm sure there are things here and there that we've probably missed.
Antony 14:15
So yeah, I mean, so, so interesting, the interesting approach that that will be like a blackbox approach where you've got the product and you've got the documentation, but you've got no access to the source. So you only have the documentation to look at to figure out how things work. That's actually an interesting technique. I don't know whether it would be really frustrating or just, you know, would be a really good exercise. But yeah, I guess, I guess, if you don't have the source code available, you have to rely on the docs. And that's that could work. No,
Kevin Åberg Kultalahti 14:43
I mean, it should for that should force the docs to be really good, though. Right?
Antony 14:48
Well, yeah, absolutely. Absolutely. They have to be, sir. We could discuss it maybe when our next maintainers meeting is but we can we can bring it up maybe.
Ben McCann 14:59
Yeah, I think I One of the things I'm really most excited about with Svelte kit as a maintainer, which probably doesn't, doesn't sound exciting as a user is that we've now got a configuration file, which is like I kind of a, obviously, basic feature. But, you know, we had a lot of different prs in sapper, that that are in the queue that depended on adding some new configuration option. And we really wanted to find a way to do this holistically, like a lot of these different PR suggested different ways of configuring your project, or whatever new option they were adding. And so we didn't want to have, you know, half a dozen different ways of enabling any new feature. And so now we've kind of got one standard way of doing that with Svelte kit. And I think that'll block a lot of development efforts, where, you know, we we wanted to come up with a holistic way of doing it before merging all these prs. And so, hopefully, a lot of the prs that are in the sapper queue, we can revisit with Svelte kit and, and get those in.
Antony 16:10
And I think I think in terms of curation and the original, the Holy Grail for rich is no configuration at all right? But I think he's realised now, that's probably not a possible thing, because there is, people have different use cases. And the project is quite widely used now. And I think that one of the fallout we saw from not having a config file is that every other project that uses Svelte has a config file. And they all use different formats and these different ways of doing things and different namings, different variables. So we've created the Svelte kit config file, and almost defined the format of what Svelte config would look like. And it's natural to do that, I guess. But what it means is that you'll see a few of the projects around snow pack being one of them. Were there config file format for Svelte actually changed based on the ideas from Svelte kit. So, hopefully, yeah, we'll have reached this kind of we've kind of converged on this final config. layout as much as possible, at least anyway.
Shawn 17:04
It's very cool. This question actually makes me ask another dumb question, which is Svelte kit seems spiritually much closer to Svelte than Sapper was, like, separate seemed like a different project altogether, like it could have been run by a different maintainer is, is that, you know, the config files is named svelte.config.js, right? Something like that. I think I think, right, like it's not svelte kit dot config.js, like this is Svelte like we are we always, you know, essentially, is the meta framework, kind of just like just merging into the framework, the framework itself.
Ben McCann 17:41
I mean, I, I think that though, they'll always be separate code bases, and like, you should still be able to use Svelte without using Svelte kit. But, you know, for for folks that are getting started, we want to have kind of a blessed path that makes it easy to get up and running. If like, if you look at the Svelte FAQ today, there's like a question that says, you know, what routers should I use with Svelte? And there's like, half a dozen different recommendations in there. And it's, I think, hard as a beginner to know what the differences between all those routers and which one you should use, and in the future that that answer is going to be Svelte kit. And, you know, we want to make sure that there's kind of one way to do development that works really well that everybody's, you know, put their eyes on and made sure that we've made it a good experience. And so you'll still be able to do all the things you can do with Svelte today and still, build your own Svelte project without using Svelte kit. But, you know, for for folks who just want to get something running without having to, to put a lot of thought into having how to put all these building blocks together, we want to make that really easy.
Kevin Åberg Kultalahti 19:02
So So this, this makes me think of of like an sp a mode? I think that's been something that that's been missing in sapper for forever, I think. Right? So is that something that you could do with just one of those adapters and Svelte kit ?
Ben McCann 19:18
I don't know if it'd be an adapter or a new option, but it is something that that I expect will be coming we've, we've got a ticket internally to build that. So nice. And I actually had a PR to do that in sapper. And one of the things that got hung up on was, you know, how, how do we want to configure this and so I think that that questions, but I'm blocked now and hopefully that's a feature that you'll see coming.
Antony 19:44
I think one of the one of the problems with sapper was that people really didn't know how it related to Svelte at all. Like Sean says, it's almost like a different maintainer. It's, it's a different project. And so I think one of the ideas was Svelte kit is That we bring together. It's a kitten round Svelte rather than an application framework that happens to you. So if that makes sense. So it's a series of tooling that allows you to take Svelte from a UI framework or UI language or UI library, whatever you want to call it into something you can build a full app with. Separate was separate app builder. But it wasn't always clear that that's what it was for. And yeah, like Ben said about routing and stuff. It was confusing. It's got its own router. Can I use it with externally? No, you can't because it's so cool to SAP because it does. SSRS pa and if you baked into the product, so yeah, so Svelte capable. The idea being it's like an extension of Svelte It's a superset of Svelte It's a thing that sits around Svelte. Now the caveat to this, of course, is that there is still a notion of a Svelte kit thing, so you have like attributes prefix with Svelte kit, things like Sapper noscroll translate directly to Svelte kit, noscroll. I can't recall that actually, Ben. But the notable attribute is prefixed with the kit, no tap notion because it's specific to to kit and it means nothing outside of that.
Kevin Åberg Kultalahti 21:12
I've actually been looking at the changelog. There's not much in there in the in the small kit one, but it's fun to see when when new new versions go out.
Antony 21:25
The Svelte kit changelog, yeah, is that
Kevin Åberg Kultalahti 21:29
it's in the it is yeah, you can find it on. I
Ben McCann 21:36
actually didn't know there was a change log. I've never seen
Kevin Åberg Kultalahti 21:41
nothing in it.
Ben McCann 21:41
Yeah, it might not be updated.
Kevin Åberg Kultalahti 21:46
Well, I mean, it seems to be updated. I should find it like,
Antony 21:51
we're on like version zero point next 37 or something right now, I think and it doesn't get released that often. So it's I mean, it's it gets it gets a new master branch every like, I don't know.
Kevin Åberg Kultalahti 22:04
Yes. So let's see the latest. latest patch notes are prevent infinite loop when fetching bad URLs inside error responses. And handle assets path when pre rendering.
Antony 22:20
These are quite recent. I think. This is like a leak. I think
Unknown Speaker 22:29
PMP.
Ben McCann 22:32
is, is it's set up with changesets, and it's probably auto generating the change log based
Kevin Åberg Kultalahti 22:42
on unpkg anyway. It's fun to see. Oh, yeah. Even though it doesn't make much sense.
Antony 22:49
That makes sense. Yeah. The changelog is checked in. Yeah, fair enough.
Shawn 22:53
All right. I've got other a couple others have begun to read questions is the goal. So is the goal to one to one parody with sapper? Or do you think we'll have to lose anything? I know there'll be a migration path. But let's talk about, you know, what's the trade off? Like what are we? Are we not losing anything?
Ben McCann 23:15
Yeah, I think that's been one of the hard things with the development of sapper is we we do still get prs to sapper. And, you know, we've we've been trying to merge as many of those as we can, at the same time that there have been some that have proposed new features. And I think, like, we don't want to be in a situation where people adopt a new feature on sapper. And then it's not present Svelte kit. So, you know, trying to be really careful that any changes that we make and sapper, we're also making an Svelte kit. And they're, they share a lot of code, but they're also different code bases. And so some of those changes are easy to port, and some of them are not. And so, you know, it's been kind of a case by case basis to figure out like, which are ones that we can easily add to both versus like, which are things so we should just wait for small kit and add them there. Go Yeah, I
Antony 24:15
think I think Sapper is in a kind of like a maintenance mode, isn't it? It's it's in a mode where we still support it. We're still obviously interested in fixing bugs and things because people rely on it and it's time to migrate. But the idea being a migration path is so smooth that anything you can just go straight into kit. And we have that many features. That's That's the goal. Anyway,
Shawn 24:38
the thing the thing I've never been sure I've never used ESBuild. I've like looked at the docs, but I like you know, we're essentially switch switching. You know, the bundler from either roll up or whichever we call it Webpack to ESBuild. And like, Is that is that a smooth process like don't we lose stuff like You know, whenever I want to use something in my tool chain, like I know, I can either pick Webpack or roll up and it'll probably work, but not have when it comes to adopting iOS build I have no idea.
Ben McCann 25:12
Yeah. So the if you use sapper today, it's actually invoking your builder for you. And it's, it's tweaking the builder and hidden ways to which it so like sapper has its own internal plugins that I'm trying to remember exactly what they do now, but they, you know, I think a lot of this stuff around like, like they inject your CSS files into your JavaScript files, and they do code splitting on your CSS. And then they it pulls out information about your build in order to build the preload headers that are in sapper. And so we're we're in kind of this tricky middle ground right now where you can configure your build, but you don't have complete control over it and you're not executing it. And I think that, like there are parts of that, that hopefully are a little better structured in Svelte kit, you know, so like, one of the things that people have been asking for for a long time, is the ability to do basically what we've called adapters, and Svelte kit, where, like, we've built these adapters to allow you to host on all types of different environments. And so like, you know, we want to allow you to host on an environment that doesn't require node, for example, or like we want to allow you to export to static pages, or vercel or now are these different hosting platforms. And I think that was kind of tricky to do before. And so there with Svelte kit, there are still parts of the build tooling that are not directly managed by web Packer roll up because they're, they're managed by our bundling process. But now we have first class support for all of these different platforms.
Antony 27:14
I think, I think also when Ben talks about internal roll up plugins and internal web pack plugins inside inside sapper, and it's true what what you see in separate as a Webpack config or a rollup config, it looks a lot like a rollover, Webpack config, but it's not really what it is. It's a configuration file. That one has some separate stuff injected into the output so sapper tells it where to put its files. And but also the whole thing, exports things rather than actually run through roll up and exports things that sapper then augments, and then that gets pushed into roll up programmatically, right. So it's all kind of an illusion, really, with sapper, it's very, very heavily tied to the internals of how it works. I think it's the size one there's reasons for that. And with Svelte kit, it is yes build but actually one of the core concepts of snowpack, which is what what is build is running through snowpack defines a no locking strategy. So you're not locked into using the snowpack when you build a snowpack project. Therefore, you can remove snowpack and build it where else you want. There's no nothing specific there to snowpack. And that stays true for Svelte kit. Not that you can report snowpack necessarily, but because it's quite built in because there's a saw, but what you're getting there is you're getting as billed for your local dev environment, why should developing but when you pump the build out in the side, bundle from production, you're using just pure roll up and all Webpack whereas I think I think it's got broad support. Now I don't know if it'll have Webpack support, but it will have just pure output via roll up. And also as another kind of layer of indirection here, the esbuild Svelte, the esbl plugin uses the roll up Svelte plugin. So therefore you can actually adapt that because it's still compiling Svelte through rollup through your Svelte, right. So you're not really escaping from from bundlers in the most common sense, rollup is still there in order that you can pull things into you as build, and they get converted to JavaScript. And then the JavaScript is what is built is compiling. But that's all in depth. So when you come to produce a build for production, you're using roll I believe it's a plugin now and so your final production build is still a rollup build. He probably even more of a rollup build than Sapper uses right now.
Shawn 29:41
That's actually a really nice Yeah. Thank you that
Ben McCann 29:44
there were also I think in sapper some sometimes some confusion around like do I do things and roll up or Webpack or do I do them and Svelte pre process. So you know, if you want to use post CSS, for example, Like there are multiple ways of setting that up, and some work better than others. And so, you know, hopefully some of those stories we can make be a little bit clearer with Svelte kit. Yes, I think that's one of the things I'm most excited about in Svelte core is source maps for pre processors. So Svelte has had source map support from the beginning. But if you want it to use preprocessor, then you lost source map support. It was something that that just got implemented and one of the recent versions. And there's a number of kinks that we've been working out over the past few weeks. And so, you know, that's been entirely driven by the community. You know, there's a couple of folks, Mila, who and D massage that I'm terrible with the usernames, I've probably got this slightly off. But there's a lot of issues today where like, if you try to use TypeScript with Svelte, where the source map support just isn't great, because TypeScript support with Svelte is so new, I think that you'll see that get fixed in the next couple of releases. So there's going to be the next release of roll up plug in Svelte and the next release of Svelte will both have additional fixes. You know, that that supports getting to be fairly good today. But there are places where things are off by a line here and there, which makes it difficult to use. And so that's gotten really quite a bit better over the past weeks. And that's going to be really exciting for a lot of users.
Kevin Åberg Kultalahti 31:43
That sounds great.
Shawn 31:44
I actually had no idea I always saw it like in the pre process code. There actually is a way that you can, you know, modify the source map and send it back to Svelte. I had no idea that didn't work.
Ben McCann 31:58
Yeah, so there is and so, roll up plugins, Svelte executes the preprocessor and executes the Svelte compiler, and it needs to hand the source map from the preprocessor to the compiler. And that was like a one line change to make, but it just hadn't been implemented yet. Because it was really a pretty new feature. And so that was kind of like one of the final pieces that we need it. Like we built these features independently, and then we just needed to hook them up. And so that's going to be in the next release. Overall, a plugin Svelte 701 or seven, one our I don't know what the version number is going to be. But yeah, after seven.
Shawn 32:46
So so there's only only programmers debate what comes after seven.
Kevin Åberg Kultalahti 32:52
So this is like, there's a lot of overlap here. With the language tools. It sounds like are you working like closely with with Simon and whoever else is working on those?
Ben McCann 33:05
Um, yeah, I think that things for this particular feature, like they, it hasn't really overlapped with language tools a whole lot. But Simon's helped a lot with a lot of the TypeScript improvements. Like in Svelte core, he's been adding type definitions. And so I think when you combine these different features together, the the type definitions and the type definitions that are in sapper as well, and in the source map support, the TypeScript story is going to really start to be a first class story and become a much, much better experience.
Kevin Åberg Kultalahti 33:49
That's awesome. A lot of people want one TypeScript. From what I understand. Yeah. You know, Ron, man. Okay, so. So there's this Svelte loader loader thing was started Webpack thing.
Ben McCann 34:08
Yeah, so I think probably all the maintainers use roll up, which means that unfortunately, the Webpack plugin had gone unloved for a little while. But Webpack five recently came out and spurred a bunch of interest from the community and updating that. And so we've recently gotten a good chunk of prs into that project. And so the next version is going to support web pack five, it's gonna support node 14, and it's got a completely rewritten HMR implementation. There was kind of a HMR implementation in there from the Svelte two days that never worked with Svelte three. And so that was always kind of like the top issue. In that repo that the readme says there's HMR support, and there, there really wasn't. And so that that's going to be a really exciting release for web pack users, which I think is probably like, I don't know, maybe 30 or 40% of Svelte users. It's, you know, it's a sizable chunk. Yeah, I think it's gonna make life a lot better for a lot of people. And so, you know,
big shout out and thank you to all the folks from the community again, that was another thing that was entirely community driven. So non 25 and Smitty, VB and Greek so you know, got got a lot of those really drove that whole process. I know No, it's pretty funny cuz like,
Shawn 35:49
funny cuz that's, those are their discord chat names as well. So yeah, those are their names as far as I'm concerned.
Antony 35:56
Sometimes they get names as well. Yeah, that's
Shawn 36:00
right. sweatsuits. Six, yeah, yeah. Consistency is good.
Kevin Åberg Kultalahti 36:06
Yeah. Right. So So we have some some questions from the from the community. We, we asked for, so we have one here. Should should people with separate apps panic? Should they panic a lot? Or just a little? I don't know.
Ben McCann 36:25
Yeah, I mean, the there's gonna be a fairly easy migration path. We've already like migrated the example apps, though, externally, those those are still on sapper. But within the Svelte kit, repo, those have all been migrated to Svelte kit. And like that was a fairly straightforward process. We need to put together a migration guide still, but that's something that we'll do. And actually the real world sample app rich basically completely rewrote, because it was never really written in no way that sapper apps should be rewritten, should be written so that that one was a bit of a larger change, just because there was a whole bunch of other improvements that they got made there. But like, if you look at the Hacker News sample app, that was pretty straightforward to port that was a pretty small set of changes. And so the there's so much of the Svelte code, like all the the client side Svelte code, especially, is is basically the separate code. And so like the code that's going to be in your project hasn't really changed. Most of the changes and Svelte kit are all like, they're in the development server, and they're there on the server side and and sappers are Svelte kits internals. And so you know, it's, it's the things that users don't really touch in their projects that are changing the most.
Kevin Åberg Kultalahti 37:55
Cool, sounds good. No question is so from from our user? How can they help out pretty much help the core team? develop these things?
Ben McCann 38:13
Yeah, I think that what Svelte needs more than anything, is people getting involved in helping us review issues and prs. There's just a lot of them, and it's really hard to keep up with them all. You know, and we, it's kind of a catch 22 like, we want to encourage more people to, to get involved so that we have more help with those things. But, you know, it's it's so hard, keeping up with them all to really get people involved with with the projects submitting prs. And, and so I think it's really, the review of those things. That's actually how I ended up becoming a maintainer was, I kind of noticed that their sapper PR queue had grown quite a bit. And I just went through and started leaving comments on all of them unprompted. I wasn't quite sure how that was gonna be received. But luckily, it was received well, a lot of those prs have, like since been been checked in and there's still a lot more I know, that that we need to get get to and get in sort of trying to make it through that backlog. I think another thing is, we recently put up an open collective. And so thanks to everybody that's contributed to that, you know, I don't know that we've had a lot of communication about how our, we're going to use those funds. But I think one of the things that we're most interested in is bringing on somebody to help with triage of some of those things. And that might not happen immediately. But, you know, as we grow a bit of a balance, that's one of the areas that we're going to be looking at is that is probably that and ways that we can accelerate self development. Makes sense,
Antony 40:00
I think, yeah, in terms of reviewing prs. Like, that's also a similar way to how I got in was reviewing, reviewing issues and sort of, you know, figuring out if there are real issues or not issues or whatever else. I think that reviewing prs is super useful, giving the code a try. And the hub project by GitHub makes it really, really easy to actually just test this out. You check out Svelte use hub to change the PR, and then you just basically run your, your test project against against the PR, so it is quite easy to get set up. And then it's just figure out if it works or not really. So yeah, it's all stuff that goes to commuters guide again, it's also something that we haven't really got around to building properly yet. Yeah, I think Yeah, whenever that sort of stuffs abusable
Ben McCann 40:43
I think one of the things we we'd really love is to have kind of a guide to the code and a contributors guide that you know, right now we we've got a contributor sky that kind of has some guidelines about how to contribute to the project, but doesn't really help you get ramped up on the code base. And there's really only like a pretty small handful of people, you know, there's like three or four people that know the code base really well, because it is a pretty comp, Plex piece of code. And so you know, if anyone wants to take that on, we would love to have a better contributors guide that kind of describes how the code base is laid out. And like where the core pieces of functionality are, and how they fit together and how they work to help get more people ramped up in the community to being able to contribute.
Shawn 41:37
I've actually so a lot of times, when I introduce fault to the people, I actually send people directly to the code base to show like, it literally, you know, to prove there's no runtime, you just show the direct instructions. I forget the name of the functions, but it's literal. So most of the functions are just like one liners, especially when you're when you're doing like the DOM mutations. Yeah, I mean, I think I think that's, that's one way of really getting familiar with the Svelte codebase but also just understanding Svelte fundamentally. Yeah, you've inspired me, I want to go check out some prs.
Kevin Åberg Kultalahti 42:14
I think maybe like a, like a video tutorial or a screencast showing off, like how you would, how you would review a PR or do anything more major, rather than just like that's typing out issues. Could be something.
Shawn 42:33
Yeah, we could put that on the YouTube channel for civil society. And yes, get more eyes to it. Maybe it might be an interesting method. But yeah, it sounds like it sounds like there's a bunch of ways people can support like, monetarily, peer review, and then I guess more documentation on the codebase. Quality.
Kevin Åberg Kultalahti 42:52
Cool. All right. Do we have any, any other interesting topics we want to talk about? before we head on to pics,
Antony 43:04
as an interesting one here, this is from the Twitter but it's obviously not directly related to what we asked, but it's when do you think the first roles is felt developers will start to appear? I mean, that's an interesting question. Because from what I understand, there's actually quite a few roles out there appearing now. I think decathlon were most recently hiring. I'm not sure what the hiring for could be new team. It could be the existing site, because for those who don't know, the European decathlon sites, which is a huge, huge brand in Europe, and in the UK, in fact, then their new site, their rollout in Europe is actually running Svelte to one the UK is running the legacy code base. It looks like so maybe it's porting the UK one. I'm not sure but they're absolutely hiring right now. Yeah, look for Svelte developers. There's quite a few jobs in the in the jobs channel on discord if you want to have a look through some directly related to Svelte jobs. I hired two stockbrokers, you know, I had literally four stock bumpers, so that's good fun. I'm not hiring at the moment, but maybe again in the future, a bit of luck. But yeah, so there definitely are jobs out there. You just have to sort of know where to find them.
Kevin Åberg Kultalahti 44:10
Yeah, I saw one. By like one of the largest Swedish universities looking for a Svelte developer. I think for some sort of like data is not sure. Nice. I was interested as
Antony 44:26
I saw, actually, a school seeing on them discord today, a school, a school child, 15 year old has actually said that his school's asked him to learn Svelte as part of a project. Isn't that super interesting? Yeah, I know. He's like, he's come to the school with his homework. Like, they've taught me to do this as well. How do I do it? Is it
Kevin Åberg Kultalahti 44:48
the guy that that has contributed a lot to Svelte society website lately? Maybe?
Antony 44:53
I don't know. I don't think it is because he was saying that you found something very complicated. I was like, well Kinda yeah but also not, not really. But it's weird there because like if schools are teaching Svelte muscles can't get better than that.
Shawn 45:10
I guess I should also mention we keep track of you know, notable production, usage of Svelte on the tube and as well society Twitter. The typical ones that we always raise are like Spotify Apple, IKEA. What's IKEA? Yeah. And then I guess the data in the database angle I guess the the official government. German government site for vaccinations is also in Svelte. We have Square Enix and Disney they had like Kingdom Hearts and their their main page was in Svelte. There's, there's like a bunch of Alaska Airlines for their booking reservations, uses Svelte as well. There's there's just a bunch and these are just like the household names. Obviously. There's there's a bunch more Schneider that are
Antony 45:54
beyond Of course, you know, a start.
Shawn 45:57
Yeah, exactly. But I'm not so much in favour of like Svelte jobs as just like, you know, web developer in general, and then just pick the tool that that fits you. So I'm not I'm not too concerned about having Svelte in the job title.
Antony 46:10
Yeah, I think I think the reason I like that concept of Svelte jobs is because, you know, if I were to stop doing biankin, going in a job, I really would want to just carry on using Svelte and I would be looking for a specific style job, I wouldn't be looking for a front end job necessarily, I'd be looking for a Svelte job. And just because it's something that I enjoy using every day, in fact, like I said before, on the show, I'm sure, it's kind of, I'm a full stack developer, I could do any part of the stack. And I've always kind of avoided front end. But actually Svelte is the one thing that's brought me back into the front end thinking I really enjoy working on on webwise. Again, which is, which is quite a statement, really, because it's still quite difficult, you know, there's still browser compatibility to worry about, and all that kind of stuff, you know. So I think it's valuable to have a Svelte specific job, and I think that's a good thing that that's being advertised
Kevin Åberg Kultalahti 46:59
in that way. Okay. Yeah. So I shall go, then, yeah, you should, it's your second.
Antony 47:07
So this is gonna, this is gonna This is where we where our ratings dropped to zero, right? So yep, code comments are bad, I just want to say that, all comments, they should be banned. liberals in the past to remove them. So you can't commit comments to your code base. The reason being, if you've got code comments in your code, it means that your code is violating one of Kent Beck's four main rules is Kent Beck is very prominent, this sort of stuff, but he is absolutely right in the code should show intent. And if you're writing comments to show intent, then your code is obviously not showing intent. And for me, that is a direct, you know, a direct violation. So for those who don't, who can't back, have a look at my Twitter, he's very, very prominent software Dev, a very long time. A lot of the stuff if you kind of follow his guidelines, makes them much, much cleaner, much more readable, much more sensible, logical code, it's easy to maintain. So the priority map, as he does, it has four elements from lowest to highest, the lowest element in his map is fewest elements. So that's the fewest component parts to make it a whole. The next two are to no duplication. Obviously, you know, try principle, don't repeat yourself. If you've got up to code here in there, it's a maintenance headache is a testing headache, and you could get in sync. So remove that into a single place, abstract it and call that, again, within reason. It's like a hard and fast rule. It's within reason. And then the second one on that level is revealed intention, your code should read, in that it reveals that tense so that it makes sense for the person reading it. And the additional downside to comments in this concept is that a comment is not testable. So a comment can go out of date when you write the code. And someone can change that code. Not that the comment, there's no test to check that. So therefore, the invalid if somebody is relying on that comment, which, for comments to have a purpose, they'd have to rely on it, then it means that they're reading something which isn't true and potentially even does the opposite of what the code says. So there are danger if one comment is false or wrong then or even misleading, because it's English language, right? Or whatever language but mostly English. And it can actually give the wrong impression about the code. It can say the wrong things, and then you end up misunderstanding the code and potentially writing books. So therefore, my my, my notion here is that code comments are actually bad. And of course, it's his top element in this map is passes the tests. That's probably the most important of all, no matter anything else. As long as it passes, the test is good. But back to code comments quickly. I believe that code comments for code smell. I believe that code comments are a bad thing. They're damaging, and I genuinely believe that they're, they do more harm than good. And that's my controversial. That's my kind of speak now.
Shawn 49:52
It's a very good one.
Antony 49:53
A controversial opinion. I always get flamed on this for Twitter, I always get flamed non stop. So So just
Shawn 50:00
to be super clear, the entire Beyonk codebase does not have comments.
Antony 50:05
You are correct. Not a single comment. Well, it does make you write better code. It does make your app decayed. Do you?
Shawn 50:16
What about Svelte? Svelte prs like D Do you? Would you reject a PR over? You know, an excessive comment of you probably allow so small comments
Antony 50:30
Yes, so the Svelte codebase goes against a lot of the things that I believe in standards like linting, and things like that it goes against them. This is Rich's style, and his you know, the general maintainers. A great stylist is totally fine with me. And comments are the same, right? The notion is that comments are included that code base, therefore, I'm totally happy with comments being there. And so I accept prs with with code comments, because it's not a violation. However, I will admit to when I see rich adding code to the code base, we've Ben adding code to the code base. But there's the comments.
I'm like, No!! I'm totally right and totally fit. But I've just like, it's the way it is how it is. The weird thing about linting in about code style is it actually doesn't matter. What's more important is that everyone uses the same code style. So therefore, if this is the code style Svelte code base, and I'm more than happy that we don't spend time bike shedding about whether they should underscores and variable names or use camelcase. I'm much more happy that we should just have a single style. And actually, I'll be honest, I'm actually coming around underscores and variable names now, which is really not voting. Well, my team because we've always been against that. But hey, you know,
Shawn 51:43
progress.
Kevin Åberg Kultalahti 51:45
Yeah, we actually
Shawn 51:46
had someone comment on Twitter that the Svelte code base does have a bunch of underscores stuff, and it's very readable. It's quite readable.
Antony 51:54
It is it has underscores internally, and it uses camel case for external API. Yeah.
Shawn 52:01
Sorry. Good.
Kevin Åberg Kultalahti 52:03
Yeah. So any, any other unpopular opinions? I have one, a short one, but
Shawn 52:09
Well, I thought that was such a good one. It's hard to follow up, Ben. Yeah. Yeah, I'll
Ben McCann 52:14
jump in and say, don't use Svelte kit yet. Just use saffer. For now. I know people are really excited to use Svelte kit, but I think you're just gonna cause yourself more trouble. There's no documentation for it yet. There's not really any support for it yet. Like the things are still changing. And so I know, like people are starting new projects, and I don't want to have to migrate. But it's it's not going to be a painful migration. And it'll be be a lot less pain than using a project that we don't really intend for people to use yet. Yeah. Yeah.
Unknown Speaker 52:58
It's popular here.
Kevin Åberg Kultalahti 53:01
Yes. So so I have I have a small, unpopular opinion. Maybe it's not unpopular, actually. It's hard to read tailwind. I started tinkering with tailwind and it's it's actually quite okay. was better than I thought, but, but reading it is really, really rough. Having having HTML for with classes.
Antony 53:23
So your opinion is that it's hard to read tailwind?
Kevin Åberg Kultalahti 53:28
Yeah. I guess so. Wow.
Antony 53:31
That is that is the burning fire, pitchforks, pitchforks and Dawn? Well,
Kevin Åberg Kultalahti 53:37
it's not so much that it's hard to read. It's more like, it's just like a jumble of everything in the HTML, and I get confused. So I'll probably learn.
Antony 53:48
Who knows. I'm no sale would fun. I probably inclined to agree with you. It's it's class overload. But But yeah, I can see that definitely causing some controversy.
Kevin Åberg Kultalahti 53:57
It is nice, though. Like, for this one project. I've tried it on.
Shawn 54:02
Ben, what's your take on too, and
Ben McCann 54:05
I haven't used it yet.
Shawn 54:08
You probably have an opinion, though. You've probably looked at it.
Ben McCann 54:12
I haven't Yeah.
Shawn 54:21
I won't. I won't comment until when stuff but I can I can then jump in with the last unpopular opinion, which is that serverless is killing static sites. And I just realised this, that like there's really no more reason to have like a traditional static site generator that jet pre generates 1000s and 1000s of pages like we used to benchmark sapper on like, how long does it take to do 30,000 pages like doesn't matter anymore. And I realised this partially because this socket, partially because of remix in the React ecosystem. And next JS everyone is is moving towards serverless says like the the rendering unit. And I think that's why like, the reason we had static site generators turned out so many sites was because compute was, you know, centralised and we needed to run the build process and then distributed on a CDN, and that model worked. But now that basically, every hosting platform has serverless, that it's super easy to spin up, that we can just like, run the the page generation on demand and cache it. And there's no need for a static site generator anymore. So that's my opinion.
Antony 55:39
Yeah, I think I think that I think I kind of agree with that opinion. Because obviously, like, generating on the fly is effectively static site generation, you're generating something into the cache. You're just not doing it. At the time. Yeah, yeah, you're doing it, you're doing it kind of on request on requests for the first request. Makes sense. If you've got a sensible caching strategy and a way to clear that cache then, then yeah, I think that's a great, that's a great idea. Yeah.
Shawn 56:04
So I mean, I don't know if I don't how profound This is, but like, you know, obviously, I used to use Gatsby a lot. And Gatsby is like, if this insight is true, then Gatsby's kind of dead. So is like every other static site generator like it's fine. I still use it because it's like a tried and tested codebase. But just the developer experience of like updating a page and not having to wait for a billion minutes for it to rebuild. It makes it a superior paradigm already. Absolutely.
Kevin Åberg Kultalahti 56:34
All right, picks. What do you have? We got to go fast now. I gotta run
Antony 56:42
Right? I pick the todos smart heating system. So I've been when asked how my boiler fitted ask the fitter to fit me this like the cheapest possible wireless receiver because I was going to get smart heating and then I didn't get
Kevin Åberg Kultalahti 56:56
a random pick. Estela random
Antony 57:00
pretty good, right? But anyway, more random Shawn, they say I was getting fitted and never thinking about it and then one day this cheap smart heating system this this cheap sorry this cheap wireless heating system which I will name sailors don't ever buy and the crap it actually broke just just stopped working one day and I was sat in the middle of December in England in the cold which is like one degree or less Celsius. So I got my friend how Tato I looked it up. It is the most amazing beautiful onboarding system i've you know products come with a how to set product up and usually it's it's varying levels of how good it is. And this product is literally you as a layperson going and adapting opening your boiler and fiddling with the wiring right and yet they managed to talk you through it on a smartphone step by step every single detail what's important what was occurred what what you should label everything. I did the whole thing in like 12 minutes or something and to end a tumour board or apartment the first time ever. I took all the circuit shut my boiler, I started unscrewing things and rewiring it and God knows why I was doing crazy stuff, right? And it's totally fine because today is so watertight setup you tell it what boy you've got. It even shows you a picture of your entire setup and I've had a pretty random setup specific boiler specific water heater specific wireless transponder that we use some some naff sales sales sales product or is it had pictures of all of it and how to remove it, how to fit their stuff. Fantastic. So if the product is great, it's wonderful. It's great smart heating, but the setup is just is something that people should aspire to is how to onboard people onto a product. So my pick is today's my eating.
Shawn 58:44
Wow. Dude,
Ben McCann 58:48
that's hard to follow up. I'd say my pick is Narcos Mexico. That's the I know everybody's been watching Tiger King and that chest one.
Shawn 58:58
But he's got the eyes. Yes. Yeah.
Ben McCann 59:02
I'm all about Narcos Mexico.
Shawn 59:04
So I watched I watched the original Narcos Is it is it just like with different actors like what? Yeah, it's related.
Ben McCann 59:11
It's about the Mexican cartels.
Antony 59:13
I thought this sounds great to watch this. Yeah, the
Shawn 59:17
first narco is is really good.
Kevin Åberg Kultalahti 59:18
It is. So good. So my my pick is something called kitty. It's a it's a terminal. Terminal replacement. Pretty nice. You can customise it. pretty much it.
Antony 59:37
Kitty, right?
Kevin Åberg Kultalahti 59:39
Yeah. Yeah, like a small cat. It's, it's it's actually very, very nice. It's GPU rendered. Which is better than those electron thingies. Right. Yeah. To render some stuff Yeah.
Shawn 1:00:00
I guess I'll pick Audacity. I don't know if you guys have messed around with it, but it's it's open source, audio editing software. And it's surprisingly powerful. I've never really, I've used it before to edit minor clips. But then I took some time over the weekend to learn how to set levels and like mix clips together and like, post process like pops and stuff like that. It's really powerful. And it's open source, and it's very performant and just amazing piece of, I guess, open source collaboration. And I didn't I didn't know I don't know the history behind this, but I'm curious to learn more, but it's just really good software to use. In other nice Shawn will be on new editing of the podcast, right.
Kevin Åberg Kultalahti 1:00:46
All right, it is. Yeah, yeah, it is. So that's all the all the pics done. And that's it for this time. Thanks, Ben for for coming on and talking about separating Svelte and then thanks for having me everything else. All right. We'll talk to you guys next episode. Bye bye
Transcribed by https://otter.ai
