Tan Li Hau on contributing to Svelte, his compiler handbook and much more!

Svelte Radio

Li Hau joins us to talk about his experience contributing to Svelte and how he got started. We talk about the best way to get involved as well as his compiler handbook. Enjoy.

Li Hau joins us to talk about his experience contributing to Svelte and how he got started. We talk about the best way to get involved as well as his compiler handbook. Enjoy!

Sponsors:

  • Mono is a digital product studio that works remotely. Within the Svelte community you might know Wolfr he is a designer that worked on the Routify, Svelte Society day and Svelte Summit website. He wanted to sponsor this episode with a simple message: as a design team, they are open for client projects. They have extensive experience designing web applications with full-on custom design systems. Mono is typically responsible for the UI and UX in a project and they work alongside developer teams.
  • Level Up Tutorials brings you cutting-edge, focused & high quality video tutorials for web developers and designers. Check out the Svelte For Beginners as well as Sapper for Beginners courses.

Links: Meetups:
Picks:Transcription:
[00:00:00] KA: Hi, everyone. Welcome to another episode of Svelte Radio. Today, we have another guest. But first, let’s get into introductions. I’m Kevin. I run a site called Svelte School, where I teach you all about Svelte and what to do and what not to do in Svelte. Soon, we are going to have our first video course. Keep looking. Yeah, that's me.
[00:00:26] SW: Exciting. I’m Shawn. Hi. I’m also known as Swyx. I work at AWS as a developer advocate. What have I done with Svelte recently? I played around with Elder.js and I’m working on moving my own site over to Elder.js as a static site generator built in Svelte.
[00:00:42] AJ: Hi. I’m Antony. I’m the CTO of Beyonk, which is an adventure, well, a venture experience booking platform. I’m also a Svelte maintainer and I have very high CPU usage. Yeah.
[00:00:59] KA: All right. Our guest for today is Li Hau. You might know him from his contributions to Svelte. I’ll let him introduce himself.
[00:01:09] TLH: Hello, everyone. I’m Li Hau. I guess, my full name is Tan Li Hau. Tan is my family name. You can find me @lihautan on Twitter. Who am I? I’m a Svelte contributor as well, like Antony. A bit of myself; I’m currently in Singapore like Shawn, like Swyx. Actually, I’m originally from Malaysia. For those who don't know where Malaysia is, it's a Southeast Asia country right between Thailand and Singapore. That's where I’m from. It has better food, no offense, than Singapore. Although the culture-wise and weather and everything is almost the same.
I’m currently working at Shopee as a front-end developer. Shopee is this e-commerce platform, we would say the leading number one e-commerce in Southeast Asia. For those who don't know about Shopee, last year we had Ronaldo as our ambassador. It's very funny. I promise you. You can search for Shopee Ronaldo and we get him to do a baby shark dance with Shopee. That's hilarious. You have to check it out. I think a lot of people who are not in this region would think that Shopee and Shopify is related, but we are not.
[00:02:30] SW: I had a friend from Malaysia when I was young. His dad owned a restaurant in Manchester and one day he went to the restaurant and he said, “Order anything you like, any food you want, because it's all free. You can have anything you like.” It's amazing. I ordered my what I thought would be amazing dish and it came to the table. When it arrived, he immediately thought it was his and stuck his fork right in the middle of it and stuck it on his plate. I was like, “No.” Yeah, I didn't really eat much Malaysian food that day, sadly.
[00:03:02] KA: I would say the food in Malaysia is pretty good. I went a couple years ago. I like it.
[00:03:07] AJ: For those who get to eat, I’m sure it's wonderful.
[00:03:12] TLH: Hopefully, one day after the pandemic is over then, maybe you guys can come over and I can bring you guys around, hopefully.
[00:03:18] KA: Yeah, that sounds good.
[00:03:19] AJ: Amazing.
[00:03:20] KA: What got you interested in Svelte?
[00:03:23] TLH: Well, so I would say I was interested in the idea of Svelte early on. Maybe a bit more background about myself with the company. Basically, in Shopee, I’m on a so-called working platform-related stuff, which means that I work less on future related stuff, but more on fixing your webpack config and table config, upgrading labels and stuff. That's because I volunteered into this role and we made this role into me.
I was playing with all this webpack, Babel and all this stuff. Once in a while, we encounter weird bugs, because we upgrade to the latest version. I have to figure out why by basically reading the source code of Babel, for example, to figure out why. Then slowly and slowly, I get more familiar with them and I started to actually make code fixes and make a PR to them. That's how I get into open source.
At some point in time, I have this idea of you can play with Babel after a while, I was thinking, why don't we compile JSX and React into what Svelte is doing? Basically, back then was I think Svelte too. I was like, “Oh, you can just compile as well the same template into plain JavaScript. Why can't we do it with JSX?” I was playing with it, but said, it's too hard for me. I can't figure it out. I was talking with my colleague and I was thinking, “Should I invest more effort into this, or what do you think about this project?” He was telling me his advice, which is when you have some cool idea and someone has already implemented, you can either work on your own idea to make it better, or you can actually collaborate with the author and you can do even better things in collaboration. That somehow planted that seed into me.
Actually, last year, Hacktoberfest. For those who don't know about Hacktoberfest, so GitHub has this annual event of Hacktoberfest, where you contribute to – I think it's in collaboration with DigitalOcean. If you make three PRs, or maybe five now, you will get a DigitalOcean stickers and swags and t-shirt. That's my main motivation.
Basically, I was like, okay, how about just take this opportunity and take a look at source code? That's how I get started. Basically, I’m just reading source code and understand how it goes and find out the easiest issues and figure out how to fix that. Slowly and slowly, I see there's some to-do's in the source code. I was like, “Oh, this sounds doable.” I’m just like, do it and make another PR and yeah. Sooner or later, one day, Rich just inboxed me on Twitter and say, “Hey, do you want to join Svelte?” That's how I get into it.
[00:06:23] SW: GitHub and DigitalOcean tricked you into Svelte, sort of.[00:06:29] TLH: I’ve been collecting their t-shirts every year, but I always couldn't get the size right. There's one year, I get it too big. The other year, I get it too small. I just don't know. I just don't know what happened.
[00:06:41] AJ: It sounds like SDD, which is swag-driven development. I mean, I think that's quite a reasonable approach to things. I like it.
[00:06:51] KA: You're pretty known for a couple of blog posts that you've written, the first one being the compile Svelte in your head part one and you have a couple of others. Maybe, I think you got the idea from Shawn, right?
[00:07:03] TLH: Yup. Yeah, Shawn. You want to talk about it?
[00:07:06] SW: I was organizing the Svelte society meetups in New York. I was thinking of ideas for talks, because in the way that we organize meetups is very inspired by order at the rocks in typescript New York meetup, where he has a beginner, intermediate and advanced talk, so that everyone who comes to a meet up has something to look forward to. Oddly enough, the beginner ones are actually the hardest to do, because most people don't want to do the beginner talk. They just want to talk about something that is at the edge of their abilities. I was thinking about it and then I was thinking that I don't really understand how Svelte works, so I used that as my beginner talk.
Essentially, the Svelte repo has the compiled output. I was just doing a mapping from here's what you have on the left-hand side and here's what it compounds on the right-hand side. Let's try to predict what each of these things are. I ran out of time, because I did that on the day of the meetup. I didn't finish it as a talk. I gave it as an unfinished talk. It did not go so well. Then I went home to Singapore and then I went to Shopee’s internal meetup. Shopee has a really good meetup. They meet every week. I gave it again as an unfinished talk, because I didn't work on it at all.
[00:08:17] TLH: I couldn’t tell.
[00:08:19] AJ: Really selling yourself out, Shawn.
[00:08:21] SW: Quite a bit of my skill is just in time speaking.
[00:08:28] KA: Just in time speaking.
[00:08:32] SW: You try to do as much prep as possible, but at the end of the day, you realize that you just have to get very good at improvising and whatever comes on the screen. In NYC meetups, we have a fun segment, especially in Manhattan JS and Brooklyn JS, we call battle decks. Battle decks is when you go up in front, they start giving you slides that you haven't seen before and then you're supposed to make a talk based on the slides that you haven't seen. You're talking about whatever happens and then you transition to the next slide and it's show something completely different and then you have to find a way to segue into that.
[00:09:02] AJ: That sounds hilarious.
[00:09:03] SW: It’s a nice improv thing. Yeah, especially because they fill it with bullshit business terms, which is usually funny. Yeah, leverage your synergies. Yeah, I did that with Svelte. Then I think, Li Hau, saw the potential and actually followed up with a proper –
[00:09:18] TLH: I feel it's a very good way or perspective in explaining Svelte. Yeah, so one day I was thinking, that is a really good idea, a good way of presenting Svelte. Also, there's a very catchy title, like compile Svelte in your head. I was trying to figure out a different title, but I’m just bad at naming things, so I’ll come up with titles. I just went the idea, Swyx, telling him, “Hey, your title, can I just keep it? Can I use it? We do the flow. I like the flow, but I will write a blog post about it. I couldn't figure a title. Can I just use it – use your title as well?”
He’s very generous. He said yes. That's how the compile Svelte in your head part one comes about. It's just a beginning of Svelte, and I think there's a lot of things to be covered. I wrote part two, part three. There's a lot of things in my mind. In a draft, basically I didn't manage to publish them. Definitely, there's a lot of things to cover, such as if, else, how does a wait looks like and transitions. Yeah, there's a lot of things to be covered.
[00:10:24] AJ: Actions.
[00:10:24] TLH: Actions, yes. There's so many things to cover. Yes, slots.
[00:10:30] AJ: I’ll tell you why I think the title appealed to me, actually is because if you interview for a lot of the big tech companies, the big five, I can't remember what the acronym is for them, one of the things they often ask you to do, even in pre-screening is they'll ask you to write code, but not use a compiler. They'll ask you to talk through it and literally manual looping and stuff like that. I think being able to compile something in your head is actually quite a useful skill for anything really. When you do it and I thought it was ridiculous at the start, because I thought this is so pointless, because we have compilers. It's like not using a calculator. Why you do the math in your head.
The reason being is because obviously, you can really understand what your code is doing under the hood and you can spot inefficiencies much more easily if you're compiling it yourself, rather than using a compiler, or relying on tooling. I think the title is genius, actually. It’s super catchy. I really like it.
[00:11:17] KA: I came up with the name for Svelte Society and Svelte Summit and blog post titles and that's about it. That's all I got.
[00:11:24] AJ: Hey, it’s a skill.[00:11:25] KA: Zero value ad titles actually play a big part in how I think it is. For sure, because it's something that you promise the reader and then you get their attention and then you have to deliver on the promise.
[00:11:35] AJ: I think you just described clickbait.
[00:11:41] SW: It's only clickbait if you don't deliver.
[00:11:46] TLH: Swyx has this term called two words, right?
[00:11:49] SW: Yeah, it was a philosophy, I think more than a term, but yeah.
[00:11:52] TLH: No, no, no. I mean, I said two words. I was also thinking how do I cram, compile Svelte in your head into two words, catchy title, but I just couldn't make it.
[00:12:02] KA: That sounds impossible.
[00:12:05] SW: I think, you took it to part one, part two and part three and I think – are you planning to continue? Then you also had a Svelte compiler handbook. Is that a separate initiative?
[00:12:13] TLH: Yes, it's quite different. I think the idea, or the I would say, target audience maybe is a very different pick, or perspective into Svelte, where one looks at compile Svelte in your head looks at how actually Svelte’s compile the code into JavaScript and how do you run it. How does it look like in JavaScript, because with that, you have a sense of what is the constraint, or what is the limitation of the syntax itself. There's a lot of things people are asking that I just couldn't compile it to JavaScript. I don't know how to implement it in JavaScript to do that thing.
Most of the case, that's the reason why we couldn't do that feature. Basically, Svelte is a compiler. You have to always think about how do you compile that to JavaScript? If you couldn't think about that, or you have to do a lot of things in the runtime, basically, it's a no, no, I think in the Svelte’s philosophy somehow.
The other thing would be people are quite interested in Svelte. They want to contribute. After you know how to compile things Svelte into JavaScript, but you don't know how the compiler works. You don't know where things are. For example, if I’m telling you a div element will compile to document.createelement div, but where is that code written in? Which part of it? That would be the reason why I wrote that, because I think a lot of people wants to know and basically, they don't have a handbook, or a place to learn about it. I inspired by the Babel handbook, if you guys know about it.
There's this Babel handbook that basically gives a lot of tips and tricks on how to do things in Babel, like how do you write plugins in Babel. That's also where the inspiration of the titles is coming from. Basically, I’m just bad at naming and coming up with titles, so I’m just boring it from everywhere.
[00:14:05] KA: It seems to be working though. I’ve read all of them and then I really like them. Some other questions. What's your favorite PR to Svelte? Which one that you've done are you most proud of, or was the most fun to write?
[00:14:20] TLH: I don't really know. I think there's one story that's interesting. Basically, I was trying to optimize it in a sense where make it – if you're using a variable in your template, but if that variable is never changed before, like you don't change that variable at all, you could –basically I was thinking like, why not inline it in a HTML? If you have a static element in Svelte, what Svelte will do is using inline HTML to make it shorter than really create the DOM elements. If you start to have expressions, it will de-optimize into creating text notes and defend, things like that.
I was thinking, “Hey, this variable is not changed at all, right?” Because there's this number one tutorial. The first thing in on the tutorial will be hello world, cons name equals world and then you just use the word and you don't change the name at all. I was thinking, why not? Just make it, better where you just inline that – when you're doing the inline HTML, you use a string template literally instead. Then that got merged, but then someone pointed out that that will create cross-type scripting vulnerability, because you will never know what variables it will be.
That got reverted a bit, where we figure out maybe inner text content and things like that that is cross-type scripting safe. That's interesting. I never thought about that before, to be honest. That was one of my earliest PR. Maybe that's why I remember the most, I guess. Yeah, the first few PRs and I already introduced a vulnerability.
[00:16:03] SW: It's definitely one of those things, where you make the mistake once and then you'll never make it again.
[00:16:08] AJ: Yeah. Start learning the lesson the hard way. This might be a stupid question, but it's just recently, I’ve heard people calling pull requests, MRs. What does MR stand for?
[00:16:16] TLH: Merge.
[00:16:17] AJ: Oh, merge request. Okay.
[00:16:20] TLH: Basically, it's a branding of GitHub, where pull request is a brand thing. If you go to GitLab, it's called merge request. There's no such thing as a pull request. That's the difference.
[00:16:30] SW: Google calls it like the CL contribution or something listed.
[00:16:35] AJ: Yeah. I mean, because I know that Linus himself, the guy who wrote git, he doesn't like GitHub's pull requests at all. He's completely against them, the way they work, because he says it's basically an augmentation of the original feature. I wonder what his original feature was called. I don't know.
[00:16:52] KA: Yeah, I don't know. This is news to me.
[00:16:55] AJ: Now if you look at Linux, look at the Linux source code on GitHub, it's read-only. It's just a mirror.
[00:17:01] TLH: I’m using GitLab at work and GitHub in public. I always mix up these two words. That's how I know about the difference between MR and PR, because I just realized that hey, how come GitLab is always using MR and GitHub is always using PR?
[00:17:14] AJ: What does Bitbucket use? Who knows?
[00:17:17] KA: Well, that's a good question. I think they're using pull requests.
[00:17:20] SW: I think they are, because I’ve never seen anything other than pull requests. I’ve never really considered it actually.
[00:17:25] KA: Yeah. How would you encourage people to contribute to Svelte for the first time?
[00:17:30] TLH: For the first time, read my blog if you don't – If you don't know how it works, I guess, hopefully it's helpful to you. If it's not, also let me know. At least I can edit it, because right now, I guess, that's something that we are lacking of. I guess, maybe after reading it and getting more familiar with the codebase, maybe you should write another blog, or docs, or things like that to telling people how to read Svelte code. I guess it's a bit hard for beginners, especially because it's like a compiler. It's very different than a normal library, because compilers have different steps. It's just very different.
[00:18:07] AJ: The learning curve that other frameworks don't really have.
[00:18:10] TLH: Yeah. It's really tough, but if you're reading enough compilers, like Babel. I haven't read typescript, but Svelte. After a while, you just maybe mark down MDX and that current thing. After a while, you start to get the catch of how they do things in a compiler. Then you start to see, because they follow certain design patterns in doing things, then you start to get a hold of it, then I guess, you know what to look for things. The learning curve is high and that's how I would recommend people to start.
Once you get through that hump and you want to work on features on Svelte, I guess you just go to GitHub issues and find things. We have this new maintainer, Ben. He was very helpful. Basically, he just go to every issues and trash them, comments or close them if it's not relevant anymore.
I guess, basically, all the things is in the GitHub issues. All the things that you can do is in the GitHub issues. If you think it's not there, maybe it's a feature that you want, then RFC propose some future requests.
[00:19:17] AJ: This is something we discussed at the recent maintainers meeting is how can we aid new contributors getting onboard and yeah, like Tan Li says, one of the things is raising a feature on GitHub as an issue, sure. If it's something that's going to cause a lot of discussion, a lot of bike shedding, that sort of thing, then an RFC is the correct way to go about it, because that's literally the place for that thing. We see a lot of pull requests come in that are a significant feature that's had no real discussion. It's just been someone's idea in an issue. No one's really fed back on it and it's just – it's unlikely to get merged, because what you're doing is you're affecting so many users with your API and the way you think it should work. It's very a unilateral mindset. I think an RFC for an open discussion about how to shape the future of the Svelte API is really important.
[00:20:02] KA: Also, you don't have to actually do coding to contribute to Svelte. You can fix documentation. You can blog about it. You can do videos on Svelte.
[00:20:14] SW: Test PRs. You can test existing PRs. You can feedback on them. There's loads of stuff. The way I became maintainer is because I was just basically closing issues verbally. Obviously, I couldn't actually close issues, but I was just saying, this isn't an issue, whatever. I’ve tested. This doesn't work, or does work, whatever and that's it. That's how I became a maintainer. That was my path in.
Anything is useful, anything that helps the community, anything that helps the burden on maintainers, because there aren't that many of us and we're very busy with our day jobs, I guess. Everything is useful.
[00:20:46] TLH: I think, Antony mentioned about tests, right? The best way of raising an issue on Svelte, actually is too – I think most people would – some people just describe the problem, a better way would be come off with a repo on Svelte rebel, a minimum reproducible thing that we can just see, yes, it breaks. I think, even better would be write a test case that breaks and that's even better. Someone would be interested in writing the fix for it. You don't have to worry about you don't know how to write a fix. I’ll be there, I guess.
[00:21:21] AJ: Absolutely.
[00:21:22] KA: Makes sense. If you could have any new feature in Svelte, what would be the feature you would pick? What's on your wish list?
[00:21:31] TLH: Maybe of confession first. I’m not using Svelte at work. Sorry, guys. Yeah, we are using React. Too bad. Actually, what I want on Svelte, l feel there's a very huge potential for Svelte, because it's compiler base, which is a place where it could do is to optimize for the server site rendering, and as well as the hydration part. I think there's a lot of things that can be done. Basically, Svelte can know firstly is SSR, I think it's already done basically, but there's edge cases of SSR, or things that I think SSR can do, like for example, prefetch.
Because right now if you're using an await block, basically, server site rendering will always returns you, depending, like the loading is the out resolve or whatever, because the SSR is synchronous. Unless, you're using Sapper. Sapper is different. Sapper does it, where it creates – there's a prefetch magic export where you can do a prefetch to do it. SSR compiled target, if you compile Svelte into SSR mode, you can't do that. It's synchronous, so you can't fetch anything. You can't fetch the await.
After that, basically, Svelte can know what elements, or where it's static, especially if you're doing a static site, like block. Basically, a lot of things are static. You don't really have to hydrate. Hydrate as in. How hydration works is that you have to map back whatever is on the DOM to a reference in your code. Then moving forward, just use those reference instead. In the meantime, if you have things like event handler and action and things like that, you run those as well. It's just keep the part where we create nodes. The creation part is kept, because you just claim whatever is on the DOM.
For static slides, basically Svelte right now is claiming every element. It doesn't really care whether it's static or not. I feel that there's something that a compiler can do. A compiler should be able to know whether certain things are static or not. There's a huge opportunity to improve over there. That's why I’m excited. That's why I’m being part of Svelte, because I want to try it out. Basically, I guess, React team in Facebook, they are doing their own thing, but I get involved in those things. I just want to try that, like this concept, whether it works or not right. That's what I’m interested in and I want to do something about it.
[00:24:00] KA: Yeah. Have you looked at Elder.js?
[00:24:03] TLH: I haven't read through the code, but you guys mentioned about it last episode, right? I went through the readmes and it's very interesting, but I haven't really look into the source code yet to see how it’s done.
[00:24:14] KA: Yeah. Because, I think he's using or they are using, I should say, a preprocessor for figuring out, like what elements are to be hydrated. I’m not sure how that is one way to do it without having the actual feature in Svelte. I think they default to just using the server side render. They render to server side. I think that's an interesting idea. It breaks some of the – you can't really use actions, if that's your approach, I think, which game over. Yeah. Well, the thing is actions are hydration for single elements anyway, right?
[00:24:52] SW: Yes, they are. Yeah.[00:24:53] KA: If you could have that feature, as well as the partial hydration of components, that would be nice. Mostly because I like actions, though. You guys probably know that.
[00:25:03] TLH: I mean, a simple idea would be maybe a generated ID on your element that you use action and then you just get element by ID to get that element only and then you apply action on itself. That would be much better than go through all the elements on your DOM.
[00:25:20] KA: Yeah. I was thinking about how you would do it and that's pretty much like conceptually, how I figured it would work. I’m not experienced enough to actually implement it. I should try making a preprocessor for something like that. That would be fun. Typescript, how do you feel about that in Svelte? Do you use typescript at work at the moment?
[00:25:44] TLH: I think Swyx knows about it. Yeah, we were using flow. Breaking news, right now we are actually experimenting with migrating from flow to typescript, because of the community support that typescript has. It's a pain process, but I guess, we have to go through with that.
We started very early with our code base, where we decided to use a static analysis, a static type checking. Back then, I think that was three, four years ago. I think back then, flow is more promising than typescript. Yeah, but you never know these things. We were hoping that flow gets better. I was thinking about contributing a flow, but it's written in old camel and it's just a pain to setting someone to read the code.
[00:26:29] SW: What are the pain points? Because I’ve accumulated quite a few stories of flow to typescript migrations on the React typescript cheat sheet. I haven't done it myself. On the surface, it looks pretty similar. There are some minor differences, but what's the pain point?
[00:26:43] TLH: The pain as in there's a lot of work to be done, rather than – Yeah, there's just a huge code base that there's a lot of work to be done. That's all. Yeah, and that takes time. You have to make sure that every code that you change or transform still works at its intended. Yeah, I think that's the main problem.
[00:27:04] KA: In Svelte, have you tried typescript in Svelte?
[00:27:08] TLH: Yup. I managed to make a PR language tools last week, because we just merged this, okay, upcoming feature for Svelte. I think in a Svelte component, basically, you have slots. Basically, you can't know where the user of your component, whether they pass in a slot or not. Back then, it's not possible to do it, unless you go through the props and figure that out yourself. The next version of Svelte would have a syntax called dollar, dollar slots where you can basically get that to know, to figure out whether a certain slot is being passed in.
I was thinking, hey, this is a new thing. I think I should add it to the language tools as well to get the type checking for that, at least when you type another slots and then you press dot and then it should suggest you the slot’s names that you use, that would be cool. That's what I was thinking.
[00:28:04] KA: That's exciting.
[00:28:05] TLH: That is already merged in. You still can't use dollar, dollar slots yet, but I think it's working now, basically, I guess. Yeah, but the syntax itself is not available in Svelte yet. We haven't published a new version.
[00:28:16] KA: All right. Do we have any last questions?
[00:28:20] AJ: No. I mean, I don't have any questions. I was just going to say that I think Tan Li is basically, the slots man. King of slots.
[00:28:29] TLH: I learned a lot from slots. Yeah, in the very beginning, it's very confusing, but I learned a lot and there's a lot of bugs that yeah. I learned a lot, basically with this.
[00:28:40] KA: All right. We're going to go into our second segment. First, a word from our sponsor.
[SPONSOR MESSAGE]
[00:28:52] KA: Are you looking to get better at building websites in Svelte? Well, you're in luck. LevelUpTuts has tutorials on how to get started. Check out the Svelte for beginners and Sapper for beginners courses at svelteradio.com/level up. Now we're back to our regular topics. First up, we have plenty. What's plenty? Anyone.
[00:29:17] SW: I don't know where it came into my consciousness, because I think it was on Hacker News a few weeks ago. They build themselves as a site builder. I think of them as a WYSIWYG CMS. They can edit directly on the site. I’ve seen this before with forestry's Tina CMS and there's a bunch of CMS's that let you directly edit elements on your page. If you go to plenty.co, you can just type in – you just edit parts of the page and that's interesting. It's built with Svelte.
[00:29:45] AJ: A good choice. A good choice. Always a good choice. Yeah.
[00:29:51] KA: All right. Then we have Sheperd.js. This is pretty cool, right? How would you describe this, you shepherd your users on your website to the correct features? It highlights your – how would you describe this? It's like a tutorial walkthrough.
[00:30:09] TLH: Yeah, a guided walkthrough.
[00:30:10] KA: Yeah, walkthrough. That that's good – a good way of describing it.
[00:30:14] SW: It feels like a cartoony type of vibe. Actually, it's pretty similar to Li Hau’s own site, because it has the black borders, very thick shadows. Anyway, I think it's a tool for doing walkthroughs and I think this is something that I haven't needed to implement something like this, but if I needed to do a product walkthrough, I’ll use something like this for sure.
[00:30:36] AJ: Yeah. I think it's something that we would use actually. We are using one, a competitor right now, but we're pretty unhappy with the competitor’s bundle sizes and all sorts of other things. Definitely something I’ve been looking into.
[00:30:48] KA: Interesting.
[00:30:50] SW: CodePen actually uses another version of this as well. I’m not sure what they call it. They talked about it on CodePen Radio, the thing that they used to do in product walkthroughs. I think there are a bunch of these tools out there. I just haven't needed them.
[00:31:03] KA: This one is built in Svelte, right?
[00:31:06] AJ: Exactly.
[00:31:10] KA: Okay. Should we talk about this, the Svelte scale thing, that F. Nelson did?
[00:31:16] SW: Yeah, sure. I’ve looked at it a little bit. Honestly, I don't know why he decided to do it this week, but this has been a very, very long standing question about Svelte's overhead, because Svelte, like Li Hau says, if you go through the compiling, you understand that there are some parts which are quite repetitive and that's based on Svelte not having a runtime essentially, or having a very, very small runtime. Rich Harris also talked about this at the Svelte Society Day final talk, where he said there is a crossover point. When we get there, we can actually figure out how to optimize it, because Svelte is a language.
What F. Nelson actually did was to essentially run the simulations by bootstrapping pieces of source code from zero source kilobytes to 80 source kilobytes and then translate that to a bundle size of zero to a 150 kilobytes, just seeing how much does that actually generate. How big does your source code base have to be to generate a bundle size of a certain amount? Then plotting a line, like a regression line and then doing the same exercise for React and then plotting the Svelte line versus the React line and seeing where the crossover comes in.
Then, he concluded that the crossover point is a 120 kilobytes, which is pretty interesting, because that's roughly the exact size of the React runtime itself. Meaning, that when you get to a point where your Svelte output, your swap compiler output gets to the size of React, then you're actually start – you're starting to be better off using React instead of Svelte.
His final point after arriving at that crossover point was that you never get there, because Svelte component source sizes are so small that even the Svelte dev site only gets up to 40 kilobytes, not a 120. The real-world medium clone Svelte site only gets up to 25 kilobytes. You never get to a 120. The conclusion is yes, it scales.
[00:33:10] AJ: I think it's worth that final point clarifying that it is actual Svelte source that has to reach that file size. That's a lot of sources and that's a huge amount of source. I don't think all of our applications combine that with built Beyonk are a 120K. If you're building application that big, I think maybe it's even time to consider breaking it down to multiple applications, because I can't imagine how big the application gets at that point. Yeah, it's a pretty important finding, I think, that the crossover point is almost impossibly high and a lot of users will never ever reach it.
[00:33:41] KA: There was a point about code splitting, right?
[00:33:43] SW: I think when we talk about bundle size, what we're concerned about is actually bundle size correlates to how fast a user downloads your application and actually sees the code, which means that what's the minimum size of code that you need to be in the browser before you can actually interact with the application? My point is you usually won't go there. Even, you mentioned that the whole site takes 34 kilobytes, but that's the entire site. You don't have to download everything to just see the website.
I mean, if you say you want that, I don't think any user would go through from the first page to every page, like staying within the same session. Most probably, he will go visit the first page and then close the tab and open again and go to another thing. You don't really need to download entire site to just see the site. You just need that page. That is where you do code splitting, where you basically break down pitch level and then probably if the page is too big, then you break down by component level, where anything that is below the screen where you don't see it on the first time, you don't really have to load them, that would be the code splitting part. I mean, the entire site is 34 kilobytes, I think. I get the number. If you do code splitting, then per page is nowhere near there at all.
[00:35:04] AJ: Yeah. If you look at the way that Sapper does code splitting, for example, every component is almost a different chunk, so it does a lot of that heavy-lifting of splitting for you.
[00:35:14] KA: Good news for Svelte, I would say, follow this. One element of that is also that he looked at Preact and he also found that Preact had a shallower curve than Svelte, which I think was a very good point in favor of Preact. I think that maybe the other difference then comes with the other out of the box features with Svelte compared to Preact.
[00:35:36] AJ: I think what Preact, is only 3 kilobytes, I think, isn't it?
[00:35:40] KA: Yes. Yes.
[00:35:43] AJ: Pretty small. Super small.
[00:35:46] KA: I think this comparison was also with the animation library included, as well as some other part? I think I read that somewhere. Maybe I’m misremembering though. I’m not sure. Anyway, let's move on. The new Svelte Society website. Well, sort of new, kind of new. Last night, or was it the day before, recently anyway, I merged the staging branch into the master branch and so we have a new website. It looks the same, but it doesn't have – the earlier website was only the website for the Svelte Society Day. Now it's the actual website for Svelte Society. All the recipes are there. It's under heavy construction, something I’d like to say. We're looking for help, if anyone is keen on contributing, we welcome that. If you want to add recipes, you do pull requests with a new file.
[00:36:44] SW: Yeah. I think the recipes effort was quite successful. We got quite a bit of contributions. Honestly, I think now it's a matter of publicizing that we have them and then making it easy to contribute back. I don't see an edit button here, so you probably need to –
[00:36:59] KA: Yeah, that's a good idea.
[00:36:59] SW: - probably need to GitHub. Yeah. I mean, hopefully Svelte Society can be a nice second layer on top of the core Svelte API docs.
[00:37:09] AJ: I think another, yeah, another good thing is if you see one of those recipes and you're an expert in that particular field, then by all means, feel free to improve it and make it more concise, proof whatever else. Because I think a lot of it is written by somebody who's discovered how to do something and maybe it's not the best way. All that stuff is good as well.
[00:37:28] TLH: It looks great.
[00:37:31] KA: Yup. Congratulations. It was time to get this merged in. Yeah, things always take too long, or longer than you think, unfortunately. All right, Flare in Svelte. Have you guys used Flutter much?
[00:37:52] SW: Only for the first time this week, because we launched a Flutter – we launched Flutter support at work, so AWS now supports Flutter. People are very excited about that.
[00:38:02] KA: It’s like amplify for Flutter?
[00:38:04] SW: Yes. People are like, AWS is supporting Flutter. It's a thing now. No, it's one service in AWS supports Flutter.
[00:38:14] KA: It's better than zero.
[00:38:16] SW: It's always funny how you can tell the person is biased by how they spin things. Anyway, so it's a start and I tried it out. It's basically, a more type safe React, which is pretty funny about all the new UI paradigms. Is it 50Y?
[00:38:32] AJ: Yup. Yup. It’s 50Y.
[00:38:35] SW: Yeah. Okay. There's 50Y, there's jetpack compose from the Android team and then there's Flutter, all of these are all React inspired. All their APIs are heavily, heavily React inspired. It's just weird seeing React paradigms in other languages. It's like, Flutter is in Dart and then the others are in other languages. I think one thing that's definitely in its favor is that it's got a better standard library, like anything that you want out of the box, icons all the way down to scrolling – infinite scrolling lists. All there. It's definitely much more convenient than having to find your own.
[00:39:09] KA: Yeah. Yeah. I remember trying Flutter for a bit after using React Native for a while. I was pleasantly surprised by it for sure. Flare is something that you usually use to make animations that you can just import straight into Flutter pretty much. Someone made a Svelte, I don't know what to call it, a library or wrap – Yeah, yeah. Something that makes it possible to import the animations into Svelte as well. That's pretty neat.
I haven't used the tool to make the animations, but it's supposedly very easy to make. The downside is that you have to import the flare.js library, which is 7 megabytes big. A bit too big for the web, but maybe if you can make it work for Svelte Native, that would be cool. I haven't tried it, but maybe.
Time for our second sponsor spot. We'll be back in a bit.
[SPONSOR MESSAGE]
[00:40:08] KA: All right. Our second sponsor is Mono Company. Mono is a digital product studio that works remotely. Within the Svelte community, you might know Wolfer. He's designer that worked on the Routify website and he also has worked on the Svelte Society Day website, as well as the Svelte Summit website. He wanted to sponsor this episode with a simple message that as a design team, they are open for new client projects and they have extensive experience designing web applications with full-on custom design systems.
Mono is typically responsible for the UI and UX in a project and they work alongside developer teams. They love designing web apps and want to support Svelte, because it's an awesome framework. Check out their website at mono.company. That's M-O-N-O.company. We have some meet-ups to talk about.
[00:41:02] SW: Yeah. I put some in here just to try to raise visibility for them, in case anyone is in a position to join them. I think the first is Svelte Brazil is coming up on 1st September, which is next week. Yeah, if anyone is speaking Portuguese and/or is in Brazil, I would join. I think they seem to be quite active. I think they have a monthly meet up going, which is pretty cool.
[00:41:25] KA: Yeah. Then Svelte Society Day friends at the of September.
[00:41:29] SW: Yeah. That’s the end of September. I got more talks than Svelte’s Society Day got, which is great. I am not going to understand them, but we can check it out and see what's up in the French side of things. The organizers are just really responsive on the ball. It's pretty exciting to see. I think the cross-language element is something that I’ve never personally done in terms of community building, but it's actually pretty high potential for Svelte at least, I think.
[00:41:57] KA: Yeah. I’m going to bank on YouTube's auto translate thing.
[00:42:02] AJ: Good luck with that.
[00:42:02] KA: We’ll see if that works. Yeah. Svelte Philippines. This is new, right?
[00:42:09] SW: Because of where the community is, they run it as a Facebook group and it's private, so I cannot see when their next event is. If you are in the Philippines, check it out. It's a Facebook group. There's a 150 people there. It's a decent-sized meetup already.
[00:42:23] KA: Cool, cool. All right and then the big one, Svelte Summit.
[00:42:29] SW: Yeah. Give us an update.
[00:42:31] KA: Yeah. We have loads of proposals for talks, which is good, like more than double last time so far. You can still submit proposals as well. If you're interested in doing a talk, it could be long, it could be short, beginner, advanced, intermediate, anyone is open to submit. You can do that on the sveltesummit.com website. Yeah, check it out. Okay, so I think that's all of our topics for today. Do we have picks? I don't have picks.
[00:43:04] AJ: I did have a pick. I’m trying to remember what my pick was. I did have a pick. There's plenty of picks. I think my pick is going to be a really weird, a really abstract one. I just want to say that I bought a dishwasher on eBay. I bought it for 30 quid, because it had a crack in some of the plastic on the side, like the water tank. I basically bought it for 30 quid. It's a 700 quid dishwasher. It's two-years-old.
I got some gorilla glue, maybe gorilla glue is my pick. I don't know. I gorilla glued the plastic and it works perfectly. I’ve now got a two-year-old 700 quid dishwasher. That is my pick, because it's probably the best thing I’ve bought this year. Never mind this recently.
[00:43:48] SW: Gorilla glue is the thing that it sticks to glass and it makes – is that what it does?
[00:43:52] AJ: It sticks to almost anything. The thing it doesn't stick to is this polypropylene plastic. I must say that the dishwasher is polypropylene plastic on the tank. It still sticks. I sanded it down. It sticks fine. The reason I used gorilla glue is because one, it's waterproof, which is impressive for glue. The second thing, it’s actually heat proof, so it can withstand ridiculous heat, like 70 degrees. Also, I think minus 20 as well. It's really, really resilient stuff. It's way better than any glue I’ve seen before. Yeah. Really, really good stuff.
I think the way it works is interesting. The way it works is actually, just a quick mention is that when you put it on something, it actually expands. It expands into any pores it finds on the materials you're gluing. It becomes almost part of the material.
[00:44:37] SW: That's pretty smart.
[00:44:40] KA: Yeah. I wish I was a material scientist sometimes. All right, do you guys have any picks? Should I try to find something?
[00:44:51] SW: I can go. Actually, I’m going to pick GitHub's renaming project. A lot of people are interested in moving and renaming their default branches from master to something else. I think main is the default that people are moving towards. GitHub is doing all the engineering for this for us. They enabled the ability to fall back on branches, I think in August. The thing that they just released as a new feature is to set the default for new projects. When you create a new repo on GitHub, you can set it to whatever branch name you like. That's a new feature as well in git itself. Git version 2.28, which is released this year has a new config called init.defaultbranch that you can name. I wrote up a cheat sheet of things that you can do to do this renaming thing and I put it in the list. Basically, GitHub's renaming is my pick.
[00:45:45] KA: Cool. Nice.
[00:45:47] AJ: Very cool. Yeah, that's nice.
[00:45:49] SW: The one thing that it doesn't have right now is mass renaming. I have 600 repos on GitHub. I’m not going to go through and do them one by one. They're working on a tool to do a mass rename.
[00:46:01] KA: That'd be pretty nice.
[00:46:05] TLH: I have a pick. Yeah, so I was reading – I think recently, I was subscribing to a lot of newsletter. I found this newsletter called Front-end Horse. Very interesting. It's like a horse, as in H-O-R-S-E.
[00:46:19] SW: Yeah, Alex trust.
[00:46:22] TLH: Detailed breakdowns on how do you do a certain animations. Yeah, basically interesting project. I think the latest issue was that they break down a CodePen telling you the individual techniques and how to achieve that. That was pretty amazing. Because usually when sometimes newsletter will just curate interesting projects, or interesting pens, but you have to figure out yourself. Yeah, this is my pick. Front-end Horse, guys.
[00:46:53] AJ: Front-end Horse. That's an interesting one.
[00:46:55] KA: Yeah, it's a funny name.
[00:46:57] AJ: What is this thing with horses? There's the horse of JS and all sorts of things like that?
[00:47:01] SW: Yeah. That is JS. I think that's unrelated. I think there's a horse TLD and it's just better than .com.
[00:47:11] KA: It's an actual TLD – hyphen and dot –
[00:47:13] SW: .horse.
[00:47:14] AJ: That's great.
[00:47:16] KA: I thought it was just part of the name or something. I guess it is. Yeah. Okay, so my pick is a YouTube channel, a guy called Kevin Powell. He does CSS stuff and I’ve been binging on his videos the last week or so, learning a lot of neat CSS tricks that I didn't know about. I’d highly recommend it. You can do a lot of things in CSS that you couldn't really do before. They're very neat. You can get rid of a lot of JavaScript and just use CSS instead.
All right. Cool. Those are our picks. That was it for this week and we'll talk to you guys in a couple of weeks again.
[00:47:58] SW: Thanks to Li Hau for being our guest.
[00:48:00] TLH: Thanks for having me.
[00:48:05] AJ: There’s a lot more people listening now.
[00:48:07] SW: I know, right? Thanks to the people in the audience for staying silent in the entire time.
[00:48:17] TLH: Thanks for having me. Tt's been very happy to be on here. I’ve been listening for you guys for the past few episodes.
[00:48:24] AJ: He’s a true fan.
[00:48:27] TLH: Yeah. There's a lot of things to learn about Svelte. I think that's the only – it's rare to find Svelte podcast or newsletter, I guess.
[00:48:35] KA: Yeah, for sure. For sure.
[00:48:38] TLH: You guys did a very good job of curating interesting projects that's coming out on Svelte.
[00:48:42] KA: Thanks for the kind words. All right. Bye, guys.
[[00:48:46] TLH: Bye.
[00:48:46] AJ: Bye.

Please note that Dev Shows isn’t affiliated with the featured podcasts. Each podcast’s content (logo and other images, audio, and text) is property of the show itself. Their content is retrieved from the show’s RSS feed and may contain the occasional error, such as an MP3 audio URL that doesn't work. And, of course, any opinions expressed, or product endorsements made, by a show’s host(s) or guest(s) are theirs alone.

All other content is © 2020–21 Dev Shows.

Made by Bruce.
I’m a freelance developer available for hire.

Audio Player

-
--:--
--:--