A snapshot of 15 October 2026; line counts are from that day.
CadCraft · architecture
How CadCraft 0.5 is built today, and what changes in a Rust fork and a C++ fork. Each fork is shown under two designs: the one 0.5 uses (web first, one build everywhere) and the one The Terminator described on Discord (native, Rust, built to match the desktop push/pull modeller many people learned on).
dev/ buildsCounted with wc -l on 2026-10-15. Compiled help files and language files are left out. "Touches the DOM" means the file mentions document., window., addEventListener, getContext( or THREE., so the 69% is a rough line between logic and UI.
Sheet 1 · as built
One JavaScript build runs in the browser at /use and /lab, and inside Studio's web view on Windows, macOS, Linux, Android and iPad. Heavy work that we didn't write ourselves comes in as WebAssembly, and most of it is C or C++ already.
getcadcraft.com, server rendered
CadCraft Studio, the only desktop download from 0.5
Shared by every app, switched on per build by its manifest
Lines per dev/ build
Canonical in lib/ or one app, copied into the others
Pinned under assets/vendor/<lib>/<ver>; dashed = old releases only
What puts pixels on screen
Sheet 2 · patterns
These are the habits the whole codebase follows. Each card shows how 0.5 does it today in JavaScript, then what it turns into in each fork. Most patterns port as ideas. A few disappear, and a few become real decisions.
Structure
Every app keeps its model, geometry, file formats and commands in DOM-free modules. Only a few files per app draw or handle events.
Sharing
An app's build never imports another app's folder, so shared code is copied in and checked by sync scripts.
--check. Each app test fails on drift.cc-dwg, cc-ifc and m3d once.Editing
doc.change(label, fn), store.change, model.change: every edit, including assistant and LISP edits, is one labelled transaction.
Commands
The CadCraft engine runs commands as async functions that wait on c.point(), c.distance() and c.select(). LISP's (command …) drives the same path.
Safety
DWG, IFC, SKP, PDF, the clipboard, .ccinput.json, add-ons and library items are all validated on read. The browser sandbox is the outer wall.
Concurrency
DWG reads, IFC scans, LISP, CraftScript, auto count and RVT each run in a module Worker built from the library's own files.
Versions
A frozen x.y folder per release, a current symlink, and an import map that pins every vendor URL.
Shell
Panels, phone layout, touch, input profiles, help panel, offline and settings tabs come free to any build with the right markup.
<main>'s role=toolbar, aside panels, the "phone" key.Words
Every string goes through t() keys from lang/*.json. Help is Markdown, compiled per build with trademark checks.
Extending
AutoLISP, CraftScript, Lua, Python and MCP tools are all sealed: no network and no files. Add-ons are JS loaded at runtime.
Proof
Known answers, plus second readers (ezdxf, LibreDWG, ODA, web-ifc, OpenSKP's TS package) and Playwright runs of each app.
Sheet 3 · designs
The language and the design are separate choices. The 0.5 design is about reach: one build in every browser and every Studio. The Terminator's design is about feel: a native modeller that matches SketchUp, fast on big files.
| Original 0.5 | The Terminator | |
|---|---|---|
| Goal | Eight apps for drafting, BIM, models, PDFs, takeoff, civil, steel and parts, under one license | One modeller that matches the SketchUp desktop workflow exactly |
| Where it runs | Browser (/use), Studio on Windows, macOS and Linux, Android, iPad | Native desktop |
| UI | DOMCanvas 2DShared shell, menu styles, touch and phone layouts | iced or egui, a native window |
| 3D | three.js / WebGLgpu path tracer | "High performance 3D", which in Rust means wgpu |
| Engines | own JSManifold wasm Rust→WASM planned for 0.7 (Track RS), benchmark first | Rust throughout |
| .skp files | cc-skp reads .skp (2.5k lines of JS, OpenSKP as the map). Doesn't write. | "OpenSKP being ready to go". It reads and writes, in Python, TS, .NET, Dart and C++. There is no Rust package. |
| Starting point | This codebase | A fork of Ingetrazo (we haven't looked at it) |
| Strength | Zero install, one build everywhere, tablets and phones, Live co-editing, eight apps sharing engines | Speed and feel on big models, one language from kernel to pixels |
| Cost | JS speed limit on very large files (the Discord "razor" file). The DOM doesn't feel native. | No browser, a full UI rewrite, one app instead of eight. Text input, IME and accessibility are harder. |
Sketchup isn't a program that's good because it has crazy features. it's good because it's entirely about a certain workflow
high performance 3d, in rust
openSKP being ready to go
rewrite in rust with iced or egui
Sheet 4 · the forks
Each fork can keep the 0.5 design (the engines move, the UI stays JS in a web view) or take The Terminator's (everything native). The bars show the language mix of our own code at the end of each fork, by lines. They are rough: vendor libraries aren't counted, copies count once, and a rewritten UI is assumed to be about as long as today's.
Base: about 242k lines of unique app JS (103k UI, 139k logic once copies are removed), 8k Rust, 18k PHP. The website stays PHP in every fork, because accounts, sync, the library and licenses are HTTP services.
Engines move, the JS UI stays in the browser and Studio's web view
Native UI and native 3D, desktop first
Track RS, carried all the way
/use and offlineWhat The Terminator asked for
The way Manifold ships today
cxx crate) or a new C++ host (Qt WebEngine, CEF or a webview library)The FreeCAD-shaped route
Sheet 5 · what comes into view
About 86k copied lines and 18 sync scripts become one library each. That is the clearest win in both languages and both designs, and it removes a whole class of drift bugs.
Under the 0.5 design the 103k lines of UI stay. Under The Terminator's they all go. That one choice decides most of the cost, more than the language does.
/use, the lab, phones, tablets, offline save and LAN browser joiners for Live all depend on the web build. Keeping them means compiling the engines to WASM in either language.
MarkupCraft and TakeoffCraft are built on pdf.js rendering, text and annotations. A native fork in either language ends up on PDFium, which is C++.
three.js scenes, edges, sections, the view cube and the GPU path tracer all need replacing under the native designs. Under the 0.5 design they stay.
Our Apache-2.0 rule (no GPL, LGPL or MPL outside Pyodide's folder) is easy to keep in Rust. C++'s strongest CAD libraries are the ones 0.4 removed.
Tauri 2, the Live server and the control channel are 8k lines of Rust today. A Rust fork extends them. A C++ fork has to bridge to them or replace them.
Runtime JS add-ons and sealed scripting don't survive the move to native code as they are. WASM plugins (wasmtime) keep the seal in both languages.
The fixture corpus, known answers and outside oracles are already in place. Running the same suites against JS and each fork is how a fork proves itself, the rule Track RS set.
Accounts, licenses, cloud sync, the library and downloads are HTTP services. Every fork talks to the same API.
Decision in the way. The project rule today is to never promise a native app: CadCraft runs JS in the web view, and Rust is planned to arrive as WebAssembly under Track RS in 0.7, after the forks are tested. Both Terminator-design cells change that rule, and only the owner can change it.