Lompat ke konten utama
EP 103

Ngborolin Svelte feat. @lihautan

Ringkasan Episode

Bantu Koreksi

Episode ini membahas tentang Svelte dan Svelte 5 bersama Lihau, seorang Svelte maintainer yang bekerja sebagai Front-end Engineer di Shopee Singapore. Lihau berbagi perjalanan menjadi maintainer Svelte yang dimulai saat pandemi COVID-19 ketika ia mencoba membaca kode Svelte di GitHub dan membuat pull request kecil. Diskusi mencakup perbedaan antara Svelte dan React, keuntungan menggunakan Svelte untuk animasi dan transisi, konsep compiler Svelte yang mengubah kode menjadi vanilla JavaScript, serta perubahan besar dalam Svelte 5 yang memperkenalkan runes untuk universal reactivity. Episode juga membahas tentang SvelteKit sebagai meta framework resmi, contoh aplikasi populer yang menggunakan Svelte seperti Apple Music dan syntax.fm, serta tantangan dalam mengadopsi framework baru di lingkungan perusahaan.

Poin-poin Utama

  • Lihau menjadi Svelte maintainer setelah membuat beberapa pull request kecil saat pandemi COVID-19, dibantu oleh kebetuan bahwa Rich Harris sibuk dengan proyek COVID di New York Times
  • Svelte bekerja sebagai compiler yang mengubah kode menjadi vanilla JavaScript, sehingga tidak ada runtime overhead di browser, berbeda dengan React yang menggunakan Virtual DOM
  • Svelte 5 memperkenalkan runes dan effect hooks yang terinspirasi dari React hooks, memungkinkan universal reactivity yang bekerja di mana saja dalam kode
  • Shopee masih menggunakan React untuk sebagian besar proyek karena maintainability dan familiarity, bukan karena keterbatasan Svelte
  • Lihau merekomendasikan SvelteKit sebagai meta framework resmi untuk sebagian besar use case, dari blog statis hingga aplikasi dinamis dengan server-side rendering
  • Contoh aplikasi populer yang menggunakan Svelte termasuk Apple Music, syntax.fm, dan PocketBase admin UI
  • Tim Svelte menggunakan test suite yang komprehensif untuk memastikan backward compatibility saat mengembangkan Svelte 5, dengan test case yang dapat dilihat langsung di repository

[Menelefon]

Halo, halo, halo.

Selamat malam.

Selamat malam, teman-teman.

Selamat malam. Apa kabarnya?

Hari ini selasa malam.

Selasa malam, tanggal 29 Oktober 2024.

Ini waktunya.

Ngobrolin web.

Nggak ada yang ngomong, waktunya ngobrolin web.

Ini bertepatan juga.

Hari ini apa, kemarin ya?

Hari Sumpah Kemuda itu kemarin ya, 28.

28, 28?

Iya, 28.

Ini kan hari kesatuan pasal C, Pancasila itu?

Pancasila itu September.

Habis komen.

Habis nonton film itu.

G30us besoknya, 1 Oktober.

1 November?

Kok November?

Oktober lah.

Yalah, kan habis G30us.

Udah lewat.

Perlu penataran Pempat lagi semua ini.

G30 Oktober kan?

G30s.

G30s, wey.

September?

Lihat transkrip lengkap (516 segmen lagi)

Senuari?

Yang jernas Kamis ini di Wali.

Di Wali?

Gak ngikutin saya, maaf.

Di Wali?

Di Wali hari Kamis 31 ini.

Pasti tau gara-gara selama berapa.

Tanggal Merah ya?

Tanggal Merah di Singapura.

Apa sih?

Malaysia Singapura punya komunitas keturunan indianya tuh ngerayain di Pavali kan ya?

Di Wali.

Nah tanya aja sama Kresna nih, tuh.

Kresna lebih mengerti sepertinya nih.

Kayaknya di Bali nggak ngerayain di Wali?

Nggak, beda.

Oh beda ya?

Itu kayak kultur.

Kultur.

Seperti ini mirip view.

Nggak, ada miripnya.

Agak beda, agak beda.

Ya beda.

Agak beda.

Mirip dalam arti, kayak apa tag-tagnya itu bentuknya.

Elementnya, menyerupai, deket sama HTML.

Nggak JSX.

Tapi cara kerjanya beda.

Oh berarti temen-temen di sini jelasin cara kerjanya.

Ini di mana ini?

Oh nanti kita tanya.

Berarti beberapa teman di sini ada yang belum familiar dengan Svelte ya berarti ya?

Kecuali Kresna ya?

Coba di chat pada tui siapa yang pakai Svelte, siapa yang...

Hindu di Bali tidak ngerayain.

Oh iya, sorry, sorry, salah.

Iya, makanya kultur India.

Saya suka kebalik-balik.

Kapan saat terakhir, kapan saatnya tepat mempelajari Svel?

Saat yang tepat sebenarnya kemarin.

Saat yang kedua saatnya paling tepat adalah sekarang.

Ini mengumpung Svelte 5 nih, mengumpung Svelte 5.

Jadi, ajarannya jadi lebih enak kan ya.

Kenapa sih sebenarnya?

Gimbal paling besarnya apa Svelte 5?

Svelte 5 di rewrite ulang semuanya.

Wow.

Ya, tapi bentar tadi siapa yang udah pakai Svelte, siapa yang belum bentar?

Svelte itu dikembangkan kurang lebih 18 bulan, 1 setengah tahun ya.

Ya, jadi yang bikin itu si Mas Rich Harris itu ya.

Pas dulu beliau masih kerja sebagai developer di New York Times ya, di online media.

