Sean:
Hi and welcome to PodRocket. I'm Sean, and joining us today is Scott Spence, Developer Relations Engineer at Storyblok and Svelte Society London meetup organizer. He recently gave a talk at Connect.Tech 2022, Building with SvelteKit. Welcome to the podcast.

Scott:
Hey. Thanks for having me, Sean, and it's really nice to be here.

Sean:
Yeah, we're excited to have you. Before we jump into things, do you mind just giving us a little background? Tell us about yourself and your role.

Scott:
Sure, yeah. I'm a second-career dev, recently transitioned into web development, a web developer since 2018 now. So, it's quite a while. Transitioned into developer relations in 2021, so I'm pretty fresh to the role. And my role at Storyblok, as you said, Developer Relations Engineer, mainly to remove friction and help educate people around using headless CMS systems.

Sean:
Awesome. Then how'd you get involved with Svelte Society London?

Scott:
Svelte Society London, I can't remember. I think I just wanted to get involved with the meetup. I think I reached out on Discord maybe or spoke to one of the current organizers and asked him if I could help out, and I've been helping out ever since. It was November 2021, I believe. I've been doing it for quite a while now, try to keep a good cadence, so try to do it on a monthly basis, and yeah, the next one's next week.

Sean:
I'd love to jump more into that, building with Svelte talk, and just go through some of those points. So, how is Svelte different from some of other frameworks? I think, as web developers now, we're used to seeing new frameworks come on all the time. A lot of people are, "You know what? I'm just going to stick with the React." But why should people give Svelte a chance?

Scott:
JavaScript fatigue was the thing a couple of years ago. I'm not sure if it is anymore to be honest, and I mean SvelteKit is new. Svelte itself, been around quite a while. Since 2016 I believe, so it's v3 now, and I was very much involved with the Gatsby ecosystem and I think it was the latest version bump, and it's obviously me doing something wrong, but one of my sites was really slow and I thought, "I'm just going to try this Svelte thing." I think I saw a talk from Rich Harris where he did the announcement for Sapper v1, and there was a big drum roll in the video and he said the launch of Sapper v1 is going to be never, and introduced SvelteKit and then showed us SvelteKit and how that was working. I was really impressed with that, with Rich as a speaker in general.
If anyone's listening and they are not familiar with Svelte, there's a great talk which everyone references by Rich Harris, which is called Rethinking Reactivity. If you just search Rich Harris, Rethinking Reactivity on YouTube, you'll be able to view it, and it's a great overview of Svelte and how it works. I think that was for Svelte v3, and in it he goes through what makes Svelte reactive. What you asked me initially, and I've sort of rambled on a bit now, Sean, but is that what makes it different is that Svelte is a compiler. So, rather than have your sort of JavaScript runtime shipped to the browser and have a virtual DOM to track if anything's changed, it compiles all of your JavaScript CSS and HTML up front. It knows anything which is going to change up front. The thing with the compiler as well, you're only ever shipping the minimum set of features you need rather than a whole set of features which you get with other frameworks.

Sean:
Yeah, right. And I know that one of the problems that people run into with JavaScript is trying to get the [inaudible] size down, and of course things like next now will be more smart about code splitting and what they actually ship to the browser. But in terms of rethinking the reactivity part, how does the actual developer experience differ from using maybe something like React or another framework?

Scott:
The reactive variables part was a bit funky to get your head around. If anyone's listening and they don't know how reactive variables work in Svelte, it's basically a dollar colon syntax and then you put your reactive variable after that. A lot of people are like, "Whoa, what is this?" It's going back to Rich's talk again. It is actually valid JavaScript, it's used for labeling lines in JavaScript but because Svelte's a compiler, they use that for the reactive part, it's not well known and not widely used.
The Svelte team co-opted that and started using that for the reactive part of Svelte. The other thing with Svelte, which might trip some people up is if you have a component and you want to pass props to it. In a component, you would accept those props as export, let prop name. A lot of people don't drive with that, but if you just roll with it, it's just like bringing in props to any other component really. But you're just using a different syntax and a lot of people, they struggle with that as well. But because it's a compiler, exporting props to the component, it doesn't sound right, but that's just how the prop comes into the component.

