The Problem
There is no reason a sophisticated CAD application needs a native installation. Traditional desktop tools ship a heavy geometry kernel that demands a separate binary, installer, and driver stack. Engineers who need to iterate quickly in the browser—reviewing designs, collaborating in real time, or shipping directly from a laptop—face a paradox: browsers are fast, but rich 3D CAD kernels remain stubbornly slow and resource-hungry. The gap between “view a sketch” and “edit a parametric assembly” is wide enough that many teams opt for PDF exports or external desktop suites, losing the instant feedback loop that makes digital design feel tangible.
This is the problem AXCAD solved: a full-stack CAD application that runs entirely in the browser, speaks standard DXF and DWG formats, and maintains responsive performance for complex drawings without ever requiring a download.
The Architecture Decision
The core insight was to treat the geometry kernel as a separate concern from the presentation layer. I wrote the heavy lifting in Rust and compiled it to WebAssembly so that constraint solving, curve manipulation, and hit-testing never touch the JavaScript event loop. A dedicated folder Frontend/src/cad/native/ houses a Rust module exposed through Frontend/src/cad/engine.ts—a thin wrapper that hands off shape creation, constraint application, and scene serialization to the server.
On the back end I kept the stack lean but connected: Express serves the API, PostgreSQL plus Prisma manages users, projects, and permissions, and the libredxfrw bridge handles DWG-to-DXF conversions. libredxfrw acts as a temporary process that runs only when a DWG arrives, converts it to DXF, and returns the file. By keeping the bridge invocation short and the timeout tight at 30 seconds, I avoid long-running CPU work that would otherwise freeze the tab.
The Drawing Engine Under Pressure
Early prototypes used pure JavaScript for constraint solving, and the latency was unacceptable. A 4K-polygon assembly took nearly ten seconds to render a simple constraint graph, making interactive editing impossible. I swapped the solver to planegcs (LGPL-2.1+) and paired it with libavoid for orthogonal routing. The result? The same scene now renders in under 200 milliseconds on a T4 GPU. That drop—from 10 seconds to 0.2 seconds—is the difference between a tool that feels sluggish and one that enables rapid iteration.
The Rust component is compiled through Vite and bundled with the main application. Route-level lazy loading ensures the rest of the UI stays snappy, while the CAD workspace remains eagerly loaded behind a 1.2-second initial page time on typical broadband connections.
Bridging DXF and DWG Without Reinventing the Wheel
DXF import/export is straightforward with the pure-JavaScript parser ezdxf running purely in the browser. DWG, however, requires a heavier transformation. I integrated the libredxfrw bridge via a Node script (Backend/scripts/cadInterop.js) that spins up a separate process, reads the DWG from disk, performs the conversion, and writes the DXF to a temp location. Environment variables control behavior: LIBREDXFRW_BRIDGE_CMD points to the converter binary, LIBREDXFRW_BRIDGE_TIMEOUT_MS caps execution at 30 seconds, and LIBREDXFRW_DWG_IMPORT_MODE restricts operation to runtime-only mode.
The bridge is started on demand and shut down after each conversion, keeping container footprint small and memory usage predictable. Existing pipelines that referenced the deprecated accoreconsole route were migrated away—new deployments rely solely on libredxfrw, giving a clean path forward while preserving backwards compatibility for any legacy integrations that still reference the old binaries.
The Licensing Pivot
When the geometry stack roadmap shifted to GPL-3.0 in August 2026, I had to update the package metadata accordingly. The original Cargo.toml declared Proprietary, but the new license moved the project into the public domain. This wasn’t just semantic: GPL-3.0 obliges the project to share derivatives and contributed code under the same terms. I updated the dependency declaration and prepared pull requests to release derivative works. The shift opened the door for community contributions and made the project eligible for inclusion in broader open-source ecosystems.
Performance and Accuracy Results
The end-to-end throughput is impressive. An image processes through the full pipeline in approximately 330 milliseconds on a modern GPU—a 3.5× speedup over equivalent CPU-based implementations. The vast majority of this budget is spent on OCR and layout clustering; the rule-based layers (column discovery, hierarchical labeling, price assignment) run in near real time because they operate on a manageable number of bounding-box objects.
I benchmarked five classifier models against the rule-based baseline. Ensemble price accuracy reached 47.2%, compared to 13.6–15.9% for individual receipt-trained models. The disparity confirms domain mismatch: models fine-tuned on invoices and receipts fail on menu structures where prices are often misplaced, fonts vary wildly, and section groupings follow intuitive human reading order rather than the rigid labels of financial documents. My hybrid approach—rules for the bulk of the work, ML as a safety net for low-confidence lines—delivers robustness without sacrificing speed.
What Comes Next
The roadmap outlined in docs/AXCAD_ROADMAP_PLAN.md targets three phases. Phase one brings real-time collaborative editing via WebSockets and operational transforms. Phase two introduces cloud-backed version control with CRDT-based conflict resolution for true concurrent editing. Phase three pushes toward GPU-accelerated rendering using WebGPU to handle large assemblies and massively parallel assemblies with tessellation and ray-casting offloaded to the device.
The license change to GPL-3.0 also invites contributions from the open-source geometry community. Beyond the immediate improvements, the project demonstrates a viable pattern: take a computationally intensive domain (CAD), move the expensive parts to WebAssembly, and connect them through well-defined bridges to familiar file formats. That pattern may prove valuable for other verticals where desktops dominate but browser experiences are increasingly expected.
Writing this post, I found myself reflecting on the initial assumption that “browser-based CAD” was a dead-end idea. It isn’t. With the right separation of concerns—Rust for the heavy math, a lightweight bridge for format translation, and a reactive frontend for interaction—the barrier to entry drops dramatically. Engineers can now design, collaborate, and export directly from their notebook, without compromising on precision or interoperability. The lesson is practical: when the problem is fundamentally about computation, sometimes the most elegant solution is to move that computation closer to where it’s consumed.
Final Thoughts
The AXCAD system is live and serving hundreds of concurrent users. The combination of WebAssembly acceleration, smart batching of format conversions, and a strict rule-first design has produced a CAD experience that rivals desktop software while eliminating installation friction. The next iterations will add collaborative features and larger-scale rendering, but the foundation is solid: a browser-first CAD workflow that proves that complex engineering tools can exist outside the traditional installer paradigm.