Terus abis itu, ya dari awal Svelte sampai Svelte versi 3 atau 4 ya.

Abis itu dia dipekerjakan oleh Versel untuk kerjain Svelte secara full time.

Memaintain hal full time.

Jadi Svelte sebenarnya sampai versi 3 itu masih kayak side project ya hitungannya.

Project sambilnya karena si Mas Rich Harris itu masih nyambi kerja sebagai developer.

Cuma di sana maksudnya kerja di media, terus karena ada kebutuhan buat kerjaan,

bisa difasilitasi, maksudnya dikasih waktu buat bikin framework,

sebenarnya compiler library sih, cuma kan suka disebut framework, bikin framework sendiri.

Maksudnya di sana ada kultur, ya udah, di sana boleh bikin apa yang terserah.

Kalau di kita tuh ada nggak sih, misalnya yang terjadi kompas online atau di-pick atau apalah gitu,

buat kebutuhan itu, terus ya saya mau bikin framework aja Pak.

Paling internal, ada, paling internal mungkin ya, nggak dipublish.

Oh iya ya, kalau internal sih umum sih, cuma ini yang bikin oleh Carmen di open source.

Dan memang dijarin generic bukan cuma buat kebutuhan dia bikin artikel, bikin website in your control.

Iya, ini ada info juga nih, katanya dia itu bekerjanya sebagai designer bukan developer.

Si Mas Rich Harris.

Cuma kelihatannya kalau, ada beberapa cerita.

Bukan, ada divisi desain, maksudnya kayak department.

Oh dia developernya.

Cuma maksudnya skillsetnya bisa aja dicampur.

Jadi maksudnya department desain, cuma nggak tahu job titlenya exactly gimana.

Cuma maksudnya kalau di beberapa tempat di luar tuh, desainnya tuh nggak selalu berarti harus UI atau visual design.

Seingat saya sih dia tugasnya adalah membuat visualisasi-visualisasi di...

Data face.

Data visualisasi kan, makanya dia selain bikin spread juga bikin ada library.

Library, apa itu namanya yang bisa chart, charting tapi bisa tanpa jelas.

Css doang, css doang.

Orangnya gila, orangnya gila.

Cuma karena itu balik ke kebutuhan itu kan media online kan.

Selain harus bisa nampilin visualisasi data yang kompleks, harus ditampilin dengan enak dicerna.

Tapi harus cepet juga kan, orang baca berita buru-buru.

Harus bisa diakses dalam, mungkin ada versi AMP-nya, EMP-nya yang JavaScript-nya juga terbatas.

Jadi harus bisa.

Dan pas banget malam ini karena kita kedatangan tamu spesial dan karena tamunya spesial terpaksa kita mulai dari detik ini kita harus berbahasa Inggris.

Let's speak English.

Kita orang berbahasa Indonesia dengan lancar.

Kita orang berbahasa Malaysia saja.

Eh bisa?

Betul, betul, betul.

Kita berbahasa Malaysia saja.

Jadi, please welcome Lihau.

Hello, hello.

How are you Lihau?

I'm good.

Just got off from work and thanks for having me.

Thanks for coming over here.

Nice to meet you.

Can you play the piano?

I try.

So, before we get started, we already started anyway, but before we ask you some question or you ask some questions,

how about you tell us some introduction about yourself and what you do.

Okay, hi everyone, I'm Lihau and I'm a front-end engineer at Shopee.

I'm based in Shopee, Singapore.

So, yeah, that's about myself.

So, that's about myself at work.

Outside of work, a few years ago I participated actively on the Svelte in open source

and also Svelte.

And these days I'm mostly busy with work, but I will go to maybe speak at conference once a year or twice.

I'm just trying to get to know new people and maybe as an opportunity to just travel around to see people.

You're based in Singapore, right?

Yes.

I watched you online when you gave a talk for Svelte Indonesia community during Covid.

Oh, yes, yes, I think that was when I first started going to speak and just meet new people online.

Yeah, before you get famous.

No, I'm not famous.

I'm not famous for watching your talk before you got popular.

No, I'm not popular at all.

I don't think I'm popular at all.

I'm just, yeah, thanks for all this.

So, how you get started to become a Svelte maintainer?

Okay, I think I've shared with some of you before.

But let me quickly go through the story.

I think it's an interesting story.

So, it was during, so first of all is at my work, I'm really interested in learning about build tools.

And so I'm more on working towards like the help of my team to webpack.

And I find it interesting, I find like upgrading like React, Webpack, ESLint, this kind of tools interesting and challenging.

You know, like reading through the documentation and figuring things out.

So, this is basically things that I've been doing at work.

And that's how I got into like figuring out like how things like how open source library works.

I think that is the first time I got into know about there's actually people, there's actually like open source libraries.

What actually means is that there's actually code that is on GitHub that you can actually go and look at.

And so that's where I get into and like trying to understand all these projects.

And during COVID I was very, like everyone is stuck at home, nothing to do.

And I was like scrolling through Twitter and I saw this new framework was released in 2019.

I wouldn't say it's released, there's a new version 3 that was coming out, Svelte 3 during COVID.

A lot of people, like some people around me that I follow was talking about it.

And I was very curious and I realized that they also have their code.

They also are open source projects, they have their code in GitHub.

So I decided to like clone the code and take a read and like trying to figure out actually how does it work.

Because it feels very magical to me.

And to be honest, the first time I read it, I don't even know where to start.

I don't even know how it works.

But so I think like basically I know like okay this is the entry, like you know in the package JSON there's a main file and there's an entry file.

So that's basically that's how it starts, right.

And so basically I try to comment things out and see like oh where, which part is where.