Sean:
I ended up looking up that label thing. It's funny because I had never heard of that feature of JavaScript. You could give up nested loops, you can label the loops and you can choose to continue on either of them. But it's pretty interesting and I don't think too many people are going to complain that they've co-opted that feature.

Scott:
It's a great tool for having anything of which you want to react to any user interaction on the page. You can just put it into one of these reactive variables, it's really handy.

Sean:
What advice would you have for maybe orgs or teams who want to use Svelte and they've bought into the better developer experience but they might have a hard time justifying it with that alone to their company?

Scott:
That's a great question and there is a great answer in a talk from one of my friends, Chris Ellis who I believe it was the August Svelte Society meetup in London and he did just that. He works for a company called XtendOps and they work in South American countries which don't have a great mobile internet speeds and they needed to be able to ship applications or tools to mobile users. They didn't really use desktops. He was very bullish on that. He was the CTO, but he had to sell it to the rest of the company and without going into too much details, basically reduced lead times. I'm guessing if you saw the talk at Connect.Tech, I think I'll go over this as well, it's reduced lead times, it's easier to understand the code. It's a lot more concise so onboarding developers is, it's a lot faster.
It's simpler to pick up because it is actually more CSS and JavaScript contained in a file. What I actually didn't cover as well was that Svelte itself is a superset of HTML and I think the reason why Rich Harris chose that is because JavaScript, CSS and HTML all in one file. That is the reason why it was chosen to be a superset of HTML. Anything which is in HTML spec is going to be fellows in Svelte. Selling it to your boss, let's say, would be faster lead times, onboarding is quicker and smaller, relatively faster but not massively. They're all benefits as well.

Sean:
Yeah, I definitely see the efficiency gains. In that talk, you compared different code snippets. I think it was React versus Svelte in most cases the Svelte one was a bit smaller for sure. It seemed like there was less boiler plate.

Scott:
Yeah, roughly 40% less code to do the same thing. I tried not to draw too many comparisons, but I think I did it with vanilla JavaScript as well where you just have a button and it's less verbose for vanilla JavaScript and for React. Because it's declarative, you tell the browser what you want the outcome to be rather than every exact instruction it needs to have. But that's a framework feature rather than just a feature which Svelte has and the others don't because declarative frameworks do just that for you.

Sean:
Yeah, that definitely seems like a big part of why there's less code though I guess, in JavaScript via [inaudible 00:09:12]. You tell the browser to add an event listener and then you listen and do a certain thing or it's just like if you tell what the outcome should be then it's a lot simpler it seems. That's Svelte, but there's this thing SvelteKit so maybe for our listener who might not know the difference, do you mind going in into that a bit?

Scott:
Yeah, I mean SvelteKit, if you are familiar with Nuxt and Next.js, SvelteKit is the equivalent to Nuxt is to, what do I call it? Nuxt is to Vue and Next.js is to React, SvelteKit is to Svelte.

Sean:
I think one way to think of it is SvelteKit is sort of a broader encompassing framework on top of Svelte that adds maybe more convenience features to it.

Scott:
Absolutely, yeah. It will add your routing, it'll give you the ability to use endpoints in now. You can do your database calls, it utilizes http methods so you can do your... I'm trying to think of the other words. Get, put, and delete, and-

Sean:
Post.

Scott:
Yep, those ones. You can use those in SvelteKit endpoints, takes care of your routing, it's got an awesome router. Because if anyone's listening, they aren't aware that the actual creator of Svelte, Rich Harris along with, I'm trying to think of his actual name, but I just know his handle was DumbdyDumbDumb. I think there's two of the main core maintainers of Svelte and SvelteKit are actually working for Vercel. They were very privy to a lot of the changes which Next.js was making and decided to artistically take those features and use them in SvelteKit as well. There are a lot of features in SvelteKit which are similar to what you would get in Next.js And it's what you'd expect with a modern day meta framework let's say.

Sean:
Got you. Yeah, so that's funny. There's some inspiration perhaps from Next, maybe they saw the writing on the wall and how popular some of those features would be. One of the interesting, so I'm more experienced with Next than SvelteKit. One of the things I love about it is that you can declare whether something's going to happen statically at build time or server side or whether it's going to run on the browser. Are there any analogs to that in SvelteKit?

