My fascination with gears led me to the scripting mechanism in both Fusion 360 and Onshape. Both CAD packages offer only minimal gear generation capabilities, and not even built-in to the main software: Spur gear generation was given in the form of an external add-in. This meant they are ideal introductory entry points to examine the different design philosophies.

The Onshape team invented their own scripting language called FeatureScript. It has some superficial similarities with C-style languages which helps a software developer get up and running more quickly on the new language. The code libraries are designed specifically around designing parts within a Onshape feature studio.

In contrast, Autodesk did not try to invent a new language. Instead, they decided to support multiple existing languages and let the user choose the one that best suits their purpose. C++ or Python. (Fusion 360 used to also support JavaScript, but support has been deprecated.)

Readability: Because FeatureScript was designed specifically for its task, the code is much more direct and readable. All API are designed to fit with FeatureScript because that's the only language supported. Fusion 360 C++/Python code must call into the Autodesk library code which had to be adapted to be usable across languages. Advantage: Onshape.

Performance: C++ can be compiled to native code and executed on the local computer. For small tasks, this will be the fastest possible option. Python code running locally wouldn't be quite as fast, but unlike FeatureScript, it does not have to deal with network latency. Advantage: Fusion 360

Security: FeatureScript executes in a secure sandbox on Onshape server, and thus limited in risk for exploitation by bad actors. In contrast, a native C++ binary can easily host hostile code. Python is slightly better in this regard, but it's not clear how much effort (if any) Fusion 360 puts into running Python securely. Advantage: Onshape

Development: Like the rest of Onshape, all work with FeatureScript takes place within the user's web browser window. If the developer does not like the Onshape FeatureScript editor, they are unfortunately stuck. In contrast, Fusion 360 presents many options. C++ development takes place on a platform-appropriate IDE (Visual Studio for Windows, Xcode for MacOS) and for Python the Spyder IDE is provided. Advantage: Fusion 360

Evolution: FeatureScript is owned by Onshape and any future evolution is fully under Onshape control. Since all FeatureScript written by users are stored on Onshape servers, they can validate any future changes for compatibility. In contrast, Autodesk owns neither C++ nor Python and could not direct future evolution. And since Autodesk does not host the plug-in code, they have no visibility on breaks in compatibility. Lastly, as history has shown, Autodesk can choose to abandon a language (JavaScript) and all the users on it. Advantage: Onshape

Capability: FeatureScript is constrained to feature creation in a parts studio. Autodesk API is currently roughly similar, focused on the model designer portion of Fusion 360, but they are starting to branch out. As of this writing they've just started rolling out some basic scripting capabilities for the CAM module and stated intention to do more. Advantage: Fusion 360

Python LogoFor the immediate future, I intend to focus on Fusion 360 scripting via Python. I've wanted to become more proficient in Python, and this would be a good way to look at Python through a lens entirely different from writing Qt code on a Raspberry Pi. I also have ambition to write Fusion 360 plug-in that leverages external libraries to provide novel services, and that's not possible when stuck inside the FeatureScript sandbox. I will just have to keep a careful eye on the Python library imports in an effort to keep the security risks under control.