That means the core of Hammerspoon goes from being incredibly complicated, to really just a protocol conformance.

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.

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.

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.

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.

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.