Rich Harris talks SvelteKit and the future of web development
Rich Harris joins us to talk about SvelteKit; features, plans and all sorts of fun stuff.
This week we get a glimpse into the future of Svelte and SvelteKit! Rich joins us to talk about the new thing in town, SvelteKit, as well as what the future of web development could look like.
Some topics that we discuss:
- Release date
- SvelteKit vs Sapper
- Features
- Adapters
- Ideas about what is next
If you missed the talk at Svelte Summit check it out here.
Picks:
- Robot Vacuum
- OnePlus 8T
- SavvyCal
- Begin.com
Transcription:
[00:00:00] KA: Hello, everyone, welcome to another episode of Svelte radio. I'm your host, Kevin, I run Svelte school. And today we have a very special episode, we have the creator of a Svelte, Rich Harris. But before he gets to introduce himself, we'll kick it off with our other hosts.
[00:00:19] S: Hey, I’m Sean, work at AWS on random stuff, including trying to get Svelte into AWS and that is an ongoing mission.
[00:00:30] A: Hi, I'm Anthony, and I'm the CTO of Biank. And also Svelte maintainer.
[00:00:35] RH: And I'm a graphics editor at the New York Times currently working on SvelteKit.
[00:00:42] KA: Whoo, cool. The new shiny thing before we get started, how are you? How's everything with the election and all of this stuff? How's the workload?
[00:00:50] RH: For me, thankfully, it's settling down. Last week was quite a busy week for everyone. Certainly in the graphics department at the times and probably in the organization as a whole. It's very difficult to avoid getting sucked into the madness. But you know, what is fun? There's no better place to witness history than from a newsroom, even if it is a virtual newsroom scattered around people's homes.
[00:01:10] KA: Something I didn't didn't appreciate about your election coverage is that you're actually spinning up visualizations fairly quickly based on what counties or states are in focus at the time. Like, there's some parts of this that you could not have prepared beforehand, right?
[00:01:26] RH: Yeah, there's some sleight of hand, you know, you prepare for a variety of different outcomes. But yeah, like, as soon as the results start coming in, the politics editors, and the graphics editors who are covering this, are bashing their heads together and trying to figure out what is the story. And then that kind of filters down to the people making the charts and maps. And we all come together, we analyze data, and we try and figure out what just happened. There is some infrastructure that's already built out, because you kind of know that people are gonna want to know which parts of the country swaying in one direction. But yes, a lot of it is kind of rapid response, data visualization.
[00:02:05] KA: So you've got Lego blocks for building visualizations that will tell you population, this area voted this way or whatever, you've got that sort of stuff?
[00:02:14] RH: Yeah, like you know that you're going to need a lot of demographic information about counties, like we know that the results are going to be coming in per county or in New England it’s per township, because they like to do things differently. And you just have all of the data that you might possibly need in a massive spreadsheet at a time. And then you can also plug it in to make something relevant.
[00:02:37] KA: Alright, so we're not here for the election. We're here for something that's more exciting.
[00:02:48] RH: That’s certainly, perspective
[00:02:51] KA: For sure. So we're going to talk about SvelteKit today. So before we dive in to the questions, what is SvelteKit?
[00:02:59] RH: SvelteKit is, in one way it's a successor to Sapper. And you could even think of it as Sapper 1.0, if you like. But in another larger sense, it's our kind of vision for the way that you should build Svelte apps in future. It’s something that we've been kind of talking about in a peripheral sense for a long time, we've been talking about how we can evolve Sapper to take advantage of some of the recent trends in front end development, particularly the rise of serverless. And more recently, the rise of unbundled workflows, which I'm sure we'll get into later. But it all sort of came to a head recently, you know, the pace of development on Sapper had hit a bit of a low, at least until Ben McCann really picked up the baton and started churning through issues. And people were getting a little bit frustrated, I think with the progress. And Anthony is one of those people because he uses Sapper very heavily in his job. At a certain point, we're like, “What if we just started from scratch?” Like the big rewrite, as opposed to trying to get all of these ideas into what was honestly kind of a watery codebase. I sort of proposed this very hesitantly in the discord thinking everyone was going to yell at me. And instead everyone was like, “Oh, yeah, let's do that.” And so that was sort of the germ of the idea. And then over the last, I guess, month or so, the idea turned into a prototype, and the prototype turned into a project with a name. And I was, I guess, reckless enough to announce it at Svelte summit as a thing that I was working on. And then at that point, it was like a de facto, this is what we're doing. Now. This is, this is it. So now the whole team is full steam ahead. We've got some new contributors as well, people who haven't previously been on the Svelte core team are helping us out. Andreas [inaudible] is one of them and Dominic who created Sleet helping out in the repo and it's actually looking good.
[00:05:00] A: I think that probably the alternate version of that story is that Rich claimed to going on holiday, he went on holiday, he came back a week later and SvelteKit appeared. And then we spent ever since bikeshedding the name.
[00:05:15] RH: I promise I didn't do it on holiday. I would have been very sad, I had a really nice break. And if I'd spent it in front of a laptop, I'd have been very unhappy with myself in trouble. It's just the way these things right, the first 80% of a project is you can build it pretty rapidly. But then once you start to get into the details, that takes the remaining 400% of the time. And that's the situation that we're in at the moment.
[00:05:15] A: The modified Pareto principle.
[00:05:41] KA: Obviously, I'm not so steeped in the history of Svelte as much as some other people here. But I feel like this is something that happens every now and then in rich land. This idea that a big rewrite would update just a lot of the core assumptions and change the design to something that is much more enjoyable. Is there like lessons that you learn from you know, having done things like these, for example, going from [inaudible] to Svelte? And then from pre Svelte 3 to Svelte 3? I thought that these are pretty major bumps. Right?
[00:06:09] RH: Yeah, I mean, I guess the main lesson that I've learned is probably that it is a good idea. Because software, it grows organically, right? And there are layers at the bottom, that very often don't make a lot of sense anymore because things change, especially in the front end world, things are changing all the time very rapidly. And we started sick of dealing with a legacy code base, but because there's actually a new foundation that you want to build on top of them then it is worthwhile. But at the same time, I have also learned every time I've embarked on any kind of big rewrite that it is going to be so much more work than you anticipate. Because the old thing that you're replacing, it did a lot of stuff. And you're, the new thing needs to do all the same stuff.
[00:06:59] KA: Just better. Yeah.
[00:07:02] A: It’s also I guess, we're sort of building in parallel with Sapper, it's not like we’ve just abandoned Sapper completely. Sapper is now in I guess, in the kind of maintenance mode although it's not really officially announced yet. We're adding to it as we go. And the issue of course there is any new stuff or fixes you put into Sapper have to be then ported across to SvelteKit. So it's actually keeping track of that as well, actually, it's actually quite difficult. So it almost inhibits us, it makes us try not to do too much on Sapper, even though we need to keep it going.
[00:07:32] RH: Yeah, and that plus, you know, psychological factors, I think, really driving us to get this work done as fast as we possibly can, in spite of all of our schedules, we really want to get this done sooner rather than later.
[00:07:45] KA: Speaking of getting this done. Are we talking hours,days? Try it for real.
[00:07:59] RH: The one thing that I've said about timing publicly, other than I'm not gonna say anything publicly about timing, is, I think we're looking at weeks rather than months, I would be disappointed if we didn't have a public beta or beta, we've had a long conversation about how to pronounce that word, sometime this year, which gives us just under two months to the public. And then, you know, a 1.0 version is gonna be a little bit longer, it kind of depends on what people find, when they first try it out. And if there's all sorts of bugs and use cases that we haven't considered, then, you know, might push things out a little bit, but you know, hopefully, early 21, we're going to have it stable.
[00:08:47] A: I think also that the reason that committing to an ETA isn't really possible, really even giving that rough guideline, Svelte has no full time maintainers. It has people who have real jobs in the real world who do this in their spare time. The advantage to that, of course is that you know that everything that's going into Svelte and Sapper and SvelteKit, and everything is people's passion, and it's stuff that people want to do, not stuff that they feel is a chore or that they're paid to do against their will or anything like that. It's really a product of passion. And I think that gives it an advantage over something that's maybe run to a sort of an expectation or a schedule or a more official, [inaudible] call it company I suppose.
[00:09:32] RH: Also no ivory towers here, everything we build is driven by very real world practical needs.
[00:09:39] KA: Now that we know what SvelteKit is and when we can expect it, should we get into some questions? I think the first one that most people that are coming from Sapper are wondering about is what about migration? How easy or hard will this be?
[00:09:54] RH:Yeah, so one way to think of it is imagine that we did put out a Sapper 1.0 and we’ve said all along that there's likely to be some API changes between, like, where are we now Sapper 0.28 and Sapper 1.0. And every time we've released a new version of Sapper we've had a migration guide that sort of walks you through the process, it's actually not going to be any different from that. There are some changes that we have to make because we're embracing serverless is this first class idea, but like the bones of the project are going to be relatively unchanged. And so we've been migrating some of the existing sample sample projects like our Hacker News clone and our Real World clone, it's not that much work. Because your file structure continues to represent the structure of the application, we have the same file name convention for dynamic routes, and all that sort of thing. Things that have changed, let's go through the list. Previously, you would have had a custom server.js, because the expectation was that you're going to be running a node server, or you're going to be statically exporting the entire app, we can't make that assumption anymore because there isn't going to be a server in the traditional sense, there's going to be a set of serverless functions.
So right now there is no function that will run for every single request, other than the function that generates the session context, which like, includes your user information and stuff like that. And so you can't use things like Express middleware, and stuff like that, which you might have been using before. As things stand like all of this is, you know, subject to change, if it proves that there are a lot of things that people just simply cannot do without having a custom server. But right now, we're trying to lean as far as we can in the direction of being like fully serverless. On the same note, your endpoints, so we used to call these server routes, which has a bit of a funky name, we're now taken to calling endpoints, which is to say that if you have a file like sourced/routes/foo.js, that will respond to requests to the slash foo. And inside that, your handlers no longer take the request and response object that you get when you're dealing with notes HTTP module. Because if your on an ADLS lander environment or something like that, then you don't see those things, you are given an object that represents the method and the headers and the body and everything like that associated with the request. And your job is to return an object that contains a status code, some headers and the body.
And so we're basically adapting to that surface, which means that you will need to write all of your endpoint handlers, we might change the preload signature. And we think that we can probably improve that a little bit. And a lot of people don't like the fact that you have this inside your preload functions. And so we might fix that. But everything else is just a few little cosmetic bits, bits and bobs here and there. If you have a very complex build config, like if you've changed the Webpack config, or the roller config in your project, then you'll need to find some way to represent those changes in the new Snowpack config. But that's about the extent of it, I think.
[00:13:08] KA: Something I am a little bit vague on is so we're splitting things up from a single server to multiple serverless functions. Do we have fine grained control over which of these are statically rendered? Or which of these are dynamically rendered? I don't know if that's the term.
[00:13:23] RH: We do. So there is this concept of pre rendering that can apply to all of the different adapters. We'll explain what adapters are at some point in this episode, I'm sure. And essentially, what that means is that as the functions are being built, we can pre render a subset of the application as static files, and they will just get dumped on your CDN wherever. And then when a request comes in for one of those static pages, it will just retrieve the pre rendered HTML, which is great, because there's no work to do. Having said that, I don't know if you've been following what Remix are doing at the moment? They have a conviction that static site generation is a waste of time. And actually, we should be dynamically pre rendering everything but using cache headers in such a way that it is as if you had statically the pre rendered everything. It gives you the benefit of the dynamic rendering, but without the downside of pre rendering, which is that if you have a very large site, it might take several minutes to pre render all of your pages. So you can sort of amortize that cost over the life of the app. That's a long winded way of saying yes, we do have pre rendering, but also we're kind of thinking about whether that is the right direction, and there's more exploration warranted around that topic.
[00:14:42] A: I think it's a very interesting direction. Yeah.
[00:14:44] KA: I had a question about like the, so in other frameworks like Next js. you have this gets static props thing, for example. I guess this touches a bit on that. So prefetching data at build time.
[00:14:56] RH: Yeah, well Next has get static props and get server side props. If you have a static pre renderable page, then you call one function. If you have a dynamic render page, then you call a different function. We're not doing that, we just have one consistent way of pre loading data, whether it's a pre rendered or not pre rendered route. And the way that we differentiate between pre renderable pages and non pre renderable pages, is you just export a Boolean. Export cons pre render equals true. If that exists on a given page, then the adapter can know that it can pre render these pages. And you don't need to seed it with the pages that are pre renderable. Because it can just look at the route manifest that it generates and identify the statically rendered pages for you. I think is the same idea. But I think the implementation is a little bit simpler. As far as you know, offering an app is concerned.
[00:15:51] KA: I think, this idea, especially, you know, just thinking about the caching stuff, if you go down that path, it would mean that you basically a very predictable build times because you don't essentially don't have to build your pre rendered page, they would just get pre rendered on request, that'd be an interesting solution, it would change it from like, O of n to like, maybe O of one. But then I think it's also one of those things that's very contentious, because it's just not a norm to set cache headers in a lot of JavaScript frameworks. It's definitely a bit on Ryan and Michael's side of things. And it's something that so having worked in Nullify, myself, Nullify does stick to the fairly strong view that people don't never, they either never set cache headers, right. Or they tried to do it right. And then the first set of problems, they turn it off, and then they leave it off. Because that's that's the way you solve problems with cache invalidation, you just stop caching. It is an upcoming struggle, I feel like that that we're really going to see play out because of all these frameworks exploring this space.
[00:16:51] RH: It is. My guiding light around caching is a blog post that Jake Archibald wrote a while back, in which he basically says there's two reliable ways to set cache headers. One is the content is immutable. It has, like some unique identifier in the file name, like a hash of the contents. And then you can treat that as immutable. Once the browser has it, they can hang on to it indefinitely. because nothing's ever going to change. And that's guaranteed. The alternative is, you're going to need to check everything with the server. And the server can respond with a 304, which means nothing has changed since the last time you had this file. So you can use the version in your cache. But you still need to check everything with the server.
And anytime you start to get into or maybe you can hang hang on to this file for a little bit, then don't check for like the next 10 minutes or something. Inevitably, you start getting a mismatch between, you know, you've got some resources cached and some other resources that relate to that resource, uncashed. And it gets out of sync. And this is, this complexity is magnified when you have a server rendered page, which is cached for a certain amount of time. And then if you if you navigate to that page client side, and the framework is just getting the data for that page, instead of the page itself, then that JSON file or whatever it is, will have a separate cache lifetime. And so the server rendered page and the client rendered version of that page will be out of sync. And even Remix doesn't have a solution to this problem, it is a really tricky thing. But I think what Remix is doing is pretty smart. After talking to Ryan and Michael a little bit about this, it turns out that what they're doing is they're actually controlling the deployment as well as the generation of the files that get deployed. So their equivalent of our adapters, they are also responsible for invalidating caches on the various platforms, which is how they're able to have this level of granular control. Whether it's worth thinking about adapters in SvelteKit in the same way, that they should be responsible for deployment, as well as just for building, is something that we probably need to think about. I think
[00:18:55] A: I think also, if you're generating a lot of content up front, and then you know, static, generating content, and then you're deploying that content, and then someone changes what their contents based on, and then you have to rebuild the whole thing, you're going to have that build delay, whilst all that content is rebuilt anyway, unless you're gonna have a way to build them one by one, which should be very quick. So if you're rebuilding all that content, every time someone makes a change, then that's basically the equivalent of having a long cache on some stuff and having stale content rendered to the browser. So I don't think either is a silver bullet. It's definitely an issue that needs a lot of thinking about.
[00:19:32] RH: Yeah, it's one of two hard problems in computer science.
[00:19:34] KA: Right. So TypeScript support, of course.
[00:19:39] RH: Yeah, we're gonna have full TypeScript support when we launch, you know, whatever your definition of full TypeScript support is like, we'll have the ability to set up a TypeScript project when you do [inaudible] in Svelte it already, in fact, asks you, “Do you want this to be a TypeScript project?” And if you hit yes, then it will add TypeScript to your package. It will convert the example component to have Lang equals Ts, give you a Ts config, all of that stuff. And it just kind of just kind of works. There's other little nuances about how we incorporate Svelte check into this setup. But the short answer is yes, TypeScript will be supported. We're not making the mistake this time.
[00:20:21] A: I think you've also, you've also touched on another point there, that SvelteKit has a CLI, and it has a config file. And that's there's two things that originally we considered to be a not not a good thing. And now they are sort of, they’ve become part of what we're building. So might be interesting to talk about why?
[00:20:41] KA: Maybe back up a bit as to why do you get in the old case?
[00:20:44] RH: Yeah, so for a long time, we kind of rejected CLI’s in favor of just plain old template repo. And that's your project. To make that easier. We have this tool called DGIT, which essentially clones a repo without all the history, and has some like nice stuff around discovering the repos that you've already claimed in the past, so that you don't need to type it out each time. And it will do offline caching and stuff. But it's basically just cloning a repo and then deleting the docket folder. And that's nice, because you're really, you're showing your work, there's no, there's no magic, there's no, like if you do a Create React app thing. And then at some point, you're going to stray from the happy path and you're going to need to eject from your Create React app setup. And at that point, you're on your own. And what was formerly this relatively self contained thing just kind of splurges all over your file system. And it's just a, it's a very confusing experience. And so we've felt quite strongly that it's better to just give someone some files and say, this is how they interact with each other, if you want to make changes, go nuts. And that way also people can, they can make their own base repos. Like if you spin up a lot of projects, then you might have some opinions about how to set that up about how to do tests and this, that and the other. And so you can make your own repo which is based on ours, and then you've got a project template that you can clone just as easily as cloning our own.
But we are introducing a CLI and I think that is largely motivated by the TypeScript thing, if I'm honest, because we've got a situation now where once you clone the Svelte template, you have to sort of run a command that sets up TypeScript. And if you look at the script that does it, it's, it's like breathless, like it's very clever, and it works. But it's also kind of messy. And if we're going to start adding stuff like that, if we're going to have questions about how you want to set up your project, then I sort of think that we need to be in control of how that project is initialized a little bit sooner. And it's also just people know what npm-init aoes, people are familiar with that. So the fact that you'll be able to do npm-init in Svelte, without installing a single thing, that will give you a Svelte project, and you can get started really quickly. I think, I think that's neat. But you'll still have the ability to DGIT from a repo that you maintain, if you have specific requirements. I think it gives us the best of both worlds, gives you a really nice onboarding. But we're still not going down this whole messy eject or don't eject route, that some frameworks seem to like.
[00:23:39] KA: So this config file. So that's where you would define your adapter, your pre processors, all of this stuff?
[00:23:48] Yes, yeah. So that's another thing that we resisted for a while having a Svelte config file, because config files have a way of getting a little bit unwieldy. And so we sort of said, maybe, let's put the brakes on this and not have a config file just yet. But then what happened, of course, was people in the community, thought, “We want to have a Svelte config file for our tools.” And so people created incompatible Svelte config files. So you know, you have one in the Snowpack starter project, you have one in the Parcel plugin, and they are fundamentally incompatible. So we sort of had to come along and say, we're laying down the law, this is what a Svelte config file is going to look like. And now that we're having this, like official way, like this is how you build Svelte apps, we have a SvelteKit and this is the officially supported way to build Svelte apps. It's less of a problem to have a Svelte config file because the project structure is already just kind of more predictable and more understandable if that makes sense.
[00:24:49] KA: Speaking a bit about adapters. Can you tell us anything about which ones are going to be coming at launch? Like which ones are you excited about having?
[00:24:58] Also what adapters do? Because Yeah, I myself don't really know?
[00:25:03] That's a good question.
[00:25:06] RH: You've got two choices, you can do Sapper build, which will create a node server that serves your app. And then you have to find the platform that can run a node server. And that's harder now than it used to be. Like, for example, before [inaudible] now v one, you can just run a node server. And that was great, really easy way to run a Sapper app. Now v two comes along, and you can't do that anymore, because they're gone fully serverless. So that's like a, an indication of the sort of direction in which things are going. Sapper Build was designed for the world formerly existed, Sapper Export, on the other hand, would build your server, it would then start your server and then it would crawl your and make out what it found.
There was no in between, between Sapper Build and Sapper Export. Now, we want to be able to say some pages are pre renderable, some pages are not pre renderable. And so that means doing things in a slightly different way, at the same time, we want to be able to generate Cloud Functions that run on Netlify, or Vercel or Begin or any of these other platforms. CloudFlare Workers. Yeah, that's another big one. It's difficult for the framework itself, to be able to satisfy the competing demands of these various platforms. So one of the big changes in SvelteKit relative to Sapper is this concept of adapters. The way that works is when you build your site, it happens in three phases. The first phase is we run it through Snowpack, which is what powers SvelteKit. And that will generate what we call the unoptimized build. And that's just like a one to one transformation of the files in your project. It'll do it twice, once for the server side rendered version of your app, once with the client side rendered version of your app. We then move on to phase two, where we optimize that output, we run both of those applications through roll up that allows us to do things like bundling things into coarse grained chunks, which are better for loading performance, we can extract CSS from your application and write it out as static CSS files. And we can generate the manifest that allows the Cloud Functions to know which code they need to load in order to render the page that's being requested. And so after that, we've got something that is pretty agnostic and doesn't actually do anything yet. So we we applied the adapter to it as a final step, which takes the optimized build and massages it into the form required for the various different platforms be that a node server or a purely statically exported site as with Sapper, or one of the higher function providers that we're going to support. You asked what we're going to support at launch. We don't have like a list yet, but you know, definitely Vercel, definitely Begin, definitely Netlify, definitely CloudFlare Workers, I think.
[00:27:57] KA: I'd be happy to help pitch in support forAWS.
[00:05:00] RH: Definitely AWS Yeah,
[00:28:02] A: It's worth noting, yeah, that a lot of people have come forward and say that they'd like to build an adapter for their platform of choice. And I think that's, that's a great thing. That's a really fantastic thing. The list that we have right now it started off with Rich building the Netlify one, I built the Vercel and Begin ones based on what Rich did with Netlift because, well Vercel was easy, because I'm already hosted on it. And I wanted to work on there. And I want to see how much work it would be because I helped build the original Vercel builder as well. And the Begin because I mean, it’s my pick, Begin.com is my pick, right? I really like what they do with architects, I really like the fact they have data built in. I really like that kind of stuff. And so I just wanted to see how quick can I get this new thing running on this platform? And how different is it to, to Netlify, for example? And it actually is not that different at all. And that's quite nice thing about adapters they are, they're all turning out to be roughly along the same lines, which is really interesting. Those lines are [inaudible] underneath it looks like so it's pretty straightforward really.
[00:29:03] RH: Yeah. So in addition to these official adapters that we're talking about, there's going to be a well documented API for people to build their own adapters. So any platforms that we don't support, people will be able to support them themselves. And actually, there is a conversation happening about how much stuff we want to do ourselves and how much we want to farm out to other people and let them maintain it. But the API is very much not locked down yet. So yeah.
[00:29:27] A: Hence why we haven't just invited everyone to build
[00:29:31] KA: There's an open question of whether every meta framework like Remix is doing something you know, [inaudible] is doing something, whether every meta framework should have adapters or should every meta framework target a single format? And I may have brought this up with you Rich I don't remember, but Glenn [inaudible] proposed FAB, the front end something application bundle, which are basically containers for front ends and it's a fancy way of just saying let's just standardize what we what we export to so that all the providers know what to ship agnostic of framework and all the frameworks know what to build to. Doesn’t that make sense?
[00:30:08] RH: It makes total sense. And I've chatted with Glenn about this. I should have added that to the list actually, we definitely want to have a FAB adapter for SvelteKit. I'm actually surprised that more people aren’t using FAB, it’s such an obviously smart idea.
[00:30:20] KA: Because he targeted CloudFlare. He was like only CloudFlare. And then that was the story for like two years.
[00:30:27] RH: That's another easy way for us to support multiple platforms is -
[00:30:32] A: I think on the flip side of that coin, of course, and I think it’s fantastic idea. I think the flip side of that, unfortunately, is that you can make something that adapts to everything. But abstraction has a cost. And I think that at some point, you encounter a bit where well, this won't work now, because this radically new, different thing that’s super optimized, won't fit into this pattern. So you can understand why there's there's always kind of a, it's not a silver bullet. Nothing's a silver bullet I suppose.
[00:30:57] RH: [INaudible] outsource our adapters to FAB but because we do want to be able to optimize specifically for different platforms. But it's a great net to catch the things that we can support ourselves.
[00:31:10] KA: I want to move on to developer experience. So this kind of seems like one of the important things with SvelteKit, things like Snowpack, and the adaptors I guess, are also part of that. What are some pain points that you'd like to explore in the future when it comes to bringing the developer experience even further along? Not particularly anything to do with SvelteKit, more like just general thoughts? Hmm. Wow, that
[00:31:39] RH: Hmm. Wow, that is a big question. That I think SvelteKit represents a big upgrade in developer experience from Sapper, just because the Snowpack developer experience is so good. For people who haven't tried it yet, like it's worth just trying out one of their sample projects so that you can get a sense of, of how the thing works. It doesn't have any of the delays that are involved in traditional bundlers at development time. And it also has some really nice features like it has error overlays. As soon as there's an error in one of your files, you'll instantly get feedback in the browser, you don't need to have your terminal visible at the same time as you're developing, it just gives you way better feedback. The hot module reloading is really robust in my experience, it's just great.
But I think it does open doors to potentially some future improvements that we haven't really begun to explore yet. One of those is the idea of having something like a Storybook type experience built into the framework. I'm not personally a user of Storybook.
[00:32:40] KA: Have you tried Svench?
[00:32:41] RH: I haven't tried Svench yet no, but it's on my list of things I want to play with. Aesthetically, I just can't get on board with the way that stories are written in Storybook. And also, like it takes a little time for a Storybook to get started. But now that we have this unbundled workflow, you no longer need to point your bundler at all of the components that you want to have in your Storybook, because everything is just dealt with at runtime. So I think we could have a built in Storybook type experience that would be really slick and really fast. But then, you know, once you start thinking along those lines, you start asking yourself, why not just bring this stuff directly into your editor? And so I'm also kind of idly wondering about what an integration between, say, VS code and SvelteKit could look like? Can we start to move more in the direction of wiziwig component editing?
[00:33:37] KA: That would be pretty cool. I have wondered because I also faced that frustration with Storybook, we used it at Netlify and a bunch of other open source projects that I contribute to. And yeah, it is way too slow. And that needs to be changed. But the workflow of having independent components apart from your app, so you can develop in piece, but also document and kind of have a live design system, it does make a lot of sense. We all have a source slash components folder anyway, like, let's actually make use of that in some way. I think you're gonna build that as a layer on top, but some people use vim and all that. So it's nice to have a standalone browser version and the browser version, you can just kind of bring into VS code pretty nicely as a VS code extension. And then the other thing to take note of is that people often build their Storybooks as an externally available site, so that people can reference their design systems just for designers and whatever.
[00:34:33] RH: Yeah, and actually, this this is a point worth touching on. At the moment, we have this fairly neglected component template for if you want to build a Svelte component for distribution or component [inaudible] for distribution. You don't get as much hand holding as if you want to build an app with Svelte. And we can change that with SvelteKit. I think that using SvelteKit for building component libraries, or even just single components is going to be first class experience, because we can have this storybook type thing in the future. But even without that, you can build your demo site using the components in your source slash components folder. And you can put that somewhere. But you could also have, we haven't built this yet. And like, we haven't really talked about it even among the core team, but you could have a CLI command that packages out as a component language for distribution as well. And I think that could be very powerful, that could cause a renaissance in component libraries in Svelte and you can do things like pre process all of the components in your components folders to strip out the SASS and the TypeScript, and whatever, so that it's easily importable everywhere. But while you know, keeping the component source otherwise intact, and, you know, we can generate export maps, and all of these other things that are a pain to set up yourself, we can just do it for you.
[00:36:01] KA: Speaking of things that are a pain to set up, testing, so Sapper had a Cypress included right, at some point, I'm not sure if it still does?
[00:36:11] RH: Yeah, it's been removed, actually.
[00:36:15] KA: So what's the idea with testing when it comes to the SvelteKit? Have you guys thought about anything around that?
[00:36:22] RH: We have an issue open for it. Every time we start talking about testing, like, yeah, we recognize the importance of testing. But honestly, what kind of tests make sense to have in a front end project? It's far from clear like, what stuff you are supposed to be testing, we don't want to have some sort of official recommendations that end up with people writing meaningless tests. A lot of front end tests are kind of meaningless. They're just duplicating the functionality of the frameworks and test suite, which is not a good use of anyone's time. So I don’t know, Anthony?
[00:37:02] A: I think, you have to pick the problems you want to solve. And I think for us to determine what a good testing strategy is, is not a problem that we really want to solve or we’re even set to solve. I think a lot of the maintainers especially have different views on what testing is, I'm not even sure now that, I, my view on testing has changed. In the last three years, it's gone from ice cream cones to mountains, and you name it, it's all over the place, it's very difficult to say what a good testing strategy is, it's very app dependent. It's very much about where you are going. I like to build very dumb, thin front ends, and very smart backends. And therefore, I can actually replace the front end or have a native app or anything else like that anytime and not lose the crux of the application. And I think that it does almost make a lot of acceptance testing extremely costly. Because you're writing tests for something that you effectively throw away. It's almost a waste of time to throw the front end away or make some drastic changes to the workflow. I think it's one of those things that it's easy to pull out and say, look to somebody, his name's slipped my mind, the guy who writes testing framework, or testing library. So it's better to defer to someone that came and say, look, go and have a look at what the recommendations are from people who sort of make this their core goal rather than to try and educate as part of building something that's not really related to this at all.
[00:38:30] RH: That said, like in a situation like yours, maybe it makes sense to make it easy for you to do testing of your endpoints separately from testing your components. Because if that's where all the heavy lifting has been done.
[00:38:42] A: But let's not also forget, like my applications, when I say the front end, I'm talking about everything that Sapper serves. So my testing in logic is in my happy application, it's in my in my API, I don't really have that many server routes. It's a tough one. My API is covered in tests. My front end is definitely lackluster in terms of testing. It's got a few unit tests, and not much else.
[00:39:04] RH: Yeah. And there is a cost to having a default, because most testing setups, like they'll need something like Puppeteer or Playwrite. And these are big dependencies. So if you're starting a new project, then you've got to spend several minutes installing all that junk before you can start developing. If you're going to use that then fine. But if maybe you're not going to use that, then do we want to impose those opinions on people? I don't know.
[00:39:27] A: And you’ve got browser support and it could be flaky, you know, different, we find the Svelte tests are actually quite flaky on various browsers, on Macs and things like that. And on Windows machines, you've got to worry about that. You've got to have an infrastructure for running the tests. All this kind of stuff is stuff that we really can't define for somebody, I suppose.
39:45[00:39:45] KA: I guess the Svelte team doesn't have to decide for people, there’s something that we can do is send people to relevant pieces of information wherever we can find it. Mainly because I've seen people reject Svelte out of hand because they're like, “Oh, look at them,” and they've been like, pointed to that specific [inaudible] FAQ that kind of just does this like [inaudible] a little testing. Yeah, it's honest. It's just like people like to be given the full package. And sometimes it just takes it a little bit of better communication sometimes. So yeah, we can work on that.
[00:40:15] RH: I love testing. And it should be absolutely forefront of everyone’s mind all the time. And I absolutely endorse it. But yeah, it's just not something that can be answered quickly or even well, really, in this context. So I agree, FAQs and documentation would be a good place to start.
[00:40:32] S: So in Sapper and SvelteKit, we have the router, is that changing anything?
[00:40:38] RH: No, it basically behaves exactly as the Sapper router does. We're not changing anything there, which is one of the reasons that it's going to be fairly straightforward to migrate your application. People do keep asking is, “Is this going to be a standalone package that we can use outside SvelteKit?” The initial answer is no, the medium term answer is maybe. There is some complexity around that, like you need to have a good way to. So it needs to work server side and client side, right? And at the moment, because Svelte server side rendering is synchronous, it makes it a little difficult to work with, you know, a manifest that includes dynamic inputs and stuff like that. So there's just a lot of complexity and nuance that we need to work through before we can offer something that can be decoupled from the rest of the SvelteKit CLI.
[00:41:24] A: I think when I build projects a lot, I tend to build a [inaudible] of it first. And the boundaries between the different components are always sort of logical boundaries in my head, and in the code. And they're not necessarily physical boundaries, or different projects or modules. And I think probably the same goes for what we're doing here is that there's definitely a notion in our heads that we want to have the router as a separate component. It isn't right now, it is as Rich said, very difficult to do. But every bit of work we do towards the routing, we are consciously thinking, is this isolatable? Can this be separated at some point?
[00:41:58] S: One other big topic is the internationalization support, and it comes up a lot, right? What are we looking at on that front?
[00:42:09] RH: That is not a problem that we're going to solve for 1.0, that's still going to be a problem that app developers have to solve themselves unfortunately. It's a big and complex and fascinating topic. And when we first started talking about it in the context of Sapper, we generated a huge discussion about the best way to do stuff. I maintain my belief that a project structure like SvelteKit’s, gives you the opportunity to do some stuff with internationalization that is ordinarily quite difficult. But we are just not focusing on that for 1.0 release. Because if we do, it'll be a 2022 release.
[00:42:49] S: It also has to be something that someone wants to work on. Right? There has to be interest there right?
[00:42:56] RH: I think that there is interest, it's just it's a ‘too many cooks spoil the broth’ type situation, we've got to have a very clear direction that we agree that we want to go in, we can't just sort of open it to the floor and say who wants to work on this? Because we'll end up with absolute chaos. And there's there's a lot of overlapping problems involved, like the routing side of it. Also, how do you express localize text inside your components? How do you generate that localized text in the first place? Like what format do you use? Do you support multiple different formats of localization? There's just so many questions that we need to have good answers to, and we need to decide how opinionated we're going to be in our answers to those questions.
43:38[00:43:38] KA: I have an ending question, if no one else has any other topics that they want to raise. What's on everyone's wish lists for Svelte in 2021?
[00:43:48] RH: Oh, wow.
[00:43:48] A: I mean, that it exists.
[00:43:52] KA: I think that will be achieved. So, setting your bar high there.
[00:43:59] A: You know, manage your expectations I guess.
[00:44:02] RH: I definitely think it will continue to exist. We've talked about how we would love for the Svelte community to be more diverse. We are very typical of an early adopter focused open source project in which you know, our user base is unfortunately slightly homogenous. And, you know, if we can find a way to reach people who aren't currently using Svelte, that don’t look like us, then that would be a wonderful thing. And I think it would be the benefit of the project's health overall.
[00:44:33] KA: Yeah, I was gonna raise that. I got to think of something else.
[00:44:37] S: I think it's kind of tangential, I'd like to see more accessibility features in Svelte, things like maybe high contrast warnings.
[00:44:48] RH: So this is the kind of thing, I hadn't thought of this at all until you said it just now but this is exactly the kind of thing that having a central officially supported project structure like SvelteKit, kind of allows you maybe to do a little bit more reliably, because you can, you can say in a very predictable way, like, this is how you build the application so that you can serve it and inspect it using Playwrite or whatever. And you can't do that if the project structure is completely arbitrary. But if we can say that the majority of our users are going to be using SvelteKit, then that is exactly the sort of thing that we can start thinking about adding to the developer experience.
[00:45:27] S: I'll plug Kevin's favorite topic here, Svelte actions. I started actually prototyping a little, you know, project, just just to see, just to achieve consensus on what people think would be nice as official Svelte actions, things we all use a lot like onClick Outside, we all have some version of that anytime we write a model. And then I already forget what else, long press would be interesting for mobile web. Yeah, stuff like that is stuff I'm accumulating. And so there is an RFC. I took a stab at prototyping it. And you know, maybe you will see it merged -
[00:45:59] KA: I actually thought about an action for focusing on an input, it would be pretty sweet, focus on loading the page. Anyway.
[00:46:10] A: Isn't that the antithesis of accessibility? I think it's like that's the opposite of because I know that the problem if you focus on that attribute, then it's unexpected for users who aren't using keyboards or something like that, I can’t remember the exact rule.
[00:46:21] RH: I think you want to avoid auto focus when a page first loads, because people who use keyboards to navigate will expect the focus to be in a different place. I think it is okay to use auto focus in content that is created dynamically. Like if you create a new dialogue, then it's useful to focus the input in that dialogue immediately. But the accessibility rule sort of does this blanket, “You can't do that,” when you add autofocus to an input, which is, I often find myself adding the ignore declaration.
[00:46:52] KA: It’s there in HTML. Why would they put in an HTML if it were not supposed to use it?
[00:47:00] RH: Left hand right hand.
[00:47:02] S: This is what would be nice, with more accessibility warnings. It would help me stop myself from doing stupid stuff like this.
[00:47:10] KA: I would also say like inside the Svelte code base, I think there's a lot of to do's left on the accessibility stuff, right?[00:47:17] RH: Yeah, I mean, the biggest one is like when you do have, well the biggest one for me is when you do encounter an accessibility warning, like if you add autofocus, you will get a warning, but it's not at all clear how to disable it. Like you sort of have to know about the like, what the warning codes are, which we don't expose anywhere. And it's not very well done. We need to fix that.
[00:47:36] KA: All right. All right. To do list. Let's go on to pics if you have any. I can start. I got myself a robot vacuum machine a couple of days ago.
[00:47:45] RH: Oh we can see it over your shoulder.
[00:47:47] KA: Yes, yes, exactly. Best purchase I've done in years. Love it.
[00:47:53] S: Do you go barefoot in your home? Or are you -
[00:47:56] KA: Yeah, I do.
[00:47:36] S: No wonder.
[00:47:36] KA: I think it's a American thing to like, always wear shoes in the house. Or at least like non Asian thing. I don't know. Yeah, like the Roomba just cleans up things that you would already have on your floor. Anyway, I don't know what I'm saying but -
[00:48:13] RH: Does that not rob you of the joy of vacuuming though?
[00:48:17] Joy of vacuuming. What? What joy?
[00:48:22] RH: Vacuuming is by far my favorite chore. Because you get such a sense of accomplishment. I have one of the battery powered Dyson's which takes a lot of the hassle out like you know you don't need to bend over and like unplug it and then put it into the new socket in the room that you're doing now. I just walk around with this battery powered Dyson and you collect all of the dust off the floor and then like you look at it inside this transparent cylindrical container and you feel a real sense of accomplishment. I think if I had a Roomba I wouldn't get that that pleasure once a week.
[00:48:54] A: My wife shows me that right, so we've got, we've got the Dyson too. We've got two of them, one for upstairs, one for downstairs. And what she does every time she uses it she comes in and shows me all of the dirt that’s in it, like it’s some sort of like award. I don't understand it. But now I kind of get it. It's not just her. People do this and are entertained by it [inaudible]. I do however, I will say that I hate vacuuming. I really I don't enjoy any chore really, but especially vacuuming. I do have a Roomba as well. And one of the good things well [inaudible] the fun thing is taking apart after it's done a few cleans and pulling all the hairs out of it and cutting all the bits of it. That's satisfying. That's absolutely great fun. I can sit there for like an hour, taking it apart and pulling all the bits of stuff and hair. It's great fun. Great fun. So you have that joy to look forward to Kev.
[00:49:46] S: I got a new phone recently, and I'm quite enjoying. My old phone, I had the Pixel two XL and it served me pretty well but the screen was like smashed up and it was just dying and everything. So I asked people on Twitter what phone I should get between some Samsung Galaxy, whatever the newest one is, or the Pixel five, or the One Plus 8T. And the Pixel five was the overwhelming favorite. So I bought the One Plus 8T. And I've been very happy with it.
[00:50:14] A: You made the right choice.
[00:50:17] S: Yeah, I made the right choice. Yeah, Anthony was one of the people who steered me towards, I think maybe you actually sent me a YouTube review of the One Plus 8T in comparison with the Pixel and it’s just much better phone, or somebody did, and it convinced me, it's really high powered. And it costs the same as the Pixel five. And it has this sort of nice, turquoise, shiny case on the back, just a very well put together device. So if anyone needs a new phone, then check out the One Plus range. I’m not paid to say that.
[00:50:49] KA: Actually, so I moved. I have used, I used iOS, I used Apple iPhones for 13 years since launch. And I switched to Android in February. And I went through the same rabbit hole and I landed on One Plus as well. It was the 6T because I'm cheap. I think my conclusion between Pixel and One Plus is that like Pixel, just randomly, like prioritizes camera over everything else, no matter what it has to have the best pictures, but I don't take many that many pictures. So that's what made me choose the One Plus which is you know, have better specs for everything else. And a decent good enough camera. And I think that's the way -
51:24[00:51:24] RH: Yeah, I actually bought a decent camera recently, like one of the new mirrorless ones that is like the DS, the old DSLR, but a little bit smaller. And so now when I go somewhere I want to take photos, I will take that with me. The image that it produces is just so much better than what you get out of a phone camera, that I'm not taking as many pictures with my phone anymore. So it was the same thing for me. It's just not a priority. I think that phone cameras have sort of slightly cheapened the art of photography. And I refuse to participate in this nonsense.
[00:51:55] A: I will say that I, I went the other way, I had an iPhone 1 originally, I then switched to One Plus and I had my, I bought One Plus One. And it was stupidly cheap. Because it was when they first launched, they were just basically free almost. And it lasted me six years. And I couldn't actually make it break in order to get a new phone. It's amazing. It just slowed down a bit. And they’d stopped making the OS for it. And I switched to iPhone. And the only thing that's good about this is the health thing with the watch. It's really good. But I miss the Android. And the only reason I’d go back is to go back to a One Plus. The browser on this is terrible. Safari is just a joke, it’s useless. So I'm very much of the opinion now that I might look at Android again.
[00:52:37] KA: It's a trade off. My summary is iOS is the better operating system. But then Android has the better browser. So pick your poison.
[00:52:47] S: They're both pretty locked down. Right? I guess you can sideload on Android.
[00:52:51] Android you can kind of choose what you install. And I think One Plus are very good for actually having customer [inaudible] and stuff. Their phones will take quite a lot of stuff without a lot of modification, they’re a very generic kind of hardware. Well at least they were when I had one.
[00:53:03] KA: I've been using a new calendar app, Savvy Cal. It’s by a friend, Derek Reimer, he’s sort of trying to make his make his way in terms of like, indie hacking his own business, and I kind of bought it as a way to support him, but then it actually turned out really good. So it's exactly like Calendly except that it's indie and it looks different. I always get compliments on it whenever I drop a link to people. And I think that a lot of people don't do that. So they do they always do the back and forth emailing or like, “I'm free at least three times. Can you make any one of these?” And it's just better if you just give them a choice. I've been enjoying it. And he's got some like nice, pretty nice team features coming in, which is which is exciting for my team.
[00:53:42] RH: This looks this is good. Actually, this looks perfect for what I need. Nice. Nice pick.
[00:53:46] A: I think my pick has to be Begin.com. I mean, I said it before, right? I'm really enjoying it. I really like [inaudible] architect. And I really like the fact that it's got built in data. I've started building a small project on it just to see, you know how that actually works. And it's pretty great. It's a pretty great experience. So yeah, that's my pick.
[00:54:04] KA: I mean, Brian's a friend, we should try and have him on to chat.
[00:54:08] RH: I like products like that where like you know the people who build it. At least a little bit.
[00:53:13] KA: Yes, so you can yell at them.[00:54:15] RH: Yeah, but also, so you kind of have a sense of their product philosophy, and whether it's something that you align with.
[00:54:24] S: Yeah, it's more relatable, right? Yeah. Thanks for coming on, Rich. Always fun to hear your thoughts. Thank you everyone for listening. And we'll talk to you in a couple of weeks again.
[00:54:38] Bye. Bye.
[END]
Some topics that we discuss:
- Release date
- SvelteKit vs Sapper
- Features
- Adapters
- Ideas about what is next
If you missed the talk at Svelte Summit check it out here.
Picks:
- Robot Vacuum
- OnePlus 8T
- SavvyCal
- Begin.com
Transcription:
[00:00:00] KA: Hello, everyone, welcome to another episode of Svelte radio. I'm your host, Kevin, I run Svelte school. And today we have a very special episode, we have the creator of a Svelte, Rich Harris. But before he gets to introduce himself, we'll kick it off with our other hosts.
[00:00:19] S: Hey, I’m Sean, work at AWS on random stuff, including trying to get Svelte into AWS and that is an ongoing mission.
[00:00:30] A: Hi, I'm Anthony, and I'm the CTO of Biank. And also Svelte maintainer.
[00:00:35] RH: And I'm a graphics editor at the New York Times currently working on SvelteKit.
[00:00:42] KA: Whoo, cool. The new shiny thing before we get started, how are you? How's everything with the election and all of this stuff? How's the workload?
[00:00:50] RH: For me, thankfully, it's settling down. Last week was quite a busy week for everyone. Certainly in the graphics department at the times and probably in the organization as a whole. It's very difficult to avoid getting sucked into the madness. But you know, what is fun? There's no better place to witness history than from a newsroom, even if it is a virtual newsroom scattered around people's homes.
[00:01:10] KA: Something I didn't didn't appreciate about your election coverage is that you're actually spinning up visualizations fairly quickly based on what counties or states are in focus at the time. Like, there's some parts of this that you could not have prepared beforehand, right?
[00:01:26] RH: Yeah, there's some sleight of hand, you know, you prepare for a variety of different outcomes. But yeah, like, as soon as the results start coming in, the politics editors, and the graphics editors who are covering this, are bashing their heads together and trying to figure out what is the story. And then that kind of filters down to the people making the charts and maps. And we all come together, we analyze data, and we try and figure out what just happened. There is some infrastructure that's already built out, because you kind of know that people are gonna want to know which parts of the country swaying in one direction. But yes, a lot of it is kind of rapid response, data visualization.
[00:02:05] KA: So you've got Lego blocks for building visualizations that will tell you population, this area voted this way or whatever, you've got that sort of stuff?
[00:02:14] RH: Yeah, like you know that you're going to need a lot of demographic information about counties, like we know that the results are going to be coming in per county or in New England it’s per township, because they like to do things differently. And you just have all of the data that you might possibly need in a massive spreadsheet at a time. And then you can also plug it in to make something relevant.
[00:02:37] KA: Alright, so we're not here for the election. We're here for something that's more exciting.
[00:02:48] RH: That’s certainly, perspective
[00:02:51] KA: For sure. So we're going to talk about SvelteKit today. So before we dive in to the questions, what is SvelteKit?
[00:02:59] RH: SvelteKit is, in one way it's a successor to Sapper. And you could even think of it as Sapper 1.0, if you like. But in another larger sense, it's our kind of vision for the way that you should build Svelte apps in future. It’s something that we've been kind of talking about in a peripheral sense for a long time, we've been talking about how we can evolve Sapper to take advantage of some of the recent trends in front end development, particularly the rise of serverless. And more recently, the rise of unbundled workflows, which I'm sure we'll get into later. But it all sort of came to a head recently, you know, the pace of development on Sapper had hit a bit of a low, at least until Ben McCann really picked up the baton and started churning through issues. And people were getting a little bit frustrated, I think with the progress. And Anthony is one of those people because he uses Sapper very heavily in his job. At a certain point, we're like, “What if we just started from scratch?” Like the big rewrite, as opposed to trying to get all of these ideas into what was honestly kind of a watery codebase. I sort of proposed this very hesitantly in the discord thinking everyone was going to yell at me. And instead everyone was like, “Oh, yeah, let's do that.” And so that was sort of the germ of the idea. And then over the last, I guess, month or so, the idea turned into a prototype, and the prototype turned into a project with a name. And I was, I guess, reckless enough to announce it at Svelte summit as a thing that I was working on. And then at that point, it was like a de facto, this is what we're doing. Now. This is, this is it. So now the whole team is full steam ahead. We've got some new contributors as well, people who haven't previously been on the Svelte core team are helping us out. Andreas [inaudible] is one of them and Dominic who created Sleet helping out in the repo and it's actually looking good.
[00:05:00] A: I think that probably the alternate version of that story is that Rich claimed to going on holiday, he went on holiday, he came back a week later and SvelteKit appeared. And then we spent ever since bikeshedding the name.
[00:05:15] RH: I promise I didn't do it on holiday. I would have been very sad, I had a really nice break. And if I'd spent it in front of a laptop, I'd have been very unhappy with myself in trouble. It's just the way these things right, the first 80% of a project is you can build it pretty rapidly. But then once you start to get into the details, that takes the remaining 400% of the time. And that's the situation that we're in at the moment.
[00:05:15] A: The modified Pareto principle.
[00:05:41] KA: Obviously, I'm not so steeped in the history of Svelte as much as some other people here. But I feel like this is something that happens every now and then in rich land. This idea that a big rewrite would update just a lot of the core assumptions and change the design to something that is much more enjoyable. Is there like lessons that you learn from you know, having done things like these, for example, going from [inaudible] to Svelte? And then from pre Svelte 3 to Svelte 3? I thought that these are pretty major bumps. Right?
[00:06:09] RH: Yeah, I mean, I guess the main lesson that I've learned is probably that it is a good idea. Because software, it grows organically, right? And there are layers at the bottom, that very often don't make a lot of sense anymore because things change, especially in the front end world, things are changing all the time very rapidly. And we started sick of dealing with a legacy code base, but because there's actually a new foundation that you want to build on top of them then it is worthwhile. But at the same time, I have also learned every time I've embarked on any kind of big rewrite that it is going to be so much more work than you anticipate. Because the old thing that you're replacing, it did a lot of stuff. And you're, the new thing needs to do all the same stuff.
[00:06:59] KA: Just better. Yeah.
[00:07:02] A: It’s also I guess, we're sort of building in parallel with Sapper, it's not like we’ve just abandoned Sapper completely. Sapper is now in I guess, in the kind of maintenance mode although it's not really officially announced yet. We're adding to it as we go. And the issue of course there is any new stuff or fixes you put into Sapper have to be then ported across to SvelteKit. So it's actually keeping track of that as well, actually, it's actually quite difficult. So it almost inhibits us, it makes us try not to do too much on Sapper, even though we need to keep it going.
[00:07:32] RH: Yeah, and that plus, you know, psychological factors, I think, really driving us to get this work done as fast as we possibly can, in spite of all of our schedules, we really want to get this done sooner rather than later.
[00:07:45] KA: Speaking of getting this done. Are we talking hours,days? Try it for real.
[00:07:59] RH: The one thing that I've said about timing publicly, other than I'm not gonna say anything publicly about timing, is, I think we're looking at weeks rather than months, I would be disappointed if we didn't have a public beta or beta, we've had a long conversation about how to pronounce that word, sometime this year, which gives us just under two months to the public. And then, you know, a 1.0 version is gonna be a little bit longer, it kind of depends on what people find, when they first try it out. And if there's all sorts of bugs and use cases that we haven't considered, then, you know, might push things out a little bit, but you know, hopefully, early 21, we're going to have it stable.
[00:08:47] A: I think also that the reason that committing to an ETA isn't really possible, really even giving that rough guideline, Svelte has no full time maintainers. It has people who have real jobs in the real world who do this in their spare time. The advantage to that, of course is that you know that everything that's going into Svelte and Sapper and SvelteKit, and everything is people's passion, and it's stuff that people want to do, not stuff that they feel is a chore or that they're paid to do against their will or anything like that. It's really a product of passion. And I think that gives it an advantage over something that's maybe run to a sort of an expectation or a schedule or a more official, [inaudible] call it company I suppose.
[00:09:32] RH: Also no ivory towers here, everything we build is driven by very real world practical needs.
[00:09:39] KA: Now that we know what SvelteKit is and when we can expect it, should we get into some questions? I think the first one that most people that are coming from Sapper are wondering about is what about migration? How easy or hard will this be?
[00:09:54] RH:Yeah, so one way to think of it is imagine that we did put out a Sapper 1.0 and we’ve said all along that there's likely to be some API changes between, like, where are we now Sapper 0.28 and Sapper 1.0. And every time we've released a new version of Sapper we've had a migration guide that sort of walks you through the process, it's actually not going to be any different from that. There are some changes that we have to make because we're embracing serverless is this first class idea, but like the bones of the project are going to be relatively unchanged. And so we've been migrating some of the existing sample sample projects like our Hacker News clone and our Real World clone, it's not that much work. Because your file structure continues to represent the structure of the application, we have the same file name convention for dynamic routes, and all that sort of thing. Things that have changed, let's go through the list. Previously, you would have had a custom server.js, because the expectation was that you're going to be running a node server, or you're going to be statically exporting the entire app, we can't make that assumption anymore because there isn't going to be a server in the traditional sense, there's going to be a set of serverless functions.
So right now there is no function that will run for every single request, other than the function that generates the session context, which like, includes your user information and stuff like that. And so you can't use things like Express middleware, and stuff like that, which you might have been using before. As things stand like all of this is, you know, subject to change, if it proves that there are a lot of things that people just simply cannot do without having a custom server. But right now, we're trying to lean as far as we can in the direction of being like fully serverless. On the same note, your endpoints, so we used to call these server routes, which has a bit of a funky name, we're now taken to calling endpoints, which is to say that if you have a file like sourced/routes/foo.js, that will respond to requests to the slash foo. And inside that, your handlers no longer take the request and response object that you get when you're dealing with notes HTTP module. Because if your on an ADLS lander environment or something like that, then you don't see those things, you are given an object that represents the method and the headers and the body and everything like that associated with the request. And your job is to return an object that contains a status code, some headers and the body.
And so we're basically adapting to that surface, which means that you will need to write all of your endpoint handlers, we might change the preload signature. And we think that we can probably improve that a little bit. And a lot of people don't like the fact that you have this inside your preload functions. And so we might fix that. But everything else is just a few little cosmetic bits, bits and bobs here and there. If you have a very complex build config, like if you've changed the Webpack config, or the roller config in your project, then you'll need to find some way to represent those changes in the new Snowpack config. But that's about the extent of it, I think.
[00:13:08] KA: Something I am a little bit vague on is so we're splitting things up from a single server to multiple serverless functions. Do we have fine grained control over which of these are statically rendered? Or which of these are dynamically rendered? I don't know if that's the term.
[00:13:23] RH: We do. So there is this concept of pre rendering that can apply to all of the different adapters. We'll explain what adapters are at some point in this episode, I'm sure. And essentially, what that means is that as the functions are being built, we can pre render a subset of the application as static files, and they will just get dumped on your CDN wherever. And then when a request comes in for one of those static pages, it will just retrieve the pre rendered HTML, which is great, because there's no work to do. Having said that, I don't know if you've been following what Remix are doing at the moment? They have a conviction that static site generation is a waste of time. And actually, we should be dynamically pre rendering everything but using cache headers in such a way that it is as if you had statically the pre rendered everything. It gives you the benefit of the dynamic rendering, but without the downside of pre rendering, which is that if you have a very large site, it might take several minutes to pre render all of your pages. So you can sort of amortize that cost over the life of the app. That's a long winded way of saying yes, we do have pre rendering, but also we're kind of thinking about whether that is the right direction, and there's more exploration warranted around that topic.
[00:14:42] A: I think it's a very interesting direction. Yeah.
[00:14:44] KA: I had a question about like the, so in other frameworks like Next js. you have this gets static props thing, for example. I guess this touches a bit on that. So prefetching data at build time.
[00:14:56] RH: Yeah, well Next has get static props and get server side props. If you have a static pre renderable page, then you call one function. If you have a dynamic render page, then you call a different function. We're not doing that, we just have one consistent way of pre loading data, whether it's a pre rendered or not pre rendered route. And the way that we differentiate between pre renderable pages and non pre renderable pages, is you just export a Boolean. Export cons pre render equals true. If that exists on a given page, then the adapter can know that it can pre render these pages. And you don't need to seed it with the pages that are pre renderable. Because it can just look at the route manifest that it generates and identify the statically rendered pages for you. I think is the same idea. But I think the implementation is a little bit simpler. As far as you know, offering an app is concerned.
[00:15:51] KA: I think, this idea, especially, you know, just thinking about the caching stuff, if you go down that path, it would mean that you basically a very predictable build times because you don't essentially don't have to build your pre rendered page, they would just get pre rendered on request, that'd be an interesting solution, it would change it from like, O of n to like, maybe O of one. But then I think it's also one of those things that's very contentious, because it's just not a norm to set cache headers in a lot of JavaScript frameworks. It's definitely a bit on Ryan and Michael's side of things. And it's something that so having worked in Nullify, myself, Nullify does stick to the fairly strong view that people don't never, they either never set cache headers, right. Or they tried to do it right. And then the first set of problems, they turn it off, and then they leave it off. Because that's that's the way you solve problems with cache invalidation, you just stop caching. It is an upcoming struggle, I feel like that that we're really going to see play out because of all these frameworks exploring this space.
[00:16:51] RH: It is. My guiding light around caching is a blog post that Jake Archibald wrote a while back, in which he basically says there's two reliable ways to set cache headers. One is the content is immutable. It has, like some unique identifier in the file name, like a hash of the contents. And then you can treat that as immutable. Once the browser has it, they can hang on to it indefinitely. because nothing's ever going to change. And that's guaranteed. The alternative is, you're going to need to check everything with the server. And the server can respond with a 304, which means nothing has changed since the last time you had this file. So you can use the version in your cache. But you still need to check everything with the server.
And anytime you start to get into or maybe you can hang hang on to this file for a little bit, then don't check for like the next 10 minutes or something. Inevitably, you start getting a mismatch between, you know, you've got some resources cached and some other resources that relate to that resource, uncashed. And it gets out of sync. And this is, this complexity is magnified when you have a server rendered page, which is cached for a certain amount of time. And then if you if you navigate to that page client side, and the framework is just getting the data for that page, instead of the page itself, then that JSON file or whatever it is, will have a separate cache lifetime. And so the server rendered page and the client rendered version of that page will be out of sync. And even Remix doesn't have a solution to this problem, it is a really tricky thing. But I think what Remix is doing is pretty smart. After talking to Ryan and Michael a little bit about this, it turns out that what they're doing is they're actually controlling the deployment as well as the generation of the files that get deployed. So their equivalent of our adapters, they are also responsible for invalidating caches on the various platforms, which is how they're able to have this level of granular control. Whether it's worth thinking about adapters in SvelteKit in the same way, that they should be responsible for deployment, as well as just for building, is something that we probably need to think about. I think
[00:18:55] A: I think also, if you're generating a lot of content up front, and then you know, static, generating content, and then you're deploying that content, and then someone changes what their contents based on, and then you have to rebuild the whole thing, you're going to have that build delay, whilst all that content is rebuilt anyway, unless you're gonna have a way to build them one by one, which should be very quick. So if you're rebuilding all that content, every time someone makes a change, then that's basically the equivalent of having a long cache on some stuff and having stale content rendered to the browser. So I don't think either is a silver bullet. It's definitely an issue that needs a lot of thinking about.
[00:19:32] RH: Yeah, it's one of two hard problems in computer science.
[00:19:34] KA: Right. So TypeScript support, of course.
[00:19:39] RH: Yeah, we're gonna have full TypeScript support when we launch, you know, whatever your definition of full TypeScript support is like, we'll have the ability to set up a TypeScript project when you do [inaudible] in Svelte it already, in fact, asks you, “Do you want this to be a TypeScript project?” And if you hit yes, then it will add TypeScript to your package. It will convert the example component to have Lang equals Ts, give you a Ts config, all of that stuff. And it just kind of just kind of works. There's other little nuances about how we incorporate Svelte check into this setup. But the short answer is yes, TypeScript will be supported. We're not making the mistake this time.
[00:20:21] A: I think you've also, you've also touched on another point there, that SvelteKit has a CLI, and it has a config file. And that's there's two things that originally we considered to be a not not a good thing. And now they are sort of, they’ve become part of what we're building. So might be interesting to talk about why?
[00:20:41] KA: Maybe back up a bit as to why do you get in the old case?
[00:20:44] RH: Yeah, so for a long time, we kind of rejected CLI’s in favor of just plain old template repo. And that's your project. To make that easier. We have this tool called DGIT, which essentially clones a repo without all the history, and has some like nice stuff around discovering the repos that you've already claimed in the past, so that you don't need to type it out each time. And it will do offline caching and stuff. But it's basically just cloning a repo and then deleting the docket folder. And that's nice, because you're really, you're showing your work, there's no, there's no magic, there's no, like if you do a Create React app thing. And then at some point, you're going to stray from the happy path and you're going to need to eject from your Create React app setup. And at that point, you're on your own. And what was formerly this relatively self contained thing just kind of splurges all over your file system. And it's just a, it's a very confusing experience. And so we've felt quite strongly that it's better to just give someone some files and say, this is how they interact with each other, if you want to make changes, go nuts. And that way also people can, they can make their own base repos. Like if you spin up a lot of projects, then you might have some opinions about how to set that up about how to do tests and this, that and the other. And so you can make your own repo which is based on ours, and then you've got a project template that you can clone just as easily as cloning our own.
But we are introducing a CLI and I think that is largely motivated by the TypeScript thing, if I'm honest, because we've got a situation now where once you clone the Svelte template, you have to sort of run a command that sets up TypeScript. And if you look at the script that does it, it's, it's like breathless, like it's very clever, and it works. But it's also kind of messy. And if we're going to start adding stuff like that, if we're going to have questions about how you want to set up your project, then I sort of think that we need to be in control of how that project is initialized a little bit sooner. And it's also just people know what npm-init aoes, people are familiar with that. So the fact that you'll be able to do npm-init in Svelte, without installing a single thing, that will give you a Svelte project, and you can get started really quickly. I think, I think that's neat. But you'll still have the ability to DGIT from a repo that you maintain, if you have specific requirements. I think it gives us the best of both worlds, gives you a really nice onboarding. But we're still not going down this whole messy eject or don't eject route, that some frameworks seem to like.
[00:23:39] KA: So this config file. So that's where you would define your adapter, your pre processors, all of this stuff?
[00:23:48] Yes, yeah. So that's another thing that we resisted for a while having a Svelte config file, because config files have a way of getting a little bit unwieldy. And so we sort of said, maybe, let's put the brakes on this and not have a config file just yet. But then what happened, of course, was people in the community, thought, “We want to have a Svelte config file for our tools.” And so people created incompatible Svelte config files. So you know, you have one in the Snowpack starter project, you have one in the Parcel plugin, and they are fundamentally incompatible. So we sort of had to come along and say, we're laying down the law, this is what a Svelte config file is going to look like. And now that we're having this, like official way, like this is how you build Svelte apps, we have a SvelteKit and this is the officially supported way to build Svelte apps. It's less of a problem to have a Svelte config file because the project structure is already just kind of more predictable and more understandable if that makes sense.
[00:24:49] KA: Speaking a bit about adapters. Can you tell us anything about which ones are going to be coming at launch? Like which ones are you excited about having?
[00:24:58] Also what adapters do? Because Yeah, I myself don't really know?
[00:25:03] That's a good question.
[00:25:06] RH: You've got two choices, you can do Sapper build, which will create a node server that serves your app. And then you have to find the platform that can run a node server. And that's harder now than it used to be. Like, for example, before [inaudible] now v one, you can just run a node server. And that was great, really easy way to run a Sapper app. Now v two comes along, and you can't do that anymore, because they're gone fully serverless. So that's like a, an indication of the sort of direction in which things are going. Sapper Build was designed for the world formerly existed, Sapper Export, on the other hand, would build your server, it would then start your server and then it would crawl your and make out what it found.
There was no in between, between Sapper Build and Sapper Export. Now, we want to be able to say some pages are pre renderable, some pages are not pre renderable. And so that means doing things in a slightly different way, at the same time, we want to be able to generate Cloud Functions that run on Netlify, or Vercel or Begin or any of these other platforms. CloudFlare Workers. Yeah, that's another big one. It's difficult for the framework itself, to be able to satisfy the competing demands of these various platforms. So one of the big changes in SvelteKit relative to Sapper is this concept of adapters. The way that works is when you build your site, it happens in three phases. The first phase is we run it through Snowpack, which is what powers SvelteKit. And that will generate what we call the unoptimized build. And that's just like a one to one transformation of the files in your project. It'll do it twice, once for the server side rendered version of your app, once with the client side rendered version of your app. We then move on to phase two, where we optimize that output, we run both of those applications through roll up that allows us to do things like bundling things into coarse grained chunks, which are better for loading performance, we can extract CSS from your application and write it out as static CSS files. And we can generate the manifest that allows the Cloud Functions to know which code they need to load in order to render the page that's being requested. And so after that, we've got something that is pretty agnostic and doesn't actually do anything yet. So we we applied the adapter to it as a final step, which takes the optimized build and massages it into the form required for the various different platforms be that a node server or a purely statically exported site as with Sapper, or one of the higher function providers that we're going to support. You asked what we're going to support at launch. We don't have like a list yet, but you know, definitely Vercel, definitely Begin, definitely Netlify, definitely CloudFlare Workers, I think.
[00:27:57] KA: I'd be happy to help pitch in support forAWS.
[00:05:00] RH: Definitely AWS Yeah,
[00:28:02] A: It's worth noting, yeah, that a lot of people have come forward and say that they'd like to build an adapter for their platform of choice. And I think that's, that's a great thing. That's a really fantastic thing. The list that we have right now it started off with Rich building the Netlify one, I built the Vercel and Begin ones based on what Rich did with Netlift because, well Vercel was easy, because I'm already hosted on it. And I wanted to work on there. And I want to see how much work it would be because I helped build the original Vercel builder as well. And the Begin because I mean, it’s my pick, Begin.com is my pick, right? I really like what they do with architects, I really like the fact they have data built in. I really like that kind of stuff. And so I just wanted to see how quick can I get this new thing running on this platform? And how different is it to, to Netlify, for example? And it actually is not that different at all. And that's quite nice thing about adapters they are, they're all turning out to be roughly along the same lines, which is really interesting. Those lines are [inaudible] underneath it looks like so it's pretty straightforward really.
[00:29:03] RH: Yeah. So in addition to these official adapters that we're talking about, there's going to be a well documented API for people to build their own adapters. So any platforms that we don't support, people will be able to support them themselves. And actually, there is a conversation happening about how much stuff we want to do ourselves and how much we want to farm out to other people and let them maintain it. But the API is very much not locked down yet. So yeah.
[00:29:27] A: Hence why we haven't just invited everyone to build
[00:29:31] KA: There's an open question of whether every meta framework like Remix is doing something you know, [inaudible] is doing something, whether every meta framework should have adapters or should every meta framework target a single format? And I may have brought this up with you Rich I don't remember, but Glenn [inaudible] proposed FAB, the front end something application bundle, which are basically containers for front ends and it's a fancy way of just saying let's just standardize what we what we export to so that all the providers know what to ship agnostic of framework and all the frameworks know what to build to. Doesn’t that make sense?
[00:30:08] RH: It makes total sense. And I've chatted with Glenn about this. I should have added that to the list actually, we definitely want to have a FAB adapter for SvelteKit. I'm actually surprised that more people aren’t using FAB, it’s such an obviously smart idea.
[00:30:20] KA: Because he targeted CloudFlare. He was like only CloudFlare. And then that was the story for like two years.
[00:30:27] RH: That's another easy way for us to support multiple platforms is -
[00:30:32] A: I think on the flip side of that coin, of course, and I think it’s fantastic idea. I think the flip side of that, unfortunately, is that you can make something that adapts to everything. But abstraction has a cost. And I think that at some point, you encounter a bit where well, this won't work now, because this radically new, different thing that’s super optimized, won't fit into this pattern. So you can understand why there's there's always kind of a, it's not a silver bullet. Nothing's a silver bullet I suppose.
[00:30:57] RH: [INaudible] outsource our adapters to FAB but because we do want to be able to optimize specifically for different platforms. But it's a great net to catch the things that we can support ourselves.
[00:31:10] KA: I want to move on to developer experience. So this kind of seems like one of the important things with SvelteKit, things like Snowpack, and the adaptors I guess, are also part of that. What are some pain points that you'd like to explore in the future when it comes to bringing the developer experience even further along? Not particularly anything to do with SvelteKit, more like just general thoughts? Hmm. Wow, that
[00:31:39] RH: Hmm. Wow, that is a big question. That I think SvelteKit represents a big upgrade in developer experience from Sapper, just because the Snowpack developer experience is so good. For people who haven't tried it yet, like it's worth just trying out one of their sample projects so that you can get a sense of, of how the thing works. It doesn't have any of the delays that are involved in traditional bundlers at development time. And it also has some really nice features like it has error overlays. As soon as there's an error in one of your files, you'll instantly get feedback in the browser, you don't need to have your terminal visible at the same time as you're developing, it just gives you way better feedback. The hot module reloading is really robust in my experience, it's just great.
But I think it does open doors to potentially some future improvements that we haven't really begun to explore yet. One of those is the idea of having something like a Storybook type experience built into the framework. I'm not personally a user of Storybook.
[00:32:40] KA: Have you tried Svench?
[00:32:41] RH: I haven't tried Svench yet no, but it's on my list of things I want to play with. Aesthetically, I just can't get on board with the way that stories are written in Storybook. And also, like it takes a little time for a Storybook to get started. But now that we have this unbundled workflow, you no longer need to point your bundler at all of the components that you want to have in your Storybook, because everything is just dealt with at runtime. So I think we could have a built in Storybook type experience that would be really slick and really fast. But then, you know, once you start thinking along those lines, you start asking yourself, why not just bring this stuff directly into your editor? And so I'm also kind of idly wondering about what an integration between, say, VS code and SvelteKit could look like? Can we start to move more in the direction of wiziwig component editing?
[00:33:37] KA: That would be pretty cool. I have wondered because I also faced that frustration with Storybook, we used it at Netlify and a bunch of other open source projects that I contribute to. And yeah, it is way too slow. And that needs to be changed. But the workflow of having independent components apart from your app, so you can develop in piece, but also document and kind of have a live design system, it does make a lot of sense. We all have a source slash components folder anyway, like, let's actually make use of that in some way. I think you're gonna build that as a layer on top, but some people use vim and all that. So it's nice to have a standalone browser version and the browser version, you can just kind of bring into VS code pretty nicely as a VS code extension. And then the other thing to take note of is that people often build their Storybooks as an externally available site, so that people can reference their design systems just for designers and whatever.
[00:34:33] RH: Yeah, and actually, this this is a point worth touching on. At the moment, we have this fairly neglected component template for if you want to build a Svelte component for distribution or component [inaudible] for distribution. You don't get as much hand holding as if you want to build an app with Svelte. And we can change that with SvelteKit. I think that using SvelteKit for building component libraries, or even just single components is going to be first class experience, because we can have this storybook type thing in the future. But even without that, you can build your demo site using the components in your source slash components folder. And you can put that somewhere. But you could also have, we haven't built this yet. And like, we haven't really talked about it even among the core team, but you could have a CLI command that packages out as a component language for distribution as well. And I think that could be very powerful, that could cause a renaissance in component libraries in Svelte and you can do things like pre process all of the components in your components folders to strip out the SASS and the TypeScript, and whatever, so that it's easily importable everywhere. But while you know, keeping the component source otherwise intact, and, you know, we can generate export maps, and all of these other things that are a pain to set up yourself, we can just do it for you.
[00:36:01] KA: Speaking of things that are a pain to set up, testing, so Sapper had a Cypress included right, at some point, I'm not sure if it still does?
[00:36:11] RH: Yeah, it's been removed, actually.
[00:36:15] KA: So what's the idea with testing when it comes to the SvelteKit? Have you guys thought about anything around that?
[00:36:22] RH: We have an issue open for it. Every time we start talking about testing, like, yeah, we recognize the importance of testing. But honestly, what kind of tests make sense to have in a front end project? It's far from clear like, what stuff you are supposed to be testing, we don't want to have some sort of official recommendations that end up with people writing meaningless tests. A lot of front end tests are kind of meaningless. They're just duplicating the functionality of the frameworks and test suite, which is not a good use of anyone's time. So I don’t know, Anthony?
[00:37:02] A: I think, you have to pick the problems you want to solve. And I think for us to determine what a good testing strategy is, is not a problem that we really want to solve or we’re even set to solve. I think a lot of the maintainers especially have different views on what testing is, I'm not even sure now that, I, my view on testing has changed. In the last three years, it's gone from ice cream cones to mountains, and you name it, it's all over the place, it's very difficult to say what a good testing strategy is, it's very app dependent. It's very much about where you are going. I like to build very dumb, thin front ends, and very smart backends. And therefore, I can actually replace the front end or have a native app or anything else like that anytime and not lose the crux of the application. And I think that it does almost make a lot of acceptance testing extremely costly. Because you're writing tests for something that you effectively throw away. It's almost a waste of time to throw the front end away or make some drastic changes to the workflow. I think it's one of those things that it's easy to pull out and say, look to somebody, his name's slipped my mind, the guy who writes testing framework, or testing library. So it's better to defer to someone that came and say, look, go and have a look at what the recommendations are from people who sort of make this their core goal rather than to try and educate as part of building something that's not really related to this at all.
[00:38:30] RH: That said, like in a situation like yours, maybe it makes sense to make it easy for you to do testing of your endpoints separately from testing your components. Because if that's where all the heavy lifting has been done.
[00:38:42] A: But let's not also forget, like my applications, when I say the front end, I'm talking about everything that Sapper serves. So my testing in logic is in my happy application, it's in my in my API, I don't really have that many server routes. It's a tough one. My API is covered in tests. My front end is definitely lackluster in terms of testing. It's got a few unit tests, and not much else.
[00:39:04] RH: Yeah. And there is a cost to having a default, because most testing setups, like they'll need something like Puppeteer or Playwrite. And these are big dependencies. So if you're starting a new project, then you've got to spend several minutes installing all that junk before you can start developing. If you're going to use that then fine. But if maybe you're not going to use that, then do we want to impose those opinions on people? I don't know.
[00:39:27] A: And you’ve got browser support and it could be flaky, you know, different, we find the Svelte tests are actually quite flaky on various browsers, on Macs and things like that. And on Windows machines, you've got to worry about that. You've got to have an infrastructure for running the tests. All this kind of stuff is stuff that we really can't define for somebody, I suppose.
39:45[00:39:45] KA: I guess the Svelte team doesn't have to decide for people, there’s something that we can do is send people to relevant pieces of information wherever we can find it. Mainly because I've seen people reject Svelte out of hand because they're like, “Oh, look at them,” and they've been like, pointed to that specific [inaudible] FAQ that kind of just does this like [inaudible] a little testing. Yeah, it's honest. It's just like people like to be given the full package. And sometimes it just takes it a little bit of better communication sometimes. So yeah, we can work on that.
[00:40:15] RH: I love testing. And it should be absolutely forefront of everyone’s mind all the time. And I absolutely endorse it. But yeah, it's just not something that can be answered quickly or even well, really, in this context. So I agree, FAQs and documentation would be a good place to start.
[00:40:32] S: So in Sapper and SvelteKit, we have the router, is that changing anything?
[00:40:38] RH: No, it basically behaves exactly as the Sapper router does. We're not changing anything there, which is one of the reasons that it's going to be fairly straightforward to migrate your application. People do keep asking is, “Is this going to be a standalone package that we can use outside SvelteKit?” The initial answer is no, the medium term answer is maybe. There is some complexity around that, like you need to have a good way to. So it needs to work server side and client side, right? And at the moment, because Svelte server side rendering is synchronous, it makes it a little difficult to work with, you know, a manifest that includes dynamic inputs and stuff like that. So there's just a lot of complexity and nuance that we need to work through before we can offer something that can be decoupled from the rest of the SvelteKit CLI.
[00:41:24] A: I think when I build projects a lot, I tend to build a [inaudible] of it first. And the boundaries between the different components are always sort of logical boundaries in my head, and in the code. And they're not necessarily physical boundaries, or different projects or modules. And I think probably the same goes for what we're doing here is that there's definitely a notion in our heads that we want to have the router as a separate component. It isn't right now, it is as Rich said, very difficult to do. But every bit of work we do towards the routing, we are consciously thinking, is this isolatable? Can this be separated at some point?
[00:41:58] S: One other big topic is the internationalization support, and it comes up a lot, right? What are we looking at on that front?
[00:42:09] RH: That is not a problem that we're going to solve for 1.0, that's still going to be a problem that app developers have to solve themselves unfortunately. It's a big and complex and fascinating topic. And when we first started talking about it in the context of Sapper, we generated a huge discussion about the best way to do stuff. I maintain my belief that a project structure like SvelteKit’s, gives you the opportunity to do some stuff with internationalization that is ordinarily quite difficult. But we are just not focusing on that for 1.0 release. Because if we do, it'll be a 2022 release.
[00:42:49] S: It also has to be something that someone wants to work on. Right? There has to be interest there right?
[00:42:56] RH: I think that there is interest, it's just it's a ‘too many cooks spoil the broth’ type situation, we've got to have a very clear direction that we agree that we want to go in, we can't just sort of open it to the floor and say who wants to work on this? Because we'll end up with absolute chaos. And there's there's a lot of overlapping problems involved, like the routing side of it. Also, how do you express localize text inside your components? How do you generate that localized text in the first place? Like what format do you use? Do you support multiple different formats of localization? There's just so many questions that we need to have good answers to, and we need to decide how opinionated we're going to be in our answers to those questions.
43:38[00:43:38] KA: I have an ending question, if no one else has any other topics that they want to raise. What's on everyone's wish lists for Svelte in 2021?
[00:43:48] RH: Oh, wow.
[00:43:48] A: I mean, that it exists.
[00:43:52] KA: I think that will be achieved. So, setting your bar high there.
[00:43:59] A: You know, manage your expectations I guess.
[00:44:02] RH: I definitely think it will continue to exist. We've talked about how we would love for the Svelte community to be more diverse. We are very typical of an early adopter focused open source project in which you know, our user base is unfortunately slightly homogenous. And, you know, if we can find a way to reach people who aren't currently using Svelte, that don’t look like us, then that would be a wonderful thing. And I think it would be the benefit of the project's health overall.
[00:44:33] KA: Yeah, I was gonna raise that. I got to think of something else.
[00:44:37] S: I think it's kind of tangential, I'd like to see more accessibility features in Svelte, things like maybe high contrast warnings.
[00:44:48] RH: So this is the kind of thing, I hadn't thought of this at all until you said it just now but this is exactly the kind of thing that having a central officially supported project structure like SvelteKit, kind of allows you maybe to do a little bit more reliably, because you can, you can say in a very predictable way, like, this is how you build the application so that you can serve it and inspect it using Playwrite or whatever. And you can't do that if the project structure is completely arbitrary. But if we can say that the majority of our users are going to be using SvelteKit, then that is exactly the sort of thing that we can start thinking about adding to the developer experience.
[00:45:27] S: I'll plug Kevin's favorite topic here, Svelte actions. I started actually prototyping a little, you know, project, just just to see, just to achieve consensus on what people think would be nice as official Svelte actions, things we all use a lot like onClick Outside, we all have some version of that anytime we write a model. And then I already forget what else, long press would be interesting for mobile web. Yeah, stuff like that is stuff I'm accumulating. And so there is an RFC. I took a stab at prototyping it. And you know, maybe you will see it merged -
[00:45:59] KA: I actually thought about an action for focusing on an input, it would be pretty sweet, focus on loading the page. Anyway.
[00:46:10] A: Isn't that the antithesis of accessibility? I think it's like that's the opposite of because I know that the problem if you focus on that attribute, then it's unexpected for users who aren't using keyboards or something like that, I can’t remember the exact rule.
[00:46:21] RH: I think you want to avoid auto focus when a page first loads, because people who use keyboards to navigate will expect the focus to be in a different place. I think it is okay to use auto focus in content that is created dynamically. Like if you create a new dialogue, then it's useful to focus the input in that dialogue immediately. But the accessibility rule sort of does this blanket, “You can't do that,” when you add autofocus to an input, which is, I often find myself adding the ignore declaration.
[00:46:52] KA: It’s there in HTML. Why would they put in an HTML if it were not supposed to use it?
[00:47:00] RH: Left hand right hand.
[00:47:02] S: This is what would be nice, with more accessibility warnings. It would help me stop myself from doing stupid stuff like this.
[00:47:10] KA: I would also say like inside the Svelte code base, I think there's a lot of to do's left on the accessibility stuff, right?[00:47:17] RH: Yeah, I mean, the biggest one is like when you do have, well the biggest one for me is when you do encounter an accessibility warning, like if you add autofocus, you will get a warning, but it's not at all clear how to disable it. Like you sort of have to know about the like, what the warning codes are, which we don't expose anywhere. And it's not very well done. We need to fix that.
[00:47:36] KA: All right. All right. To do list. Let's go on to pics if you have any. I can start. I got myself a robot vacuum machine a couple of days ago.
[00:47:45] RH: Oh we can see it over your shoulder.
[00:47:47] KA: Yes, yes, exactly. Best purchase I've done in years. Love it.
[00:47:53] S: Do you go barefoot in your home? Or are you -
[00:47:56] KA: Yeah, I do.
[00:47:36] S: No wonder.
[00:47:36] KA: I think it's a American thing to like, always wear shoes in the house. Or at least like non Asian thing. I don't know. Yeah, like the Roomba just cleans up things that you would already have on your floor. Anyway, I don't know what I'm saying but -
[00:48:13] RH: Does that not rob you of the joy of vacuuming though?
[00:48:17] Joy of vacuuming. What? What joy?
[00:48:22] RH: Vacuuming is by far my favorite chore. Because you get such a sense of accomplishment. I have one of the battery powered Dyson's which takes a lot of the hassle out like you know you don't need to bend over and like unplug it and then put it into the new socket in the room that you're doing now. I just walk around with this battery powered Dyson and you collect all of the dust off the floor and then like you look at it inside this transparent cylindrical container and you feel a real sense of accomplishment. I think if I had a Roomba I wouldn't get that that pleasure once a week.
[00:48:54] A: My wife shows me that right, so we've got, we've got the Dyson too. We've got two of them, one for upstairs, one for downstairs. And what she does every time she uses it she comes in and shows me all of the dirt that’s in it, like it’s some sort of like award. I don't understand it. But now I kind of get it. It's not just her. People do this and are entertained by it [inaudible]. I do however, I will say that I hate vacuuming. I really I don't enjoy any chore really, but especially vacuuming. I do have a Roomba as well. And one of the good things well [inaudible] the fun thing is taking apart after it's done a few cleans and pulling all the hairs out of it and cutting all the bits of it. That's satisfying. That's absolutely great fun. I can sit there for like an hour, taking it apart and pulling all the bits of stuff and hair. It's great fun. Great fun. So you have that joy to look forward to Kev.
[00:49:46] S: I got a new phone recently, and I'm quite enjoying. My old phone, I had the Pixel two XL and it served me pretty well but the screen was like smashed up and it was just dying and everything. So I asked people on Twitter what phone I should get between some Samsung Galaxy, whatever the newest one is, or the Pixel five, or the One Plus 8T. And the Pixel five was the overwhelming favorite. So I bought the One Plus 8T. And I've been very happy with it.
[00:50:14] A: You made the right choice.
[00:50:17] S: Yeah, I made the right choice. Yeah, Anthony was one of the people who steered me towards, I think maybe you actually sent me a YouTube review of the One Plus 8T in comparison with the Pixel and it’s just much better phone, or somebody did, and it convinced me, it's really high powered. And it costs the same as the Pixel five. And it has this sort of nice, turquoise, shiny case on the back, just a very well put together device. So if anyone needs a new phone, then check out the One Plus range. I’m not paid to say that.
[00:50:49] KA: Actually, so I moved. I have used, I used iOS, I used Apple iPhones for 13 years since launch. And I switched to Android in February. And I went through the same rabbit hole and I landed on One Plus as well. It was the 6T because I'm cheap. I think my conclusion between Pixel and One Plus is that like Pixel, just randomly, like prioritizes camera over everything else, no matter what it has to have the best pictures, but I don't take many that many pictures. So that's what made me choose the One Plus which is you know, have better specs for everything else. And a decent good enough camera. And I think that's the way -
51:24[00:51:24] RH: Yeah, I actually bought a decent camera recently, like one of the new mirrorless ones that is like the DS, the old DSLR, but a little bit smaller. And so now when I go somewhere I want to take photos, I will take that with me. The image that it produces is just so much better than what you get out of a phone camera, that I'm not taking as many pictures with my phone anymore. So it was the same thing for me. It's just not a priority. I think that phone cameras have sort of slightly cheapened the art of photography. And I refuse to participate in this nonsense.
[00:51:55] A: I will say that I, I went the other way, I had an iPhone 1 originally, I then switched to One Plus and I had my, I bought One Plus One. And it was stupidly cheap. Because it was when they first launched, they were just basically free almost. And it lasted me six years. And I couldn't actually make it break in order to get a new phone. It's amazing. It just slowed down a bit. And they’d stopped making the OS for it. And I switched to iPhone. And the only thing that's good about this is the health thing with the watch. It's really good. But I miss the Android. And the only reason I’d go back is to go back to a One Plus. The browser on this is terrible. Safari is just a joke, it’s useless. So I'm very much of the opinion now that I might look at Android again.
[00:52:37] KA: It's a trade off. My summary is iOS is the better operating system. But then Android has the better browser. So pick your poison.
[00:52:47] S: They're both pretty locked down. Right? I guess you can sideload on Android.
[00:52:51] Android you can kind of choose what you install. And I think One Plus are very good for actually having customer [inaudible] and stuff. Their phones will take quite a lot of stuff without a lot of modification, they’re a very generic kind of hardware. Well at least they were when I had one.
[00:53:03] KA: I've been using a new calendar app, Savvy Cal. It’s by a friend, Derek Reimer, he’s sort of trying to make his make his way in terms of like, indie hacking his own business, and I kind of bought it as a way to support him, but then it actually turned out really good. So it's exactly like Calendly except that it's indie and it looks different. I always get compliments on it whenever I drop a link to people. And I think that a lot of people don't do that. So they do they always do the back and forth emailing or like, “I'm free at least three times. Can you make any one of these?” And it's just better if you just give them a choice. I've been enjoying it. And he's got some like nice, pretty nice team features coming in, which is which is exciting for my team.
[00:53:42] RH: This looks this is good. Actually, this looks perfect for what I need. Nice. Nice pick.
[00:53:46] A: I think my pick has to be Begin.com. I mean, I said it before, right? I'm really enjoying it. I really like [inaudible] architect. And I really like the fact that it's got built in data. I've started building a small project on it just to see, you know how that actually works. And it's pretty great. It's a pretty great experience. So yeah, that's my pick.
[00:54:04] KA: I mean, Brian's a friend, we should try and have him on to chat.
[00:54:08] RH: I like products like that where like you know the people who build it. At least a little bit.
[00:53:13] KA: Yes, so you can yell at them.[00:54:15] RH: Yeah, but also, so you kind of have a sense of their product philosophy, and whether it's something that you align with.
[00:54:24] S: Yeah, it's more relatable, right? Yeah. Thanks for coming on, Rich. Always fun to hear your thoughts. Thank you everyone for listening. And we'll talk to you in a couple of weeks again.
[00:54:38] Bye. Bye.
[END]