- I am not a company. This is an individual, highly-flawed passion project. Let's be kind.
- I wanted to build an Open-source, cross-platform version of these tools that focused on reusable scripts
- Linux builds exist, I don’t have the machines nor bandwidth to support them. I will need the community to step up if they feel it’s worthwhile
We use Script Kit a lot internally at egghead.io for course/transcript production, so any success beyond that is honestly just a bonus.
If there are any ideas/features/questions I can help with, the best place to ask is over on our GitHub discussions page (much easier to share code, etc).
Thanks John. I'm immediately excited by this project. I love the idea of alfred et. al. but there's always something lacking about them: it's difficult to do plugins, or they're done in a language I don't know, or they're not cross platform.
This ticks all my boxes (as far as I can tell) so I'm looking forward to trying it this weekend.
At the risk of sounding like an HN contrarian: I find it fascinating how many projects reinvent the wheel with a complex solution for something that's already easily possible, while introducing all sorts of limitations and security issues.
This seems like a repository of—hopefully verified—NodeJS scripts, and a standard library of common tasks, presented by a slick graphical launcher. The appeal seems to be that it's cross-platform (yet no Linux?), and that users can write their own scripts.
But... Other than the standard library, which might be useful, all of this is already possible. Just write your scripts _in any language_ and launch them via the universal launcher: the command line. Or, if you want to get fancy, use any number of script launchers, like rofi on Linux.
I'm curious to know what this tool does differently or better than what's currently out there.
At the risk of sounding myself like a knee-jerk HN meta-cliché... you absolutely do sound like the famous Dropbox quote from here, or CmdrTaco's comment on the original iPod.
Absolutely every single tool in this space is re-inventing the wheel. The entire concept of this kind of system automation scripting is, "do stuff that you could already do — but more conveniently."
Now "more convenient" is maybe a slippery concept, but it could mean:
- the same scripts work on different platforms
- the interface for creating, managing, and executing scripts is good
- include a good core library of building blocks to make tedious foundational things quick
- generate a lot of user support/enthusiasm, resulting in e.g. lots of scripts, good forum or a lot of blog posts or docs, that make it easier to work with
- offer UX or design elegance that somehow warms users' cockles
- start with really good defaults
You could do any one of those things well and make the world better.
I currently use Raycast on Mac and it's cool, but it's Mac-only. On Linux I use Albert, but am still looking around (for years). The built-in commands of these tools are appreciated, but even when they are just invoking scripts I myself wrote, as a user I still want any help I can get in organizing my scripts and commands, syncing them across my machines, restoring them when I set up a new machine, and easily editing them in a convenient way that works well with revision tracking.
Plus (in theory) I'd love to see other features, like easy ways to share useful automations with friends/family/whoever, etc.
My point is that there is absolutely nothing wrong with reinventing the wheel if you can make a better wheel, especially in the context of day-to-day user interaction automation scripting.
(For me personally, the potentially exciting bullet point for this particular system is "cross platform" — even if Linux is still WIP.)
Thanks. I don't want to be _that_ guy, so I appreciate the different perspective.
I can see the appeal of a standard library of common tasks to make certain workflows more convenient. And this tool is certainly an improvement over existing proprietary tools that are not as easily extensible.
My main criticism is that given that it's "made for developers", an audience that technical can already do all of these things. And if the intention is to make things more convenient for them, publishing a NodeJS library would accomplish the same thing, without reinventing the way they already launch scripts.
I suppose the difference of opinion boils down to the subjective perception of "convenience". The workflow I use to solve these problems is convenient for _me_, but might not be for someone else. So it's difficult to relate to alternative workflows, but at the same time I shouldn't be dismissive of the fact that it works for others.
plus, rust-rewrite-all-your-utilities efforts, what rust really adds is syntax highlighting and esp be .gitignore aware but I now need remember quite a few different option flags. admittedly, the old unix tools(e.g. find,grep,etc) should had .gitignore-awareness etc a few years back, which is still undone.
> But... Other than the standard library, which might be useful, all of this is already possible. Just write your scripts _in any language_ and launch them via the universal launcher: the command line.
How do you not understand why people would want to do something faster than they typically do it?
I understand the reason for using Javascript as the scripting language here, because of its mass appeal, but to me personally it's super disappointing and a missed opportunity.
Python to me has always been the ultimate glue and scripting language and it's sad to see it is not leveraged more often.
"The ultimate glue and scripting language" is taking it too far, I think.
I have loved Python too, but fell out of love a long time ago. Julia is much better in many ways, _in my opinion_.
Lua is a language that I have no experience of myself, but which is often embedded in things like this, because the interpreter is very small (if I'm not mistaken), which makes it convenient, and therefore in some ways superior to using either Javascript or Python.
Just saying that there are many opinions and ways to think about this.
Looks great! And your site is also beautiful and clear.
One piece of feedback: I saw the Apple download options and didn't realize there was a (much subtler) windows option. I think most people will miss that and think this is Apple only.
I'm sure there's worse hiding beneath the covers of some apps you use on a regular basis; e.g. Teams, Office, most AA/AAA games, etc. While Electron is far from optimal, just because a great app is built on top of it doesn't make that app any less great.
As an example, although I do have a prejudice against Electron based apps myself, that doesn't prevent me from using VSCode, which itself is based on Electron. VSCode is pretty great, and I'm not going to not use it simply because it uses Electron.
They already are – there's a system webview on Windows and macOS. There are a few "Electron alternatives" that use the system webview instead of bundling a copy of Chromium. Tauri [0] is one of them, built around Rust, and it's pretty great. I built a video editor with it.
The usual complaint against this is that you have to support multiple browsers (Edge/Chromium on Windows, Safari on Mac).
Are those services or just shared libraries? I would imagine, although I'm not sure this is the case, that 50 tabs in a browser consume fewer resources than 50 individual WebViews.
Raycast is an amazing tool, I use it everyday and have a few custom scripts to do stuff. Highly recommend.
It's super nice to press cmd + space and type a common thing I do without having to think. I use it to move windows around, switch from light/dark mode (frontend dev) switch focus between Firefox, terminal and IDEs, control Spotify, manage my Asana tasks, the list goes on :)
A few things to get out of the way:
- I love Alfred/Raycast/BetterTouchTool/etc
- I am not a company. This is an individual, highly-flawed passion project. Let's be kind.
- I wanted to build an Open-source, cross-platform version of these tools that focused on reusable scripts
- Linux builds exist, I don’t have the machines nor bandwidth to support them. I will need the community to step up if they feel it’s worthwhile
We use Script Kit a lot internally at egghead.io for course/transcript production, so any success beyond that is honestly just a bonus.
If there are any ideas/features/questions I can help with, the best place to ask is over on our GitHub discussions page (much easier to share code, etc).
Cheers - John Lindquist