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. 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.