Supper Club × Raycast with Thomas Mann

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax. This is a podcast with the tastiest web development treats out there. We got another supper For club for you, with, I I believe are you the creator of Raycast, Thomas?

That's correct. Yeah. One of the cofounders of it.

One of the cofounders of Raycast, which is, a I'm gonna call it a productivity app. It's, App launcher, a calculator, a converter, literally everything, and it seems to be eating all of the other applications that I use it seems to be like, oh, every every 2 weeks. Oh, that that takes care of another a clip clipboard app I used to do, or that use takes care of my Snippets app that I used to use. And, Scott and I have been big Raycast users for probably a year now.

And, as a long time Alfred user, I was very, happy to move over to it. It's it's just awesome. So we're having him on today to talk about that and

And whatever else comes on. So, Thomas, thank you so much for coming on. Yeah. Thank you for having me. I mean, I've been, Syntax Fitness for a while, so Kinda kinda nice to be behind the scenes now and and putting out my word as well.

This episode is sponsored by Fire Hydrant. Fire hydrant helps innovative engineering teams prepare for, respond to, and learn from incidents.

It's the one stop shop to develop and scale a world class incident management

program. Do you wanna give us I know I gave a bad a bad explanation

of what Raycast is other than I love it. Can you give us a rundown of of what it is? Well, sure. Yeah. I mean, you didn't describe it too badly. I think Raycast is one of these tools because we can do so many things. It's Really hard to explain sometimes, where we oftentimes just describe it as a general productivity tool for Mac Pro users. It's a Mac app.

And if you're familiar with the Mac, you know, spotlight and all threats, so we say, like, it's a spotlight on steroids.

So, yeah, we have Build in the obvious things like searching applications, but you can also use it to search files.

We have a clipboard history built in. We added window management, which we Felt like it's an obvious thing that everybody needs to install another application, so we mapped that into Raycast.

And then quite recently or not, That's actually a little bit longer ago. Like, a year ago, we opened up an an API and a store. So, basically, everybody can now build what we call extensions in Raycast, and this basically enables to have things like 1 password in there, like Spotify controls.

You can search GitHub issues and pull requests.

We have pretty much support for everything you can think of, and all of them are open source, which is pretty cool so everybody can jump in and contribute and build their own extensions for their own use or also helping and contributing to other extensions to make it richer every day. Wow.

Yeah. And I just I just opened up the store just now, and there's an you know, I really love, like, the trending section of it because it does see, Like, at a glance, like, what what types of things are people are installing? For instance, like, I have a lot of extensions installed for Raycast, but I I didn't know there was a homebrew one, which makes sense. And Now I have a homebrew extension installed. And, like, man, now I don't have to do brew find whatever, and and I could just do it all within Raycast where I do everything else. So, man, Gotta love it. Gotta love this extension star.

Yeah. I I love that as well because it it's I think right now, it's Pretty much at a point where it's kinda like Versus Code where if you want it, somebody has made something for it, which is Awesome. Because that probably speaks to the the authoring experience because so many people have have gone out and made it. I remember with with Alfred, I had lots and lots of workflows. We had to download them, and there was, like, a third party package manager for it. But then, like, updates were a little tricky, and It used in, like, PHP or Node or whatever language on your machine, and sometimes that didn't work. And, the experience with this is really, really smooth. No shade to Alfred because I I absolutely loved using it for many years, but this seems to be, it feels like when I move from Sublime Text to Versus Code, that feels very much the same way. We're like, oh, wow. There's so many extensions, And the the UI is exactly what I've been missing. Like, the UI is so much more flexible, and, I've just been been very, very happy with It just even it's just simple things like the the file search. I'm sure it's not simple, but for what I don't understand Why the finder search in macOS is so awful? Like, I can never find what I'm looking for when I use the finder search, but I feel like I get a much better result. Do you guys did you write your own finder search in in Raycast?

So with to find the search, actually, we rely on, the spotlight index. So what what Mac or Apple does, they basically have this huge index Where they indexing every file you have on your Mac, and and basically picking that to have some APIs for that. It's called MD Query. So we're using that, so we're relying on that. But what we did is, like, we wrote our own index for applications because we were relying on Also, the spot that index, it was a little bit buggy here and there and, like, cost issues. So we basically build our own one to be snappy and faster and building on top of that.

