Hammerspoon maintainer here - I'm enjoying reading all the comments, and hoping that everyone isn't going to be annoyed that I'm mostly working on a v2 atm, which switches from Lua to JavaScript :D
Would you mind elaborating on your vision for v2? Was there a certain limitation in the previous architecture that you’re trying to avoid this time around? Was there something in particular that drew you to choosing JavaScript for this version?
Honestly, in 2026, I do not want to be maintaining a 100k line Objective C program.
So, my current experimentation with a v2 is to see how easily I can catch up with where v1 is, just using Swift and JavaScriptCore.
There are lots of things about the Lua APIs that I don't like, and I'm addressing some of those as I go, but I'm currently in a phase where I'm targeting parity with everything I need for my v1 config, at which point I can cut over to running v2 and then see how things are looking and what can be refined/reworked.
Presumably that'll be released in [checks calendar] 18 days?
I'd take a minor quibble with one of the Reddit commentators:
> "Lua is a language that was built for people that are not programmers, and Hammerspoon (or at least building it's extensions) is targeted specifically at programmers."
Hammerspoon[0] isn't targeted at programmers because it's abstracting hard things (interfacing with macOS system libraries, etc.) into easier ones (the Lua spoons) where accessibility to non-programmers is surely a goal.
[0] I'm excluding extensions because the included spoons cover many scenarios people would be interesting in using and, to be honest, building "extensions" to something as tricky as Hammerspoon would be beyond many programmers[1], never mind non-programmers.
[1] I'm reasonably experienced and pretty fast at the "huh? <-> search <-> experiment <-> kludge <-> test <-> passable code" cycle even with completely new technologies and I definitely wouldn't be keen on attempting a Hammerspoon extension.
Where JS massively wins here, to my mind, is that there is so much tooling available for it, to the point that I'm already not actually writing my v2 config in JS at all, I'm writing it in TypeScript and compiling it to JS.
> Where JS massively wins here, to my mind, is that there is so much tooling available for it
Yeah, I can see that being a big win for development and people already invested in the JS ecosystem.
(I'll stick with Hammerspoon v1 until it breaks and then figure something else out because it'll be a cold day in hell before I subject myself to JS/Node/Typescript again. The trauma runs deep and wide.)
> I'm already not actually writing my v2 config in JS at all, I'm writing it in TypeScript
Will give v2 a go with `lua2js`[0] transliteration and see if that's workable.
Yay! :D
>.. enjoying ..
:)
>Lua to JavaScript
:\
Well, I have been a long user of Hammerspoon, and Lua, so thanks for the great app, it made a difference for me for a long time .. would be happy to hear why, but don’t feel obliged, the switch to JS over Lua, but anyway, thanks again!
The more complex answer is that Hammerspoon is currently about 100k lines of Objective C, and none of us really want to work on it anymore when Swift is the much nicer place to be doing macOS development.
Technically we could slowly convert in-place from ObjC to Swift, but there will always be a need for "LuaSkin", the bridging code we've accumulated over the last 13+ years, and rewriting that in Swift would be significantly complicated.
JavaScript, however, is already bridged for us because WebKit needs it.
What will v2 enable??
Beyond my enjoyment/productivity on the developer side though, I think v2 will be a big boost to user enjoyment/productivity, mostly because they'll be able to get much nicer IDE integrations for their config file, and be able to do things like write their config in TypeScript.
I have a feeling that letting people do what Hammerspoon can do, but in a TypeScript environment that they're much more likely to know, than Lua, will be huge for the project.
Lua is a better JS.
/ducks
That means the core of Hammerspoon goes from being incredibly complicated, to really just a protocol conformance.
Things programmers believe. It's interesting how some knowledge fundamentally assumed by default. For whatever reasons, the notion is widespread. You're a programmer? Therefore you must know JS, SQL, Bash and Python. In practice, what I've found after decades working with various teams - most programmers have pretty inadequate knowledge of any of these things.