JIRA

link

you’ll write better code if you can focus 100% of your attention on solving one clearly-defined problem at a time, and you’ll grow as a developer by reflecting on what’s working and what you’re struggling with.

How the Raycast API and extensions work Learn more about how we built the Raycast API and how it works under the hood FELIX RAAB MAY 31, 2023 Since releasing our API, lots of developers have asked how it all works under the hood. It’s a great question, if a little knotty, especially because we’ve intentionally tried to hide when users interact with extensions in Raycast. Although users do technically install an “extension” through our store, it should never feel like they are. One of our early design goals was that we avoid a second-class mini-app that shows in some frame in Raycast, where developers use technology X and user interface paradigm Y, then ship it. Sorry if that’s disappointing to any webview fans out there! Why’s that our philosophy? Well, Raycast is a fully native macOS app and we treat extensions as first-class citizens. To us that means consistently rendering a native user interface with our customizations. So users feel at home as soon as they open a command powered by an extension. But you typically develop native UI in Swift and compile code in Xcode, so how does the entire system work? Instead of diagrams and code, we’ll use “tech storytelling” to dive into our journey here, including our current solution, the decisions and tradeoffs we made and the concrete technology and architecture we’ve been using. Here’s an outline: Some context from the early days Our first attempt: TypeScript + JSC Our second attempt The developer experience Feature parity and new territory Some context from the early days Soon after launching we found our superpower: creating our community After the public release of Raycast in October 2020, we started exploring how we could create an API for developers. Our goal was for them to have the freedom to customize Raycast and create shareable extensions that other users could install, in a similar way to an app store. This was important for our success because we couldn’t build integrations for the vast tooling landscape all by ourselves. Sidenote: if you’ve ever tried to build an extension for a more complex tool such as Atlassian’s Jira, you might feel us 🥲 We wanted to create a community with collective creativity, where people could build cool and useful things that we wouldn’t even think of. An extension became an umbrella term for one or more “commands” You can launch commands to run some business logic, often by presenting a user interface to Raycast. Inside the command, you can perform “actions” in our central “action panel” that’s everywhere in the app. There’s no limit on how extensive a command can be. If you look at some of our extensions in the store, they could classify as their own apps running inside Raycast and building on the UX toolbox we use throughout. At first we thought there should only be a single command per installable bundle or package. We had no idea people would push the platform and build uber-extensions such as GitLab or Supernova. So it took us a while to arrive at the conceptual model of having an “extension” that exposes one or more “commands” (yes, naming is hard 😅). Thinking through our technology choices Since we’re in the world of desktop apps, we didn’t have a blueprint for an architecture that we could copy and implement. On the other hand, enabling plugin functionality for applications is nothing new, so we started researching the basic tech that would let us dynamically load, run and unload extensions in our desktop client. Looking at our old comparison table of pros and cons of the various approaches, you’d find tech buzzwords like: Bundled Node Runtime JavaScriptCore + Node Polyfills WebKit Deno Lua XPC Web Server-Client I could go on but you get the idea 😅 Popular extensible apps such as Visual Studio Code seemed worth a closer look because it: is a desktop app running on macOS has an extension store and developer community is open source. Problem solved? Unfortunately, not quite. That’s because Visual Studio Code is an Electron app and there’s a Node runtime running. This might trigger a sense of unease in some macOS developers who’re used to paying for polished native macOS apps and can spot an Electron app a hundred miles away. Plus, wasn’t Node a runtime that forced developers to use a programming language that many see as flawed? With a package ecosystem riddled by security problems that caused half of the entire web not to work at times? Plus a bunch of other issues, so that its creator went ahead to fix all mistakes in a new shiny runtime? Perhaps. On the other hand, according to Atwoods’s Law, JavaScript is here to stay, other languages compile nicely to JavaScript, and Visual Studio Code does work quite well… Our first attempt: TypeScript + JSC We set JavaScript as our primary runtime language and TypeScript as our main extension language. We could have chosen something more eclectic and simple, like Lua. But there were a few questions on our minds about that: Would people really build