But, Wes, I also like the Okay. Comparison you did from moving from supply into Versus code, which is actually quite interesting. Never thought about that. But I guess One of the big piece about Versus Code is the ecosystem, right, like, which makes it a great editor, which is well, you can use it as a plain text what they can add in more and more things on top of it and just make it a proper ID for, I guess, by now, pretty much every programming language that is out there. And then, yeah, you're defaulting trust to to searching extensions that you find useful, and then they're popping up in in Versus code and and can just install them with one click. And, Well, this was one of the inspirations for our platform as well. It's like we wanted to have, like, really an end to end solution. Right? So Not something fragmented, but something where a developer can sit down, have a great developer experience to build those things. I mean, both of us, cofounders are developers, and We've already developer centric company, so we wanted to build something. Basically, for us, right, we wanted to have fun building those things. And And then also didn't want to end with building it. I mean, when you just build something, that's not the Android. You wanna share it. So we basically build a store where you can just publish it. And then when it's published, there's also the consumer side of things. So you can search for stuff. You have the trending section as Scott described where you can find, like, what we create, actually, every Wednesday, like, top 3 extensions that we find really cold the last week.

And then you can discover the whole extension ecosystem because I think that's also one of the things which is always when it grows, You still wanna have, like, a little bit of a creation, like, what are cool extensions that people should know about, always a little bit of an interesting thing that maybe people haven't discovered yet, And giving, like, this full experience, I think the closest is probably the the app stores, like, the place around the Ios app store that we've seen there. So, like, People can build something, publish it, and then getting in front of, like, 1,000,000 in decades, which is really cool to see. So, yeah, we wanted to bring all of that in in a productivity app that we use, And, that is what Ray causes nowadays, which we're really happy with.

Yeah. It's it solves one of those big Problems were like, it's something that is developer engineer kind of centric without feeling like it is. It feels like it's Easy to use as a user. You're not diving into configs for everything, but the power's there. Like, I it It took me no time whatsoever to figure out how to and to get my own, essentially, shortcut running that Allows me to quickly send a post request with some data to a specific URL. Like, that took no time at all. And That kind of power that you get as a developer to do those types of things, usually comes at a cost of usability. But with Raycast, it doesn't really it always feels super easy to use.

Do you do you guys have, like, a Team of designers or designer who's in charge of making those usability decisions there. Yeah. Definitely. Great to hear that it is actually like that because that's one of the goals we have is, like, Having an easy to use app and then giving flexibility as you go forward to really unlock the the power you wanna have as a developer.

And so, yeah, we have 2 designers in house. Both of them work on the app as well as on the website. So we really work everything that you see from us is built by us. So We're, like, really product centric in this way.

And, like, we've from the get go, we basically said, well, like, we Raycast is an app that you use, I don't know. Dozens, hundreds of time a day, so we really wanna have something that looks pretty, right, as well, because that's kinda, like, the least we can do when you see an app every day. We wanna have it nice looking.

So design is like a big part of us, and it's quite challenging if you have this small window. It's just very restricted.

And a lot of people nowadays rely on it with the muffled memory, they build over time. So you need to be very careful with the design and make it more like a design system, this is how we think about it right now. And I think the what we did early on, we didn't start straight away with a platform and an API to 10 trade cost. Right? What we did is we build the 1st extension ourselves, actually, natively, on the macOS platform with Swift, to actually experience it. Right? How is it to build those things? What is the UX we wanna have? Can we make a that fits, I don't know, 10 or 20 different extensions that maybe come from completely different angle. And as soon as we knew that, then we basically said, okay. Now let's layer an API on top of that and see how it can make it really easy, which was a super interesting process in itself because, I mean, building an API is always really challenging to nail it, that People understand it Yeah. And like to use it, which is really hard. Yeah. Let let's so let's talk about that. We'll wind back to the stack used to make Raycast, and then we'll talk about the API, which is so, like, you

you have built Raycast to be native, which is much to Most Windows users, disgrace because, like, we always had Alfred, and people are like, oh, what's the Alfred equivalent on windows, and everybody like, well, there's kinda like this one that's it's, it's okay.

And then, Raycast came out, and I was like, oh, this is for sure built in, like, web tech, and I I had started digging in. I tried to, like, change the colors. I was like, where's the CSS file? And then I was like, oh, this thing is not. I would just assumed it was. So, like like, why did you build it native?

Yeah. Good good question. So, yeah, there is no CSS or HTML involved. It's all native folks. So it's, you can't just simply change the theme there. Sorry.

But sorry to all the Windows users yet.