Scott:
It's changed a couple of times now, so I'm not actually 100% certain of what it is, but I'm going to need to find out. With the v1 launch of SvelteKit, they did a naming convention with the plus page.Svelte and plus page.js or ts. This was around August time where they sort of totally changed this naming convention. A lot of people got mad, a lot of people didn't like this because the naming convention was in the past you could just put in a page name, you could just call your homepage dot Svelte and that would be your homepage or it'd actually be like forward slash homepage rather than a dot index. But the SvelteKit core team decided to have anything which would be a root name, be in a folder and it'll be co-located with the code, which was going to load any data to the page at that time and any data which would come from a server which would be in a plus server.ts or js file.
they really separated the concerns there with that sort of information so you know exactly where you are going to get data. If you want to get some server data, you'd go into your server.ts file or if you wanted to get your page data you'd go into your page.js file. There's really good separation of concerns with that. But there are a couple of variables which you can export at the top of a page to say, "I want this to be server ended only, I want this to be statically rendered." But I can't actually think of what they are. But yeah, there's a lot of fine grain control in there.

Sean:
Yeah, no it seems like it pretty important to separate those concerns of what's running on server versus client. One of the things about Next that I find interesting is that you can have the same file and then some of the code might be running in the client and if you export get static props, that'll be running on the server. There's different things that you might not want to run on the client versus server. In my opinion, it's good to know which and separate them as much as possible I guess even just for security reasons.

Scott:
Yeah, the thing is though, say if you want to read some markdown from a file with Svelte, you'd need to use the file system and you can edit that on the server, but then you want to get that into some front end code, you'd need to do a fetch from a page.js file and then that would load up the data for the page. There's a bit of jumping around to get to stuff, but like you say, it is well separated,

Sean:
The trade-off makes sense, I guess. That seems you do more shuttling of data around, I guess it sounds like to have that separation of concerns. That's interesting. Yeah, and I understand where the community is coming from, I guess then.

Scott:
While we're talking about separation of concerns as well, there was always this thing where you would always have separate js, HTML, and CSS files, Svelte gone, "No, we're not going to do that, we're going to have it all in one file." It's sort of gone full circle again. But I don't know, I've been working with it since around April, 2021, I think. After 2019 everything's just sort of blurred into one. I've been used it for quite a while. I've been along for the ride up to v1 with the release of SvelteKit, had all the fun everyone else had in August last year of having to refactor any project that was in SvelteKit to accommodate the new route instruction and stuff like that. I'm very comfortable with it now and I can't remember the last time I looked at some React or React code, so I'm very much in the ecosystem now, so might be a little biased as well.

Sean:
Yeah, and React has undergone some major changes as well. I know this one's now more a few years ago, but the class to function-based component. Certainly some folks had to do some rewrites in the React community as well.

Scott:
I loved the change from class-based React over to Hooks. It just made so much more sense to me. What's the one where you always had to put the call back in, but you never put it in and you're always like, "Why isn't this working?"

Sean:
Async Await. Yeah, the fix for the callback hell.

Scott:
Yeah, that was good times. I used to work at an agency, my first two sort of web development jobs were in agencies and we had an old React 15 project and everyone hated going near it and as soon as Hooks come along we're like, "Yeah, we're going to convert this to use Hooks." There was four people on the team, each one of us tried and failed and we just left it. It's like, "Okay, they could just stay there and we'll just have to work with classes in React until it gets sunset." Which he did quite soon after that happened. But yeah, it was a revolution

Sean:
Or you could pitch the Svelte rewrite.

Scott:
I would love to have done that. I was a very keen to have done it in Gatsby at the time because it would have just simplified things a whole lot. It wasn't a very big site and there was several pages and I was like, "Look, this is going to be a lot faster." That was my selling point. It's like, Gatsby, fast. State pages goes out, people can interact with it and a lot of the stuff we were doing didn't have a great deal of stuff which needed to happen, not on the server and if you using the static site there's not a great deal you can do. But that was the sort of main driving force behind a lot of projects taking on Gatsby at the time. Yeah, there were some people who were not so happy when really large projects come along with hundreds of thousands of pages and they had to wait a long time for stuff to build. Anyway, let's not talk about that.