But it doesn't get me too far because it's quite boring and I don't even know what I'm trying to look for or try to figure out.

But it just happens, I think I got lucky that I found like there's this file, there's this module that says like,

there's some like comments that says to do like we need to have a better way of implementing it.

And I can't remember exactly which one, maybe it's like a debug tag or something,

which is like very obvious by the name, the function itself, it's related to something.

But just so I try to like maybe figure out what the comment means and try to make that change.

And so I remember that time I make some changes and then commit and then push and make a pull request and then I go to sleep.

And then nothing happened, yeah, nothing happened.

So it was a few after a few more days until like oh I saw someone like comment on it and like oh this looks good to me and then got merged.

And then only like oh okay.

I was like oh okay, but I think it's probably because the thing that I made was like not a big change,

it's just changing a few lines of code that makes it like easy to review and merge.

And so I got more motivated, I feel like oh I think this is something interesting.

Maybe let me try and read more and try to find out like is there more to-dos or is there more issues that actually I can understand and I can try to do.

And that's how I get started, like making more pull requests, yeah.

And I have to say I got very lucky.

During that time it was COVID, the main maintainer, Rich Harris, he was at that time he was at New York Times,

which is very very busy with building the news reports about, you know, remember, I kind of remember like during COVID there's a lot of news.

Interactive.

Interactive.

Interactive COVID.

Information, yeah.

Yes, yes, exactly.

Yeah, all those things and it's, I think he's very busy building all those websites and he don't have time for Svelte.

And I think I got very lucky because of that as well where no one is looking at it and I managed to like make a few more pull requests until they notice like oh how about do you want to join us, be part of the team.

Basically means like add us, I will add you into this special group chat, you know, so that if you have any questions you can ask there, things like that.

Yeah, and that's how I got involved into like Svelte.

Oh wow.

So you're just lucky.

It's not lucky.

It's a combination of luck and perseverance, like hard work, consistent hard work.

And the moment, yeah.

And the time and the time as well, right?

Yeah, like I think like if I, at that time I don't, because of my work, I wouldn't know that oh actually you know open source means the code is in GitHub and those are just JavaScript where you can use it.

Those are just JavaScript where you can understand, because I, in my work I did something like we were trying to, when we're trying to upgrading some of the build tools we have to figure out like oh why this doesn't work and then make like issues, create issues and like actually maybe like show that oh this line of code doesn't work and then make questions and stuff like that.

And it was then realized that oh actually you know it's not some magical things that happen behind, it's all JavaScript.

Yeah, it's important to understand that.

We can even fix it because we need it for work.

Yeah, let me, let me do the full request.

Did you get any t-shirt?

Like swag.

Yeah, is there a swag for being a maintainer of Svelte?

I don't have, I don't have something with me right now.

But I remember, I remember the first time I was, the first Svelte Summit, I was there.

The first one after the, after COVID.

The first physical one.

In the UK? I think in Sweden?

I was at Sweden a few years ago. Yeah, yeah.

After COVID?

Yeah, after COVID.

Yeah, the first one.

So I got the t-shirt from the conference and I got to meet the people in the first time.

They pay you to go.

And you can say, oh is that you who refued my PR?

Yeah, exactly. I get to meet people, I get to see that, oh, oh, this is, this is how Rich Harris looks in real life.

Oh, you met him in real life, yeah. Oh, nice, nice, nice.

Yeah, yeah. It was, it was, it was very interesting.

Like people that you, you heard about it online and you managed to see them in person.

I think especially because in, yeah, I think especially because in Southeast Asia, even when we go to meetups and conference,

usually you don't, I mean some of the packages or libraries that we use sometimes,

I use, are created by people from say America or from Europe and they maybe don't come here often.

So it was interesting to be there, to see them in person.

Yeah. But I've heard, I've heard Evan Yu in Singapore right now, no?

Yes, yes, yes. And so, so you guys should come to, I mean if anyone wants to meet Evan Yu,

you should come to Singapore for conference.

You met him at any meetups?

Hockerhoods, no, no.

Someplace, randoms.

Not Hocker, I don't think we stay near each other. He probably stays somewhere like condominiums or like very rich place.

But I think, I don't know, actually I have no idea where he's staying.

But he's, he's, he's in, I think I've seen him in conferences, like there's like one conference.

So he's active in the local developer community.

I think he, he does show up in local community, conference or meetup.

Yeah. But, yeah, yeah.

So now we can go to DevFest Singapore. Let's see if Evan Yu is coming.

Evan Yu speaks?

Yeah, you should invite him to speak.

Yes, meetup maybe.

Invite him to speak and then, yeah, then he will, he will show up.

That will be interesting topic now if Evan Yu come to any DevFest in Singapore and the topic is why you don't need Angular.

And let's just use Vue or something like that.

Vue.

Yeah, I guess that will be interesting.

So, so in your day-to-day life, day-to-day work, you don't use.

Do you use Svelte?

You use React, right?

Oh, no.

Oh, no, yeah.

I think, I think there's a huge part of, the most part of Shopee is written in React.

There is a bit of Vue.

I think in the, in the very beginning of Shopee, people are more, Evan, like because we are like just starting, like start up and we are all very adventurous on choosing all different frameworks.

And as team grows bigger and bigger, I think people are thinking more on like maintainability.

Maintainability, yeah, how many developers use it.

Yeah, and also like maybe on how easy to transfer people around on different projects, right?

Maybe like, I think it's also part of maintainability where if someone is, maybe you have a team of people working on this project and maybe some of the members left, then can anyone help to maintain or do they need to learn something new to come in and maintain these projects?