But, yeah, I mean, like, first of all, like, the team and also both cofounders, we like Apple enthusiasts. Right? So we work, basically, the majority of our professional career in Ios. And then during our time when we worked at Facebook, we actually switched also to work on the Mac. So we were quite familiar with the stack. And so when we started, we were just like, okay. Well, this app is something which is very close to the system. Right? As I described earlier, we use this, spotlight index, and we search files and apps. All of this core functionality is very core to the system, so you can't really easily go ahead and, like, build a build a electron app or web app and Hook into it. You'd still need to do the extra work to make it really fast. And, well, we wanted to make it incredible fast, so we went down with, like, picking, like, Swift, which we are familiar with as well and and kick that off. And we also wanted to make the app feel very at home at macOS. Right? So we picked the design language that Fits right into the Mac, with the vibrancy and the translucency we picked and around the corner so that it almost feels like it's part of the system. And this was, like, one of the core things we have. So the app itself is is native, a 100%, but what we then with the extensions API did, We knew that, well, not everybody wanna write Swift code. Right? So we wanted to enable it to as many developers as possible. So there, we opted For JavaScript, to be precise, TypeScript, to basically guarantee that that many developers as possible can build it.

So this is how we balance it, basically. The core of the app isn't highly swift, but then the extension ecosystem is TypeScript, React, and Node,

which most developers are familiar with nowadays. Yeah. I thought that was was really interesting that that's the way, that you make it available to everybody, which is good Because, like, if you were to, like, make the API available in Swift or Python or something like that, I don't think that you're gonna have the biggest ecosystem out there because you're you're severely limiting it, but I think anybody who is able to sorta get along with a little bit of TypeScript, and make it. I thought it was interesting.

Can you talk a little bit more about, like, why did you choose React to build a API And instead of just using JavaScript, is that a difference? I I I have this us, I have another question, but I'll ask you there. Why did you choose React?

Guys, okay. Let me start. Yeah. I mean, as everything, it's not something you decide from one day to another. Right? There's, like, an exploration phase with these big bets that you usually do. So When we when we were confident and we figured out what Raycast is in the UX of it, we thought, like, okay. Let's now build an API, and then we went into an exploration mode. The first thing we actually did was what, Wes, you mentioned, like, just building a JavaScript API. Right? So it was kinda like you're throwing a chasing over the fence, and then the app picks it up, and it's Kinda, like, treat it as a render tree. So whatever is in there, we would render, and then you could call an action back. And the JavaScript picks it up, And you basically come communicate back and forth between the JavaScript land and the native land.

And for that, we actually use JavaScript core. So not Node, which is 3 8, but JavaScript core.

It's a really plain JavaScript.

That is that the engine that's in Safari? That's correct. Yeah. So that's the that's the Apple engine. It's based I think WebKit uses it and then, therefore, Safari, and I think it's the only one that is available bundled basically inside of the Mac, but it's a very closed JavaScript, runtime. So there is nothing like fetch network request doesn't have file access, so it's really plain JavaScript, as plain as it can guess, basically.

And so we Picked that at the beginning and said, okay. Cool. We picked that, and then we add more functionality to it. So, for example, exposing a fetch method that would then be natively executed And all of these kind of things that you know from the other JavaScript, run times, but making it basically exclusively in Raycast.

But then as always, like, what we do, we work very early on with people from our community together, and they started building extensions and tried out the API, and then often came back with the same feedback. It's like, well, I just wanna use my favorite npm module. I just wanna, I don't know, install, some some OctoKade or whatever and just use that, and that didn't work. Right? Because we our OctoKade runs on on Node and this other stuff, and it's all these compatibility issues.

And then so there was this understanding. Okay. Cool. We probably should switch to node, to just enable much more and give what people are familiar with. Right? Because I feel like the best API is something that you already know. You have nothing to learn. You can start from the 1st day.

And so this was the decision to go with with Node and NPM ecosystem.

But then on the UI layer, what we also figured out is, well, having a trace in API is nice, but it's actually quite cumbersome to deal with, and we wanna make it really convenient to deal with, especially when you wanna do something like optimistic updates and get really the last mile, performance out of it. So then we said, okay. Let's let's use React.

But as I mentioned earlier, we don't have any HTML or CSS involved. What we did, we basically build our own React Reconciler, which, was fun. It's actually, it's really good. There's, a great blog post out actually from Dan about React as a UI runtime, which is coming from a different angle. Right? So React itself, What we know is, like, this React dom, this renders to the web, but React itself is just a plain, what they call that is what the reconciler is responsible for. So we build our own one, which basically spits out a render tree that Raycast understands, And we're picking up this render tree, and then just render what the extension gives to us.

And and that is a is a game changer, right, because now you have React and node, and we build everything on TypeScript to be type safe from day 1.

And people can use that straight away.

