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, Jacob Stordahl and the hosts discuss Jacob's transition from WordPress to Svelte and the practical aspects of developing third-party JavaScript widgets. They also touches on the role of AI in content management. Tune in!
Recorded on October 18, 2024
Summary
In this episode of Svelte Radio, Jacob Stordahl and the hosts discuss Jacob's transition from WordPress to Svelte and the practical aspects of developing third-party JavaScript widgets. They also touches on the role of AI in content management. Tune in!
Recorded on October 18, 2024
Discussion
- Who is Jacob Stordahl
- Svelte Summit Talk Spring 2023
Unpopular Opinions
- Jacob: you shouldn’t use a git ui! git is poorly designed
- Kevin: you shouldn’t use fetch() on the client
- Antony: MacOS is not that great!
Picks
- Jacob: Staff Engineer by Will Larson
- Kevin: Satori
- Antony: BunnyCDN
Creators & Guests
Host
What is Svelte Radio?
Things about Svelte. Sometimes weekly, sometimes not.
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
[upbeat music]
Welcome to Svelte Radio.
Hey, welcome everyone.
It's another Svelte Radio episode.
[imitates music]
This is a new intro.
I'm joined today by my co-host, Anthony.
Hello.
Hey, and we have another guest today, Jacob Stuhdal.
Hello. Welcome.
Hey, how's it going? Thanks for having me.
Yeah, thanks for joining us.
Before we get into it, let's hear some status updates
from Anthony and myself.
What have you been working on?
What I've been working on,
mostly stuff to enter the American market,
survive in the American market,
mostly around taxes, which is great fun.
Apart from that, I had COVID.
That was fun.
Again.
Yeah, just general stuff.
So is this American market feature stuff thing,
is that why you're going wild on Twitter
with regards to biking?
No, it doesn't make a difference to me
whether people drive or not in America.
It's just I do believe that America is,
and to a great extent, the UK is owned by the car lobbies
and people can't see it.
Like you don't need a car to go everywhere.
Big car, it is big car.
But the thing about big car is we say big farmer,
big car, but big car is real.
Like it is literally the main car companies
that lobbied against having any other form of transport.
That's why you've got roads with no pavements.
It's just stupid.
Or roads with no sidewalks.
It's just owned by cars, right?
And it's infuriating and kind of sad, really.
Yeah.
Lately I've been working on getting dynamic OG images.
I think that's the word for Svelte Summit,
which has been frustrating and fun at the same time.
I've been using a--
Did you use Jeff Rich's code for that?
I did use some parts of it, yeah.
But I've adopted it a bit.
But yeah.
We did that as well.
I'll talk more about it in the picks.
But yeah, Jacob, hello.
Welcome again.
Hello.
Who are you?
[laughter]
Why are you here?
Do you want to give us a short intro?
Sure.
Yeah, I'm a software engineer.
I work at a company called Styletics.
We can talk about what I do a bit later.
But yeah, I'm a self-taught software engineer,
web developer.
I started, gosh, 2015.
I took my first college course on basic HTML.
CSS3 had just gotten released.
We learned Bootstrap 3, I think, was out at the time.
So I was kind of at the tail end of that sort of old Web 2 stuff.
And so, yeah, I worked in--
Well, I guess my journey to full-time development is kind of interesting.
But eventually I started doing WordPress freelance development.
I really leaned into that during when the pandemic started.
And then shortly after that, discovered Svelte
and kind of have been bullish on Svelte ever since.
Yeah, I get to write Svelte full-time, which is really nice.
And yeah, that's me.
That's not very common to be able to write Svelte full-time.
No, I actually got coffee with Rich when he was here in Minneapolis
filming with Front-End Masters.
And he was shocked that I was full-time writing Svelte.
He doesn't know anyone that--
Even places like New York Times, people that use it heavily,
they're not writing it full-time.
But yeah, all the code I write is TypeScript and Svelte,
which is really, really fun.
Yeah. Sounds like a dream.
A dream that many want to live.
So you mentioned briefly before we started recording
that you came from a WordPress background.
Do you miss the good old days of WordPress?
[laughter]
I don't.
No.
I don't know.
I do really like-- and maybe this is my unpopular opinion, number two--
is I like PHP.
It's really nice.
I think the syntax is great.
I love writing HTML in the middle of my--
It feels very Svelte in that way,
combining your control flow with your templates.
I really liked it.
Dealing with clients and plugins,
those two aspects of doing WordPress development is awful.
I hated that because clients think they know everything
if they've used WordPress before, and they don't.
And they will throw whatever plugin in the world in there,
and then you have to deal with it.
So shortly after learning about Svelte,
and then around that same time I also learned about Sanity,
which I think is the best headless CMS.
I moved all my freelance projects to that stack
because it was just so much faster.
I don't need to buy a server.
I could just chuck it up on Netlify or Vercel or whatever
and deploy stuff for free, which is a game changer for me.
And having the Git workflow built in and all that sort of stuff that we get,
we all just take advantage of it.
It's just kind of table stakes now.
At the time for me that was huge.
I had tried to move my WordPress stack to Git auto-releases and all that stuff.
It was just a pain.
Yeah. I remember using back in--
So I used to do some WordPress development way, way back.
And I remember there was something called Bedrock,
which let you kind of do modern development.
But it was still very finicky.
I remember it was pretty rough.
We've actually moved our main homepage
or moving our main homepage to WordPress from Svelte,
which is the devil, but the reason being because it's easier for people to edit
without having to go through the development team, which is fair.
And we've also moved the company we acquired their site across.
We've built a site for someone else in WordPress as well, like a provider.
And I'm probably the world's smallest fan of WordPress.
No, the world's least fan of WordPress.
I don't know. I don't like WordPress.
But what I will say is that with a plugin called Simply Static,
we now push all the sites to Bunny.net CDN,
so that WordPress is never exposed to the public,
and that makes me a lot happier.
So all that they're seeing is static files in the CDN.
And that I can handle because it ultimately turns WordPress
into kind of like a crappy web builder, which is basically what it is.
But we never have to contend with anything being exposed to real people,
which is great.
Or hackers.
Well, exactly.
Exploits 629 known CVs on the CV database, etc.
Yeah, definitely.
One a week.
Yeah, I mean, it's good for the back of the day, but it's still bad.
Yeah, I guess it's the fact that WordPress runs most of the web as well.
Yeah, exactly. It's well exposed.
But it's also the whole--the plugins are a mess.
And they're the root cause of most of the issues it has.
And it's a hard job because it's like a marketplace.
The thing that annoys me is in the marketplace, they don't vet them.
So they've got plugins there that don't work with the current version,
so why show them to me?
I don't want to show a plugin that may not work.
It's crap.
Yeah.
All right.
Yeah, I mean, my policy was always just,
if you want a plugin to do a thing, I will find the plugin,
and I will install it and make sure that it's going to work
with everything else that's going on.
But I do agree that even just the improvements to the block editor
in recent versions of WordPress, people like to shit on it a lot,
but it's really powerful for a lot of different stuff.
You just have to know what you're doing.
If you can generate static pages and put them on a CDN, there's no issues.
It's going to be the same, just as performant as a swell kit website,
maybe even more so.
And then your people can edit content, which that's where the value is.
If your client can't edit their stuff, it's not really valuable to them.
They're not really getting what they're paying you for, right?
Yeah.
I would say that.
The only thing I have is I would say that obviously the HTML output
from these builds isn't particularly great,
and so you may have a performance.
Your Lighthouse scores may look great,
but your actual real performance might be less so.
It's likely to be less so, especially if you're using Elementor
or anything like that.
Yeah.
Right.
Okay, so Jacob, what do you actually do when you're writing Svelte at work?
Yeah, it's so incredibly niche, but it's been really, really fun.
I guess I'll kind of talk about what Styletics is at a high level first,
and then we can talk about what I do and what my team does with Svelte.
So we build a content platform that allows e-commerce retailers,
some of the biggest brands in the world,
to basically bundle their products into merchandisable bundles.
So the most common is outfits.
A lot of our customers are apparel retailers.
Let me see if ones I can name.
I think Nike is a really big one.
So you go to a Nike page looking for a T-shirt,
and then you scroll down the page and there's a JavaScript widget
that's like a carousel of outfits that contain that shirt.
And so it's kind of like giving you outfit inspiration.
It's like cross-selling,
incentivizing of other products that you wouldn't normally have maybe seen as a visitor.
And so we do this full stack from importing their catalogs
to showing the widgets on their page.
We do the whole thing at scale for some of the biggest retailers in the world.
So it's been a really cool challenge.
The back end entirely is written in Clojure,
so I don't really touch that stuff because I don't know Clojure.
But then the front end where we're shipping,
people might know third-party JavaScript is often what it's referred to.
You put a script tag in your HTML that downloads,
and then usually immediately invoked function expression is run.
We also now are shipping ES modules because they're supported in the browsers.
But most people use the old-fashioned IFI bundle.
And so then you have this widget on the page,
and the UI is all Svelte.
This is what we choose to use.
We're shipping, gosh, we just launched so many products.
We had what we call August Market Week.
So we launched, I think, four new products that are completely new,
alongside our existing six or seven different widgets.
And so they're just different user experiences
on top of this content that we produce internally.
So we have a team of stylists that use our internal AI machine learning tools
to produce these outfits based on different attributes
and different sorts of criteria.
It's a really, really cool back-end system.
And then we just fetch data from an API, render our Svelte component,
pass it props, and we have a widget.
Yeah. In terms of when you're building this widget,
are you using SvelteKit or is it straight up Svelte?
What's the situation back there?
Yeah, we're just using Svelte.
I've thought about building a SvelteKit,
because we have one widget that does actually have routing built into it,
but it's hash-based routing that gets appended to the page URL
that the widget is loaded on.
So I would love to build a SvelteKit adapter
that could basically morph the routing to be that hash-based routing.
And so you could have this SvelteKit application
that still has a server somewhere,
but could attach its routing inside of an application.
I haven't explored that, because we only have one product
that actually uses this routing, hash-based routing.
So that's a really pressing issue,
but it's definitely something I want to research.
But no, we actually ship with Vite and just Svelte.
It's basically an SPA that gets rendered.
And so what we do is we have a JavaScript class.
When the function runs, when you download the script,
that class is appended to the window,
and then the client has to call new widget
and then pass it some sort of configuration.
So you need to know the div that you want to insert the widget into,
and then some other configuration for the API and the display layer.
And so, yeah, it's just a Svelte and Vite build.
Yeah, I was going to say, that sounds pretty standard
when it comes to attaching it to some element.
It's how you would really attach most things.
Yeah, and so we have a little layer on top of how the--
you call new app or whatever you imported your Svelte component as.
The class kind of wraps that, and so we can do things like A/B testing.
If the user is on the control side of an A/B test,
we don't need to render the component at all.
We just hide it and then maybe send some analytics or something like that.
So that's why we don't just have the client instantiate the Svelte component,
because we have some other logic that runs before it's rendered.
But you could just import the Svelte component
and render it in the same way. It's pretty much the same.
Cool. So you--
Hmm, that's interesting. I'd love to see the--
or hear more about how it--
the AI stuff sounds intriguing as well.
How the-- maybe that's proprietary, though.
How they use the AI to create new styles.
I guess they take products and then just--
I don't know. Is that something you can talk about?
I don't know. And honestly, I don't know much about it.
I think it's mostly just-- that's why we still have a huge team of human stylists.
So they're kind of-- my understanding of it is that
they're giving feedback to these models that are producing this content
based off of different attributes.
We have style attributes, color attributes, textile, fabric attributes.
All this sort of stuff is attached as metadata to these items.
And then there's some process.
Honestly, I'm really ignorant to it because I just kind of fetch from the API
and throw it into the HTML.
But honestly, the cool thing about how well it works
is that we've started to experiment with building
sort of aggregation APIs on top of the Closure APIs.
So we have these generic APIs where you can fetch outfits that are already created.
You can fetch items based on similarity.
We call our replacements.
Maybe this is a feature that we sell to people like Upsell.
Instead of just showing the outfit as it exists,
what if you allowed the user to swap items in and out?
Maybe they like this outfit, but they want a different purse
or a different set of earrings or something.
So we have a whole API where you can send it a list of item IDs
and it will return adequate replacements for those items.
And so they're kind of really generic.
And so we've explored building Fastify APIs
to aggregate these into different shapes,
doing multiple fetch calls, but just as a way for us to prototype
what does a different API experience look like
and what user experiences could that enable us to do?
I prototyped-- this isn't something we're doing,
so it's fine that I'm talking about it,
but say you add something to your cart,
similar to at the grocery store you see packs of gum at the checkout.
What if we could recommend accessories, purses, jewelry,
those sorts of things that go with the item
that you just added to your cart?
And so I built a Fastify API that aggregated
these two different APIs together.
And yeah, it worked really, really well because at the base
it's these AI ML models that are producing really, really good results
and we just kind of have to figure out the best ways
to display it to users, which is really fun.
Right. Yeah.
I wonder how these e-commerce websites figure out
these combination deals.
I don't know if that's how you call it,
but below an item it could be like,
"Oh, this item is often bought with these trousers," or whatever.
I know how Amazon does it.
I mean, they probably just do a lot of people buy this item with this item.
I think they just shove random stuff together because it's usually rubbish.
It doesn't make any sense.
It could be.
So when it comes to building with Svelte
and in this particular use case,
are there any particular Svelte features that stand out as very good or very bad?
Well, honestly, I always compare building what we do
to building a first-party platform or something that's way more complex.
The really nice thing that I like is generally the UIs are a lot simpler.
And so I find things like, I'm building a widget right now that's new
that uses a single store as a state machine globally
because it's less than 15 components.
It's really, really simple.
I've been loving just using stores and how portable they are.
We have this global--we call it the DB.
And so the app can just sort of automagically update as the user interacts.
And it's not even a custom store.
It's just a writable with an object in it.
And we just make sure that object is a flat object.
And off to the races. It works wonderfully.
I think--yeah, I don't know.
I think if there's stuff in Svelte that I don't like--
I do think that the patterns--yeah, right.
I do think the patterns introduced with runes that are going to come up are better.
I think skewing the language of JavaScript in a Svelte file
has always felt a little weird.
I will say that I think Svelte and the way that it messes
up the JavaScript language enabled me to learn JavaScript.
So I tried to learn JavaScript in college, and I didn't get it.
I was an art kid. I liked the DOM. I was a graphic designer.
I did not understand functions or programming at all,
what a variable is. I couldn't understand it.
It was so visual.
And so I tried to learn React, and I find that this JavaScript abstraction
on top of JavaScript doesn't really help you learn JavaScript.
But if you know HTML, and you have this HTML abstraction on top of it,
and you can sprinkle in JavaScript,
that's really what enabled me to start to learn and really get it.
Which I think is really, really cool.
But I think that there's a foot gun there where if you don't understand
why or how Svelte is doing this magic,
you don't understand why export let is weird.
Or the dollar label.
You don't know what labels are.
And now in my work, I need to know what labels are.
Whereas before, when I was just doing website building,
I didn't need to care about labels.
So I think it is really good for beginners,
and I do push beginners often to just look at Svelte,
because I feel like it makes it more fun to learn JavaScript,
because you can actually just get stuff on the page
without needing to know what a React fragment is,
when you learn React.
- Yeah, mapping over an array to get things out and stuff like that.
It's also the fact that you can just use--
you don't even have to use the script tag or the style tag at first.
You can just write HTML straight up and then get something on there.
- Yeah.
And when I was first starting, that's exactly what I did.
It's just HTML as components, basically.
It's all it needs to be.
I was building static websites that didn't even need the content updated.
And so I would just--
it was just componentizing HTML, which was my biggest gripe
with building just static HTML pages, was the copy-pasting.
And so I feel like Svelte is a really good middle ground in that regard.
- Yeah, agreed.
I guess we're tooting our own horns here.
Is that a saying?
- Yeah, you think it's a saying?
- I think it's a direct one, though.
That's the question.
- Well...
- All right, so embedding--
Svelte, you mentioned before we started recording
that you wanted to explore maybe building a meta-framework.
What's the idea there?
- Yeah, I've toyed with this idea for--
god, it must be a year.
Basically, I heard about the Streams API
is supported in all the browsers now.
And so the biggest issue that we always run into,
and anyone who's built third-party JavaScript knows this pain,
this is why I added in my Twitter bio that my goal is to make you
hate third-party JavaScript less.
Because we get scrutinized in B2B SaaS more than anyone.
Because some executive will run a Lighthouse score
and see that we're impacting their performance by two points
and they want to throw the whole contract out the door.
And it's just-- so many people have this negative connotation
around third-party JavaScript.
And so I thought, what if we could learn from SvelteKit a little bit,
but make our own meta-framework that's purpose-built
for third-party JavaScript,
where you have this thin client.
Right now we have a bunch of logic that runs in the client's browser.
They're fetching data from multiple sources.
They're running a bunch of computation
and then rendering something
and maintaining all the event listeners
so that hydration happens in the browser.
So what if, instead of that, you had this really thin client
that all it did was fetch from a server
and that server returned streamed HTML
and you put it in your dev.
And then you had this really thin client
that all it did was fetch from a server
and that server returned streamed HTML
and you put it in your dev.
And all of that other logic, computation, API requests,
data fetching, whatever else, happens on the server.
And then we just hydrate.
After that HTML is added,
before the user needs to interact with it,
we just update and hydrate.
And that's it.
It's such a niche problem.
What we're doing now works fine enough
and we write good enough code that in general
we can prove we don't have a negative impact in Lighthouse scores.
Which is for some reason the metric that everyone seems to want to die over.
I don't really understand it.
It's a number that they think is objective.
It's frustrating that a lot of these people that have a problem with it,
they don't really understand what it means in reality.
If you go and use our widgets,
they're incredibly fast and performant
and really nice to interact with.
And the actual perceived performance by the user is incredible.
Maybe we'll build this framework
and if we do I'd love to do a Svelte Summit talk about it
because it'd be really cool.
But we'll see. I don't know.
I don't know if it's already JavaScript, but who knows.
Maybe it's useful to other companies and other people could contribute.
I don't know.
I feel like there's a lot of companies that have embedded stuff.
It's probably not their main kind of product,
but often you see companies have this extra widget thing
that you can just embed as part of their suite.
Yeah, our whole business is built on that.
In fact, having widgets.
There you go.
You have a customer.
Yeah, it's definitely not a niche.
That's how I found Svelte actually.
I was building third-party widgets for getting a loan when you're at checkout.
We were building one of those for a Danish DIY store or whatever.
And that's how I found Svelte.
That's very nice.
You find Svelte in the search engine.
You find Svelte in the least expected way.
Yeah.
And then you realize you've been doing everything wrong.
Yeah.
No, is there anyone that could produce a single standalone file to include them in the site
that would make a widget rather than including that view library as well,
React or whatever?
Ah, right. Yeah, that makes sense.
Yeah, and that's the big reason I think in my Svelte Summit talk in the spring,
I mentioned that it's kind of the obvious choice to me.
Because I've seen people ship widgets.
Before I was at StoLytics, I worked as the web manager for the largest technical college
here in the Twin Cities in Minneapolis.
And?
We had a vendor sell us this thing.
It wasn't my decision to pay for it.
Someone else in leadership decided.
And yeah, it was using React.
The whole React library to our website
for this little tiny button that floats in the corner
and is like a chat bot thing.
Worth it.
And yeah, it's ridiculous.
And so yeah, Svelte is the obvious choice, I feel like, for this use case.
Because all you have to do is bundle the output, really.
And if it's simple enough, you don't even really need to do that.
That's it.
Yeah.
I hadn't thought about the React,
like having to ship React or Vue or whatever.
That makes it so much worse.
Cool.
I guess we touched on Runes already,
but do we want to talk a bit more about that?
What do you think?
I don't know. No one?
I was really skeptical at first.
Everyone talks about React brain, I feel like I had Svelte brain.
It's hard to see the things that have been the most constant change.
But after playing with them a little bit in the playground,
I think that it unifies
and makes the language a lot more cohesive.
Like yeah, reading the blog post with the bulleted list
of all these issues that Runes will solve,
it kind of solves all the things,
all the foot guns that you can run into.
Again, like I said, if you don't understand how the magic works
and you're building a complex application,
Runes hopefully will take care of a lot of that
and make it a lot simpler.
And everyone's talking about getters and setters being bad.
Everything in JavaScript is an object.
Learn getters and setters. It's how the platform works.
They're really great.
I think in the live stream yesterday,
something that can automatically add those getters and setters to your objects.
I feel like that would be great.
Not having to manually type them.
A lot of our internal packages and APIs that we build
for stuff is all classes with getters and setters.
It's a really great pattern.
I hope that the learning curve will be
maybe a little easier with Svelte
because you don't need to understand all that different sort of magic.
It's just, this is how Runes work
and they will work the same across everything.
Especially getting rid of that export let for props
I find is going to be really killing.
Two of my favorite things for sure.
Why though?
Export let, the name, and that's apparently a prop?
It is kind of weird in a sense.
You don't know it unless someone told you what it means.
Yeah, I guess I've just been doing this too long.
Export let to me seems logical, but it's true.
It is weird. It's definitely weird.
I kind of had the same initial reaction towards Runes as well.
I quickly came around.
I'm just worried that, well,
I'm always worried that we'll lose a lot of the
beginner friendliness, but I don't think that's the case here.
I think it could be.
It could be the case, but ultimately we want to have
something that's acceptable to all.
I might push my fight to the resistance to
getting rid of the dollar colon, for example.
Because we plan to remove it in a future release.
Maybe we defer that a bit.
Just because I feel that's part of the joy of building
something quick is just going in and going, "That's reactive. Done."
So I don't know.
There'll be resistance for that because of duplicative code
and resistance in the size of the library and stuff.
I don't think it's going to go away in Svelte 5, right?
No, not in Svelte 5.
Maybe not 6, maybe not 7.
But at some point, I think eventually we don't have to have two ways to do something.
And I think that's the bit where I go,
"We have lost a little bit of something here because
that's kind of the joy of being able to build things super quick and
not understand too much."
I've been thinking about this for a while,
but maybe it's the fact that TypeScript is growing so much
that it's part of making people want to change things
so it works with TypeScript. Does that make sense?
If you're just writing JavaScript and you're writing Svelte,
there's no issue with writing--
well, other than the fact that things can get pretty hairy
if you have a lot of reactive statements, stuff like that.
But there's no issue with typing, right?
Because there are no types in JavaScript.
So I feel like it might be the case that TypeScript has kind of
pushed Svelte towards being more TypeScript compatible.
And that is the reason why you get rid of dollar colon, for example.
Because you can't type that, right?
I don't know. I'm just speculating.
TypeScript is growing, right?
So it's probably good that Svelte is moving in that direction regardless.
But yeah, let's move on to the best section of the show,
as I always say. But it's not, of course.
It's just the unpopular opinions.
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
Who wants to go first?
I'll go first. So my unpopular opinion this time
is that Mac OS X isn't particularly good.
I saw your tweet thing.
Well, to the kids, I don't know what his name is.
Yeah.
Well, yeah. So every time I hear someone say how great Mac OS X is,
every single time they're referring to the great tools you can buy
and install on it. And I'm like, well, that isn't a feature of OS X.
That's actually a gap, a functionality gap in OS X
that you're filling with a good tool
because it doesn't exist natively in the OS.
That's not like... that doesn't make OS X good.
It makes OS X bad, if anything. Right?
And so, yeah, I just I don't get it.
Like I have built into Gnome and Linux everything that I need.
And sure, I can add extra tools if I need to,
but I don't really have any.
I don't use any third party things other than a browser
and VS code and stuff like that.
And I don't even need to install Homebrew,
which is an absolute joke of the system.
Like all of the stuff is just rubbish.
It's just like third grade, third grade, third rate,
third rate equivalents of tools I already have built in
or a massive void where something should be like window management
or screen recording or what else.
I don't understand what that was.
Yump or it's called. Yump tool.
I don't know what it's called.
Whatever the tool is you're talking about where you drag and drop things.
I can drag and drop like just by dragging and dropping.
- What? - It's right there.
I couldn't... I read the homepage.
I'm like, what does this tool do?
What is it for?
But what I'll tell you is that trying to copy files
to drag and drop and move on OS X is infuriating.
It constantly unclicks them all and then they're not selected.
I'm like, how is it this bad?
I can't just grab some stuff and copy it.
And no amount of key combos helps.
And there's no filtering.
- Just don't move stuff. - Exactly.
- It's easy. - And there's no tabs.
And the layout's disorganized.
And it's just on and on and on.
So actually on my OS, I just opened Nautilus and ta-da, it all works.
Got some tabs, drag and drop there, copy that, filter by file name,
search, mass rename, it's all there.
Why do I need a tool?
Why am I paying someone to do that for me when it's free?
So yeah, that's my opinion anyway.
All right, Jacob.
Well, I do agree, actually.
I'm a decade macOS user.
And Anthony, I've essentially riced my macOS to be like Linux.
I have like i3 style window management, keyword shortcuts.
The only reason I like it is because of the ecosystem.
I get my phone notifications on my--
all of that stuff just works.
But I agree, everything else about macOS is frustrating.
Yeah, I need a screen recording app.
I have to have Raycast to have real window management.
Even the ways that the settings in Mac can--
you're so limited in your customization.
I have to like hack so much stuff.
Yeah, I agree.
My unpopular opinion is that--
well, it's actually twofold.
One is you should never use a Git UI,
including the VS Code built-in version control tab.
Throw that in the garbage.
And it's because Git--this is my other unpopular opinion--
Git is really poorly designed software.
It's really complicated, and it's really hard for people to learn.
And I find if you're a beginner and all you use is VS Code,
the second you're on a team where anyone's doing anything weird
or complicated with Git, you will be completely lost in the weeds.
Because that was my experience when I joined Styletics.
I was using VS Code at the time, just using the version control tab,
hadn't really ever worked on a team using Git.
And so the second someone was like, "Oh, you need to cherry pick this commit,"
I was like, "What is that? What's the ref log?"
The second you get into anything complicated--
Just re-base it and hard-force reset to the head.
Yeah, exactly.
And so you need to take the time to learn Git deeply on the command line.
Once you learn that, use whatever Git UI you want.
If it helps you and you like it, do it.
But you need to understand those complicated parts,
because if you don't, you'll shoot yourself in the foot.
I've done so much weird, improper stuff to our Git history
because I just didn't know what I was doing.
There's a course on YouTube, Free Code Camp.
I think the founder of Git Tower does advanced Git for professionals,
and it's a great course to learn Git.
So yeah, don't use your Git UI. Throw it away.
Definitely. I'll definitely check that out.
My unpopular opinion is something I posted earlier today on Twitter.
You shouldn't use fetch on the client.
And what that means is that you should do your data fetching on the server,
basically, and just get it with whatever JavaScript you're shipping anyway.
So basically, server-side rendering.
Obviously, it doesn't work if you're doing widgets or--
Yeah. Does it work?
SPAs, right?
Because if you were to do an inline update to something,
like a Salesforce Git form, it's using fetch for you.
Yep. Oh, of course.
But if you design it in the correct way,
you should be able to not have JavaScript turned off.
Right. Oh, yeah. So you have a fallback.
Yeah.
Yeah. It's fine to use fetch, but it shouldn't be like,
"Oh, here's the component. Now I need my data.
I'll use fetch in the web browser, and then I'll fill it in."
Yeah, that would be bad.
That's the point I'm trying to make.
Yeah. That's it.
All right, picks. I'll go first.
I am going to pick Satori,
because I've been building the dynamic OG image stuff.
Basically, a really nice library that Vercell released
that helps you build dynamic OG images for meta tags.
Nice.
Very relevant now that Twitter has removed the headlines
and descriptions from their own embeds.
Or, sorry, X.
X.
All right, Jacob, what's your pick?
My pick is a book.
I've been reading "Staff Engineer" by Will Larson.
It's a pretty renowned book.
It's very, very good.
If you're an engineer working on a team, I highly recommend it.
It's been a really great read.
He's really casual in his writing, but he's also very clear.
So it doesn't feel too academic or formal.
And so all of the things he's writing about
and the interviews he does with people on
what does it mean to be a staff engineer
and contribute at such a high level,
I've been really enjoying it.
Cool. Great.
My pick is Bunny CDN, bunny.net, for multiple reasons.
I guess the first one is Google Fonts.
If you use Google Fonts, it actually violates GDPR by default
because they do tracking when you download a font from there.
If you just replace--
Oh, nice.
Yeah, if you replace fonts.google.com in the URL with bunny.net,
I think it is, or fonts.bunny.net, it will work.
It's just like a drop-in replacement, but it's not.
It's GDPR-compliant.
And the other reason is because it is a fully-fledged CDN service
that has all sorts of cool stuff like pull from origin,
so you can proxy things.
I'm proxying Node.js site because it's so reliable right now
for our CI builds.
It's a lot faster from my buddy CDN.
I've moved all our static asset handling there
because it's so cheap to host this stuff.
Same sort of thing as Vercel, regional, blah, blah, blah, blah,
but it's just a lot nicer to set up.
I'm hosting all our static WordPress sites on there
because the simply static plugin pushes directly to Bunny.
You can put your own file systems on there and stuff,
and you can do functions.
It's got built-in AI, so you can do image generation.
It's got built-in image resizing,
so you can do all the fancy image resizing stuff you want to do.
It's full of features, and it works really well.
So, yeah, definitely my pick.
An alternative to Cloudflare and--
Exactly, a much more user-friendly alternative to Cloudflare.
Probably a less bundled alternative to Vercel
because it just focuses really on the CDN part.
Yeah, it's great.
Yeah, that makes sense.
Cool. That's our show today.
Jacob, thanks for joining us.
Where can people find you?
Follow me on Twitter @storedoll.dev.
The dot is spelled out.
That's also my blog if you want to read.
I've published some more technical articles recently
exploring Google Cloud Functions with testing them with VTest
and TypeScript decorators,
using decorators to simplify error handling.
It was a pattern I developed at work and wrote a blog post about.
So, yeah, if you want to learn stuff,
you can read my blogs or follow me on Twitter, I'm sure.
Me and Antony will be riling up the motorists some more.
Big car, yeah.
We're doing some other kinds of shitposting, yeah.
Yeah, hopefully we can have you back on
when you start building this meta framework thing.
We'll see.
And if you're interested in that, ping me on Twitter and let me know.
Because I feel like it's just me that wants it
and I have no gumption to actually do it.
Yeah, if you need some external pressure.
Yeah, exactly.
All right, and with that said, thank you all for listening
and we will talk to you next week.
Hey, it's Kavir.
If you like the show, please drop a review on your favorite podcast player.
It would help out a lot.
Thanks.
[BLANK_AUDIO]