JSketcher: browser-based parametric CAD with JavaScript

JSketcher's browser CAD architecture

JSketcher addresses a specific gap between scripted geometry and conventional CAD workflows. It is intended for designers and developers who want to define dimensions as named parameters, solve sketch relationships, and rebuild 3D models through a feature history. The project originated as a way to make models for 3D printing, but its documented outputs also support 2D drawing work through DWG and SVG export. The browser is part of the product model rather than a later packaging layer: the README states that no server-side code is required and that the application uses client-side JavaScript and WebAssembly.

The core is a 2D geometric constraint solver. It receives constraints such as horizontal, perpendicular, tangent, symmetry, radius, angle, and point-on-object relationships. Those constraints restrict the positions and relationships of sketch entities. A dimension repository allows constraints to refer to symbolic names rather than fixed numeric values. When a named dimension changes, the README says the sketch is resolved again. This is the mechanism that gives JSketcher its parametric behavior.

The 3D side builds a model step by step through feature history. The README also says that a compare step propagates edge and face IDs. The stated purpose is to keep those IDs stable as the model changes, which matters when later operations refer to faces and edges. Solid operations, including booleans on BREP objects, are handled through OpenCascade. JSketcher is therefore not a single geometry implementation from top to bottom. Its JavaScript and TypeScript constraint engine works alongside OpenCascade for solid modeling operations.

The repository layout also shows that this is a full application codebase rather than a small solver library. Directories named `modules/`, `web/app/`, `test/`, `build/`, and `dev-guide/` separate model logic, browser code, tests, generated or packaged assets, and contributor documentation. That organization may suit engineers who want to modify both the constraint and interface layers, although it increases the amount of code they must evaluate before depending on individual solver APIs.

Installing JSketcher and starting its local server

The repository documents a Node.js development setup rather than a packaged desktop installer or a documented Docker deployment. The README directs contributors to change into the local JSketcher folder, install package dependencies, and start the application. The package script exposes the development server on port 3000 and binds it to all host interfaces.

After installing Node.js, run these commands from the project directory:

cd <jsketcher folder>
npm install
npm start

`npm install` installs the dependencies listed in `package.json` and `package-lock.json`. `npm start` invokes `webpack-dev-server` with the repository's `webpack.config.js`, using port `3000` and host `0.0.0.0`. The README links to `http://web-cad.org` for hosted examples, while `package.json` defines the local development settings. The README does not specify supported browser versions, explain how WebAssembly assets are loaded, or document a production server configuration.

The first useful workflow is therefore exploratory rather than a complete production setup. Open the local address associated with port 3000, then use the 2D Sketcher to create geometry, apply constraints, and add dimensions. For a 3D model, the documented workflow starts with a parametric 2D sketch and continues through features. The README links to a live sample model and separate 2D and 3D examples, but it does not provide a command-line model creation tutorial.

A developer who intends to change the source should also note the available package scripts. `npm run lint` checks `web/app` and `modules`, while `npm run check-code` invokes TypeScript with `--noEmit`. `npm run build` runs Grunt. These commands are defined in `package.json`, but the README does not explain the generated output layout or a deployment procedure for it.

JSketcher constraints, dimensions, and feature history

The supported constraint list gives JSketcher a sketcher vocabulary that includes Coincident, Vertical, Horizontal, Parallel, Perpendicular, Point to Line Distance, Point to Object Distance, Entity Equality, Tangent, Radius, Point On Line, Point On Arc / Ellipse, Point In Middle, Angle, Symmetry, Lock Convexity, and Fillet Meta Constraint. This range supports relationships instead of requiring every segment to sit at fixed coordinates. The README also lists a 2D measurement tool for Linear, Vertical, Horizontal, and Arc/Circle dimensions.

The dimension repository connects those constraints to model parameters. The documentation explains that a line-length constraint does not have to hardcode a value when a symbolic dimension exists. A constraint can refer to that dimension, and changing the dimension causes another sketch resolution. That gives engineers a familiar parametric workflow in which changing one named value can alter connected geometry.

The README does not state which solver states are reported when a constraint set is contradictory, underconstrained, or otherwise unsatisfied. It also does not document numerical tolerance controls, solver iteration limits, or strategies for resolving overconstrained sketches. Engineers should therefore avoid assuming that every diagnostic found in desktop CAD applications is exposed by JSketcher.

In 3D, feature history records the steps used to build the solid. This makes model history part of the design data rather than merely an editing convenience. The README describes a compare step that carries edge and face IDs forward, which is relevant because BREP operations refer to model topology. The documentation does not explain conflict recovery, history branching, model merging, or the serialized history format. The feature-history concept is documented, but its operational boundaries are not.

JSketcher 2D sketcher and 3D export workflows

JSketcher offers two related surfaces. The 2D Sketcher renders sketches with HTML5 canvas and applies the same constraint engine used by the 3D CAD application. Its export targets are DWG and SVG. The 3D modeler adds feature history, visual selection and interaction for 3D geometry, and STL export. The README associates STL output with 3D-printing workflows and DWG or SVG output with 2D design.