And, and I guess it's like organically slowly people choose like similar things or maybe we have new projects coming on and this person have been using React and setting up a new project with React is much easier than starting everything from new.

And because you have to deliver features and deliver, yeah, features, right, fast. And so, so you use the same thing that you've been very familiar with or you already have a lot of libraries or utils that is like in-house that you can use with.

Yeah.

So, so I think most of the projects.

As far as you know, there is no spell in Shopee.

As far as I know, most projects are not written.

Yeah, I think most, as far as I know, most projects are written in React.

But I don't, I don't think that that will be, we will always stay with React forever, right? I mean, but I guess it just needs to.

I think data, the data is the most important thing to like, I see the part of the question is also about how to convince.

Have you tried to convince your, your like your supervisor or something like maybe for a microsite, something, something apart from the main core app?

I actually have not really tried very hard to convince.

Okay. Yeah, I've been focusing on other problems at work rather than, yeah, and rather than the frameworks and stuff.

But I think recently, yeah, but recently we are also looking at performance.

I think that would be one aspect that we can see or talk about when, when, when we reach the state where, you know,

we reach bottlenecks of how much we can improve based on the current frameworks and stuff.

So I think we are still very early on in performance improvement.

I think we have been focusing a lot on delivering features and features.

And basically before you optimize this code, maybe we already delete the code and, you know, build new features and rewrite and factor and stuff like that.

But I think Shopee now has been more mature and it's time to like consolidate things and like look at like how to improve the performance of certain critical pages and stuff.

Then maybe by the time when we do all our best to optimize and we still think we can do much better,

then maybe we can like, you know, make some proof of concept or some data to demonstrate that.

So the data can be, of course, the data can be a lot of different dimensions, right?

One is like the performance is better written in this way than the other.

Maybe like bundle size, LCP, core vitals, and data can be also including like resource,

like how much time you need to learn this thing and use it to implement this and yeah, all sorts of data.

Then I guess that would be something that would be a more comprehensive proposal that you can bring up to someone who can make the decision.

Okay, this is another question.

Why do you think that people tend to use something like React compared to new framework like, yeah, like Spelt or even Astro or Quake or another new frameworks?

I think people are just, if you ask me, I think it depends on what kind of projects you are on

and what kind of experience you have been and what are the requirements that you need to deliver, right?

Maybe you have a lot of experience with Mearn and MearnSnap and maybe right now your requirements is you need to deliver a new feature very fast, right?

Then maybe you don't have time to learn a new thing to start from scratch or you have a lot of past experience to draw from.

Then I think it's much, it makes a lot of sense that you just do something that you are very sure of the results and you have a lot of experience

and you know that whatever problems that you face, you have already experienced know how to handle those.

So it's a more controlled situation rather than a lot of unknown unknowns, right? Of course like, so it depends on situation.

Maybe you have a lot of time and maybe this is not a very critical project, then maybe you can try and maybe it's okay, like projects that you are okay to fail, then yeah, right?

You can be more adventurous.

Yeah, so my question is related to what you just mentioned, like what types of projects, what types of web apps would you strongly recommend people to use Svelte for over other libraries or frameworks?

And on the contrary, what types of projects that you really don't, you don't really recommend using Svelte, like maybe pick something else?

Well, assume there is no external constraint like, I don't know, like team, your colleagues only write react, like disregard those factors.

Yeah, so what types of projects would you recommend for Svelte?

I don't think there's, I think if you ask the same question of what kind of projects that you would recommend people to use react and what kind of projects you would recommend people not to use react, I don't think there's a clear answer for those things.

Like there's a lot of, even like there's all sorts of applications from simple like blog to even like things like very complicated like Figma or some like Photoshop, all those are very complex stuff that you still see people using react to build a lot of those things, right?

Or even like the stream yard or like some video conferencing, calendar, all this that you still see people using react for those things and they work well in all sorts of situation, right?

So I would say the same as Svelte. Of course, like comparing to react, like Svelte is, I would say it would be much easier to use and it's much more performance and it's smaller.

And I think if it's just comparing side by side with Svelte and react, then there are certain situations, I find it so much easier to write it in Svelte than react would be things like you have to, when you're trying to do with like animation, transitions, those kind of thing, it's so much easier to work with using Svelte than work with using react.

Okay. I remember one, sorry, I remember one. Sorry. Eka, eka, eka. Go ahead.

No, no, no, just. There's a delay seems like. Yeah, there's a delay. I remember one article said that Svelte is for side, react for apps. Is this still relate?

A case. Until now? True.

This is four years ago. Yeah, this is 2020. Does it still hold true now? After react has so many new features, same with Svelte, so many new features. Does it still hold true?

Okay. I can't remember what's the argument for this one right now, but I don't think it's, I don't think that's the intention of this article. I think the article is, how should I put this, I think the main, my understanding, deeper understanding of, okay, my, from what I remember, the goal of this article is actually trying to say that

if, if you want to, like it's trying to build, bring like some ideas for people to say that, you know, instead of having react for everything, you know, maybe if you're building certain sites, you can think about using Svelte because it is really good.

It's much better than react when using it, but it doesn't mean that Svelte cannot be used for apps and stuff like that. It's just because at that point of time, everyone is using react for everything, right? So, yeah.

Like there's a world, there's, there's something else outside of react in the JavaScript web dev ecosystem. So the point is more like that rather than here, Svelte is for this and react is for that.

Yeah. Yeah. Because I remember back then, 2020, we have things like, what's the blogging thing.

Like the, there's a react framework that builds like static sites. Yeah. Yeah. And it's like, it's, it's, I remember like using Gatsby and like frameworks like this is, it's very heavy. Like it does a lot of things under the hood and like overcomplicate. I feel like very over complicated, right? It uses the graph QL and then like all sorts of things.

