build123d: The Algebraic Engine for CAD-as-Code

build123d also depends on OCP, and I agree with the prior comment that compiling to WASM is not trivial... I think this is a nice goal but is a huge project unto itself that would require more time than I am willing to devote to it.

jdegenstein, Contributor · Compile to wasm · Issue #946

The Fluent API Trap

For years, the dream of "CAD-as-code"—defining physical objects through text rather than a graphical user interface—has been hampered by API design. The most prominent Python-based precursor, CadQuery, relied heavily on a "fluent" API. This meant executing geometric operations through long chains of method calls.

While method chaining provided a concise way to represent sequential operations, it created significant friction. Massive, tangled chains broke standard IDE features like Pylance and IntelliSense. Simple control flow, such as loops or conditional logic, became cumbersome when forced into a chained structure. Worst of all, it isolated CAD scripts from normal Python logic, making them difficult to debug or unit test.

# The Fluent API Approach (CadQuery style)
result = cq.Workplane("front").box(2, 2, 2).faces(">Z").cylinder(1, 1)

# The Algebraic Approach (build123d style)
with BuildPart() as my_part:
    box = Box(2, 2, 2)
    with BuildSketch(box.faces().sort_by(Axis.Z)[-1]):
        Circle(1)
    extrude(amount=1)

The Algebraic Rebellion

build123d was built to solve this syntax trap by treating 3D topology like standard Python objects. The core innovation is the rejection of the fluent API in favor of algebraic context managers and operator overloading.

By using with BuildPart():, the framework manages state implicitly. When a developer needs to perform geometric booleans—unions, subtractions, intersections—they use standard Python operators like += and -=. Location transformations are handled by the @ operator. This turns 3D modeling into basic arithmetic, allowing developers to build complex parametric designs using the full power of the Python language.

Taming the Open Cascade Leviathan

Beneath the elegant Python syntax, build123d is commanding a leviathan: Open Cascade (OCP). This massive C++ boundary representation (BREP) kernel is the same engine that powers professional tools like FreeCAD and SolidWorks. Wrapping such a complex C++ library in Python is notoriously difficult, often leading to unpredictable behavior or performance degradation.

To tame this complexity, the build123d maintainers rely on strict enforcement of modern software engineering practices. The repository mandates a highly rigorous linting process (enforcing a 9.5/10 pylint score) and runs automated benchmarks on every push across macOS, Ubuntu, and Windows. This ensures that the overhead of the Python wrappers doesn't degrade performance during complex geometry calculations.

Unit Testing the Physical World

By fully integrating with standard Python, build123d enables a profound shift in how hardware is designed: unit testing for physical objects. Because 3D topologies are just Python objects, hardware engineers can write pytest suites to assert volume, clearance, and tolerances.

Imagine a workflow where a pull request for a 3D-printed part is automatically rejected because the new geometry fails a volume or clearance benchmark. This is not theoretical; it is a workflow that build123d's architecture explicitly supports, bringing the rigor of continuous integration to the physical manufacturing pipeline.

The Code-CAD Ecosystem

The CAD-as-code landscape is diverse, but build123d occupies a specific niche. It differs fundamentally from tools like OpenSCAD, which uses its own functional DSL and Constructive Solid Geometry (CSG) math, and CadQuery, which uses Python but traps it in a fluent API.