The documented architecture gives JavaScript and TypeScript responsibility for the sketcher, constraints, parameters, model history, and browser interaction. OpenCascade handles solid modeling operations and booleans on BREP objects. This is a concrete boundary for technical evaluation. The project is not claiming that browser code replaces every component of a native CAD kernel. It uses WebAssembly alongside client-side JavaScript, so deployment depends on the OpenCascade assets and WebAssembly integration included in the web application.

The README does not specify tessellation controls for STL, mesh density settings, geometric tolerance settings, or whether an export is automatically checked for defects. It also does not explain whether DWG export preserves layers, dimensions, blocks, or drawing units. Those details must be verified against the implementation or the linked help documentation before an organization treats either format as an interchangeable substitute for a native CAD exchange workflow.

Project saving is handled through browser local storage. That can fit a client-only demonstration or personal modeling workflow, but the README does not document multi-device synchronization, collaboration, account storage, server backups, storage quotas, or migration of old browser records. Local persistence should therefore be treated as a defined project boundary, not assumed to be a durable backend.

Where direct OpenCascade takes a different approach

A real alternative is to construct and modify BREP geometry directly through OpenCascade. The README explicitly identifies OpenCascade as the component JSketcher uses for solid modeling operations. Direct work with that geometry kernel centers on BREP entities and modeling operations without requiring JSketcher's sketcher, dimension repository, feature-history interface, or browser UI.

The difference is therefore more than a language preference. JSketcher adds a JavaScript and TypeScript 2D solver, an HTML5 canvas sketcher, symbolic dimensions, named constraints, feature history, client-side project storage, and export targets for STL, DWG, and SVG. A direct OpenCascade application instead begins at the solid-modeling layer and leaves those browser-oriented layers to the application developer. JSketcher offers more application structure, while direct kernel access can give an engineer a narrower integration path when the browser modeler itself is unnecessary.

The repository does not include the direct OpenCascade setup commands needed to make that alternative into a comparable tutorial. It also does not document the exact API surface, language bindings, or WASM distribution used by JSketcher. This comparison is limited to the documented architecture: JSketcher wraps or integrates OpenCascade for solid operations while keeping its sketch and history systems around it.

JSketcher licensing and maintenance constraints

The repository is not archived, and its last push was on 2026-04-16. That is the available maintenance fact. The README describes the current application and its features, but the repository history alone does not establish release cadence, compatibility guarantees, or support response times. The most recent listed release is `v1.0.0-dev.1`, dated 2023-05-13, while `package.json` reports version `0.1.0`. That discrepancy should be resolved before an organization pins the package or treats the project as a stable release.

The licensing boundary also requires inspection. `package.json` identifies the license as `SEE LICENSE IN LICENSE`, and GitHub classifies it as a custom licence. The README separately links to commercial licensing information. An organization should read the `LICENSE` file before redistributing bundled code, deploying the application as part of a commercial service, or distributing models and application code built with the project. This review does not interpret the licence or provide legal advice.

The upgrade path is partly visible in repository tooling. `package.json` defines `npm run lint`, `npm run check-code`, `npm run build`, `npm start`, and several Cypress-related commands. The `package-lock.json` can be used to inspect the recorded dependency graph. The README does not document whether upgrades require migrations for browser-stored projects, OpenCascade WebAssembly assets, generated models, or feature-history data. It also does not document rollback. Engineers should inspect `webpack.config.js` and the relevant files under `modules/` and `web/` before changing dependency versions.

JSketcher adoption checks and wrong-fit cases

JSketcher is a credible candidate for an engineer who wants to work on browser-based parametric CAD, extend a JavaScript constraint solver, or connect constrained sketches to a feature-based solid model. Its repository contains application code, tests, build configuration, documentation directories, and development scripts rather than only a narrow geometry package. The absence of a required server-side application is also meaningful for client-only experiments and local modeling workflows.

It is the wrong fit when the decisive requirement is a production-ready installation with documented browser support, persistent collaboration, server backups, or predictable model migration. The README does not document those capabilities. An organization that cannot accept an unclear custom licence should stop before deployment and resolve the `LICENSE` terms. A project that requires proven large-model limits, controlled STL tessellation, or fully specified solver diagnostics needs its own validation because the README does not establish those behaviors.

The first checks should be narrow. Start with `LICENSE`, then inspect `package.json` and `package-lock.json` for version and dependency details. Follow that with `webpack.config.js` to understand how the web application and its assets are assembled. Finally, open a small sample and change one symbolic dimension to see whether the sketch and resulting feature history behave as required. That sequence distinguishes interest in the architecture from evidence that it can support the intended CAD workflow.

Editorial conclusion

JSketcher fits developers who want to extend a browser-based parametric CAD system or build models from constrained sketches without a server-side application. It is a weaker fit for organizations that need a documented production installation path, a clear open-source license classification, or a broad set of confirmed operational examples. Before adoption, inspect the LICENSE file, determine whether Webpack Dev Server and browser local storage meet deployment requirements, and confirm that the supported constraints and export formats cover the intended model workflow. The repository's last push was on 2026-04-16, so its current APIs and operational expectations should be checked against that repository state.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xibyte/jsketcher on GitHub