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
For 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.



And now for something completely silly: let’s look at how our two competing hobbyist-friendly CAD offerings fare on the hobbyist-friendly single-board computer, the Raspberry Pi.
After using Autodesk Fusion 360 for a few weeks on the Luggable PC project, I’m getting more comfortable with it. Here are some thoughts and updates on a few items I mentioned in the “Round 1” post:
Sharing: I was unhappy with the complex access control system, making it difficult to just share a design to everybody. But they have since added (or I just noticed) an option on every design in the project navigation tab: “Share Public Link”. It will generate a link to share publicly. This one is actually a step above Onshape, where I can choose whether the sharing link is a snapshot or a live link to the current state. Choose whether the design itself is downloadable.

Since completing the