The only difference I mean, basically, we build our own, let's call it, mini React Native. So you also have different intrinsic elements. So you don't have diff, but we give you, like, a high level list that you can use with list items.

So you can think of our API almost like a design system. So you get a list, The forms, the markdown rendering, those kind of stuff. And this is what people use as building blocks to put the extensions together. And the great thing about that is, like, you have a really good developer because everybody is familiar with it, and you have a consistent look across the extensions because that was something which we wanted to guarantee as well. You wanna give flexibility, but with a few constraints to also, have still the usability that that we developed before. That's wild that

It's not I never even thought about that because you're using JavaScript and React to render out both, like, what it does, The functionality, but the GUI as well, but I never thought that it doesn't render to HTML and CSS. It renders out to Native, and you had to build your own layer inside of does does React have docs for that type of thing, or did did you have to figure that out?

Barely.

So there is a a saying here. If you're free, like, reconcile a package, I think the types, sometimes good, sometimes not so good. So we had to dig into it. I think we got really quickly, like, a proof of concept going and felt like, this actually feels pretty cool. Like, you can just use use state and author hooks, and it's just like, wow. This is This works really well. And then the devil is in the details, so we needed a few iterations to make it really safe and catch all the cases.

There are few reconcilers out there, so I think The, is 1 on GitHub which calls if you reconcile us out. I think the most prominent one is probably the one that you can use to build command line apps, Which I did not know before as well. So there is something that you can use React to build a command line app, which is pretty cool. So it basically instead of Wow. Rendering CSS and HTML, it just renders text that your terminal understands, which is pretty pretty wild.

And so, yeah, it's basically digging in open source.

Yeah. It's wild.

That's really cool.

So I had another question about this. This is just, like, for people listening that like to understand programming.

So the fact that you made it a, a React API where you just write tags for things like, like, when it's clicked, it does this. And is that, like, the difference of that that's a declarative API. Right? That's the difference between an imperative API? Yeah. Correct. So We we basically started with an imperative API,

where we said, hey. Please render a list. And then, we would get A callback back and say, hey. Something in the list was clicked, for example, executed.

And then we would recalculate the list and say, please run-in this list now again. And this was really cumbersome with all the state changes that, you will experience in Raycast when you search something and perform actions and wanna update into network requests, where we said, hey.

The the usual way how most people nowadays program front ends It's declarative. Right? We have React. We have Vue. We have Svelte. We have SwiftUI.

I mean, there's plenty of that knowledge out there, so it feels like the new thing. So well, We're not even a new thing. It's around for a while.

So we wanted to also be on the declarative side because if you start learning programming, you're much more likely to to learn declarative clarity of programming, at least on the front end.

And so we wanted to be a part of that as well. And I think, actually, Raycast is an interesting way to learn programming as because we put a lot of love into the developer experience, so you don't need to set up Webpack and other things. It just works out of the box because we know what we compile to.

We actually use it like a CLI, which abstracts away everything. So you just run Ray def, and then you basically have your extension up and running in Raycast. And then you can concentrate of just experimenting with The the building blocks we give you, so with the list and the forms, and and learn this way, React.

And when you then have React, you can basically jump off and and do web development straightforwardly because the knowledge just transfers very nicely, which I think is also nice when when you bet on a technology that's been around for such a long time.

It's also if people are not familiar with it, there's just, like, a 1000000 websites out there, a 1000000 tutorials that you can learn this kind of stuff, which is really good. Like, we had a few community members. They weren't React, users or developers, and they wanted to contribute. So they just took The time to learn React, which is, like, the simple things you can learn really quickly, and so now they contributed extensions also in the store, and have now also TypeScript and React knowledge, which is also pretty cool to see. That's great. Thank you.

We both come from, like, a web web world We're we're primarily building web applications. Right? When you're undertaking something like building Raycast, That interacts with the system quite a bit. Like, for instance, this window management stuff, this is fully fully getting into controlling the Operating system.

Where do you go to understand, like, what's possible essentially in the Mac ecosystem? Is this just kind of like a a, a bit of understanding that the team has of, like, what's even possible or the with this type of app when you're building, like, how are you Getting into the APIs to control macOS, and how are you coming up with the inspiration for those types of ideas? Yeah. Definitely. Good Question. So,