And most likely, most people just use it to build blocks, which is a very static, relatively static sites with a little bit of interactions. And like having react is like over too, too, too heavy, right? So, yeah. So, so I think the article goal is that, you know, instead of thinking every react for everything about for sites like that's like lightweight and static. Maybe if you just need some interactions, maybe you can consider Svelte.

Right. Yeah. And I think that's, that's the goal of the article rather than say that Svelte cannot use for applications and anything else.

Okay. Yeah. And I think at that time Svelte felt very novel, like very innovative because react, you know, use the virtual DOM. And then you have to include the react bundle in the build, like your website, your webpage actually contains react. Whereas Svelte works more like a compiler. Is that correct? So it process the JavaScript, spit into regular vanilla JavaScript. And that's what you use on your webpage.

So on your webpage does not actually contain any Svelte at all. So there's no overhead. And I think Svelte was the first to adopt that approach, I think. Is that right?

Now I think Solid or something use the similar principle. I think a lot of frameworks now have realized that there's a lot of optimization. There's a lot of rooms for optimization that they can do if they move some of those things to compile time.

Basically during build time, you can analyze the application and maybe do something to optimize the application that to the JavaScript that the user receives and save some of those time needed for the users when they have to run it on the browsers.

And I think a lot, as Eka mentioned, frameworks like Solid, I think even Vue has some build time optimization and I think even Angular and all this, they all have some sort of optimization.

Even React, right now there's like React forget, right? React compiler. So instead of you having to optimize your entire application with all the use memo, use callback, it actually analyzes everything.

You don't have to write those. And actually the code in general is even more optimal than the one that you would ever have written using the use memo.

Even the JSX that you return, all of them, they will try to optimize such that you don't have to recreate all those objects again.

All those things. So I don't know about the full history, I don't know whether Svelte is the first one to do it, but I think comparing what amongst those current big famous frameworks, I think Svelte is probably definitely one of the earlier ones to do it.

It's interesting though, you know React has compiler now, so React is in a way kind of turning into Svelte. And Svelte has like the rune, the new effect hooks, kind of like React hooks, so Svelte turning a bit like React, like they're just merging.

Like this, like this one. Or Effect, right? Like they interact with each other. Yeah, I mean even like Svelte 3, I can't remember the exact thing, but I can't remember the full story about it, but I think I heard this anecdote that someone shared with me before.

Like basically before Svelte 3, which is like Svelte 2, and then React hooks came out, and it was like, it was very new back then, right? 2018, yeah, and a lot of frameworks, like even Vue has composition APIs, was very heavily influenced by that, and I think Rich Harris also saw that, and the thing about how they can use it for Svelte.

And that's how you, that's how Svelte 3 was. It was before the dollar sign. Before Svelte 3, Svelte was written in a very, it was written differently. It was not as, not the situation as you can see right now.

The way like, for example, the use Effect, where like instead of using, like the reactive declarations, like the dollar, colon, something like that, in Svelte 3, those are all like, all setting like, like declare states and stuff, I think those are, they think about all these syntaxes when React introduced like hooks, and then they were like, okay.

This idea of writing or declaring states and effects is interesting, but it's not a nice way to write, so how we can improve it or do something like that, and then therefore like born like the Svelte tree syntax that we see right now.

And for Svelte 5, or the runes that we see right now, is actually born by the limitation of what we can do in Svelte 3.

Because analyzing the entire, analyzing the code base and trying to figure out all these things by, during the compile time by the compiler to figure out where, what variables will change, what variables is used in by template will change.

You have to track everything, and you use some heuristic to figure that out, to make sure that, to check whether which variables is reactive, and there is a lot of situation that, that logic will not, will break, or does not work.

For example, when you move this variable or this statement into another function, then it will break, it will not work anymore, or you move it to a different file, it will not work anymore. You just change, maybe you have a reactive declaration, and you just move the statement into a function, and then you can't see that this variable is a dependency of that statement, and then it doesn't rerun anymore.

A lot of this kind of things breaks when you just make some refactoring, right?

So this is the limitation of the compiler at the moment, right? Because we are not, we don't have, we have no way to figure out what are the dependencies, exhaustively, and figure out everything that we figuring out.

So that's why we introduced some runes to basically to mark, like to mark it, to tell the compiler these are the reactive statements.

You have to pay attention to this, this part, yeah, and maybe to reduce a bit of time complexity, you know, because maybe if the project is very, very large, the compiler then has to work very hard to, you know, to find, to, to detect which parts will be changed and which parts are related, like if you have a function, which pages or which components use the function.

Maybe this will improve performance.

Yeah, I think it will, that's when Spell called it the universal reactivity, right? Basically it's when you have the code that you want it to be reactive, you already mark it with like runes, right? And when you move this code anywhere, whether you move it into a function, you move it to a different file, you move it like across many, many files and folders into a different packages and stuff like that, it will still work.

Yeah, like even like you call a different function, you move into a function that inside another function, inside another function or move it anywhere, it will still work. And that's, that's why we call it's like a universal reactivity. It just works everywhere in your code.

And, and basically it's, it's yeah, that's, that's like one of the things that is much better than in Spell file or before Spell file where you can only have reactivity in components and once you move out, you have to rewrite it into using like spell store or some other ways of writing it, right? Yeah.

Which, which falls back to the clients, the runtime reactivity, which, which basically is, is what it is right now. Yeah.

Yeah, it's related to Kresna's question there. Like it's a good question. Do you have info?

