Leo Dion (host): Hey everybody.
Before we begin the episode today, I wanted to let you know of a few things.
One I'm still open to new opportunities, so if you or your company needs someone
to come in and help with any Swift development, bright digit is available.
I.
Reach out to me, Leo, at bright digit.com, or you can
go to our, the website, break digit.com to get more details.
Let's set up a time to talk and see how I can help you or your team with
whatever project they're working on.
Yeah, just let me know and I would love to help in any way I can.
Secondly, I'll be speaking at Swift Craft.
This will be in May dates.
You can check that out here and on the website.
And I will be speaking on learning how to count and being
an advanced Swift programmer.
So I'll go over some stuff about the history of numbers and mathematics
and how it's related to the evolution and complexities of Swift.
So I would love to see you there if you're gonna be in the UK, in Kent.
Come check it out.
And then I have been doing a live stream every Tuesday and
Thursday at 9:00 AM and I'm hoping to continue to do that as well.
For the foresee future.
I.
I've been doing stuff with bushel and with a new app that I'm working
on that will be revealing soon.
So if you are interested in learning what is coming down the
line, you can definitely want to check out my live stream.
It's on my YouTube channel, bright YouTube dot.
Com slash break digit.
It's also on LinkedIn and on Twitter as well.
If you like what in those live streams, I want to test
some of these features out.
I'm still looking for beta testers for Bushell, and I'd love for you
to join and get an exciting look at what you can do in Bushel.
So definitely check that out.
And lastly, we still have our Patreon, so if you want to get early access
to episodes like this or you want to, get access to upcoming articles
and drafts and a little of the feedback I've been getting from folks.
Super helpful.
Reach out to me and let me know.
That's about it.
So thank you again for joining me for this episode, and I
hope you enjoy the rest of it.
Bye.
Welcome to another episode of Empower Apps.
I'm your host, Leo Dion.
Today I'm joined by Paul Hudson.
Paul, thank you so much for joining me today.
Paul Hudson (guest): My pleasure.
Leo Dion (host): It's been, I wanna say three years since you've been
on,
I think.
Paul Hudson (guest): Since the pandemic time's a concept
noone really gets time anymore.
Leo Dion (host): I think it was like right before the pandemic I had you on.
So yeah, it's like a million years in real life.
But for those who don't know
who you are, I'll let you go ahead and
introduce
yourself.
Paul Hudson (guest): So folks, my name's Paul.
I run the site hacking with Swift.
I work on various open source projects recently that's been
the Inferno Project, which is a collection of open source metal
shaders for swifty y developers.
Then I released Vortex, which a high performance, special effect
library creating partal effects for again, Swift y developers.
I've also built control room, sitrep, unwrap, and a whole bunch more open
source, really deep in my blood.
Leo Dion (host): Nice.
Nice.
So today you wanted to
talk, when we talked beforehand, you said you wanted to talk
about Swift on the server.
Paul Hudson (guest): Yeah.
Leo Dion (host): builders.
And then a few days ago, you released
a certain project that is heavily involved in that.
Do you wanna explain
what that is?
Paul Hudson (guest): It's like I planned ahead.
It's like I planned ahead somehow, right?
Yeah, cause you had you offered a range of dates to
the podcast.
I'm planning on this new thing, working to this
new project,
and I released a Tri Swift Tokyo
last week.
So today we're recording this on, I think Wednesday, end of March.
And I rec, I released it Friday in
Tokyo.
So it's brand new and I've been working out for a while on and off,
and it's been percolating through my brain and I thought you want to
talk something interesting and new.
Here we go.
This is definitely very new and definitely very interesting.
'cause it's all in my head right now, which is great.
And I'm finally glad to release it to the world.
And this new project is called Ignite.
Someone asked me how I think up names to my project.
I'm like it's.
Pretty pathetic.
It's got imagine a 5-year-old boy who thinks, what words sound cool,
ignite, inferno, vortex, yeah, I suppose more of how it works.
And so I want to keep a, the fire themed name, so a bit of confusion
in people's brains a little bit.
And I've released Ignite, but it's not anything like the
previous metal cadence thing.
This thing is a static site generator built with Swift.
Leo Dion (host): That is awesome.
I we were speaking before the show and I was like, yeah, I've
used published before to build the bright digit website, so
I'm familiar with Sun DE's set
of libraries there.
What.
What's the different approach that you took with Ignite?
That is different,
Than publish for those who know what publish is.
Paul Hudson (guest): First, at first we don't know what
publishers or.
Things like Talker Max out there for example, or,
Ignite at all.
Let's start with what the idea is.
Do you want to build your website in Swift?
And that's the first question because you're gonna obviously use
HML, you can use CSS, you can use JavaScript right now and build,
of course, world leading websites.
Most websites in the world built stuff, right?
What these tools are allowed to do is use your Swift skills.
To build websites.
And this means you can avoid some of the complexities around
HTML and CSS, for example, making mistakes in HTMLs fairly easy.
'cause it's just a whole bunch of strings.
Miss a tag off and like a end of a H two, suddenly
everything's heading to whatever.
It's possible 'cause it's just string base.
There's no compile checking your code for you.
That's in there but also in the CSS land.
Things are complicated.
You've gotta think about things like are we in light mode or dark mode?
Are we in limited space or lots of space with media queries and similar?
It's complex.
And my pitch is that most folks don't have enough time to be a
really great Swift developer and a really great web developer.
And so there are tools out there.
You've mentioned publish already and publish uses.
But it's a whole bunch of stuff from John.
Is ink,
Leo Dion (host): Yeah, you got ink, you got plot, you
got, yeah, it's built on top.
A
lot
of
Paul Hudson (guest): You got ink, plot, splash, publish, whatever.
Ultimately you write Swift code that generates your HML.
The approach John took is different from the approach
I've taken, I've aimed for, to answer the question, what if SwiftUI were.
That style, where to let you write websites.
And I don't mean Swift y code, talker Mac is a project, a brilliant open
source project which takes Swift y code direct current Swift y code and turns
into web pages that exists already.
I have not taken that approach.
I've said when we make a list.
We say list one, two to a hundred, show text of dollar zero, whatever.
And that works great.
And we don't have to say, listen.
What I want is a large white box with a sort of black translucent capsule
on one side that moves around and then row divide is automatically,
and then indent these things here.
And we scroll, it scrolls and it tap and it activates da.
We have not to say all that stuff.
We just say list and things happen.
And what John's approach is more about encoding HML in Swift.
So you still say, give me a H two, give me a paragraph,
give me a div, give me an IMG.
Give me an li da.
I said, okay.
Can we rethink this in terms of SwiftUI?
Can I have a carousel please?
You say carousel with slide 1, 2, 3, and I've got a swiping,
scrolling, animating list of pitch.
You can swipe through just like SwiftUI works like a tab view works.
Give me an accordion so you can see a title.
Tap to unfold.
Things appear below, so it gives you a much higher level rich
collection of controls built for the web and built to be responsive
for mobile devices out of the box.
So desktop, mobile, iPad.
It adapts flawlessly with the high level controls and gives you things like the
aria frame, aria standard, the rich accessibility library framework out
there already to make sure your controls work great with screen readers, and so
you don't have to be a great web to, to make good, solid, usable websites.
Now with Swift, it's doing a lot of the heavy lifting for you.
That's my pitch with ignite.
Leo Dion (host): That I love that.
I know with Publish when I built the website, I did that.
I did like H ones, H twos, all that stuff.
And then I think shortly after I built the website for Bright
Digit, I noticed that I.
John added an API cult components, which uses result builder builders.
And I was like, dang, like now I'm like, I wish I had done that approach.
And it sounds like you're like totally taking that approach and I love it.
Make the pitch, I guess for why result builders and I think that's what you're
getting at here is a better way of
doing things as
opposed to just slapping an array together, if
Paul Hudson (guest): yeah, of course.
Yeah.
So Result Builder is let you have.
Effectively a DSL, right domain, specific language
inside your Swift code.
So you're looking at some code and let's face it, if you were to wind back
60 or seven years and show folks
with DY, it'd be alien.
And it is alien, right?
So if DY code looks nothing like Swift code, because it has a mission of
returns, there's no return there at all.
A trail enclosure, if not multiple trail enclosures.
Then we have the result builders kicking in and turning things into arrays of
stuff behind the scenes or tup views and 50 why it is, but, stuff's being
converted automatically for you behind the scenes and so you're doing lots
and lots of work behind the scenes.
Lots of Swift heavy lifting happens to make swifty y look the way it does.
As a result, you look your UI code and all is structure.
We've had this argument for a while.
Someone, I don't remember who it was, posted an article on the lines of
Swift, ey, the one true architecture is called MV Model View Architecture.
I don't know who it was, and I don't wanna get into that too
much, but and it's interesting because I disagree entirely.
I look at I don't have to worry this very much because I
don't wanna get into a fight to honest with you, but I look at.
I look at swifty y itself, and I think which part of MVC model view
controller does swifty y code sit in?
And for me it's not view, even though it's a view
protocol, it's not view code.
I'm looking at my Swifty y code and what I see is a bunch
of descriptions of stuff.
I'm not, you can't no matter what code you write, any of you what
code you write, you cannot put a single pixel on the screen.
You just can't, you describe, I want a list, I want a tab view,
whatever, but what does Tab view mean?
Like on Watch Wests, it's a scrolling horizontal list of things
with the page notes at the bottom on Macs, it's a control group
with buttons across the top on T Wests, segmented control and iOS.
The tab bar across at the bottom on visual Wests or on the left,
they all adapt automatically.
It's basically a model we're describing our layout as pure
structure and something else.
The actual view layer UI kit, app kit, whatever, renders
that out to the screen.
And so my idea is that with Result Builders, we look at model
data purely very nicely, and that's what Ignite does for you.
You see your page structure at a very high level and the
logic, it's somewhere else.
Leo Dion (host): I think one of the things that you were
in Chicago last year, but one of the things that really I.
Really clicked with me was when I saw the presentation on DEI and how like
it's such an ingenious way to express a value or a view in the case of Swift ey.
That makes it much more intuitive, I think, to a lot of developers.
And that's, that's that's where I see result, result builders really helpful.
What I've done is I've created a whole way of describing a Swift package using
result builders and things like that.
And it's just great because
it's just much more intuitive And much more much easier for
you to build stuff without having to like, pray all sorts of,
Imperative code.
I guess.
As far
as how I see it.
Paul Hudson (guest): Yeah.
And actually, am I talking Tri Swift last week, which I'll throw this
online soon enough.
I talked about how we got to this point,
like what was the route through evolution?
It took us to this point because result builders were announced after
Swift y it's quite contentious.
They had the what's new in Swift Talk on Tuesday, and it was like,
ah, yeah, these was helpful.
You saw yesterday.
Ah they're you.
Leo Dion (host): I remember like the DSL stuff
was announced perf beforehand, and I was like, okay, why
are they announcing this?
Paul Hudson (guest): No, that resulted, that was on the day.
Leo Dion (host): okay.
Paul Hudson (guest): Property s were beforehand or paid return
types were beforehand a whole bunch of things beforehand and then
that was afterwards annoyingly.
Leo Dion (host): Okay.
Okay.
Paul Hudson (guest): and so it's interesting that you look at
evolution from around that period, and it's quite murky because clearly
Apple are working on SwiftUI stuff.
They're working on SwiftUI internally and they're trying to make the
language be wrangled into a form that gets a good SwiftUI result.
And you can see them, you can see them try very hard.
They released a whole bunch of proposals, some of which made it
through like property wrappers and paper return types and da.
But other ones made it through and then weren't used.
And I mentioned in my talk the static subscript option.
Leo Dion (host): Okay.
Paul Hudson (guest): And so I give in my talk, I'm walking through, listen,
we could do H two da dah, and because I'm using their HTML at the time.
It's pure H two, PBR, whatever, real tag and Swift, right?
And in their, in, with static subscript, you could basically
say a V stack and then an opening bracket, like a square bracket, right?
And then a whole bunch of views inside there.
Then a closing square bracket.
And it's if you replace a square bracket with a brace, curly
brackets, then you get SwiftUI code.
But you could do the same kind of thing using a static subscript with
a square bracket that was allowed.
But you still have to have commas in there as well.
You have comma, comm between your views and one of the proposals that
was in evolution that got rejected.
Was to remove commas around about the 5.1 era SwiftUI.
So April time, four SwiftUI if they removed the commas, it had
been very close to SwiftUI, but obviously that didn't happen.
It got turned down as being too weird for the language.
Leo Dion (host): So one of the things you mentioned is
making the website responsive.
Like I'd like to know your philosophy as far as
How are you adopting CSS so that your websites are always responsive
and is it like, what kind of custom
theming can you plug into your site using Ignite?
Paul Hudson (guest): Yeah so why?
Realized very
quickly is that when you wanna make a website, you wanna
have a whole bunch of standard
components.
Give me a
navigation bar in there.
There's
I know, four menu items and a drop down with a few other items in
there, and a footer here and general things using lots of websites, right?
And so I reached for the world's largest library of these things, bootstrap.
Leo Dion (host): Oh,
okay.
Paul Hudson (guest): Bootstrap is a massive open source project, has
been around for almost 15 years now.
It was, I think Twitter originally made it years ago, and now it's been just
everyone using it for a long time now.
And so it builds on Bootstrap.
And, one thing I've been very upfront about with Ignite is I'm
not trying to replace HML or.
Be JavaScript free or whatever.
I'm not in that territory.
I think they've, they're doing a great job as they are.
Let's build on top of them.
I don't wanna see them as Swift developers.
I want to, if you don't know CSS, fine, they're not making you learn
CSS, but you just say there's a section here with a, B, and C inside.
I'll show 'em on the screen and it will automatically
snap to be a vertical section automatically when they make the.
Browse smaller, or if they're on an iPhone in portrait mode
or whatever it is, it takes care of so much stuff for them.
And of course they can override it.
They can say, no, you've gotta be column width four, no matter what.
Or I dunno, whatever.
They can customize that if they want to, but broadly speaking,
it does a good job outta the box.
I.
Which where I wanna get to and navigation bars collapse into a logo
and a little Bergen menu, which is a very website thing to do these days
automatically it just happens for you.
And it means devs haven't got to worry about, oh my God, how do I
do media queries in this thing?
Or and it is difficult and I know it's difficult and I don't wanna
do it either, quite frankly.
'cause we're here to, most of the part, we're here to write Swift code
or iOS apps, or macros, apps, whatever.
And if you wanna do a blog, cool.
You wanna share what you've learned with the world.
You don't have to learn this stuff.
You don't have to learn how HTML really works and how cript works, whatever.
You don't really care.
And so just the Ignites goals to try and bypass all of that and let you
write just genuinely pure Swift code.
Leo Dion (host): So I'm gonna be a devil's advocate.
When I had started my website for my company, I was afraid that by
going with a Swift framework, I would spend all the time tinkering with it
and not writing actual blog posts.
Paul Hudson (guest): Yeah,
Leo Dion (host): do you.
I guess I, I know why I've decided to go with Swift, but what would be your,
What would be your argument for going with a Swift website builder while not
being too distracted by it, if
Paul Hudson (guest): I know what you mean.
Let see now, 18 months ago I was having dinner with Tunde Adegoroye - tundsdev.
And he was saying he wants to launch his new website soon
and he's not sure what to
Do He does it in WordPress, is he?
Do it in publishes, do it in HTML from scratch.
And I was like, Tunde, no matter how good you might think you are
HTML and CSS or whatever, you aren't getting value from that.
Like you aren't here to teach the World how to build great websites.
You will want to sell courses or link to your stuff or write blog
posts, whatever the value is in what you're creating already.
The websites, the vehicle for deliverying, the value you already
have, not valuable in its own right.
If that makes sense.
And so my advice was, which you completely ignored, by the way, my
advice was if you are sit sitting around, uming and ahing about
frameworks and this and that and the other, no, just use WordPress.
Because the goal view is get content out there quickly, easily, smoothly.
Correct.
And as long as you aren't tied into some bizarre URL structure,
if it's, if it's a simple, flat URL system, you can put anywhere, you
can migrate to some other thing.
In the future, if it works very well, custom whatever you
want to GitHub files, no one really cares how it's done.
Somewhere else, it's easy.
Just keep it a nice clean url and.
That's my advice for so many folks.
The value for people is not in terms of getting a great custom site.
It's just that getting what you have out there because.
People care about your Swift code or your iOS apps or portfolio
you now get hired for, or what your blog posts you sharing.
That's the valuable stuff, not the amazing HTML you can write.
And with Ignite, my hope is in very few lines of code.
You can get the exact customizable site of your dreams.
That's my goal with, beautiful cards or blog posts with markdown
being read in the past to websites.
It, it does lots of things for you very easily because
it's a high level components.
I don't wanna build UI kit for the web, as I'm saying.
I built a swifty y style thing, web native thinking in terms of
web controls wrapping for mobile.
Someone asked me like where's H Stack?
There's no H stack in Ignite.
You have a section which makes a row of stuff, but it automatically wraps
into new rows as contents restricted.
As this page gets smaller and smaller, it wraps.
And Hay Haack wouldn't do that.
Hsac says in one row forever, and that just doesn't work.
I'm not trying to build Swift wide for the web.
I wanna build a native web first experience that happens
to build using Swift Code.
And so the goal is simplest possible thing to get a site up there.
Already.
Someone already launched a site in Mite, already in, after
four days someone launched a site Ignite, which is amazing.
Leo Dion (host): Do you wanna know who it
Paul Hudson (guest): I had met before, no I had never
met before in my entire life.
They found it, downloaded the sample projects, modified it,
published it straight away.
And I love it.
The speed they're able to work at to publish great things is huge.
And I'm really behind that.
And so it's obviously one step beyond WordPress.
Like you can get simply, you can say, I'll just use WordPress
across the board and just use that.
And that's fine.
But then you're like now I can't customize it at all.
I've got a second inside WordPresses boundaries, which is painful.
Leo Dion (host): So for me, like I just got burnt out maintaining a WordPress
site and all the plugins and the mess with security and all that stuff.
And that's why I ended up going with Publish.
And then what I've been able to do with it
and being able to take episodes like this and put it
on the webpage automatically whenever my podcast episode.
I couldn't do that in pHP, or I could, but I'm not, I don't want to.
So like I've been able
Paul Hudson (guest): Exactly.
You could, but you don't want to.
Exactly.
Leo Dion (host): Yeah.
So like I have a whole bunch of tools that I've built now for my
website in Swift where I can like put a podcast episode page upp in
Mark down automatically using Swift.
And I could do all sorts of stuff with my newsletter and have that put
imported onto the website automatically.
And that's been great.
That's the stuff that I love.
I have, I was able to import the site from WordPress pretty easily.
That worked out really well, and I have a library for that.
So it's yeah that's where I've seen the advantage with Swift isn't like.
It hasn't hurt my ability to write blog posts,
let's put it that way.
It's even made it easier for me to maintain and update it accordingly.
And that's what I've really liked about moving to Swift.
Paul Hudson (guest): Yeah.
Yeah.
So as a markdown, so I use Apple's own Swift markdown library.
Leo Dion (host): yeah.
Nice.
Paul Hudson (guest): Four making it and It's just so fast.
It's absurdly fast and really easy to use that it can go through
markdown, a blazing fast speed, so you can create, thousands of
pages from the system in a second.
It's remarkable.
And that's same thing actually that Christian Selig used for Downer.
Saw Mark Downer, saw his attributed string pause for mark
down which is great as well.
Leo Dion (host): What was your favorite part working on this
project as far as some feature that you learned about Swift that you
didn't know before you got started?
Paul Hudson (guest): Result Builders are really hard.
And I make them look easy in my talk, and they are easy for
small things, but you end up with
just like the goal is SwiftUI.
SwiftUI What it creates is absolutely brilliant.
And they've got a different set of problems to me.
Because Ignites a static site builder, it just outputs a bunch of html, right?
Flat,
Leo Dion (host): don't have to deal with property wrappers or
state management, which is a big, yeah, that's the big hill.
You have to climb with SwiftUI
Paul Hudson (guest): But also there, there's no runtime performance there.
This isn't if I worked really hard, it might take.
A third of a second to run your program, to build your whole
Leo Dion (host): Yeah.
Paul Hudson (guest): It's, it is not a lot, it's so blazingly fast,
even in debug modes, absurdly fast.
Whereas they have to think very carefully about performance
at every step of the way.
And I don't.
And so we've got a subset of problems they would deal with, but their
implementation is the one to strive for.
They've done a such good job and I'd love to get closer.
I think I will aim to get closer over time.
I might grill them at double this year.
In fact, when I see 'em in June, like, how did you do this?
How can I do this?
Because they obviously know they're the experts in that particular thing.
And so I'd love to get closer to it 'cause it's not close enough just yet.
But what I found is when you're in the groove and you're like, okay,
let's add a dropdown button here, and a carousel here and accordion
here, and really rich components.
That look just great out of the box and adapt through all to your phone.
It feels really good and.
It captures that magic of SwiftUI.
I don't care how list works or how a form works or how a
navigation split for you works.
I don't actually care.
Behind the scenes could be thousands and thousands of lines of UI kit code,
spaghetti code, horrible, whatever.
I don't care.
The result is I just see nice SwiftUI result builders
and then things just work.
And I love that.
And the same is true in Ignite right now, and I'd love to get
more power in there to get more kinds of functionality out of the
box.
Leo Dion (host): So we got result builders.
You already had a built in markdown tool.
What else do you wanna talk about Ignite specifically?
Paul Hudson (guest): I think one of the fun things I did with Ignite was
around documentation, so I wanted to document it to a very high level
because I know it's a very hard choice to start with something new.
And that's true in any framework, right?
Any language.
If there's not much documentation for it, it's a bit like, oh
my God, where do I start?
And with Ignite, I actually built a website for it.
And it, the Ignite Samples package, you can build and run it
yourself, or it's actually made a sub domain fraud on my site.
And it shows you it's a full site built with Ignite, with image
examples, text examples, grid examples, carousel examples.
All there running, it's a real website.
Running the actual code plus the code next to it.
You can say, okay, that's the one I want.
Copy that across, use that very quickly.
So lets you see it, like it, steal it, use it in seconds.
It was all but ignite as a way to let folks just get jump started
very quickly because it's horrible.
You're like, I, what I do want to do when I start, everything's blank.
And I've still got more to do.
I've still got a lot more to do in terms of documenting it
to a level I'm very happy with.
But the code is, flawed to document.
I went to every line of code, adding mark down comments, so forth best I
possibly could to all the methods in cases and nu But getting the online docs
was critical to get folks jumpstarted with example code to work with.
Leo Dion (host): so this tutorial site is built in Ignite itself.
Paul Hudson (guest): Yeah, It's, all building Ignite, so the whole thing.
You can.
It's github.com/two Store slash gi Ignite samples is
the code for the package.
And you can build locally, modify locally if you want to, or on, on the
web if it as is like Ignite samples.
Yeah, ignite samples balls dot hacking with Swift.com.
It takes you straight, straight to it, and you can just see the badge examples
and there's, it's, that's the code.
Grab that, and then it shows you how it looks below every time it renders a
h, TM L and shows you the code again.
And you can see badges straight away.
Badges are a lovely component.
They look great.
They're like the little text colored boxes that you can put over, like
your unread email account, for example, or cards right there.
They just look really good and clean outta the box, which is really nice
and it makes it very easy to use.
Leo Dion (host): DocC.
Did you ever go that route and then was like, okay, no, I should
just build a whole, like I should just build a whole website or build
the tutorial in Ignite instead.
Paul Hudson (guest): It needs to be a place.
You can see the HTML running.
Leo Dion (host): Okay.
Makes total sense.
Paul Hudson (guest): And so that's the power of it.
You can go to the, I'd say the alerts section, for example.
That's it.
It shows you an example of a code alerts.
I get really wrong with a roll of danger below it, exactly how it
looks and you can see it and just say, that's why, what that one
there, and just swipe it instantly.
And that's the power of it.
You can see the code and see the result.
That's it.
Take it.
And so it's very fast to get started with this stuff because it's right
there to use again and again.
Again.
Leo Dion (host): What do you find is the biggest part of friction that
new people have adopting this tool?
Did you get any friction As far as I don't know how to do Swift package.
I just run Xcode, or I don't even know what a command line
tool is and things like that.
You know what I mean?
Paul Hudson (guest): Oh, for sure.
The hardest problem right now is just getting started, and that's my fault.
I built three repositories as Ignite Samples and Ignite Starter, and I
was doing these three minutes before going on stage to deliver this whole
thing and announcing the project.
At the end, I was literally typing away as being announced
on a thing, and I screwed up.
Of course, I screwed up all over the place.
The starter one.
Depending on a tag I'd set in the repo, and I'm an absurd
level perfectionist, Leo.
It's, it caused a lot of damage to myself.
I spoke a typo in the Ignite.
Read me.
It was a comma.
She'd been a full stop, right?
So I was like, oh, dra, I deleted the whole repo, fix that
one thing and pushed up again.
Exactly one commit was in there at launch time.
No, like random type of fix and stuff.
It was clean at launch, basically, it.
Then my starters, depending on the tag, no exist anymore.
An exact commit that's no longer there anymore because I'd completed the whole
repo and recreated the whole repo.
And so I screwed up all sorts of different stupid ways, and that's fine.
Look I try my best.
No one's perfect.
So right now the hardest thing is just getting started because
I've got more work to do around getting the starter up.
People aren't awake and run a local server very easily, and
so there's no way of, trying it out very easily right now.
I'll fix that too shortly.
There's a bunch of work to do once, I think once you're going, you're
like, oh, this is really fast.
One thing I'd like to do, and one thing I did do in the earliest
beta this back in February when I was just noodling around was
it had SwiftUI previews built in.
So as you typed your html, it, it re rendered the page in the
preview straight away, which is very quick way of working.
I might bring that back.
We will see.
Leo Dion (host): So is that watching your folder as you save it?
And then rerunning the builder.
Paul Hudson (guest): NN no.
It's a real SwiftUI preview.
So eases SwiftUI behind the scenes.
Leo Dion (host): Oh,
Paul Hudson (guest): local web view,
Leo Dion (host): got it.
Okay.
Paul Hudson (guest): with the h pointing at your temporary
output of the build, basically.
It creates, it created problems because.
We are running a build of your site takes time to do not a lot
of time, but some time to do.
And so it would when you click a link, does a link work or not?
And if the link doesn't work, why doesn't it work?
And it's complicated and I to basically flatten the entire site
out every single time it, a small text change, it'd be quite intense.
So I yanked it early on, I might bring it back.
We'll see how we get on.
But that'd be lovely.
Able to see the whole site running in Xcode as you're
Leo Dion (host): That's awesome.
Yeah.
did you try anything with macros by any chance?
Paul Hudson (guest): Oh yeah.
I thought, oh, this is too easy.
I make my life harder and had some macros.
No.
I did not really hear macros.
No.
Look, I think right now macros
in a strange place in Swift where when you've got a problem,
macros are the solution.
I'm like we survived a long time without macros just fine.
Is there really no way you can tell this about macros.
Like tip kit uses macros everywhere.
There's no way I could have even built out macros.
Not a single way of doing that macros.
So yeah, no macros for me yet.
Leo Dion (host): Yeah.
So Tuesday, my live stream, I was dabbling into macros and creating
my own just to see what it's like.
But yeah, I could see how what you're saying with like tip kit, it's macro
macros were the thing, macros were like the Swift DSL of last year.
It was like the hidden feature like that we had talked about previously
that were going under the hood to or excuse me, behind curtains that
Apple was building for their big reveal of observe observation and
Swift data and stuff like that.
And then they use it there.
And then.
But yeah, it does seem like it's a tool that they want to use everywhere.
Now.
Do you like, is that kinda your perspective?
Is that oh, okay, like we're gonna add tip kit, let's
use macros, we're gonna add this new widget to Swift, to Vision Pro.
Let's use a macro.
Is that kind of what you're seeing?
Or do you think it has a
place in some spots?
Paul Hudson (guest): Macros right now are not very popular things
as in like people will use them.
At the end, you just level, some folks will make them, but
they don't like making them.
And I was speaking last week to Katsumi Kika who's a Japanese developer who made
the Swift a ST Explorer as well as power assert a whole bunch of other stuff.
And Katsumi is.
One of the smartest folks around on macros.
He really gets macros at a very deep level to the point where I
think a large number of people would never have been able to make.
Macros at all without the Swift a SD Explorer, because it's just, it's
so helpful explaining what things are happening behind the scenes.
And that's because it's built on Swift syntax, which is a very clever framework
that makes it almost impossible to do what you want to do with macros.
And it makes it, it's like it, it almost gives you a machine
gun and says, okay, here you go.
Where do you wanna point the machine gun?
Oh, at your foot.
Cool.
Let's go then.
And then you it's very easy to make mistakes with Swift macros, with
Swift syntax, and that's a shame.
We should try and make things harder to make mistakes, you know.
Leo Dion (host): The, yeah I had a really hard time with Swift syntax
to the point where at the end I just ended up, 'cause what you can do
now that they introduced is you can basically use a string to create like
the variable declaration rather than specifying the whole entire A ST tree.
And that's what I ended up
doing.
And I don't like it because, like you said, it's so easy for me to make a
mistake if I'm just slapping a string in my code.
Rather than
using
the niceties of Swift syntax, if
Paul Hudson (guest): a little bit, but for me, you can see the
problems in Apple's own sample code.
Like Doug Gregor made a repost of, macro examples and his URL example
to do, and it's a simple thing.
Check a URL's valid.
So there's no more optional URL nonsense, right?
That's all it tries to do.
And here's you an example.
There's multiple lines of code of guard.
This guard, there's guard this the other day just trying to get what's inside.
When you say URL hash, URL something, getting that string
inside takes a lot of work and it shouldn't take a lot of work.
And I think.
Katsumi is interested and I don't wanna speak for him, but I think
he's keen to look at waste, makes easier for people who wanna make
macros that are safe and are correct.
And what Apple do and always have done is they make something like core
text, which a really powerful, really obtuse framework for using text, but
you can do whatever you want with it.
And then they say we know it's hard, but we've made text kit.
Over it and Text Kit has all the power in a nice wrapper around that
means you have all the flexibility, all the functionality, but it's
now much hard to make mistakes.
That's what we need.
We need Swift Syntax Kit.
Leo Dion (host): So I was looking at the point free example that
they have for compose architecture or composable architecture.
And one of the things they do is kinda what you were saying, is like
they have to do an extension for this and an extension for that to
simplify it, so that way it's a lot easier for them to add the macros
that they want for compostable architecture, for instance.
And I'm like, Yeah.
that's what you end up having to do is
like creating your own wrapper.
Otherwise you have a hundred lines of
code just to write.
A few lines of code that are actually correct, if
Yeah.
Paul Hudson (guest): Yeah.
and if you want, you wanna go down the string base, typecast
says force is that fine?
Of course you can do that.
But we'd rather make good macros, our correct macros.
Leo Dion (host): I don't like what I have now.
I'm like, I'm just like, oh, this is, this sucks.
This is like PHP where you're just like inserting HTML in code inside HTML.
And I'm like, I really hate this.
But having to deal with Swift syntax is such a headache of, like
you said, what Doug had to do with guards and casting and all that
stuff that you have to do to check.
To check and build the inf the speaking of result builders.
That's what, where a result builder would be great is like having a result
builder that builds the code for you.
I wish they had gone that route.
So yeah, that would be awesome.
Paul Hudson (guest): The other problem, of course, is that people are
complaining that swift syntax is too big and too slow because it's huge.
It's a
Leo Dion (host): Yeah, it is really huge.
Paul Hudson (guest): and.
If you're just, monkeying around with local code, fine, it's okay.
But if you're now running on out on Bitrise build hours where it
checks out in tax every time, built from scratch, every time
through a simple test run, that's actually quite a lot of money now.
And people are being billed having to have sort macros and so it's,
it is landed in an unhappy place.
And my concern is bluntly that Apple are.
Maybe board of macros now because.
I, how to phrase it really?
So Apple have these, they haven't got very many people for a start,
apple under hire dramatically.
It's a bit embarrassing how much they, how they need to hire people.
But that's down them, right?
Fine.
And so the teams are tiny.
The teams are very small indeed.
And their goals are massive.
They wanna do these huge things every single year, plus three least
a year, whatever it is, right?
Every year.
Big things.
And so what happens is usually they do a massive deep dive on something.
Result builders and they go wild with result builders for a while and they're
like, okay, it's done now, bored.
Now move on.
And there's macros.
Go wild with macros, bored.
Now move on.
And they're onto the next thing again and again.
Again.
And right now they're going wild and type safety for concurrency and stuff,
which is great.
But I can't see them return to macros and say, oh, you know what this sucks.
Let's make it better.
It'll be a while if they do that.
I think if they do return to it, it'll be a while.
And that's annoying 'cause it's, people are unhappy.
Leo Dion (host): Yeah, well Put.
What else
have you been working on, I guess before we close out?
Paul Hudson (guest): I have just finished the new 100 Days of Swift
and iOS 17 that took a long time,
But to be fair I released Inferno Vortex and Ignite in that time period, three
gigantic open source projects and spoke at multiple three or four conferences
and just to have my life as well.
It's been a lot of other work in that time.
So it was slower.
I hoped.
It's now end of March.
It's finally finished, but it is done now.
It's a good thing.
Actually this week for the first time in a long time,
I have no actual work to do.
It feels weird.
I've been so dramatically overworked for the last sort of six months.
My brain's been really full every day, every night, every weekend
of things I should be doing Now.
It's very busy, very important, da.
And I'm like I have time to stop and think, and.
Plan something new, like I'm gonna do an Inferno release, a Inferno
version two's coming up soon.
And I'm looking forward to it, but I have time to actually sit
and think about what I'd like to do rather than being okay.
Next thing.
Nonstop.
And so I'm looking forward to having a bit of a break.
Not a lot.
Obviously, dub dubs coming up soon.
I booked my flights already by the way.
Leo Dion (host): There, I actually have two more questions.
What tips do you have for developers out there who want to publish an open source
Swift package project, for instance how to get started, what are some things
that you learned along the way that you wish you'd learned when you first
started publishing open source projects?
Paul Hudson (guest): I'm a massive open source fan.
I love releasing code and usually the MIT license, as, as open as I
possibly can to let folks use as much as they can, which is great.
But what I find sometimes that people put a lot of work into the
code and making great code and then don't document it enough to be
useful.
And I, by that I mean it's us usable of course.
Is it useful?
Is actually able to.
Pick it up, try it out, noodle around and make something with it.
And that's surprisingly hard.
And so if you look at the Vortex framework or Inferno, whatever
or of course Ignite as well.
They're all copiously documented, so many.
Mark down comments in the code explaining what every class, every
struck, every method does, but also a webpage of example code to work through.
You can copy and paste and try things out and understand what's going on
because it helps folks get started.
With Vortex making a positive effect.
People using a bunch of times already in the apps 'cause
it's so easy to use, import the project, copy an example code.
Run it back, it'll just work.
And I've gone through an example code of every possible particle system in there.
You wanna do confetti, you wanna do fire, you wanna do
this, that the other boom.
Example, code, example code again and again.
There it is.
Just start with that.
And of course, customize as much as you want to, but start a code because
once folks are moving, once they've got something to work with, they're away.
And I try and encourage folks to think about this in
terms of like human language.
If you wanna learn.
French or Japanese or whatever.
You start somewhere by listening to people speak and
you can mick them as a kid.
You listen to mommy saying something or daddy saying something, say
it back from the same thing they said, and you'll learn and learn.
The more you hear, the more you say, and then you make your own things.
Eventually, and this is why I.
View sources in all web browsers because you could look at how
someone sold problem and steal it and use it your own stuff.
It's vitally important to see example stuff before you write your own stuff.
And so if someone makes a library, please do.
I love seeing more code, but do your best to document it, get
folks moving as easily as possible.
Leo Dion (host): One point I want to make is if you are gonna sh document
something, don't document it by breaking it down into its pieces.
Nobody wants to know how to conjugate a verb in French, rather.
You want to you will at some point, but like you said, I like the idea of
okay, repeat, hear a word and say it.
And I think what I like what you've done here is with for instance, vortex that
I'm looking at is like you have sample code that gets you up and running.
As soon as possible.
Instead of saying, okay, here's the 52 ways you effects, you can do,
it's no, here's how to get started.
You ought to know more.
Here's how to, here's more documentation on that.
I think it's so hard to like.
When you're working on something all the time to be able to explain it to
someone as if they don't know what you're talking like from ground one
because you've been, your head's been
into it.
And that's a really hard talent to have is to explain something what is it?
Explain like I'm five, when you've been in something so
much, does that make sense?
Paul Hudson (guest): It does.
There's actually a language teacher I love very much called
Michelle Thomas, and his approach is to teach you a bunch of what
he calls keys in a language.
And once you know the key to move somewhere,
you can start saying what you want to say.
For example, in French, it'd say a good one is J Japan.
I think that you can say J Japan's k.
Stop, think whatever.
I'm going to go whatever home soon or whatever you want to
get, catch the train, whatever.
But you can say a little bit, stop, unlock an expert, say
a little bit, stop, unlock an next bit and work forward.
And so giving folks a key to start your project.
Start with this little thing here.
Boom.
You're away.
Leo Dion (host): I love that.
Paul Hudson (guest): is important.
It's important.
Leo Dion (host): What are you most excited about or worried
about when it comes to WWDC?
Paul Hudson (guest): So I'll be there the entire week again.
I'm flying out Tuesday beforehand this time.
And so I,
I'll get over a jet lag more or less, five hours at least by, by Monday
rolling around, which is quite nice.
And then I'm there the entire week and I fly back Sunday.
'cause Saturday normally is like a game day with friends and stuff.
We play like escape rooms and stuff.
Which is fun.
And so I love that part.
That's my favorite part by far, is seeing all my Bay Area friends
again, all my Apple friends again, and just hanging out,
getting coffee and so forth.
I'm really looking forward to that.
That's the best part by a long way.
And for folks who don't get to go.
There's, James, the break points are there.
I always have happy hour there.
Things happen around dub.
It's not just like dub or nothing.
There's a whole community buzz around the whole week and I love it.
It's just got great fun and I hope this year.
Okay, so listening, I hope this year that core sushi is back course.
Sushi used to be Bill Bumgarner's pre-event sushi thing.
A brilliant sushi place in Campbell, I think.
Near San Jose.
Is it photo gata sushi?
I remember.
It's been a while.
Anyway and it was a great event to meet people and have nice time and stuff
that it more people, meeting people and hanging out and chatting and stuff.
That's the best bit by far.
Biggest fears, we're gonna find out every year oh, is this the year they're
finally gonna hire a great dev pubs team who do documentation way better than me?
Whatever.
We'll see.
We'll
Leo Dion (host): Wait, why do you want, why do you want that?
Then fewer people need to go to hacking with swift.
Paul Hudson (guest): That's the biggest fear
Leo Dion (host): oh, that is the, okay.
Okay.
Got it.
Okay.
Paul Hudson (guest): It's not a fear.
I
Leo Dion (host): I know.
Paul Hudson (guest): But certainly people come to me for a reason,
which is right now they don't get the level of thoughtfulness or
care from Apple's documentation that they want to see, and they
don't get that from ChatGPT either.
And so my stuff helps.
Here's the code you want, it's te checked, it's
updated, it's all good, dah.
Use that.
And folks appreciate that right now.
And so maybe this year that'll change.
We'll see in three months, right?
Leo Dion (host): Yeah.
Yeah.
Paul, was there anything else you wanted to mention before we close out?
Paul Hudson (guest): No.
All good.
Leo Dion (host): So I will see you in Kent.
Are you coming to Chicago?
Paul Hudson (guest): Ah.
I'm not gonna Chicago now.
I'll be in ton now.
Leo Dion (host): Yeah.
Okay.
What Are you speaking on at Swift Craft this year?
Paul Hudson (guest): It's a weird thing.
I'm not giving a talk this year.
I am doing a workshop
Leo Dion (host): Workshop.
Okay.
Paul Hudson (guest): and then that's on Tuesday
and then I'm staying Wednesday, Thursday, Friday and not doing a talk.
I'm just hanging around basically.
So we'll see.
Basically it's a bit odd.
Leo Dion (host): Okay I'm gonna, I'm really looking forward to that, Paul.
I will see you in Kent when I talk about counting and Swift and stuff,
So I'm looking forward to that.
Where can people find you online?
Paul Hudson (guest): So on Twitter, I'm two straws on Reddit.
I'm two straws.
Fl.
Two straws on GitHub.
Two straws on YouTube, two straws.
Instagram, two straws basically two straws is high.
Find me.
It's pretty easy to find, I think.
Leo Dion (host): And the website is hacking with Swift.
For those who don't know, Paul, thank you so much for coming on today.
It was fantastic to, to have you on again.
Paul Hudson (guest): Thank you.
Leo Dion (host): People can find me on Twitter at Leo g Dion.
My website is Bright Digit.
If you're watching this video on YouTube, please subscribe and
I'd love to hear back from you.
And if you're watching this on YouTube, or excuse me, if you're
listening to this on a podcast player, please post a review.
I'd really appreciate it.
Thank you so much, folks, for joining me today, and I look
forward to talking to you again.
Bye everybody.