I mean, all of us usually work on the macro. Right? So you surround yourself with what ecosystem is there, and you see certain other apps doing certain things. And I think one of the things that, I just experienced myself with window management, for example, in particularly, It's like, well, everybody has those app to do window management. Right? But what I find always hard is I can only remember my Global hot keys to put the window left and right and maybe also maximize it in center. But sometimes I have the situations where I wanna put something top left, top right, And then a quarter. And then I don't know the the hot key, and then it becomes fiddly. Right? And I I really don't like that. So And then when you work on Raycast, one thing which we do or the entire team does basically all the time is solving their own problems. So this was a problem that I had, and I I took the destiny of, like, actually, it would be quite cool to have this window management stuff in Raycast.

So then I Okay. How do you do that? And then I went down into the Apple docs, figuring a few things out there, where they're explaining, basically, accessibility APIs that you can use. And with this accessibility APIs, you get information about a window or other windows, basically information about not your application, but other applications.

And then you basically have that part, and then it's a lot of moss to get it right, and then you can start building those things.

The other angle is open source. Right? There is a ton of open source out there, which is obviously, with, like, a platform, like the Apple platform, especially on the Mac, which is very, I don't know. Not that well documented, and sometimes you need to go very deep.

Certain other people might have solved this problem, so there is a ton of, inspiration there as well. They maybe have solved in a different angle, but you maybe figure out, oh, there's just 1 or the other API.

And then you find this API, and you can go down the threat. Okay. I have this API, and go forward.

But the inspiration for a ton of this stuff is just Our own problems that we experience. So clip art history, was, I think, the one of the first extensions, that we built. It was just like, well, This is something everybody needs. Let's put it right in.

Another one that we have is is the calendar. So, as with the pandemic, Everybody went on more and more Zoom calls. We felt like, well, going on a Zoom call is very fragmented. You need to open a calendar, find this damn link, and then open it. So what we did is, putting in first your calendar into Raycast, but the simple few. Right? So I don't have that many meetings or all of us in the team don't have really many meetings, so we don't need this full fledged calendar. So we thought we'd just giving you a glimpse of it. So it's called my schedule where you see what you have today and a little bit of a A heck few of a month. And then, the core thing there is, like, this magic moment when you open Raycast and you have an upcoming meeting and trust, so I trust you to join the Zoom meeting or other video calls directly, and and this forms basically, this muscle memory that I have now. I know, for example, When I have a meeting, I just press my global hot key and press return, and I'm straight into the meeting.

And all of this kind of stuff came basically out of our own inspiration.

And then when you have the idea, it's basically digging stuff out how to build it. And I think that's always, the interesting part of, like, Yep. Going down the rabbit hole. Okay. How can I actually build it? And then sometimes this needs a little bit creativity, to figure out the APIs and And digging into, okay, how do how do you get that,

and get it off the ground, basically. Yeah. It seems like you all have great intuition in that regard because it, as Wes said Early on in the show, it does feel like it's kind of eating most of the apps in my my tool chain. So, like, whether I was using with Divi for, window management, now I I don't have to have that app.

It's going to be eating Clippy. Well, where are all the apps that's eating and then l y? Clippy, divvy, or Dean on my y apps.

Maybe. Yeah.

So one piece of tech that I found out that you are using, because you so you recently rolled out, snippets, which I have been for the longest time, has been using TextExpander.

And I have been on an old version of TextExpander for years because I refuse to pay, I don't know, $6 a month for my at text text expansions. And Scott recommended a really good one the other day, but then you guys rolled it out. And I thought, okay. Like, I I'd like to move over all of my tech designers. So I went digging in the folders, and I saw that all of the things are stored in a SQLite database.

So can you explain what SQLite is and and what you use it for? Sure. Yeah.

So, yeah, we use Escaloid as a database on the client and for the ones who don't know. So Escaloid is It's one of the many databases that are available.

It became very popular, I think, on clients in general. Like, it's used a lot in mobile clients, on iOS and Android and also on desktop apps. Not so sure if it's that familiar on the web. I saw there was 1 project which I found super interesting was where somebody ported Escalized to the web that they can use it with JavaScript and WebAssembly.

But going back to back to us, so, basically, we use that as a primarily storage. So everything that you have from snippets over clipboard history to installed extensions to the index we have of the applications is stored in this application in this SQLite database.

And, so, basically, this guarantees for us is, like, a really fast database. It's easy to access.

All of that stays locally. So we like what we call a local first step oftentimes.

Basically, we don't send all of this information to the server, so it stays locally.

Comes with the downside. At the moment, we don't have synchronization. So if you work on 2 Macs, you have the information on your 1 Mac.

But the database itself is is relatively easy to use.

And then it's I think it has bindings for pretty much every programming language out there. So we have we use GRDB as far as I remember. It's basically a Swift library It makes it handy to to use this tool,