Yeah. Especially how the internal team and ambassador reaction, like did it get a lot of backlash? Of course, as far as you are allowed to ethically disclose, like were many people happy like, yay, we finally have this or were they like, no, no, it makes it so complex or whatever. And what were the arguments? Like it's, I think it's interesting.

Yeah. I have to, so I think sorry to disappoint here. I don't really know. I wasn't very, very much involved in the discussions about the entire thing. So I don't know like all the, all the, all the discussions and arguments for and against.

But I do know like whenever we come up with something like when you first see it, you were like, oh, why, why we have to do this and things like that. And, and, and it's only when you start writing your code using it, right?

You know, like try to use it to build some components, build some applications, just trying to play it for a while to say, for example, rewrite the existing code into this, into, into a code using like runes and play around with it.

Only you start to realize that, Hey, actually it's not that bad. Then you first imagine, right? When you, when you just look at the docs, you're like, oh, wow, what's this thing? Right. But then when you use it and then use it a few more times, especially to reflect the old sort of code or reflect the existing red code or whatever to, to spell fives.

Then you realize that actually it's, it's actually it's, it's actually not. Yeah. It makes sense. Right. Yeah. And, and I think it's been, I think almost a year since like we first like the, the alpha version to beta.

And then until like now, right. And I think most people have come to realize that actually it's, it's, it's actually, it's actually makes sense. And it's a nice way of writing it.

I just wondering about when Svel is now is growing and more and more features. I think Svel 4 to Svel 5 in the architectural level is like changed drastically, I can say.

The way, the way when we, when Svel 5 introduced runes and this effect. So, well, that's a foundational, foundational, sorry, how can I, foundationally changed the way of compiler fundamentally changed, fundamentally changed that detecting those state.

I'm more interested about how to keep this backward compatibility and are there any like unit testing, how, how, how, how much is the unit testing in, in, in Svel framework. In the library.

Oh, okay. So actually if you go, if you go to the, if you go to the Svel report, you, you can see all the tests that's written for Svel. And whenever there's like a issue that's being raised, yeah, you can go to the packages Svel folder and then you can.

Sorry, which one.

And then you can look for the test, test folder.

And then you can see like all these are all the tests. Maybe you just open one maybe like runtime runes or anything.

Maybe like runtime runes, look at open one of the samples.

Maybe like, yeah, any one of it will do.

Yeah, you can, you can just open any.

Open any, okay.

Yeah, I think you can open any.

And then you look at the main.svel. So this is the component, right?

Okay, so this is a component. And then if you go, you go to the config.js file, maybe on the left you see that there's an underscore config.js.

Yeah, so basically this is like, okay, when I render this component, what it should behave, what it should do, what I should see on the HTML and stuff like that.

So you have a lot of test case like this. If you scroll all the way down, these are all the tests.

On the left side, you can keep scrolling and see all the different tests.

Yeah, maybe this one. It's such a nice way to understand how it works, right? Like if you're wondering, like, you know, if you just see the syntax, like it's alien.

Like, oh, what is that? It's strange. But like if you see each test case, like it demystifies the whole thing. Oh, yeah, that's how it works.

Okay, it's all normal.

Yeah, so for the one that you just see right now, it says like await account, right? And then the count is just a state.

Or yeah, anything, right? Yeah, maybe this one you look at, you pass a, you create a state using a state runes and then pass it await.

And then what should you see on the screen, right? And then the config.js, if you look at, click on the, it basically says that you shouldn't throw an error.

Yeah, I think the test isn't assert anything, but at least it says like you shouldn't throw an error during a runtime.

So things like that.

Yeah, correct.

Yeah, so we have a lot of these kind of tests in Svelte 4.

And every time when there's someone making an issue and we fix certain bugs, usually we'll create more new test cases. When we make a pull request for the fix, we also add the new test cases, right?

So we build, that's why you see there's so many test cases because we have built out so many test cases over the years.

And when we do this over, when we are rebuilding for Svelte 5, basically the entire code base is rewritten from scratch.

And yeah, it was a totally new project. Everything was written from scratch.

And the components were written from scratch. A lot of things was, back then I think we were using some CSS parser, some JavaScript parser and some like tree libraries and like AST walking libraries, traversal libraries and stuff.

And some of those things are rewritten or create a new library out of it.

So when we implement, when we start creating the, we rewrite the compiler, a lot of those tests fail.

So we reuse all the existing test cases to run with the new compiler and a lot of those things fail.

And basically we slowly fix the compiler from there until we make sure most of the test cases pass or until all the test cases pass.

Or some of the test cases have to rewrite. Sometimes the way you use the component is no longer the way that you write it.

So that's why you see that's the runtime dash legacy, which are some of those tests are for the legacy mode and yeah, all that new tests.

So that's how we ensure that it works for when there's a new, it works, how to make sure that it works, that these are the unit tests for the Svelte.

So you have runtimes, you test for CSS, you test for server surrendering, even transitions, animations.

So I think this is interesting.

Yeah, you can click on one of them. For example, this is what you write and then you expect the CSS to look like.

With arbitrary names. For those who don't know, in Svelte components, we can just co-locate the CSS directly so we don't have to think about installing any CSS library.

CSS in JS, CSS in Svelte. Yeah, just use regular style tag. It will be compiled with arbitrary class name like that.

You can use tailwind and whatever, CSS. That's one of the reasons I like Svelte.

So you're going to Rust soon? I don't know. We'll use Rust as a compiler. Everything Rust at the end.

I don't know, but I do know that there are definitely people are looking into it. I mean like it's open source, everyone can know the source code out there.

I think you also have the test cases here, right? So probably you can use them to write your own compiler in Rust and you just test against all the test cases that you have in Svelte.

