status
dsq_thread_id
Alfred[t] is one of my favorite mac apps of all time, however, I recently stopped using it in favor of Raycast[t].
Why?
It’s all about extensions. Two factors in particular that Alfred struggles with and Raycast does quite well:
- Ease of authoring extensions
- Ease of extension discovery
What’s particualrly unfortunate is that Alfred is actually more extensible than Raycast, but it’s (relatively) difficult to create, manage, publish and update Alfred extensions.
Note: Alfred calls their extensions ‘Workflows’, but i’ll refer to them as extensions since it applies to Raycast as well.
Authoring extensions
Once you get going writing an Alfred extension it’s not difficult, but it’s a pain to get going. Using
stdin and stdout to manage data flow is simple. However, there’s a whole visual component involved…Extension authors need to click around the Alfred workflow UI to get going and connect scripts together. This adds friction and adds something new to learn.
Formatting data can also be a pain, which is why most big languages (JS, Go, etc) have third party libs to handle formatting Alfred IO data. It’s great these packages exist but it’s unfortunate they have to exist.
Compare that to Raycast, which will:
- Initialize a new extension project for you and set up all the boilerplate
- Open the project in your text editor
- Reload the project when your code changes
It would be a huge pain to set up a Raycast extension project without this automated plumbing, but they took the time to add these commands so that you don’t have to worry about it.
Strong Types
Raycast extensions are written in TypeScript, which, although it may not be your favorite language makes it much easier to interact with an unfamiliar API. Raycast’s custom React components of course require specific props to function, but the properties are all discoverable thanks to strong typing. Your editor will tell your what properties your missing and what type they’re supposed to be.
The App Store
Now the even bigger problem: Alfred’s lack of an app store. App (i.e. extension) discovery in Alfred looks like:
- Find the Alfred forum
- Search for stuff (there is no curation that I’m aware of)
- Find the link to the project (usually Github)
- Download either a pre-packaged extension (good) or read through the instructions on how to package and install the extension (bad).
- Configure the extension in the Alfred GUI (often adding a prefix for the command)
There’s nothing inherently wrong with any of this, but it’s a poor experience, even for technical users. I imagine it’s significantly worse for non technical users when they have to wade through a Github readme.
Compare to Raycast:
- Type
storeinto Raycast
- Browse or search through whatever you want
- Hit enter to read more, hit enter again to install
This is a good experience. Users don’t have to worry about how to install something, or even where to find it. It’s all automated away for the user.
So back to my initial point, where’s the Alfred app store?
Where’s the Alfred App Store?
I can’t help but wonder what’s going on at Alfred HQ, because they continue to push updates (yay!) while ignoring a clear and pressing usability issue.
A ‘Launcher’ or ‘Command palette’ app is only as useful as the commands it provides. Making extensions easily accessible and easily publishable harnesses a community of developers to make the app better, FOR FREE.
It’s unreasonable to expect a developer to provide for every niche use case (I have an extension to search transcripts of one specific podcast for instance…), so it’s important for companies like Alfred to make it not only possible easy to extend the app and distribute the extension.
The thing is, it’s not that hard to make an extension store. It’s definitely time/effort—it’s not zero—but it’s also a well-within the beaten path of web software.
My only speculation here is that Alfred fundamentally sees themself as a desktop software company and is much more comfortable working with native Objective-C APIs than with web tech.
Still, I hope Alfred can do something to retain its existing users. Version 4, and now version 5 (due soon, as of this writing) seemed exceedingly lackluster. I bought v4 b/c I’ve enjoyed Alfred for so long, not because of any of the features announced in the update. v5 looks to be much the same, but this year I won’t be buying since I’ve already left for the greener pastures of Raycast.
Alfred is great software, but it needs its users to help if it wants to thrive, and its users need Alfred to step up and make extensibility and distribution as easy as possible.