Spent last night messing around with a browser-based code-CAD studio and the plug-in language idea finally clicked for me

I actually played around with GCAD Studio a few weeks ago, mostly just to see if I could speed up some repetitive tooling without messing with my local Fusion environment. I was working on a custom mounting bracket for a Nilfisk sensor, something that needed a precise 40mm bore for the conduit. The ability to switch between the two languages was interesting.

I found that the math-based syntax was definitely quicker for just creating simple cylindrical cutouts or defining a box shape. Trying to replicate complex fillets using that method felt a little clumsy compared to the procedural approach, though. It really hammered home the separation of the concept and the implementation. The editor handles the view perfectly whether the code underneath is simple or messy. My only hiccup was getting the tolerances right in the browser environment. Sometimes the rendering seemed slightly different until the final export to gcode, but generally, the workflow felt much lighter than compiling everything on a desktop setup. It’s a neat little piece of software, even if it’s still figuring out some of the edge cases. It definitely makes quick iteration feasible!

I tried GCAD Studio last month when I was working on a custom jig for my workbench. My goal was to make a precise clamping mechanism for cutting small pieces of walnut. The core idea of switching languages was clever, but I found that translating a complex physical assembly into a functional script was actually pretty intense. It took me several hours just to get the mounting posts to align correctly before I even thought about cutting. I usually start with a physical mockup or maybe some simple sketches in a drawing program, because that helps visualize the relationship between the pieces before I commit to the mathematical definitions. Using the code-first approach forced me to think about every single clearance, like the gap between the jaw and the fence, in a way that felt counterintuitive for a mechanical part. I had to keep remembering to account for material shrinkage and the inevitable slight variations in my router bit.

Even though the viewer rendered the shape beautifully, the process of ensuring all the mating surfaces had the right tolerance was a struggle. It felt more like debugging a complex math equation than designing a piece of hardware. It wasn't a total failure, but it definitely slowed down my design phase significantly compared to just sketching the component first and then building up the model geometrically.

The thing I keep wondering about is wether the plug-in interface is documented well enough that a person could bolt on thier own language, becuase that is where this either becomes a real platform or a curiosity. I have a pile of old scripts that generate shelf pin layouts from a few parameters, and if I could wrap that logic in whatever syntax suited it and still keep the same viewer, that woud be genuinely useful. Also, since it is AGPL and runs client side, I assume my models never leave the browser, which matters to me since some of my designs are for client work and I would rather not upload them anywhere. Anyone confirmed how the plug-in API is scoped?

Gotta push back on the bit about the rendering looking slightly different until the gcode export, because that's not a hiccup, that's the whole game. If what's on screen and what comes out the other end don't match, you can't trust the preview at all, and eyeballing a part you can't trust is how you waste a print. Also curious why gcode is the export step here, I thought these tools hand you a mesh and your slicer does the rest. Either way I'd want the preview and the output to come from the same math before I'd rely on this for anything with tight fits.