It's possible. I believe the world is so huge, there's definitely someone in some part of the world thinking about it and maybe someone actually does it as well.

Isn't Svelte using roll up? Roll up, right? Roll up, fit now? You mean for Svelte kit or you mean for Svelte? No, for Svelte proper, the compiler.

No, the compiler is all written in JavaScript. So for Svelte, it's written on its own. It doesn't use any library.

So how the compiler in Svelte build? So you don't have to build anything? It's just like you can run the runtime without build it? We compile it first.

We build first. Compile into regular vanilla JavaScript. No, no, if you open the GitHub repo again, it's a source like the compiler is the source and how it's built.

How to run it? It's written in, it's actually written entirely in JavaScript with some type script. So it's not using any, yeah.

There are some build steps to optimize it, but you can use it out of the box if I remember correctly.

Yeah, let me check quickly on this one.

Okay, meanwhile, do you know that any web or web apps, popular one that use Svelte, for example, like linear app using React?

I know, for example, recently I was using Apple Music. Oh, yeah, Apple Music create with Svelte, right? I think I saw Svelte inside Apple Music.

This one. This one is using Svelte. Yeah, I don't know whether entirely or like the thing, but I do see like there's some, you see there's like Svelte class.

Yeah, in the element I just highlight. This one. Yeah, this one, yeah. This is using Svelte and then also the podcast syntax.fm also build with Svelte.

Oh, yeah, Scott is a Svelte guy. And one more that I know is PocketBase. You know, it's like SuperBase or Firebase, but you can deploy it manually using Skillite

and the user interface is using Svelte as well for the backend or the admin side.

Is the website open source? The website? Yeah, the PocketBase is open source. Yes. Yeah, the website, the Svelte website, so you can clone and learn.

The syntax website is open source, I think you can try. You can see how things work.

Side, yeah, that it goes.

Svelte. Yeah, Svelte.config, yeah. Yeah, like what version? SvelteKit, yeah. Svelte 3. They're on Svelte 3.

Yeah, now we've touched on SvelteKit. I've got one remaining question. Maybe we're going to have to wrap it up in a bit.

But important question, meta frameworks, like, you know, with all the routing and stuff, Svelte has an official one, right? SvelteKit.

So, do you know of any other major Svelte meta frameworks, like the outside of SvelteKit, or do you just recommend, okay, just go with SvelteKit, like what do Svelte developers usually use?

I think there's definitely a lot. There's definitely other Svelte meta frameworks. I just suddenly can't think of one right now.

A few years ago, I discovered like jungle.js, elder.js, but I don't think there's really game traction. But then again, now I don't really explore Svelte meta framework ecosystem.

Before SvelteKit, I think, before SvelteKit.

When SvelteKit was called Sapper, like Sapper kind of beta, like it's not really polished, then SvelteKit came out. It's the official meta framework.

Now I rarely see about, you know, Svelte-based meta framework. What do you think? Would you recommend SvelteKit or something else?

Yeah, I think definitely. I think like if you are new and you're not sure which one to choose and you don't know what you need or you want, then I would say like just start with SvelteKit, right?

It's the official meta framework that's built by the same team that's building Svelte, right?

And I think the team has put a lot of effort thinking and figuring out like what's to do. It's by the same group of people coming out, figuring out the best syntax or best way of expressing our writing application for Svelte, right?

So you will feel like it's very natural. It makes a lot of things that make sense. Yeah, and it doesn't really matter whether you are building a simple application like a blog where it's purely static or you have some pages that you need to make it very like dynamic, like server-side rendering or you do some pre-rendering.

And I think also different kind of rendering modes, they can work all together inside SvelteKit and whether you want to connect with database and do some sort of form actions, like submit data, like basic CRUD kind of application.

All this has like SvelteKit has all the solutions included, like all the opinionated way of like how you can build a Svelte application that has all these features for you.

So I would say like if you want to build an application, that's like you don't have like very specific requirements. I think most situations, SvelteKit just works. Yeah, it's the most, it makes sense and it just works, I would say.

Okay, so what's next for you? Is there any plan to make another tutorial, especially for new Svelte and Svelte next version in the future?

Yeah, definitely. I think I've been saying I will definitely make more video contents and stuff like that in the future, but I have always been procrastinating. But I think now it's really like somewhat like maybe someone like a wake-up call for me because I realized that most of my content will slowly go out of date, become useless after Svelte 5.

If I don't make new content, then I think no one will ever, that I will not have new subscribers and no one will watch my content anymore. So I think it's time for me to come back, I guess.

Hopefully it will stay and I think, yeah, I think maybe that's something that my resolution for next year maybe.

Nice. Yes, because your content is so good. For example, like build your own Svelte that we saw at JavaScript Bank weeks ago. We need that kind of content because we just not learn how to use the framework, but we know how it works behind the scenes.

Go ahead, what do you think?

No, I think I know what you are saying and yeah, I also hope, I also wish that I got, I able to see this kind of contents when I first started out and like trying to learn things and you know, especially you want to learn something and you like trying to figure out how Svelte works and you are stuck.

And if there's like a content that actually will tell you how you can go about, I think that will be very useful, right? Yeah, but I mean that kind of content is also very niche, like not everyone actually wants to know how it works.

So I can understand why you don't see that often in YouTube, but yeah, that's one of the things that I was, that was one of my motivation of creating content was to basically create some of the things that I hope that it was there when I tried to first starting out to learn things, not just basic things. I think basic things there's a lot of that out there already.

Hello everyone, hello world.

How to make a blog with just one post.

Yeah, exactly.

