Subscribe
Share
Share
Embed
Sponsored by Contentful
Welcome to the new era of content management with Contentful. Say goodbye to the limitations of traditional content systems and hello to a world where collaboration sparks innovation. With Contentful, you’re not just managing content; you’re creating content-first, multi-brand experiences across all channels effortlessly. The best part? It requires zero coding! Empower your teams to collaborate and innovate, delivering impactful digital experiences at scale. Contentful's AI-driven platform not only streamlines content creation but also ensures it aligns perfectly with your brand. Ready for a game changer? Start with Contentful for free today. Unleash the potential of your digital content and drive your business forward. Learn more at contentful.com.
Summary
In this episode of Svelte Radio we talk with Enrico about This Week in Svelte - a weekly Svelte show that he runs. Tune in!
Recorded on November 1st, 2024
Discussion
Welcome to the new era of content management with Contentful. Say goodbye to the limitations of traditional content systems and hello to a world where collaboration sparks innovation. With Contentful, you’re not just managing content; you’re creating content-first, multi-brand experiences across all channels effortlessly. The best part? It requires zero coding! Empower your teams to collaborate and innovate, delivering impactful digital experiences at scale. Contentful's AI-driven platform not only streamlines content creation but also ensures it aligns perfectly with your brand. Ready for a game changer? Start with Contentful for free today. Unleash the potential of your digital content and drive your business forward. Learn more at contentful.com.
Summary
In this episode of Svelte Radio we talk with Enrico about This Week in Svelte - a weekly Svelte show that he runs. Tune in!
Recorded on November 1st, 2024
Discussion
- Enrico
- Co-founded: Design Systems Community
- Weekly recorded show on YT
- Co-hosts
- Changelog
- Enrico
Unpopular Opinions
- Brittney: [Inertia.js](https://inertiajs.com/)
Picks
- Enrico: The Wandering Earth Part 2
- Kevin: Quest 3
Transcription
Here's a quick word from our sponsor.
Welcome to the new era of content management with Contentful.
Say goodbye to the limitations of traditional content systems
and hello to a world where collaboration sparks innovation.
With Contentful, you're not just managing content,
you're creating content-first, multi-brand experiences
across all channels effortlessly.
The best part? It requires zero coding.
Empower your teams to collaborate and innovate,
delivering impactful digital experiences at scale.
Contentful's AI-driven platform not only streamlines content creation,
but also ensures it aligns perfectly with your brand.
Ready for a game-changer?
Start with Contentful for free today.
Unleash the potential of your digital content
and drive your business forward.
Learn more at Contentful.com
[intro music]
Hey, welcome everyone to another episode of Svelte Radio.
We're back again.
Ooh, I'm joined by Brittany.
Hello.
Hi.
Back this week.
Back this week, yeah, yeah.
Hello.
And we are joined by another guest.
It's Enrico.
You might know him from this week in Svelte.
Hi, Enrico.
Hey, everybody. Enrico here.
Hey.
So before we get started, Brittany, what's new?
It's been crazy.
I went on vacation last week, so I know I missed our previous guest.
I think we had Jacob on last week, but unfortunately I had to miss that one.
We went to San Antonio where it was kind of warm.
It was like 80s and 90s Fahrenheit, so what, 30?
A little less than 30, maybe 20, 28 Celsius.
That sounds very nice.
But it was overcast the whole time.
So I tried to get in the pool, and it was like windy and cold.
It was like still not warm enough to get in the pool there.
But we came back, and it snowed yesterday for Halloween, so that was good.
We have like probably three to four inches of snow outside now.
Wow.
Yeah, we just got our first falling snow here today.
Oh, really?
So it doesn't stay on the ground, though, because it's not that cold here just yet.
Yeah, our ground is not that cold.
I thought it would melt, but it froze overnight, and it's just like stuck there.
Damn.
Yeah, that doesn't sound like fun.
Maybe you should just go more south.
I've talked about it, yeah.
We just built that pool, though, so we're like 10 years, and our kids are in school still,
so 10 years, and then we'll probably keep this house for the summer when it's nice here
and then move somewhere else, be snowbirds for a while.
Yeah, makes complete sense.
All right, let's talk a bit more with you, Enrico.
Who are you?
That might be a broad question, but how did you get into development?
Who am I?
Yes, well, my name is Enrico Sacchetti, and I am a software developer based in the Greater
Toronto area, Ontario, Canada, and what I like to do is front-end development, and ever
since I was a teenager, that's what I've been doing as a personal hobby, and some opportunities
came along, and before I knew it, it was a full-time job.
So despite my post-secondary education in video game development, I actually pursued
a career in website development because that's where the opportunities lay.
We have had so many people that are video game developers, like by originally video
game developers on the show, right?
Yeah, I feel like that's been a thing.
The person that did Wolfenstein, the felt version of that?
Snuffy, Jason?
Yeah, and a couple of other people were in video game development.
It's kind of like the music thing that we have, too.
A lot of people were musicians before they were programmers, too.
Yeah.
That's interesting.
Yeah, did you get into the game development stuff?
Was that because of interest in gaming in general?
Yeah, it was sort of a misguided interest in video games because as much as I enjoyed
playing them, making them is 100% different.
You need ongoing, persistent passion for that, as I realized the hard way after graduating.
I tried to get jobs across the world, particularly China and Canada, because I was pursuing living
there.
I actually ended up living in China for one year and became an English teacher after graduating.
Oh, cool.
So that's where I learned how to speak Mandarin and teach English.
But even though I was teaching English...
I had no idea you spoke Mandarin.
Yeah, that's a thing I can do.
But aside from that, I found myself on the weekends learning code, HTML, JavaScript,
CSS, because that was my passion.
And game development was not my passion.
In fact, when I had an interview for a job, they told me to my face, "You don't have passion
for games."
And I'm really glad that happened.
That's rough.
As rough as it sounds, I was relieved because I realized this is not for me.
And I found out very early in my career.
So I think that's a very good blessing.
Yeah.
What language was that, that you were doing the video game programming?
Programming language?
Yeah.
In university, I learned C++.
And that's what I used along with some Visual Studio stuff and frameworks.
But I never had professional experience game development.
I just had a couple of portfolio pieces, and I graduated with that.
So I was never a game developer.
I was just a student of one.
And then eventually, I came back to Canada, my home, and got married, got a job.
And the rest is history until today.
So I'm still strongly into front-end development.
Mostly in CSS in the beginner years.
But then later in 2017 or so, I got a job full-time as a React developer.
And I finally got really deep into JavaScript and things like that.
So that brings me closer to today and Svelte.
So what happened next was about a year and a half ago, I joined a new company
where I'm still employed.
And it's a small team in a large enterprise where we have some autonomy
and choices in our tech stack.
I consider myself a full-stack developer, but I will really earn the title soon
once I actually deploy a self-hosted server.
Because we have our own on-premise infrastructure, we are absolutely
end-to-end full-stack.
From the cables to the ground, to the front-end,
touching the customer experience.
I love that.
That's how Svelte Society is now as well.
Completely self-hosted in my home.
How's that server going?
Yeah, it's going great.
Is it going good?
The next cloud is humming on.
I think for Enrico, the location is probably not that good because the speeds
are apparently not great.
I'm very close to Enrico, so you want me to check?
I mean, I think you messaged me a couple of weeks ago, Enrico,
with the upload speed or something of one of the videos that you uploaded
to the server.
Yeah, to the listeners, Kev is referring to our shared server for this weekend's
Svelte Artifacts, which we'll get into in a few minutes.
But it's actually pretty good now.
I was downloading stuff at at least 7 megabytes per second.
So it's a lot better than what I had earlier.
There must have been an issue with me or something downloading at 14 kilobytes
per second.
Unexpected.
Yeah, yeah.
Let's chalk it up to just weird internet stuff.
It's a series of tubes, you know?
Yeah.
Right.
Yeah, so you mentioned this weekend's Svelte.
But maybe before that, I'd love to hear if you have any-- so you mentioned
you weren't a professional game developer, but I assume you learned C++
since you learned it in school.
Is there anything that you feel is transferable from C++ into the JavaScript
world in general?
Or maybe you haven't touched C++ in such a long time that you-- I don't know.
What's any insights?
Good question.
This is a personal take, but I think C++, the language itself,
isn't very transferable.
But I did learn object-oriented programming, algorithms, data structures,
kind of like any post-secondary student would.
And that itself, that also was somewhat transferable, but the real transferable
stuff was the grit and the soft skills.
Being able to not get frustrated and persist and study and iterate is
one of the most valuable skills as a software developer.
Being able to stick with it-- because this is top of my mind because
sometimes I talk to high school students about pursuing a career in software
development, and what I tell them is you don't need to be passionate,
you don't need to have an innate desire to be a developer,
you just have to have the persistence necessary to not get frustrated
and to keep learning on your own.
Because the passion for learning is the most important.
So as far as transferable skills go, it's mostly that.
It's just, "Oh, no, I can't figure out how to send a div in CSS."
But wait, I did know how to write this class-based object in C++,
I can walk through that just fine.
So that persistent nature is what transferred.
Yeah, that makes sense.
And as we all know, CSS is notoriously hard sometimes.
It can be really tough.
Yeah, but I did get deep into CSS in my early years.
I love CSS.
It's a good programming language.
I think you're talking to two of the wrong people to complain about CSS to.
We like it too much.
Yeah, well, I mean, I like CSS as well.
I definitely always preferred doing--
I hate it when people reach for the JavaScript solution for everything
rather than just doing it in CSS and HTML.
It's one of my pet peeves of a lot of developers.
I mean, I understand that sometimes you need JavaScript
to do something accessible, right?
But it's still--
I bet it's much easier now to center a div than it was when you started.
Yeah, that was a really bad example.
It's really easy with Flexbox nowadays.
I mean, it's really easy now.
It wasn't.
I guess in 2007, that's when I really started deep into CSS.
Yeah, some things were different back in 2007, 2012.
Nowadays, there's so much CSS that I can't keep up.
There's so many amazing new features that I haven't even used yet.
Yeah, like have you seen the amount of different units for width and height?
It's crazy.
I know they have a purpose, but there are just so many of them.
I was going to say that container queries is where something that's not--
I mean, now it's broadly available across the browsers,
but it's still not backwards compatible.
So if you have to support older browsers than the latest,
you can't really use container queries,
but that's where I like to bring in Svelte's bind on the window
and do inner width or something if I need it for--
or not on the window, sorry, on the container,
and bind to the container width.
And I can do a container query with JavaScript
where I can't really support it yet for CSS.
It's fun.
The CSS tangent aside, it was just a year and a half ago
when I started my new career, my new job, and working with Svelte.
And I always knew about Svelte ambiently, like since 2021.
I've seen news and articles, and I think, "Oh, this looks fun.
I'd like to try it, but I'm too busy."
But that's okay.
So here I am doing it on the job, and after my first day or two with it,
I thought, "Wow, this is so smooth.
I'm writing so much less code than I used to."
And that's when things got really inspiring for me,
like super-duper inspiring.
It's because of that saving time, writing less code,
and shipping things faster, like write less, do more,
that ethos just showed up before I even read the sentence.
And then I saw Rethinking Reactivity and these famous talks about Svelte,
and I thought, "Okay, this is big.
This is bigger than me."
And with my background in community management,
because in 2018 I co-founded Design Systems Community,
incorporated in Toronto, and we run a global meetup group
where we talk about design systems.
Because my job in 2017 at Telus, a telecom in Canada,
I worked full-time on design systems.
So I did lots of React components, lots of CSS, and lots of liaising,
talking to teams, kind of like what Brittany does today,
talking about their needs and making sure that we have satisfying solutions
that cover the broadest scope and iterating constantly.
And that's why we started a meetup group,
to talk more in-depth about it for selfish reasons as well as giving reasons.
Selfishly because we want to be better at design systems.
Giving because we feel like we can add stuff back.
So to throw in a pitch here, our website, designsystems.community,
has a resources center, and that's where we freely provide talks
and resources to everyone.
And I thought with my background there,
maybe I can do something with Svelte as well.
And I had this itch I needed to scratch because as much as I enjoy
supporting many different types of roles, because Design Systems Community
is very inclusive to developers, designers, content writers,
accessibility primes, product owners, at every meetup we run,
we make a point to invite all of those roles at the same time
and accommodate them.
We don't want to make just a designer meetup, just a developer meetup.
We don't want to make something exclusionary because much like
design system work at a real company, you have to include everyone.
You have to involve everyone.
You need buy-in from everyone.
So that works really well, and it's been going smoothly since.
So when it comes to Discord and joining the group here with Svelte,
I sort of started low-key, just hanging back, lurking a bit,
see what kind of small or big community this was at the time.
And I realized, well, Discord itself is pretty cool.
It's got audio. It's got stage channels.
Maybe there's something we can do to have informal discussions
about the latest and greatest in Svelte.
And that's what inspired me to kickstart this week in Svelte
earlier this year.
So for those that are interested in seeing more of the designs,
the design community, it's DesignSystems.Community.
Is that right?
Yes.
Yep. Cool.
Yeah, so this week in Svelte, you've been running this
for quite a while now, right?
I don't even remember when you started doing it.
Was it last year?
So it was this year, 2023, February, and I did a bunch of non-recorded
off-the-air streams on Discord.
And then you came to me and said, "Hey, you should record these."
[laughter]
And Brittany, I think, also mentioned that.
Increased the workload a lot. Sorry about that.
It was worth it, though.
Yeah.
Taking on the challenge of a weekly show.
Yeah, to me, it's awesome to see that it's been so consistent.
Like, almost every week, there's been one,
and you always go through interesting topics.
Community members can join on the stage and showcase stuff.
I'm always in awe of how much information you have each week.
It's kind of insane how much you can--
and that has to take so much of your time.
I don't understand how you have enough time for all this stuff.
But it's just crazy the amount of content that is put out.
And like you said, kind of consistent just every week.
Yeah, if I can ramble off that a bit.
I think the overall time and effort it takes to plan, execute,
and do post-production for a single episode is about four hours of my time.
That's all together.
And I usually do it on the weekday evenings because I have a two-year-old,
and I love to give him my time, energy, and love during the day while he's awake.
And when he's asleep, I get to do this week in stealth.
And I think part of the consistency of content is being the primary host at the time.
I now have supporting co-hosts who I will give a shout-out to.
But in the early days, yes, I was the primary source of content.
And it worked out because being a senior developer,
I do have a lot of things I'd like to share with everyone.
And I love the constant feedback loop because after each week,
there was a very diverse crowd of developers on the stream,
on average 20, sometimes as much as 50 people were on stream.
And they would leave nice comments like, "Wow, I thought I knew a lot,
but you constantly teach me something new."
And these are very senior veteran developers giving me compliments.
And they have respectable amounts of knowledge.
And I just thought, "Wow, if I can do that,
then there's an infinite amount of things to talk about."
Because whether you're a junior, early developer, or senior,
sometimes there's just not something you don't know.
And it's true. As developers, we can't know everything.
It doesn't matter if you've been in the industry for 10, 20, 30 years.
You can't know everything. There's just infinite knowledge out there.
And you may not be exposed to it. And that's totally reasonable and human.
So if I could share my knowledge and information,
and perhaps selfishly, again, learn from others
and have them show up, do some showcases, answer some Q&A,
then the content becomes a virtuous cycle.
Yeah. It kind of sounds like when I started this podcast, actually.
I wanted to listen to a podcast about Svelte, but there was no podcast.
So I mean, I started, I mean, the first episode was just me reading off
new versions of packets or something very boring.
Fortunately, Antony and Sean and you, Brittany, joined.
Like Manifest Destiny, though. You create your own dream or what you want.
Yeah. Kind of has to work like that. Someone has to just do it.
Because it is, in the beginning, I feel like it does take some time
to get things off the ground.
The same with this week in Svelte.
It took a while before these other co-hosts started showing up
and showing more interest and maybe wanting to participate.
And that initial workload is usually, at least from my experience,
it's a bit more and then it kind of gets a bit easier as you go.
Because you also get into how to do it efficiently and stuff like that.
But yeah, so this week in Svelte, it's a weekly show on Svelte
that you can catch on YouTube.
So what kind of stuff, you mentioned you talk about
kind of almost everything on there.
Or maybe not everything, but anything is of interest
because not everyone knows everything.
So could you give us maybe some examples of what you've talked about there?
Yeah, especially in the early days.
My Trojan horse topic was always accessibility.
I sneak it in every time because we're all writing code in Svelte,
which means everyone on the show listening
does some amount of front-end development.
And if you do, then accessibility matters to you.
It should. And if it doesn't, I will make it matter.
So the reason why that matters so much to me
is because back in my design systems job,
I had to learn the hard way because I didn't care about accessibility
as much as I should have at the time.
So I wasn't always like this.
I had to, through experiences and talking to people
whose dedicated role was consulting on accessibility
and compliance laws and things like that,
and they taught me things I didn't realize.
For example, one of my most memorable lessons
was I shipped a button component, you know, the famous button.
Everyone's got to have one. And it was bad.
It was bad because when the text was too large
in the French language, it truncated.
And I didn't support that because in Canada,
we have to write things in English and French.
So I didn't test for French.
And furthermore, I didn't test for increasing the font size
because our browsers have two options.
You can zoom into the page,
and you can independently increase the font size.
And some people do that when they browse the internet.
So I didn't test with increased font size.
And when the text truncated, it was a bad button.
And I was taught that it should overlap and wrap to the bottom line.
The buttons should get taller.
You shouldn't specify a maximum height.
You should specify a minimum height.
Allow the buttons to be taller. Allow the text to wrap,
especially if they're off to the side in a card, in a container,
and there's no room for it to grow wider.
Good luck convincing the designers that that's going to fly.
[laughter]
Well, the simple answer there is, what is a designer?
A designer's job is to solve a problem.
You're trying to express something. You're not a designer. You're an artist.
And that's okay. That's a valid thing to do.
But you have to understand the role you're in.
I think what we would do in that situation is truncate it
and then have a popover.
As long as you have the ARIA, is that accessible?
It is compliant, but it is unacceptable.
[laughter]
So yeah, you have a means to read the text.
Therefore, it is compliant.
And transparency is not ideal all the time.
That's a funny example you shared.
But yes, when I work with designers, I got to give them respect to it
because it's such a diverse field in itself.
There's visual design. There's interaction design.
There's content design.
And I think the first conversations you have
when you build a digital experience is content, actually, not even design.
It's really like, what information are you presenting
to your audience through the internet?
What things are your audience trying to achieve on your website
or service or e-commerce experience?
How do you make it easy for them to consume,
whether the content's written in English or another language?
How do you make it easier for them to navigate?
It all starts with content.
And content actually is done in tandem with accessibility as well.
This is such a relevant conversation for me
because we had a new product director of design come in
and look at our site and say that,
what are our users actually seeing, doing?
How are they navigating the site?
And we're talking about redoing the whole hierarchy of the site
because we don't feel like the patterns and the interactions
that the users have are consistent.
And displaying that in a more readable, more usable fashion
will lead to increased revenue.
And knowing all of that as a designer, it's a lot.
Being a designer is hard too,
but I've been trying to convince my designers
that accessibility is important and you need to know about accessibility.
They think they don't need to know about it,
but they do need to know about it
and they need to use that in all of their designs.
Right. So that's an excellent example.
So back to Kev's question about where do I source my content,
this is definitely one of those examples from real-world situations,
real-job situations, trying to solve for accessibility
and providing a Svelte solution is something I talk about pretty often
on This Week in Svelte because we're constantly faced with these challenges
and people want to know, how do I solve this with Svelte?
Well, we're here to talk about it.
Yeah. I get the impression that a lot of the topics on This Week in Svelte,
like for example, this topic on accessibility,
it's not particularly Svelte-specific, right?
I feel like often you would, any developer would probably,
what's it called? Crap.
Completely blanking on the word here.
They would gain knowledge by checking out This Week in Svelte,
even if they're not using Svelte, is what I wanted to say.
Like obviously some things are Svelte-specific,
but accessibility is for everyone.
Yeah.
Progressive enhancement is for everyone.
You could probably learn more than just Svelte stuff.
Yeah. Yeah.
So it's nice to see those topics being talked about.
Yeah.
So what are, do you have any plans for the future of This Week in Svelte?
Any ideas on what you want to do?
Is that something you've thought about?
Yeah.
So as we discuss, we understand where we source the content from.
It's primarily through ourselves.
As the regular hosts, we provide the content because we just want to talk
about the things we want to talk about and sneak in related front-end
aspects.
The future of This Week in Svelte, I think, is scaling myself.
Just like Design Systems Community, just like any meetup organization,
scaling myself is to have this thing winded up like a toy and let it walk
on its own.
And that's why I need to give many thanks to my current co-hosts.
So Kareem first-jointed.
Thank you, Kareem, for your support in the middle days and for coming back
too, because Kareem is a solid developer and he works a lot with server-side
events and things like that.
And he wants to share his things on This Week in Svelte because they come
up on Discord a lot.
Questions come up about how do I achieve this?
And my breadth of knowledge is limited.
So I need to invite specialists, and Kareem helped fill that gap.
And then Paolo Ricciuti recently joined, and he's a regular co-host every
Friday as well.
And he's awesome because he's all over the Svelte ecosystem.
If there's a GitHub issue about something about Svelte, you'll likely see
Paolo commenting on it.
Yeah.
And we've had -- so Paolo is one of the co-creators of Svelte Lab.
We've had them on the podcast a while back.
So if you're interested in hearing more from Paolo, you should definitely go
and check that episode out.
Absolutely.
And now you're going to start using StreamYard.
Are you -- you said, you mentioned before we started recording that you were
on, trying it out yesterday.
So what do you think we'll gain by using StreamYard instead of just recording
on a screen on a computer?
It'll definitely help with execution and post-production.
I also want to thank my other recent co-host, Stanislav, for taking up regular
commentary because with the four of us now, it's like, okay, that's great,
but at times it's kind of excessive because we can't always get a word in.
It's sometimes difficult to coordinate when you can't see each other.
So one of the challenges we face with Discord stages as our primary platform
of delivering this Weekend's Felt was we had to use OBS to record everything.
I had to occasionally swap between sharing the Discord chat in my recording
as well as displaying what's on my screen.
And because I don't have fancy keyboard shortcuts or like a dedicated switch
device, it was really hard for me to manage.
And I couldn't expect my co-hosts to take on that complexity either because we
just wanted to deliver, yeah, that.
Brittany, for those of you listening, Brittany is sharing a really good
shortcut keyboard that I think every streamer should have, especially if
they're on a broadcasting service.
But we didn't have that, and I wanted to simplify things.
So StreamRoute has many advantages that I won't get too deep into,
but it allows us to join easily, much like a Google Meet,
and share what's on the screen.
And there's a lot less time between handing off screen shares because
StreamRoute has a really nice backstage tool that allows people to
preemptively share their screen, and then one click you can bring it on
or take it down.
And with Discord, you had to wait for someone to stop sharing and then
start sharing your screen, and then accept accessibility settings in
macOS because you forgot to set it up.
And there's all of these things to fiddle with that make post-production
a hassle because I have to cut those bits out.
Yeah, and you're still going to have to maybe deal with that, though,
if they haven't allowed Chrome.
I think Chrome is like one of the only ones that StreamYard supports,
but if they haven't allowed it in Chrome, you might still have that.
But the other thing I thought of that you might miss from Stages is
allowing audience members to come up on stage is something that that
offers that you won't be able to do in StreamYard.
So are we just going to move to just YouTube comments?
StreamYard does allow audience members to join.
As long as they share the link publicly, which I will do in the description,
people can join us on StreamYard backstage, and I'll invite them on
if they so like to.
That's right. I forgot about that.
Yeah, so StreamYard has some advantages.
I think there's a limit on how many can be in the backstage, I think.
It's like the total people, maybe?
Yeah.
I think limitations aren't too bad because from my experience,
the good thing about our show is the agenda has been very consistent
since day one.
Like the topics we had have stayed roughly the same,
and I'm sort of happy that it ended up that way.
I was always ready to iterate and adapt, but it stayed mostly the same.
But after the show, one thing that has to make the cut is the water cooler.
We have this off-the-air idle chat that happens after I stop the recording,
and we just stick around and talk about things that are unscripted.
But with the new StreamYard YouTube recording premiering this week,
and if you're listening to the podcast, it may have already happened,
but the thing that we're going to cut is the water cooler.
So the water cooler may end up resurfacing as its own separate event,
but we're not sure yet.
But until then, it's just going to be a very clean show
that's sticking to the agenda, and we'll engage with audience members
via YouTube comments and possibly StreamYard.
Yeah, that could be actually a way to get more people to the Discord.
Since we're sharing it to the YouTube now, we have more active users
probably on the YouTube that watch that than we do in Discord,
and you could tell people we're going to do water cooler
in the Discord voice channel after, or create a channel for that.
That would be interesting.
Yeah, very excited to see where it's going in general.
Here's a quick word from our sponsor.
Welcome to the new era of content management with Contentful.
Say goodbye to the limitations of traditional content systems,
and hello to a world where collaboration sparks innovation.
With Contentful, you're not just managing content,
you're creating content-first, multi-brand experiences
across all channels effortlessly.
The best part? It requires zero coding.
Empower your teams to collaborate and innovate,
delivering impactful digital experiences at scale.
Contentful's AI-driven platform not only streamlines content creation,
but also ensures it aligns perfectly with your brand.
Ready for a game-changer? Start with Contentful for free today.
Unleash the potential of your digital content
and drive your business forward.
Learn more at Contentful.com.
I forgot, I guess we did talk a bit about the work that you're doing
at the moment with Svelte.
But what kind of stuff in specific do you work with,
with regards to Svelte?
Are you working in a Svelte application or a SvelteKit application?
So at your day job, basically.
Yeah, how do I actually engage with Svelte day to day?
It's at my job, I also have some side jobs I'll get into,
but at my full-time job, I use SvelteKit to create a classic CRUD,
nothing too special or fancy or novel.
It's just a very straightforward and traditional CRUD
in which we have the adapter node used for SvelteKit.
We self-host it, of course, and it allows our internal users.
I build internal-facing applications,
so you'll never see these publicly,
but the internal-facing app facilitates some of our team members
in other departments to do some sort of management.
And I can't get into specifics, but the overall engagement with Svelte
is just make a SvelteKit application.
And my team is about five people, or actually it's four people,
three, four developers, really, one of them is a director.
We don't have a designer on our team.
So although we chose Svelte as our de facto front-end framework
for our team and all of our projects,
we actually have a lot of short-term projects
and long-running projects on our team.
Sometimes we'll work independently on six-week projects
and move on to the next project and the next project,
almost like piecemeal agency work, but it's all internal-facing.
Sometimes we have long-running projects, which I was tasked to do.
So for the past year and a half, I'm still working on the same SvelteKit
application I started.
- Oh, interesting. - Yeah, like I'm doing a long-running project.
And it's fun, it's interesting, it touches many aspects of front-end,
but just in the CRUD sense.
The tech stack I use is, besides Svelte, I also use DaltDB,
which is a novel MySQL database that is versioned similarly to Git.
So it actually has Git branches, but using MySQL.
You can actually check out a branch, and you can do MySQL writes and reads
on a branch, and you can actually merge changes just like Git.
- Oh, wow. That sounds really nice. - That sounds pretty cool.
Is it MariaDB that has branching?
I think maybe...
What's the auth provider that uses that?
- Superbase? - I know that PlanetScale has branches.
PlanetScale has branches, but there's another one that just changed their logo.
They use Svelte and everything, and my brain is not...
They have SvelteKit on the page. We just had the person on...
- It could be PocketBase. - Thomas.
- Oh, AppRight. - AppRight. My goodness.
I think they might use MariaDB and have branching also.
But yeah, my brain was not working there. Sorry.
It's all good. And yeah, my engagement with Svelte in particular is very straightforward.
It's mostly light, light front-end views.
I tried to pursue the progressive enhancement form actions mentality,
but I wasn't very successful. I still have pages in my app that require JavaScript to function,
but I hope someday I can make it all work without JavaScript,
because a CRUD can work without JavaScript.
Everyone probably knows what CRUD means, but create, read, update, delete.
Just throwing that out there if you don't.
That's like living the dream, though. You get to work straight with SvelteKit all the time
and not... I mean, our job has Svelte, but we don't get to work with SvelteKit.
So I get to work with SvelteKit in the design system and then release it as just Svelte components.
But the main app is just Svelte 3. We haven't even upgraded to 4 yet.
- Right. - Neither have we. But there's not much to it.
I see your point. Yeah, it's good to tell the audience what I meant by CRUD.
A CRUD is something that lets you engage with data.
It's just a user-facing front end so that you can make easy changes to a database
without having to use an actual database connector client like Heidi, SQL, or things like that.
So it has to be tailor-made to our audience needs.
It can't just be editing and writing and reading. It has to also have side effects.
It has to have hooks. It has to have special events required by our target clients.
And yes, it is SvelteKit, but it's also atypical SvelteKit
because we're not using traditional authentication.
We're using enterprise header SAML authentication, which is easier than it sounds
because what happens is when they go to our SvelteKit app, they authenticate using SSO,
single sign-on, and after that, our application will get some cookie headers that say,
"Okay, this user is authorized." That's the only thing we check for.
Do the headers exist? Yes, they're authenticated.
It seems nice to not be able to deal with the hassles of implementing a whole authentication flow
and all of that.
So you mentioned you've been working for a while on this application.
Does that mean that you experienced the good old days with the different router and stuff in SvelteKit?
Or did you start using it just after, maybe?
Oh, no. I used SvelteKit before it was version one.
I had been using version 405 plus the one with the new directory-based router,
so I think that's the one we were adopting, or we had transitioned to it.
Either way, I was there when it happened, and I was all right with it.
Yeah.
You also mentioned some side jobs, side projects?
Yeah. I guess to wrap up the work stuff, since we don't have a designer on our team,
I decided that we adopt Carbon Components Svelte.
And I actually, because we use it day to day, I talked to the maintainer who Brittany had interviewed
with the SvelteScience stream, Eric, and Eric invited me on to be a collaborator maintainer.
So sometimes I go in and I help close issues and make changes for bugs that I find
so that I can help co-maintain Carbon.
And Carbon's fantastic.
Like many component libraries, it's not perfect, but it does what I need perfectly
because I have an internal facing application, I don't have a designer on my team,
I let Carbon decide my layouts, I let Carbon decide my interactions,
and I just worry about business logic, so it saves me a lot of time.
Yeah. And now with Kit, when you put a lot of the business logic in the load function
and the form actions, it must be even easier.
Yeah. Carbon's components have been a really full-featured UI library for Svelte
for a very long time.
I even remember back in 2019, I think, I remember hearing about Carbon Components.
I might be mistaken, but I think it has a pretty long history.
So it's been around for a long time.
Are you talking about the Svelte library in particular?
Yeah.
Okay. Yeah. I think the design system has been around for a long time,
but the Svelte version of that is Eric and Enrico, and I don't know if there are
any other people that help maintain that, but it is just a side.
It's not owned by IBM, correct?
Kind of. So Kevin's pretty close.
I think early commits of Carbon Components Svelte began in early 2020,
which early 2019, and that was led by Eric and his partner.
Pardon me, I forgot their name, but them two started Carbon Components Svelte.
And right now it's currently just Eric supporting it,
even though he's not currently an employee at IBM,
but he developed it while he was an employee at IBM.
So it's still IBM owned. It's still Apache 2 licensed.
It's still their copyright, and it's also their repository.
So under the IBM GitHub organization, Carbon Components Svelte there resides.
So it's still an IBM product.
But it's sort of a – yeah, but the governance is interesting,
because if you go to the Carbon Design System website,
and in case you guessed it by now, I highly regard Carbon.
I think it's one of the better design systems globally,
internationally recognized. They do a fantastic job testing.
Their QA team is everywhere. I see them constantly auditing and sending feedback.
I see the leads and the designers constantly thinking about new ways
to have interactivity without sacrificing accessibility.
They're doing a great job there.
And Carbon Components Svelte, much like their Vue and Angular libraries, I think,
or I may be mistaken with Angular, they are so-called community spin-offs
in which the governance model is they're owned by the IBM core team,
but the actual upkeep and maintenance is by community maintainers,
because they probably don't have the budget, resources, or need for those libraries.
Internally at IBM they don't use Svelte, or maybe some teams do at the time,
but no longer do. The point being that, okay, we'll freely provide Figma designs,
we'll freely provide the groundwork.
You can use our React flagship library as a grounded base,
and you can build your respective library based on that.
I think officially Angular, React, and Lit web components and vanilla HTML
are officially supported and maintained by the Carbon core team,
whereas Vue.js Svelte Carbon Components are all spin-offs, still centrally governed.
That is interesting.
Yeah, like these libraries that are started by companies and then adopted
or even maintained by the community, it's very interesting.
Carbon probably has one of the largest supported libraries
because even material, you can't find a good Svelte material library
that's maintained anymore.
Google just supports, I think, just React.
They don't even have their components online right now.
They're redoing their website, so you can't even see Google's material components.
It's just kind of crazy how much support and how far Carbon has went.
Yeah, it's hard to gauge from what's public facing.
But yeah, this is a big topic in itself that I love to get into
because I'm all about design systems.
But I do want to tackle Kev's question about side projects.
I am working on a job board, and I'm using SvelteKit and Fly.io as my host.
So it's also an adapter node sort of self-hosted project.
And I'm using PocketBase with it.
And I think a lot of us heard about PocketBase.
It's a very nice self-hostable Golang-based SQLite tool
that comes with its own Svelte-based CRUD to manage PocketBase itself.
And it scales very well.
I'd say unless you're on a large team or a large company with a large user base,
like a super large user base, PocketBase more than enough scales.
For sure. I've been using PocketBase for a while now.
And as I mentioned on the podcast before,
I've been rebuilding the Svelte Summit website.
And it's just so easy to work with.
You just change something, and it's just a joy to work with PocketBase.
Not having to manually write all the SQL queries to create tables
that they don't exist and all of this extra work.
And the ability to just export the structure of it and backup
and all of this stuff.
Really, really, really fun and nice project to work with.
I'm thinking of maybe using it for the Svelte Society website
and just go all in on SQLite and see if anything breaks.
Because the Svelte Society website would have quite a lot of users, right?
And it would be doing a lot of writes to the database,
which is where SQLite supposedly doesn't scale very well.
That's why people use Postgres or MySQL.
I don't believe that's true, so I want to test it out.
We'll see.
All right. Any other questions for Enrico, Brittany?
Or anything that you want to mention before we move on to the next sections?
The only thing I thought of is, I don't know if we touched on the changelogs.
I think I mentioned it, but did we talk about how you go through
the changelogs of anything that's changed in Svelte in this week?
I don't think we went through that, but yeah.
Sure. This week in Svelte's agenda, the very first thing we talk about
on the show is the changelog.
After publishing each show, I realized one of the most popular comments
on the YouTube videos is, "Thank you for going over the changelog."
People, I think, expect that segment to be the best segment.
They want to see the changelog and they want to hear the nitty-gritty.
And big shout-out to Paolo Ricciuti for getting nitty and gritty
on the changelog very recently.
But yeah, once I saw those comments, I had to double down.
I read the changelog. I also explained why these things change
and what things change and where's the documentation for those changes.
So yeah, it's not the biggest segment of the show,
but it is the first and foremost.
Definitely important.
Yeah, I feel like that may be one reason that keeps people coming back to it too
because it keeps you updated on everything that has changed in Svelte.
It tells you why. It shows you where to go to look up more information on it
and just keeps you in the loop of what's happening in Svelte.
Everyone should definitely check out This Week in Svelte.
Let's move on to unpopular opinions.
We don't have Anthony here today. He always has one.
I don't have one today.
Enrico, you told me beforehand you didn't have an unpopular opinion.
That's completely fine.
Brittany, do you have one?
I think the only unpopular opinion I have right now is just
don't mix bundlers and build things together
because when you try to put V and Webpack and different things like Rails
and Svelte all into one app, it's so complicated.
It's just so difficult.
Just make a new V on yourself and just use SvelteKit.
Do you remember we had Chris Toomey on way, way back?
I think it must have been like a year ago or something.
He was telling us about InertiaJS, which is like a library
where you can sort of like wire together Svelte and Ruby on Rails, I think.
Inertia has--
InertiaJS, yeah.
It could have been just Ruby and not Ruby on Rails.
Fully client-side rendered.
I came across that as well.
InertiaJS appears to be a tool that integrates traditional server frameworks
like PHP and Ruby with Node.js applications.
I'm not an expert.
I never used InertiaJS, but I believe what it allows you to do
is ship a Node.js server with SvelteKit or any Node.js-based framework
and have it communicate nicely with PHP or Rails.
Yeah, it says any modern single-page React view or Svelte app
using classic server-side routing.
So it would basically take your--kind of like we do with Svelte
and just use the client-side rendered version of it
and give you like a router and other things.
It's interesting.
I never actually looked into it.
That is not how we're doing it.
Maybe that's something you could check out.
Who knows?
Maybe.
I have an unpopular opinion.
And the unpopular opinion is that people use way too much JavaScript.
Most things should not be written on the client.
I had this--I think I mentioned the hot take last time
that you shouldn't use fetch on the client.
I firmly believe that most things should not be written
in even Svelte or JavaScript.
I don't know if that's unpopular here.
Maybe not here, but I think in the wider front-end web developer community
it definitely is.
I think most people, most companies, write things on the client.
They do their fetches on the client.
Obviously, interactivity is hard to do not on the client.
But yeah, I think the frameworks that we use could be simpler
if more people took that approach.
Enrico, you wanted to chime in here.
Yeah, that topic comes off pretty regularly at This Week in Svelte.
And you worded it pretty well.
One thing I learned to phrase things as is you should do one thing
unless you have a good reason not to.
And we don't want to neglect some developers who are working
on embedded devices or novel situations like TVs.
Obviously, if you have constraints and you're aware of your constraints,
don't listen to us.
You know what you're doing.
But if you're building traditional web-based, remotely hosted applications
like Kev was just describing, and it's something like what I do day to day,
which is CRUDs or basic user forms,
then you should not reach for JavaScript first.
So I could say I agree with that.
Maybe it isn't unpopular.
Who knows?
All right.
Pics, who wants to go first?
Maybe Enrico, you can go first since you didn't have an unpopular opinion.
Okay.
Thank you.
There was a movie I saw a few months ago, but it's still stuck in my head.
It's called "The Wandering Earth Part 2."
And there is a part one.
Both are really good spectacle movies.
They're from China, of course.
And they're like these high-budget spectacle science fiction films
that are based on a novel who's like the modern-day Arthur C. Clarke,
but he's a Chinese novelist.
And so the film industry there produced these big-budget science fiction films.
And I thought part two was--like I'm getting chills just thinking about it.
I thought part two was very well done.
It touches on so many thought-provoking topics that is executed on screen
so well and so memorably that I have to recommend it.
So my audio cut off there for a while, so I didn't hear the title.
But from the description, it sounds like--what's the--like a book?
No, okay.
I thought it was "The Three Earth Problem" or whatever it's called
because that's also Chinese, I think.
Yes, there is a Chinese TV show called "Three Body."
And I think it's being localized as "Three Body Problem."
Yeah, "Three Body" is an interesting book/show also.
You could check that out.
I think the TV show, the China-based one, it's a very long epic.
It's like 30 or so episodes each an hour long, and the pacing is gradual.
I think they tried very hard to be faithful to the novel,
and they got every single detail.
But admittedly, it's a bit exhaustive, so unless you feel in the mood for that,
it's a good show, but it's not for everyone.
It's very long.
Gotcha.
All right.
Brittany.
I am having trouble thinking of one right now.
All right.
I'll go.
So I--last week in my drunken haze--no, I wasn't drunk.
I ordered a MetaQuest 3, which is a VR headset.
Because the thing is, I want to get rid of my monitors.
I think they're just in the way, and I want to be able to work anywhere.
So I got this headset with the idea that I'd be able to just get rid of my external monitors
and put on the headset and work using virtual screens in front of me.
And I am sold.
It is really nice.
I can work anywhere and still have the screen real estate that I'm used to with--
I'll have my editor up, I'll have a browser window up, maybe I'll have some documentation up,
and it works really well.
You're wearing a headset?
Yes.
What?
My mind is, like, blown right now.
So it's actually really cool.
So you can set it up so that when you're at your desk, you only see your monitors,
and it's just like you're in a virtual office.
I see you wearing this on the stream.
Maybe I'll wear it next time, because I think you can also activate, like, a webcam
so that your avatar is showing instead of your real person, real portrait.
Oh, my gosh.
But yeah.
So it's pretty cool, because you sit at your desk and you do stuff,
but the headset itself has something called "pass-through."
So as soon as you leave the desk, it switches to camera mode,
so you start seeing the real world, if that makes sense.
That's crazy.
So you can still, like, go and get coffee and, like, drink your coffee
and still see the cup and et cetera, et cetera.
People might just look at you really funny.
Oh, yeah.
People are just laughing like crazy when they see me doing this.
But it's very nice.
So, yeah.
I can recommend checking it out.
And VR in general is very cool.
It makes me dizzy.
I think the old ones were worse in this case.
I've only ever tried this one,
but I've heard that the newer Quest 3 is supposed to be very, very good
in comparison to the old one.
We have PlayStation 5, and we got the PlayStation--
I don't know what the name of that thing is, but it's whatever--
PSVR or something.
Yeah.
So whatever that version is.
And it's--I mean, we just got it last year, and it had just come out.
So it's pretty brand new.
But when I do those, it--like, I have to sit down because I can't--
like, it just makes me dizzy.
And I think if I did it more often, I might get used to it.
I don't know.
Yeah.
If you sit down, I think it should be fine, right?
Yeah.
It is fine, but I still feel dizzy.
Yeah.
All right.
Fair enough.
I even ordered, like, prescription lenses for them that I'll put inside.
I'm going to have to check it out because I'm really intrigued now.
Yeah.
I just take my MacBook and my iPad and just use that as an extra screen.
And people still look at me funny doing that.
Like, I'll go to the bar on Monday night and sit and have a couple margaritas
while my daughter does gymnastics.
And I will work while I'm doing that with my two monitors,
like, sitting in front of me, basically.
If it works, it works.
Yeah.
Have you tried VR, Enrico?
Not too much.
I've tried Tetris Effect on PlayStation, but I don't own a VR set.
One of my coworkers talks highly about a glasses headset.
I forgot the brand, unfortunately, but they look like traditional glasses.
And just like what Kev described,
you can have three monitors virtually in front of you.
And it's really good for airplane travel.
Yeah.
Yeah, for travel in general, I think it's nice.
Like, if you're going away and you just have your small laptop, it's nice.
I think that's the show.
Enrico, where can people find you online?
Well, I have a website.
It's theetrain.ca.
That's my fun alias I've had since I was 10 years old.
And on there, you'll find a link farm to my GitHub, my Twitter.
I am not active on x/Twitter anymore.
I don't really post, but I sometimes check there.
I think, yeah, GitHub is good.
I am also theetrain over there.
And you're on Discord as well.
And I'm very responsive on all of those places.
So if you want to reach out to me for anything, you can find me on x.com or Discord.
Awesome.
And with that said, I think that's the show.
Thanks, everyone, for listening.
And thank you, Enrico, for joining us.
It was a super interesting episode.
And, yeah, we'll see you all.
I'll have you back to talk about just design systems, like for a whole hour.
Yeah.
That could be fun.
Great.
And we will see you and not talk to you next week, everyone.
Bye.
See you later.
Bye.
Hey, it's Kavir.
If you like the show, please drop a review on your favorite podcast player.
It would help out a lot.
Here's a quick word from our sponsor.
Welcome to the new era of content management with Contentful.
Say goodbye to the limitations of traditional content systems
and hello to a world where collaboration sparks innovation.
With Contentful, you're not just managing content,
you're creating content-first, multi-brand experiences
across all channels effortlessly.
The best part? It requires zero coding.
Empower your teams to collaborate and innovate,
delivering impactful digital experiences at scale.
Contentful's AI-driven platform not only streamlines content creation,
but also ensures it aligns perfectly with your brand.
Ready for a game-changer?
Start with Contentful for free today.
Unleash the potential of your digital content
and drive your business forward.
Learn more at Contentful.com
[intro music]
Hey, welcome everyone to another episode of Svelte Radio.
We're back again.
Ooh, I'm joined by Brittany.
Hello.
Hi.
Back this week.
Back this week, yeah, yeah.
Hello.
And we are joined by another guest.
It's Enrico.
You might know him from this week in Svelte.
Hi, Enrico.
Hey, everybody. Enrico here.
Hey.
So before we get started, Brittany, what's new?
It's been crazy.
I went on vacation last week, so I know I missed our previous guest.
I think we had Jacob on last week, but unfortunately I had to miss that one.
We went to San Antonio where it was kind of warm.
It was like 80s and 90s Fahrenheit, so what, 30?
A little less than 30, maybe 20, 28 Celsius.
That sounds very nice.
But it was overcast the whole time.
So I tried to get in the pool, and it was like windy and cold.
It was like still not warm enough to get in the pool there.
But we came back, and it snowed yesterday for Halloween, so that was good.
We have like probably three to four inches of snow outside now.
Wow.
Yeah, we just got our first falling snow here today.
Oh, really?
So it doesn't stay on the ground, though, because it's not that cold here just yet.
Yeah, our ground is not that cold.
I thought it would melt, but it froze overnight, and it's just like stuck there.
Damn.
Yeah, that doesn't sound like fun.
Maybe you should just go more south.
I've talked about it, yeah.
We just built that pool, though, so we're like 10 years, and our kids are in school still,
so 10 years, and then we'll probably keep this house for the summer when it's nice here
and then move somewhere else, be snowbirds for a while.
Yeah, makes complete sense.
All right, let's talk a bit more with you, Enrico.
Who are you?
That might be a broad question, but how did you get into development?
Who am I?
Yes, well, my name is Enrico Sacchetti, and I am a software developer based in the Greater
Toronto area, Ontario, Canada, and what I like to do is front-end development, and ever
since I was a teenager, that's what I've been doing as a personal hobby, and some opportunities
came along, and before I knew it, it was a full-time job.
So despite my post-secondary education in video game development, I actually pursued
a career in website development because that's where the opportunities lay.
We have had so many people that are video game developers, like by originally video
game developers on the show, right?
Yeah, I feel like that's been a thing.
The person that did Wolfenstein, the felt version of that?
Snuffy, Jason?
Yeah, and a couple of other people were in video game development.
It's kind of like the music thing that we have, too.
A lot of people were musicians before they were programmers, too.
Yeah.
That's interesting.
Yeah, did you get into the game development stuff?
Was that because of interest in gaming in general?
Yeah, it was sort of a misguided interest in video games because as much as I enjoyed
playing them, making them is 100% different.
You need ongoing, persistent passion for that, as I realized the hard way after graduating.
I tried to get jobs across the world, particularly China and Canada, because I was pursuing living
there.
I actually ended up living in China for one year and became an English teacher after graduating.
Oh, cool.
So that's where I learned how to speak Mandarin and teach English.
But even though I was teaching English...
I had no idea you spoke Mandarin.
Yeah, that's a thing I can do.
But aside from that, I found myself on the weekends learning code, HTML, JavaScript,
CSS, because that was my passion.
And game development was not my passion.
In fact, when I had an interview for a job, they told me to my face, "You don't have passion
for games."
And I'm really glad that happened.
That's rough.
As rough as it sounds, I was relieved because I realized this is not for me.
And I found out very early in my career.
So I think that's a very good blessing.
Yeah.
What language was that, that you were doing the video game programming?
Programming language?
Yeah.
In university, I learned C++.
And that's what I used along with some Visual Studio stuff and frameworks.
But I never had professional experience game development.
I just had a couple of portfolio pieces, and I graduated with that.
So I was never a game developer.
I was just a student of one.
And then eventually, I came back to Canada, my home, and got married, got a job.
And the rest is history until today.
So I'm still strongly into front-end development.
Mostly in CSS in the beginner years.
But then later in 2017 or so, I got a job full-time as a React developer.
And I finally got really deep into JavaScript and things like that.
So that brings me closer to today and Svelte.
So what happened next was about a year and a half ago, I joined a new company
where I'm still employed.
And it's a small team in a large enterprise where we have some autonomy
and choices in our tech stack.
I consider myself a full-stack developer, but I will really earn the title soon
once I actually deploy a self-hosted server.
Because we have our own on-premise infrastructure, we are absolutely
end-to-end full-stack.
From the cables to the ground, to the front-end,
touching the customer experience.
I love that.
That's how Svelte Society is now as well.
Completely self-hosted in my home.
How's that server going?
Yeah, it's going great.
Is it going good?
The next cloud is humming on.
I think for Enrico, the location is probably not that good because the speeds
are apparently not great.
I'm very close to Enrico, so you want me to check?
I mean, I think you messaged me a couple of weeks ago, Enrico,
with the upload speed or something of one of the videos that you uploaded
to the server.
Yeah, to the listeners, Kev is referring to our shared server for this weekend's
Svelte Artifacts, which we'll get into in a few minutes.
But it's actually pretty good now.
I was downloading stuff at at least 7 megabytes per second.
So it's a lot better than what I had earlier.
There must have been an issue with me or something downloading at 14 kilobytes
per second.
Unexpected.
Yeah, yeah.
Let's chalk it up to just weird internet stuff.
It's a series of tubes, you know?
Yeah.
Right.
Yeah, so you mentioned this weekend's Svelte.
But maybe before that, I'd love to hear if you have any-- so you mentioned
you weren't a professional game developer, but I assume you learned C++
since you learned it in school.
Is there anything that you feel is transferable from C++ into the JavaScript
world in general?
Or maybe you haven't touched C++ in such a long time that you-- I don't know.
What's any insights?
Good question.
This is a personal take, but I think C++, the language itself,
isn't very transferable.
But I did learn object-oriented programming, algorithms, data structures,
kind of like any post-secondary student would.
And that itself, that also was somewhat transferable, but the real transferable
stuff was the grit and the soft skills.
Being able to not get frustrated and persist and study and iterate is
one of the most valuable skills as a software developer.
Being able to stick with it-- because this is top of my mind because
sometimes I talk to high school students about pursuing a career in software
development, and what I tell them is you don't need to be passionate,
you don't need to have an innate desire to be a developer,
you just have to have the persistence necessary to not get frustrated
and to keep learning on your own.
Because the passion for learning is the most important.
So as far as transferable skills go, it's mostly that.
It's just, "Oh, no, I can't figure out how to send a div in CSS."
But wait, I did know how to write this class-based object in C++,
I can walk through that just fine.
So that persistent nature is what transferred.
Yeah, that makes sense.
And as we all know, CSS is notoriously hard sometimes.
It can be really tough.
Yeah, but I did get deep into CSS in my early years.
I love CSS.
It's a good programming language.
I think you're talking to two of the wrong people to complain about CSS to.
We like it too much.
Yeah, well, I mean, I like CSS as well.
I definitely always preferred doing--
I hate it when people reach for the JavaScript solution for everything
rather than just doing it in CSS and HTML.
It's one of my pet peeves of a lot of developers.
I mean, I understand that sometimes you need JavaScript
to do something accessible, right?
But it's still--
I bet it's much easier now to center a div than it was when you started.
Yeah, that was a really bad example.
It's really easy with Flexbox nowadays.
I mean, it's really easy now.
It wasn't.
I guess in 2007, that's when I really started deep into CSS.
Yeah, some things were different back in 2007, 2012.
Nowadays, there's so much CSS that I can't keep up.
There's so many amazing new features that I haven't even used yet.
Yeah, like have you seen the amount of different units for width and height?
It's crazy.
I know they have a purpose, but there are just so many of them.
I was going to say that container queries is where something that's not--
I mean, now it's broadly available across the browsers,
but it's still not backwards compatible.
So if you have to support older browsers than the latest,
you can't really use container queries,
but that's where I like to bring in Svelte's bind on the window
and do inner width or something if I need it for--
or not on the window, sorry, on the container,
and bind to the container width.
And I can do a container query with JavaScript
where I can't really support it yet for CSS.
It's fun.
The CSS tangent aside, it was just a year and a half ago
when I started my new career, my new job, and working with Svelte.
And I always knew about Svelte ambiently, like since 2021.
I've seen news and articles, and I think, "Oh, this looks fun.
I'd like to try it, but I'm too busy."
But that's okay.
So here I am doing it on the job, and after my first day or two with it,
I thought, "Wow, this is so smooth.
I'm writing so much less code than I used to."
And that's when things got really inspiring for me,
like super-duper inspiring.
It's because of that saving time, writing less code,
and shipping things faster, like write less, do more,
that ethos just showed up before I even read the sentence.
And then I saw Rethinking Reactivity and these famous talks about Svelte,
and I thought, "Okay, this is big.
This is bigger than me."
And with my background in community management,
because in 2018 I co-founded Design Systems Community,
incorporated in Toronto, and we run a global meetup group
where we talk about design systems.
Because my job in 2017 at Telus, a telecom in Canada,
I worked full-time on design systems.
So I did lots of React components, lots of CSS, and lots of liaising,
talking to teams, kind of like what Brittany does today,
talking about their needs and making sure that we have satisfying solutions
that cover the broadest scope and iterating constantly.
And that's why we started a meetup group,
to talk more in-depth about it for selfish reasons as well as giving reasons.
Selfishly because we want to be better at design systems.
Giving because we feel like we can add stuff back.
So to throw in a pitch here, our website, designsystems.community,
has a resources center, and that's where we freely provide talks
and resources to everyone.
And I thought with my background there,
maybe I can do something with Svelte as well.
And I had this itch I needed to scratch because as much as I enjoy
supporting many different types of roles, because Design Systems Community
is very inclusive to developers, designers, content writers,
accessibility primes, product owners, at every meetup we run,
we make a point to invite all of those roles at the same time
and accommodate them.
We don't want to make just a designer meetup, just a developer meetup.
We don't want to make something exclusionary because much like
design system work at a real company, you have to include everyone.
You have to involve everyone.
You need buy-in from everyone.
So that works really well, and it's been going smoothly since.
So when it comes to Discord and joining the group here with Svelte,
I sort of started low-key, just hanging back, lurking a bit,
see what kind of small or big community this was at the time.
And I realized, well, Discord itself is pretty cool.
It's got audio. It's got stage channels.
Maybe there's something we can do to have informal discussions
about the latest and greatest in Svelte.
And that's what inspired me to kickstart this week in Svelte
earlier this year.
So for those that are interested in seeing more of the designs,
the design community, it's DesignSystems.Community.
Is that right?
Yes.
Yep. Cool.
Yeah, so this week in Svelte, you've been running this
for quite a while now, right?
I don't even remember when you started doing it.
Was it last year?
So it was this year, 2023, February, and I did a bunch of non-recorded
off-the-air streams on Discord.
And then you came to me and said, "Hey, you should record these."
[laughter]
And Brittany, I think, also mentioned that.
Increased the workload a lot. Sorry about that.
It was worth it, though.
Yeah.
Taking on the challenge of a weekly show.
Yeah, to me, it's awesome to see that it's been so consistent.
Like, almost every week, there's been one,
and you always go through interesting topics.
Community members can join on the stage and showcase stuff.
I'm always in awe of how much information you have each week.
It's kind of insane how much you can--
and that has to take so much of your time.
I don't understand how you have enough time for all this stuff.
But it's just crazy the amount of content that is put out.
And like you said, kind of consistent just every week.
Yeah, if I can ramble off that a bit.
I think the overall time and effort it takes to plan, execute,
and do post-production for a single episode is about four hours of my time.
That's all together.
And I usually do it on the weekday evenings because I have a two-year-old,
and I love to give him my time, energy, and love during the day while he's awake.
And when he's asleep, I get to do this week in stealth.
And I think part of the consistency of content is being the primary host at the time.
I now have supporting co-hosts who I will give a shout-out to.
But in the early days, yes, I was the primary source of content.
And it worked out because being a senior developer,
I do have a lot of things I'd like to share with everyone.
And I love the constant feedback loop because after each week,
there was a very diverse crowd of developers on the stream,
on average 20, sometimes as much as 50 people were on stream.
And they would leave nice comments like, "Wow, I thought I knew a lot,
but you constantly teach me something new."
And these are very senior veteran developers giving me compliments.
And they have respectable amounts of knowledge.
And I just thought, "Wow, if I can do that,
then there's an infinite amount of things to talk about."
Because whether you're a junior, early developer, or senior,
sometimes there's just not something you don't know.
And it's true. As developers, we can't know everything.
It doesn't matter if you've been in the industry for 10, 20, 30 years.
You can't know everything. There's just infinite knowledge out there.
And you may not be exposed to it. And that's totally reasonable and human.
So if I could share my knowledge and information,
and perhaps selfishly, again, learn from others
and have them show up, do some showcases, answer some Q&A,
then the content becomes a virtuous cycle.
Yeah. It kind of sounds like when I started this podcast, actually.
I wanted to listen to a podcast about Svelte, but there was no podcast.
So I mean, I started, I mean, the first episode was just me reading off
new versions of packets or something very boring.
Fortunately, Antony and Sean and you, Brittany, joined.
Like Manifest Destiny, though. You create your own dream or what you want.
Yeah. Kind of has to work like that. Someone has to just do it.
Because it is, in the beginning, I feel like it does take some time
to get things off the ground.
The same with this week in Svelte.
It took a while before these other co-hosts started showing up
and showing more interest and maybe wanting to participate.
And that initial workload is usually, at least from my experience,
it's a bit more and then it kind of gets a bit easier as you go.
Because you also get into how to do it efficiently and stuff like that.
But yeah, so this week in Svelte, it's a weekly show on Svelte
that you can catch on YouTube.
So what kind of stuff, you mentioned you talk about
kind of almost everything on there.
Or maybe not everything, but anything is of interest
because not everyone knows everything.
So could you give us maybe some examples of what you've talked about there?
Yeah, especially in the early days.
My Trojan horse topic was always accessibility.
I sneak it in every time because we're all writing code in Svelte,
which means everyone on the show listening
does some amount of front-end development.
And if you do, then accessibility matters to you.
It should. And if it doesn't, I will make it matter.
So the reason why that matters so much to me
is because back in my design systems job,
I had to learn the hard way because I didn't care about accessibility
as much as I should have at the time.
So I wasn't always like this.
I had to, through experiences and talking to people
whose dedicated role was consulting on accessibility
and compliance laws and things like that,
and they taught me things I didn't realize.
For example, one of my most memorable lessons
was I shipped a button component, you know, the famous button.
Everyone's got to have one. And it was bad.
It was bad because when the text was too large
in the French language, it truncated.
And I didn't support that because in Canada,
we have to write things in English and French.
So I didn't test for French.
And furthermore, I didn't test for increasing the font size
because our browsers have two options.
You can zoom into the page,
and you can independently increase the font size.
And some people do that when they browse the internet.
So I didn't test with increased font size.
And when the text truncated, it was a bad button.
And I was taught that it should overlap and wrap to the bottom line.
The buttons should get taller.
You shouldn't specify a maximum height.
You should specify a minimum height.
Allow the buttons to be taller. Allow the text to wrap,
especially if they're off to the side in a card, in a container,
and there's no room for it to grow wider.
Good luck convincing the designers that that's going to fly.
[laughter]
Well, the simple answer there is, what is a designer?
A designer's job is to solve a problem.
You're trying to express something. You're not a designer. You're an artist.
And that's okay. That's a valid thing to do.
But you have to understand the role you're in.
I think what we would do in that situation is truncate it
and then have a popover.
As long as you have the ARIA, is that accessible?
It is compliant, but it is unacceptable.
[laughter]
So yeah, you have a means to read the text.
Therefore, it is compliant.
And transparency is not ideal all the time.
That's a funny example you shared.
But yes, when I work with designers, I got to give them respect to it
because it's such a diverse field in itself.
There's visual design. There's interaction design.
There's content design.
And I think the first conversations you have
when you build a digital experience is content, actually, not even design.
It's really like, what information are you presenting
to your audience through the internet?
What things are your audience trying to achieve on your website
or service or e-commerce experience?
How do you make it easy for them to consume,
whether the content's written in English or another language?
How do you make it easier for them to navigate?
It all starts with content.
And content actually is done in tandem with accessibility as well.
This is such a relevant conversation for me
because we had a new product director of design come in
and look at our site and say that,
what are our users actually seeing, doing?
How are they navigating the site?
And we're talking about redoing the whole hierarchy of the site
because we don't feel like the patterns and the interactions
that the users have are consistent.
And displaying that in a more readable, more usable fashion
will lead to increased revenue.
And knowing all of that as a designer, it's a lot.
Being a designer is hard too,
but I've been trying to convince my designers
that accessibility is important and you need to know about accessibility.
They think they don't need to know about it,
but they do need to know about it
and they need to use that in all of their designs.
Right. So that's an excellent example.
So back to Kev's question about where do I source my content,
this is definitely one of those examples from real-world situations,
real-job situations, trying to solve for accessibility
and providing a Svelte solution is something I talk about pretty often
on This Week in Svelte because we're constantly faced with these challenges
and people want to know, how do I solve this with Svelte?
Well, we're here to talk about it.
Yeah. I get the impression that a lot of the topics on This Week in Svelte,
like for example, this topic on accessibility,
it's not particularly Svelte-specific, right?
I feel like often you would, any developer would probably,
what's it called? Crap.
Completely blanking on the word here.
They would gain knowledge by checking out This Week in Svelte,
even if they're not using Svelte, is what I wanted to say.
Like obviously some things are Svelte-specific,
but accessibility is for everyone.
Yeah.
Progressive enhancement is for everyone.
You could probably learn more than just Svelte stuff.
Yeah. Yeah.
So it's nice to see those topics being talked about.
Yeah.
So what are, do you have any plans for the future of This Week in Svelte?
Any ideas on what you want to do?
Is that something you've thought about?
Yeah.
So as we discuss, we understand where we source the content from.
It's primarily through ourselves.
As the regular hosts, we provide the content because we just want to talk
about the things we want to talk about and sneak in related front-end
aspects.
The future of This Week in Svelte, I think, is scaling myself.
Just like Design Systems Community, just like any meetup organization,
scaling myself is to have this thing winded up like a toy and let it walk
on its own.
And that's why I need to give many thanks to my current co-hosts.
So Kareem first-jointed.
Thank you, Kareem, for your support in the middle days and for coming back
too, because Kareem is a solid developer and he works a lot with server-side
events and things like that.
And he wants to share his things on This Week in Svelte because they come
up on Discord a lot.
Questions come up about how do I achieve this?
And my breadth of knowledge is limited.
So I need to invite specialists, and Kareem helped fill that gap.
And then Paolo Ricciuti recently joined, and he's a regular co-host every
Friday as well.
And he's awesome because he's all over the Svelte ecosystem.
If there's a GitHub issue about something about Svelte, you'll likely see
Paolo commenting on it.
Yeah.
And we've had -- so Paolo is one of the co-creators of Svelte Lab.
We've had them on the podcast a while back.
So if you're interested in hearing more from Paolo, you should definitely go
and check that episode out.
Absolutely.
And now you're going to start using StreamYard.
Are you -- you said, you mentioned before we started recording that you were
on, trying it out yesterday.
So what do you think we'll gain by using StreamYard instead of just recording
on a screen on a computer?
It'll definitely help with execution and post-production.
I also want to thank my other recent co-host, Stanislav, for taking up regular
commentary because with the four of us now, it's like, okay, that's great,
but at times it's kind of excessive because we can't always get a word in.
It's sometimes difficult to coordinate when you can't see each other.
So one of the challenges we face with Discord stages as our primary platform
of delivering this Weekend's Felt was we had to use OBS to record everything.
I had to occasionally swap between sharing the Discord chat in my recording
as well as displaying what's on my screen.
And because I don't have fancy keyboard shortcuts or like a dedicated switch
device, it was really hard for me to manage.
And I couldn't expect my co-hosts to take on that complexity either because we
just wanted to deliver, yeah, that.
Brittany, for those of you listening, Brittany is sharing a really good
shortcut keyboard that I think every streamer should have, especially if
they're on a broadcasting service.
But we didn't have that, and I wanted to simplify things.
So StreamRoute has many advantages that I won't get too deep into,
but it allows us to join easily, much like a Google Meet,
and share what's on the screen.
And there's a lot less time between handing off screen shares because
StreamRoute has a really nice backstage tool that allows people to
preemptively share their screen, and then one click you can bring it on
or take it down.
And with Discord, you had to wait for someone to stop sharing and then
start sharing your screen, and then accept accessibility settings in
macOS because you forgot to set it up.
And there's all of these things to fiddle with that make post-production
a hassle because I have to cut those bits out.
Yeah, and you're still going to have to maybe deal with that, though,
if they haven't allowed Chrome.
I think Chrome is like one of the only ones that StreamYard supports,
but if they haven't allowed it in Chrome, you might still have that.
But the other thing I thought of that you might miss from Stages is
allowing audience members to come up on stage is something that that
offers that you won't be able to do in StreamYard.
So are we just going to move to just YouTube comments?
StreamYard does allow audience members to join.
As long as they share the link publicly, which I will do in the description,
people can join us on StreamYard backstage, and I'll invite them on
if they so like to.
That's right. I forgot about that.
Yeah, so StreamYard has some advantages.
I think there's a limit on how many can be in the backstage, I think.
It's like the total people, maybe?
Yeah.
I think limitations aren't too bad because from my experience,
the good thing about our show is the agenda has been very consistent
since day one.
Like the topics we had have stayed roughly the same,
and I'm sort of happy that it ended up that way.
I was always ready to iterate and adapt, but it stayed mostly the same.
But after the show, one thing that has to make the cut is the water cooler.
We have this off-the-air idle chat that happens after I stop the recording,
and we just stick around and talk about things that are unscripted.
But with the new StreamYard YouTube recording premiering this week,
and if you're listening to the podcast, it may have already happened,
but the thing that we're going to cut is the water cooler.
So the water cooler may end up resurfacing as its own separate event,
but we're not sure yet.
But until then, it's just going to be a very clean show
that's sticking to the agenda, and we'll engage with audience members
via YouTube comments and possibly StreamYard.
Yeah, that could be actually a way to get more people to the Discord.
Since we're sharing it to the YouTube now, we have more active users
probably on the YouTube that watch that than we do in Discord,
and you could tell people we're going to do water cooler
in the Discord voice channel after, or create a channel for that.
That would be interesting.
Yeah, very excited to see where it's going in general.
Here's a quick word from our sponsor.
Welcome to the new era of content management with Contentful.
Say goodbye to the limitations of traditional content systems,
and hello to a world where collaboration sparks innovation.
With Contentful, you're not just managing content,
you're creating content-first, multi-brand experiences
across all channels effortlessly.
The best part? It requires zero coding.
Empower your teams to collaborate and innovate,
delivering impactful digital experiences at scale.
Contentful's AI-driven platform not only streamlines content creation,
but also ensures it aligns perfectly with your brand.
Ready for a game-changer? Start with Contentful for free today.
Unleash the potential of your digital content
and drive your business forward.
Learn more at Contentful.com.
I forgot, I guess we did talk a bit about the work that you're doing
at the moment with Svelte.
But what kind of stuff in specific do you work with,
with regards to Svelte?
Are you working in a Svelte application or a SvelteKit application?
So at your day job, basically.
Yeah, how do I actually engage with Svelte day to day?
It's at my job, I also have some side jobs I'll get into,
but at my full-time job, I use SvelteKit to create a classic CRUD,
nothing too special or fancy or novel.
It's just a very straightforward and traditional CRUD
in which we have the adapter node used for SvelteKit.
We self-host it, of course, and it allows our internal users.
I build internal-facing applications,
so you'll never see these publicly,
but the internal-facing app facilitates some of our team members
in other departments to do some sort of management.
And I can't get into specifics, but the overall engagement with Svelte
is just make a SvelteKit application.
And my team is about five people, or actually it's four people,
three, four developers, really, one of them is a director.
We don't have a designer on our team.
So although we chose Svelte as our de facto front-end framework
for our team and all of our projects,
we actually have a lot of short-term projects
and long-running projects on our team.
Sometimes we'll work independently on six-week projects
and move on to the next project and the next project,
almost like piecemeal agency work, but it's all internal-facing.
Sometimes we have long-running projects, which I was tasked to do.
So for the past year and a half, I'm still working on the same SvelteKit
application I started.
- Oh, interesting. - Yeah, like I'm doing a long-running project.
And it's fun, it's interesting, it touches many aspects of front-end,
but just in the CRUD sense.
The tech stack I use is, besides Svelte, I also use DaltDB,
which is a novel MySQL database that is versioned similarly to Git.
So it actually has Git branches, but using MySQL.
You can actually check out a branch, and you can do MySQL writes and reads
on a branch, and you can actually merge changes just like Git.
- Oh, wow. That sounds really nice. - That sounds pretty cool.
Is it MariaDB that has branching?
I think maybe...
What's the auth provider that uses that?
- Superbase? - I know that PlanetScale has branches.
PlanetScale has branches, but there's another one that just changed their logo.
They use Svelte and everything, and my brain is not...
They have SvelteKit on the page. We just had the person on...
- It could be PocketBase. - Thomas.
- Oh, AppRight. - AppRight. My goodness.
I think they might use MariaDB and have branching also.
But yeah, my brain was not working there. Sorry.
It's all good. And yeah, my engagement with Svelte in particular is very straightforward.
It's mostly light, light front-end views.
I tried to pursue the progressive enhancement form actions mentality,
but I wasn't very successful. I still have pages in my app that require JavaScript to function,
but I hope someday I can make it all work without JavaScript,
because a CRUD can work without JavaScript.
Everyone probably knows what CRUD means, but create, read, update, delete.
Just throwing that out there if you don't.
That's like living the dream, though. You get to work straight with SvelteKit all the time
and not... I mean, our job has Svelte, but we don't get to work with SvelteKit.
So I get to work with SvelteKit in the design system and then release it as just Svelte components.
But the main app is just Svelte 3. We haven't even upgraded to 4 yet.
- Right. - Neither have we. But there's not much to it.
I see your point. Yeah, it's good to tell the audience what I meant by CRUD.
A CRUD is something that lets you engage with data.
It's just a user-facing front end so that you can make easy changes to a database
without having to use an actual database connector client like Heidi, SQL, or things like that.
So it has to be tailor-made to our audience needs.
It can't just be editing and writing and reading. It has to also have side effects.
It has to have hooks. It has to have special events required by our target clients.
And yes, it is SvelteKit, but it's also atypical SvelteKit
because we're not using traditional authentication.
We're using enterprise header SAML authentication, which is easier than it sounds
because what happens is when they go to our SvelteKit app, they authenticate using SSO,
single sign-on, and after that, our application will get some cookie headers that say,
"Okay, this user is authorized." That's the only thing we check for.
Do the headers exist? Yes, they're authenticated.
It seems nice to not be able to deal with the hassles of implementing a whole authentication flow
and all of that.
So you mentioned you've been working for a while on this application.
Does that mean that you experienced the good old days with the different router and stuff in SvelteKit?
Or did you start using it just after, maybe?
Oh, no. I used SvelteKit before it was version one.
I had been using version 405 plus the one with the new directory-based router,
so I think that's the one we were adopting, or we had transitioned to it.
Either way, I was there when it happened, and I was all right with it.
Yeah.
You also mentioned some side jobs, side projects?
Yeah. I guess to wrap up the work stuff, since we don't have a designer on our team,
I decided that we adopt Carbon Components Svelte.
And I actually, because we use it day to day, I talked to the maintainer who Brittany had interviewed
with the SvelteScience stream, Eric, and Eric invited me on to be a collaborator maintainer.
So sometimes I go in and I help close issues and make changes for bugs that I find
so that I can help co-maintain Carbon.
And Carbon's fantastic.
Like many component libraries, it's not perfect, but it does what I need perfectly
because I have an internal facing application, I don't have a designer on my team,
I let Carbon decide my layouts, I let Carbon decide my interactions,
and I just worry about business logic, so it saves me a lot of time.
Yeah. And now with Kit, when you put a lot of the business logic in the load function
and the form actions, it must be even easier.
Yeah. Carbon's components have been a really full-featured UI library for Svelte
for a very long time.
I even remember back in 2019, I think, I remember hearing about Carbon Components.
I might be mistaken, but I think it has a pretty long history.
So it's been around for a long time.
Are you talking about the Svelte library in particular?
Yeah.
Okay. Yeah. I think the design system has been around for a long time,
but the Svelte version of that is Eric and Enrico, and I don't know if there are
any other people that help maintain that, but it is just a side.
It's not owned by IBM, correct?
Kind of. So Kevin's pretty close.
I think early commits of Carbon Components Svelte began in early 2020,
which early 2019, and that was led by Eric and his partner.
Pardon me, I forgot their name, but them two started Carbon Components Svelte.
And right now it's currently just Eric supporting it,
even though he's not currently an employee at IBM,
but he developed it while he was an employee at IBM.
So it's still IBM owned. It's still Apache 2 licensed.
It's still their copyright, and it's also their repository.
So under the IBM GitHub organization, Carbon Components Svelte there resides.
So it's still an IBM product.
But it's sort of a – yeah, but the governance is interesting,
because if you go to the Carbon Design System website,
and in case you guessed it by now, I highly regard Carbon.
I think it's one of the better design systems globally,
internationally recognized. They do a fantastic job testing.
Their QA team is everywhere. I see them constantly auditing and sending feedback.
I see the leads and the designers constantly thinking about new ways
to have interactivity without sacrificing accessibility.
They're doing a great job there.
And Carbon Components Svelte, much like their Vue and Angular libraries, I think,
or I may be mistaken with Angular, they are so-called community spin-offs
in which the governance model is they're owned by the IBM core team,
but the actual upkeep and maintenance is by community maintainers,
because they probably don't have the budget, resources, or need for those libraries.
Internally at IBM they don't use Svelte, or maybe some teams do at the time,
but no longer do. The point being that, okay, we'll freely provide Figma designs,
we'll freely provide the groundwork.
You can use our React flagship library as a grounded base,
and you can build your respective library based on that.
I think officially Angular, React, and Lit web components and vanilla HTML
are officially supported and maintained by the Carbon core team,
whereas Vue.js Svelte Carbon Components are all spin-offs, still centrally governed.
That is interesting.
Yeah, like these libraries that are started by companies and then adopted
or even maintained by the community, it's very interesting.
Carbon probably has one of the largest supported libraries
because even material, you can't find a good Svelte material library
that's maintained anymore.
Google just supports, I think, just React.
They don't even have their components online right now.
They're redoing their website, so you can't even see Google's material components.
It's just kind of crazy how much support and how far Carbon has went.
Yeah, it's hard to gauge from what's public facing.
But yeah, this is a big topic in itself that I love to get into
because I'm all about design systems.
But I do want to tackle Kev's question about side projects.
I am working on a job board, and I'm using SvelteKit and Fly.io as my host.
So it's also an adapter node sort of self-hosted project.
And I'm using PocketBase with it.
And I think a lot of us heard about PocketBase.
It's a very nice self-hostable Golang-based SQLite tool
that comes with its own Svelte-based CRUD to manage PocketBase itself.
And it scales very well.
I'd say unless you're on a large team or a large company with a large user base,
like a super large user base, PocketBase more than enough scales.
For sure. I've been using PocketBase for a while now.
And as I mentioned on the podcast before,
I've been rebuilding the Svelte Summit website.
And it's just so easy to work with.
You just change something, and it's just a joy to work with PocketBase.
Not having to manually write all the SQL queries to create tables
that they don't exist and all of this extra work.
And the ability to just export the structure of it and backup
and all of this stuff.
Really, really, really fun and nice project to work with.
I'm thinking of maybe using it for the Svelte Society website
and just go all in on SQLite and see if anything breaks.
Because the Svelte Society website would have quite a lot of users, right?
And it would be doing a lot of writes to the database,
which is where SQLite supposedly doesn't scale very well.
That's why people use Postgres or MySQL.
I don't believe that's true, so I want to test it out.
We'll see.
All right. Any other questions for Enrico, Brittany?
Or anything that you want to mention before we move on to the next sections?
The only thing I thought of is, I don't know if we touched on the changelogs.
I think I mentioned it, but did we talk about how you go through
the changelogs of anything that's changed in Svelte in this week?
I don't think we went through that, but yeah.
Sure. This week in Svelte's agenda, the very first thing we talk about
on the show is the changelog.
After publishing each show, I realized one of the most popular comments
on the YouTube videos is, "Thank you for going over the changelog."
People, I think, expect that segment to be the best segment.
They want to see the changelog and they want to hear the nitty-gritty.
And big shout-out to Paolo Ricciuti for getting nitty and gritty
on the changelog very recently.
But yeah, once I saw those comments, I had to double down.
I read the changelog. I also explained why these things change
and what things change and where's the documentation for those changes.
So yeah, it's not the biggest segment of the show,
but it is the first and foremost.
Definitely important.
Yeah, I feel like that may be one reason that keeps people coming back to it too
because it keeps you updated on everything that has changed in Svelte.
It tells you why. It shows you where to go to look up more information on it
and just keeps you in the loop of what's happening in Svelte.
Everyone should definitely check out This Week in Svelte.
Let's move on to unpopular opinions.
We don't have Anthony here today. He always has one.
I don't have one today.
Enrico, you told me beforehand you didn't have an unpopular opinion.
That's completely fine.
Brittany, do you have one?
I think the only unpopular opinion I have right now is just
don't mix bundlers and build things together
because when you try to put V and Webpack and different things like Rails
and Svelte all into one app, it's so complicated.
It's just so difficult.
Just make a new V on yourself and just use SvelteKit.
Do you remember we had Chris Toomey on way, way back?
I think it must have been like a year ago or something.
He was telling us about InertiaJS, which is like a library
where you can sort of like wire together Svelte and Ruby on Rails, I think.
Inertia has--
InertiaJS, yeah.
It could have been just Ruby and not Ruby on Rails.
Fully client-side rendered.
I came across that as well.
InertiaJS appears to be a tool that integrates traditional server frameworks
like PHP and Ruby with Node.js applications.
I'm not an expert.
I never used InertiaJS, but I believe what it allows you to do
is ship a Node.js server with SvelteKit or any Node.js-based framework
and have it communicate nicely with PHP or Rails.
Yeah, it says any modern single-page React view or Svelte app
using classic server-side routing.
So it would basically take your--kind of like we do with Svelte
and just use the client-side rendered version of it
and give you like a router and other things.
It's interesting.
I never actually looked into it.
That is not how we're doing it.
Maybe that's something you could check out.
Who knows?
Maybe.
I have an unpopular opinion.
And the unpopular opinion is that people use way too much JavaScript.
Most things should not be written on the client.
I had this--I think I mentioned the hot take last time
that you shouldn't use fetch on the client.
I firmly believe that most things should not be written
in even Svelte or JavaScript.
I don't know if that's unpopular here.
Maybe not here, but I think in the wider front-end web developer community
it definitely is.
I think most people, most companies, write things on the client.
They do their fetches on the client.
Obviously, interactivity is hard to do not on the client.
But yeah, I think the frameworks that we use could be simpler
if more people took that approach.
Enrico, you wanted to chime in here.
Yeah, that topic comes off pretty regularly at This Week in Svelte.
And you worded it pretty well.
One thing I learned to phrase things as is you should do one thing
unless you have a good reason not to.
And we don't want to neglect some developers who are working
on embedded devices or novel situations like TVs.
Obviously, if you have constraints and you're aware of your constraints,
don't listen to us.
You know what you're doing.
But if you're building traditional web-based, remotely hosted applications
like Kev was just describing, and it's something like what I do day to day,
which is CRUDs or basic user forms,
then you should not reach for JavaScript first.
So I could say I agree with that.
Maybe it isn't unpopular.
Who knows?
All right.
Pics, who wants to go first?
Maybe Enrico, you can go first since you didn't have an unpopular opinion.
Okay.
Thank you.
There was a movie I saw a few months ago, but it's still stuck in my head.
It's called "The Wandering Earth Part 2."
And there is a part one.
Both are really good spectacle movies.
They're from China, of course.
And they're like these high-budget spectacle science fiction films
that are based on a novel who's like the modern-day Arthur C. Clarke,
but he's a Chinese novelist.
And so the film industry there produced these big-budget science fiction films.
And I thought part two was--like I'm getting chills just thinking about it.
I thought part two was very well done.
It touches on so many thought-provoking topics that is executed on screen
so well and so memorably that I have to recommend it.
So my audio cut off there for a while, so I didn't hear the title.
But from the description, it sounds like--what's the--like a book?
No, okay.
I thought it was "The Three Earth Problem" or whatever it's called
because that's also Chinese, I think.
Yes, there is a Chinese TV show called "Three Body."
And I think it's being localized as "Three Body Problem."
Yeah, "Three Body" is an interesting book/show also.
You could check that out.
I think the TV show, the China-based one, it's a very long epic.
It's like 30 or so episodes each an hour long, and the pacing is gradual.
I think they tried very hard to be faithful to the novel,
and they got every single detail.
But admittedly, it's a bit exhaustive, so unless you feel in the mood for that,
it's a good show, but it's not for everyone.
It's very long.
Gotcha.
All right.
Brittany.
I am having trouble thinking of one right now.
All right.
I'll go.
So I--last week in my drunken haze--no, I wasn't drunk.
I ordered a MetaQuest 3, which is a VR headset.
Because the thing is, I want to get rid of my monitors.
I think they're just in the way, and I want to be able to work anywhere.
So I got this headset with the idea that I'd be able to just get rid of my external monitors
and put on the headset and work using virtual screens in front of me.
And I am sold.
It is really nice.
I can work anywhere and still have the screen real estate that I'm used to with--
I'll have my editor up, I'll have a browser window up, maybe I'll have some documentation up,
and it works really well.
You're wearing a headset?
Yes.
What?
My mind is, like, blown right now.
So it's actually really cool.
So you can set it up so that when you're at your desk, you only see your monitors,
and it's just like you're in a virtual office.
I see you wearing this on the stream.
Maybe I'll wear it next time, because I think you can also activate, like, a webcam
so that your avatar is showing instead of your real person, real portrait.
Oh, my gosh.
But yeah.
So it's pretty cool, because you sit at your desk and you do stuff,
but the headset itself has something called "pass-through."
So as soon as you leave the desk, it switches to camera mode,
so you start seeing the real world, if that makes sense.
That's crazy.
So you can still, like, go and get coffee and, like, drink your coffee
and still see the cup and et cetera, et cetera.
People might just look at you really funny.
Oh, yeah.
People are just laughing like crazy when they see me doing this.
But it's very nice.
So, yeah.
I can recommend checking it out.
And VR in general is very cool.
It makes me dizzy.
I think the old ones were worse in this case.
I've only ever tried this one,
but I've heard that the newer Quest 3 is supposed to be very, very good
in comparison to the old one.
We have PlayStation 5, and we got the PlayStation--
I don't know what the name of that thing is, but it's whatever--
PSVR or something.
Yeah.
So whatever that version is.
And it's--I mean, we just got it last year, and it had just come out.
So it's pretty brand new.
But when I do those, it--like, I have to sit down because I can't--
like, it just makes me dizzy.
And I think if I did it more often, I might get used to it.
I don't know.
Yeah.
If you sit down, I think it should be fine, right?
Yeah.
It is fine, but I still feel dizzy.
Yeah.
All right.
Fair enough.
I even ordered, like, prescription lenses for them that I'll put inside.
I'm going to have to check it out because I'm really intrigued now.
Yeah.
I just take my MacBook and my iPad and just use that as an extra screen.
And people still look at me funny doing that.
Like, I'll go to the bar on Monday night and sit and have a couple margaritas
while my daughter does gymnastics.
And I will work while I'm doing that with my two monitors,
like, sitting in front of me, basically.
If it works, it works.
Yeah.
Have you tried VR, Enrico?
Not too much.
I've tried Tetris Effect on PlayStation, but I don't own a VR set.
One of my coworkers talks highly about a glasses headset.
I forgot the brand, unfortunately, but they look like traditional glasses.
And just like what Kev described,
you can have three monitors virtually in front of you.
And it's really good for airplane travel.
Yeah.
Yeah, for travel in general, I think it's nice.
Like, if you're going away and you just have your small laptop, it's nice.
I think that's the show.
Enrico, where can people find you online?
Well, I have a website.
It's theetrain.ca.
That's my fun alias I've had since I was 10 years old.
And on there, you'll find a link farm to my GitHub, my Twitter.
I am not active on x/Twitter anymore.
I don't really post, but I sometimes check there.
I think, yeah, GitHub is good.
I am also theetrain over there.
And you're on Discord as well.
And I'm very responsive on all of those places.
So if you want to reach out to me for anything, you can find me on x.com or Discord.
Awesome.
And with that said, I think that's the show.
Thanks, everyone, for listening.
And thank you, Enrico, for joining us.
It was a super interesting episode.
And, yeah, we'll see you all.
I'll have you back to talk about just design systems, like for a whole hour.
Yeah.
That could be fun.
Great.
And we will see you and not talk to you next week, everyone.
Bye.
See you later.
Bye.
Hey, it's Kavir.
If you like the show, please drop a review on your favorite podcast player.
It would help out a lot.
Creators & Guests
Host
Host
What is Svelte Radio?
Things about Svelte. Sometimes weekly, sometimes not.