Sean:
Yeah, you're moving on to better things with Svelte and SvelteKit now and are you using that at Storyblok?

Scott:
Yes. Yeah, indeed. We've got a Svelte client to use for Storyblok. Uses like the used directive so you can take a HTML node and do what you want with it basically in JavaScript. We are using that in Storyblok to manage all of the dynamic data which will come in from the Storyblok endpoint. You could do quite a lot with it and to really... I didn't code it myself, some of the people on the team did, done a great job of it with the v1 release now. Because as I've said, a lot of times now, everyone was thinking it was in beta still. We're like, "This is solid, everything's going to be fine." Then everything changed, but we're in a good place with it now and it's really handy to use.

Sean:
Awesome, yeah. Have you gotten any feedback or have you heard any issues from the Svelte Society in terms of implementing Svelte into projects or just, I guess, yeah, have you gotten stuff back from the community that you've now taken back into your work?

Scott:
There are some bits, especially with the JS client for SvelteKit is rich text rendering that. We've got a couple of outstanding issues on that. I should know, but I don't, how many actual projects are using it in production, but there are a lot more people asking about it and I can't think of actually any which has said, "Yes, we love SvelteKit and we're going to use it in production." But we're there, we've got the tools for it, so we're hoping that there's going to be a lot more adoption of it.

Sean:
Yeah, well yeah, hopefully it has a very exciting future. Yeah, you've also, just to plug that you've written some great posts on Svelte and SvelteKit and Tailwind and your YouTube channel as well. Do you have anything else to plug for our audience while we've got you here?

Scott:
My YouTube channel, I haven't actually released anything on that for a while and a lot of the content on there has been invalidated after the SvelteKit route changes. Not a great deal on there. I mean, I put a load of stuff on my blog. As I learn stuff, I'll go through and sort of document it on there so that's scottspence.com if anyone's interested. There's a couple of call bits I want to do for a talk. At the end of this month we've got the meetup coming up and as I said about the used directive where basically you can do anything within your HTML elements. I wanted to have like [inaudible 00:20:10], have your details box. I recently did a dumb project, which is my whole life, just a string of dumb projects. But on a whim I went to httpcodes.dev and it was empty and I was like, "Oh okay, is this available?"
it was, so I went and bought it and then literally I just wanted to be able to put in http error codes and just be able to filter down. I went and stole all of the http response codes from MDN and just put them into a big array and just have it as a filterable list. Within that there's a little details expansion and you could use the Svelte fly transition, but for some reason it was a bit janky at the end and I think it was just because of the actual height, it didn't know how to calculate it properly. I went in and added some custom CSS animations to it, just so it was a little smoother. That's something cool I've been sort of playing about with recently. I did a Vendure Commerce Showcase I did in December, but I've been working on a little example project which uses SvelteKit but also uses Houdini and KitQL to... Houdini is the GraphQL client for SvelteKit.
I was in touch with the person who runs Vendure, his name is Michael Bromley and he was very patient in getting me set up and running with Vendure backend. It uses the Vendure read only example API, but within that I also used some call general like you click into a search box, it expands just some nice little interactions like that. That does the same thing where you just put in your custom animation you want to use and then you can just assign that to any element you want to use in your project. That was quite cool and I'm thinking about just expanding more on that and my learnings. It was cool and it was a good experience and there was a lot learned in that, so need to sit down and document that as well. But like you're saying, again, going back to the YouTube channel, I want to do a, let's do Svelte again.
Not SvelteKit but just the absolute basics of Svelte, each part of that and I'm sort of trying to think through, I don't want to make it a whole project, small little examples you can do and just put a load of stuff out there like that. But there are some really good content creators out there at the moment. There's Joy of Code, I believe the guy's name is Matia and there's also HuntaByte. Both of those guys are putting some really good content out there for SvelteKit. If you watch YouTube and you want to consume some SvelteKit content, I'd recommend those guys. Go check them out.

Sean:
Awesome. Yeah, well if you end up putting some Svelte stuff on there as well, I'd be really interested to see that. Yeah, we'll keep an eye out on your blog for more content, but it's been really great having you on and I appreciate it and excited for what you do in Svelte in 2023.

Scott:
Awesome. Thank you. It's been great.