So, then then like, when I went to like, like advance and I realized, oh, I actually, where do I find, like what kind of, where are those things. And I don't know, maybe I'm not even sure, actually, to be honest, I don't know whether those kind of people will actually be watching YouTube videos, or what maybe they are more of a blog kind of person, or maybe this kind of person will be preferring more on like, building like, get their hands dirty and like do it on their own.

Yeah, but I don't know, but at least like, yeah, I enjoy creating those things as well.

If it's out there, people will, well, let the algorithm find the people, you don't have to do that.

So you just put it out there, let YouTube find those people.

Yeah, I think that's a good suggestion.

But is that, is that why you guys are creating this podcast as well?

Not really, because otherwise, otherwise we wouldn't be catching up with, you know, in web dev, especially JavaScript ecosystem.

We just blink of an eye, boom, new meta framework, boom, new compiler, and you know, of course, in our job, we can't just chase everything, but we need balance between, you know, like maintaining like the real world stuff and exploring in their existing technologies or new technologies.

So that's why we just commit to talk every week. Sometimes we don't really have a lot to talk, so we just ask the chat.

Or read together, read some article together in our documentation.

And try the demo.

Additionally, on top of that, right, so we as a web, well, our profession is like web dev, and most of the time we are isolated in our own world.

During the work day, working day, we just solve tickets to tickets, tickets to tickets, nothing else. Maybe you can relate that.

We don't really talk with other developers outside our own team.

But why not?

We met during the events, but after that, well, it's just one day during the events, like after that, nothing else.

And by having this podcast weekly, we can keep talking about whatever for the web.

What's new?

One or two things will catch up with our brain, and somehow when we need that in our future thing, we know it.

Plus, why don't we just also have this podcast so others also learn together with us.

We learn from others, others learn from us.

And also, you know that graphic about like someone has strong knowledge in this part, the other have strong knowledge in this part.

Like no one has the same exact same set of skills, you know, but kind of overlapping.

And it's a nice way to kind of merge all the skills and knowledge.

I've actually found like a couple of useful things for my own work based on what we talked about in the weekly podcast.

Oh, yeah, I haven't mentioned about this, or Rizna mentioned about that.

Oh, yeah, I know that one.

I just go to the Google Docs with the links.

Oh, yeah, that's it. Nice.

Oh, yeah, that's very helpful.

Yeah, you're welcome anytime if you want to join us.

Just ping us.

Or maybe if you have any side project or fun open source project or whatever that you want to promote as long as it's web and open source.

And also about Microphone N.

We haven't talked about Microphone N, so we keep that slot in the future.

Next time we can talk about Microphone N.

Our audience here is excited.

Well, they've been asking about Microphone N multiple times in the past.

They're curious about it, yeah.

But none of us actually use it.

None of us actually have the experience of Microphone N, so we cannot have the talk.

I've done Hello World Turbo repo, but that's not a legitimate experience to give a talk.

The production use case is always so different from the tutorial and sample.

Yeah, that's true, that's true.

So we will have another session, is it?

Oh, of course.

If you want and when you are free.

Yeah, anytime.

Last question before we are going too far.

Do you have a wish to work as a programmer for building tools for developers like Spelt in the future?

Would you like to work on tooling one day?

That's a very good question that I've been asking myself.

To be honest, I don't really know the answer.

The reason is because I think if I'm going to say this, you'll find it funny or maybe you'll think it's very realistic.

At least right now I think that what Shopee can pay is a stable good income than something that I don't really know.

Maybe I'll earn much more or maybe I'll get more fun and other things that I can get in return on working on toolings.

But I think right now one of the big reasons why I'm staying at Shopee is it's a good company that pays well.

And there's a lot of interesting problems that I'm working on right now.

There are times when I was thinking about something else, but it's always unknown.

Who knows, maybe one day when I really get bored and maybe Shopee pays not as good anymore, then maybe I will consider something different.

I don't know. Maybe it's not a very grand vision kind of answer.

You've got to be realistic like balancing lofty ambitions or ideas with real life stuff.

And also basically most of them are working in Europe or America.

So it's either I have to work at their time zone or maybe I have to be there physically.

But I think me and my wife, we like where we are staying right now.

So that's also another consideration. I don't think we want to move ourselves to somewhere totally different and experience a different life.

I see. Not even back to Penang.

I mean like back in hometown maybe that's a totally different story.

I mean like what I mean is the comfort food of Southeast Asia, like warm food, hot weather, durian.

Okay, so if people want to get to know you more, like want to discuss or ping you, where should they go?

That's a very good question. The reason is because I am a bit lazy.

I've tried to tell people that you can find me on Twitter, you can find me on YouTube and stuff like that.

But I realized that I'm too lazy to reply all of them.

Maybe, I think if you have questions, you can ask Riza and then maybe if a lot of people are asking the same question, then we will come, then maybe we will have another podcast.

Or join Telegram Svelte ID, there is Lihau there, mention him, maybe he read or not, doesn't matter.

If you want to open Telegram, then you're not in luck.

If you want to know more about Svelte, you can ask in the Telegram, people probably will answer your question.

If you're in luck, Lihau will answer that.

Read and answer.

Do you have any plans to come to Indonesia next year?

Is there an event? I don't know. Maybe, if there's an event, there's a meetup or something.

Let's find GDG to invite Lihau.

We will contact you very soon.

Thank you for coming to our weekly podcast.

Thank you very much for the chat.

Thank you for your knowledge, good luck and see you in the next podcast episode.

See you everyone, thank you and bye bye.

Sampai jumpa di video selanjutnya.

Deskripsi asli dari YouTube

Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.

Episode Terkait

Bagikan:

Suka episode ini?

Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.

Pilih Cara Langganan

Memuat komentar dari GitHub Discussions...

Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .