The major advantage oclif has is plugins. Plugins are a way to share code between CLIs or organize within a CLI. At Heroku, different teams manage their own CLI

The major advantage oclif has is plugins. Plugins are a way to share code between CLIs or organize within a CLI. At Heroku, different teams manage their own CLI plugin and each of those plugins have their own set of dependencies. These dependencies will not conflict with each other. It's a great way to share code and modularize a large CLI's codebase. This kind of setup isn't possible with Ruby (to have multiple dependencies of different versions). I'm not sure if it's possible with Python, but I don't think so. Node's dependency model naturally supports this behavior though. I haven't used thor in years and only looked at the docs for click. For a large CLI built in a scripting language, lazy loading of commands is crucial. It appears that click supports this, but my cursory reading of the thor docs looks like that one does not have lazy loading. I have a lot of experience trying to deliver the Heroku CLI as a ruby CLI and I can tell you first hand that dealing with ruby as a runtime dependency vs node is a world of difference. Node is simply far easier. Also, we will be coming out with a plugin for oclif within the next few months that will help you build dependency-less tarballs so the end-user doesn't need to even have node installed. (You can also do this today with oclif just by using pkg) This is also going to come with a couple options for adding autoupdates that won't depend on the local npm. The goal is to make distributing CLIs as easy as possible and have it not conflict with anything that may or may not be on the end-user's machine. If you're just building a small CLI, I don't think between these tools you'll notice much of a difference. Just use the one in the language you feel more comfortable in. oclif is really meant to solve a lot of the problems we've had with large CLIs (sharing code, distribution, dependency management, versioning, namespacing) and abstract away common issues end-users have with setting up. The choice of node is also helpful for large codebases like what we have at Salesforce and Heroku. This is an area where people's main job is writing in many different languages but everyone knows at least some javascript. This means that even if javascript isn't their favorite language, they're still able to jump in and write code. Often CLI code just isn't that complicated either (usually doesn't involve any memory management as the application is only running for less than a second, for example), so the language choice I feel doesn't matter as much as it would compared to back-end development.