Tech Stack Options: Shell Foundation Comparison¶
Source files: -
Architechture & Research/RapidDraft Studio/Architecture/Electron Based.md-Architechture & Research/RapidDraft Studio/Architecture/VS Code Based.mdLast synthesized: March 2026
Overview¶
Two primary shell options have been evaluated for RapidDraft Studio: Electron (standalone desktop application) and VS Code-OSS (open-source Visual Studio Code fork with extension platform). Both options preserve the same backend architecture and deterministic core; they differ only in the IDE/shell layer.
Recommended: Code-OSS fork with private extension platform. This choice balances speed-to-market, long-term maintainability, and extensibility while avoiding shell lock-in.
Option A: Electron-First Approach¶
Architecture¶
Build a standalone Electron application with a custom React UI renderer and a privileged main-process bridge for local app launching and filesystem watching.
Key Components¶
| Layer | Technology | Purpose |
|---|---|---|
| Shell | Electron (Node.js + Chromium) | Desktop application container |
| UI | React | Custom dashboard and workbench |
| Main Process | Node.js | Local process management, file watchers |
| Backend | FastAPI (Python) + existing stack | Orchestration, skills, artifact registry |
| PLM Adapter | Teamcenter middleware | Normalized item/revision/config access |
| Native Tool Bridge | OS-specific (shell commands, file watching) | Launch CATIA/HyperMesh, detect outputs |
Strengths¶
- Complete control over UI/UX without upstream constraints.
- Fast initial development if starting from existing React codebase.
- Direct OS integration for native app launching and filesystem watching.
- No marketplace dependency (no Microsoft or third-party restrictions).
- Familiar stack if team has Electron experience.
Weaknesses¶
- Maintenance burden of desktop app updates (signing, auto-update infrastructure, OS compatibility).
- Code duplication if browser shell is also needed (same UI logic in two renderers).
- Shell lock-in risk: investing heavily in Electron-specific features makes later migration harder.
- Slower to add IDE features that have been battle-tested in VS Code (minimap, command palette, extensions, etc.).
- UX parity challenges between Electron and browser version becomes harder to maintain.
Timeline for Option A (Q1–Q2)¶
| Phase | Duration | Key Deliverables |
|---|---|---|
| Phase 1 | Weeks 1–3 | Orchestration core (Snapshot-Run-Artifact) |
| Phase 2 | Weeks 4–6 | Teamcenter adapter, PLM workspace entry |
| Phase 3 | Weeks 7–9 | Stateful pause/resume intervention loop |
| Phase 4 | Weeks 10–12 | Electron cockpit shell + React UI migration |
| Phase 5 | Weeks 13–16 | DFM skill pack, precision hardening |
| Phase 6 | Weeks 17–24 | Review sessions, release pipeline, PLM writeback |
Option B: VS Code-OSS Fork with Extension Platform (Recommended)¶
Architecture¶
Thin fork of the Code-OSS (Visual Studio Code open-source) codebase. Most product behavior lives in first-party extensions and backend services. The fork patch set is minimal and remains rebasing-compatible with upstream.
Key Components¶
| Layer | Technology | Purpose |
|---|---|---|
| Shell | Code-OSS fork | Lightweight, branded desktop IDE |
| Extension Platform | VS Code Extension Host | Native IDE command, UI, and configuration model |
| RapidDraft Extensions | TypeScript/JavaScript | Workspace browser, workflow runner, CAD viewer, review sessions, AI assistant |
| Private Registry | Custom or Open VSX | Extension distribution (no Microsoft marketplace dependency) |
| Backend | FastAPI (Python) + existing stack | Orchestration, skills, artifact registry |
| PLM Adapter | Teamcenter middleware | Item/revision/config browser, URI scheme providers |
| Translation Service | Commercial SDK | Native format ingestion |
Strengths¶
- No shell lock-in: If extension approach doesn't work, can switch shells (Theia, Zed, VSCodium, full fork) without changing backend contracts.
- Reduced maintenance: Upstream rebases are manageable because product behavior is extensions, not fork patches.
- Battle-tested IDE fundamentals: Command palette, keybindings, settings, terminal, output panels, tree views—already engineered and familiar.
- Extensibility by design: Product grows by adding extensions, not by patching the shell.
- Browser parity simple: Same extensions can run in browser (via Open VSX + web version) for conservative teams.
- Developer familiarity: Anyone who uses VS Code already knows the paradigm.
Weaknesses¶
- Extension API surface constraints: Some advanced UX (custom 3D rendering, deep integration) requires careful webview planning.
- Private registry setup: Must build/host a private extension distribution channel (using Open VSX or custom infrastructure).
- Upstream compatibility requires discipline: patches must stay minimal and tracked as modules so future rebases are predictable.
- Branding limitations: Cannot modify core VS Code behaviors without maintaining divergent patches.
- Larger binary: Code-OSS + dependency set is larger than minimal Electron shell (though still <500MB).
Timeline for Option B (Q1–Q2)¶
| Phase | Duration | Key Deliverables |
|---|---|---|
| Phase 1 | Weeks 1–3 | Code-OSS fork bootstrap, branding, extension gallery wiring |
| Phase 2 | Weeks 4–7 | Extension platform skeleton (commands, URI schemes, tree views) |
| Phase 3 | Weeks 8–11 | Orchestration API promotion to backend contracts |
| Phase 4 | Weeks 12–15 | Commercial CAT translator integration + quality gates |
| Phase 5 | Weeks 16–19 | Teamcenter adapter, PLM-first entry |
| Phase 6 | Weeks 20–23 | AI-native workflow surfaces (assistant, tool calls) |
| Phase 7 | Weeks 24–26 | Stateful external-tool loop, deterministic resume |
Option Comparison: Trade-offs Matrix¶
| Dimension | Electron | Code-OSS | Winner |
|---|---|---|---|
| Time to first ship | Faster (weeks 10–12) | Slower (weeks 24–26) | Electron |
| Maintenance burden | Higher (updates, signing, compat) | Lower (upstream rebases) | Code-OSS |
| Shell lock-in risk | High (product fused to Electron) | Low (extensions are portable) | Code-OSS |
| Long-term scalability | Medium (monolithic shell) | High (modular extensions) | Code-OSS |
| IDE feature velocity | Lower (must build from scratch) | Higher (inherit VS Code features) | Code-OSS |
| Browser parity | Hard (separate codebase) | Easy (same extensions work in web) | Code-OSS |
| Team velocity | Medium (unfamiliar desktop patterns) | Higher (VS Code paradigm is ubiquitous) | Code-OSS |
| Extensibility for customers | Limited (plugin API small) | Large (VS Code extension API) | Code-OSS |
| Marketplace independence | Yes (always) | Yes (private registry only) | Tie |
| Custom 3D viewer complexity | Lower (direct DOM control) | Higher (webview sandboxing) | Electron |
Recommendation: Code-OSS Hybrid Approach¶
Strategic Rationale¶
-
Investor story: "Thin fork of VS Code, radical engineering workflows, private extension platform" is a credible, differentiated pitch (not "we copied VS Code's UI").
-
Engineer adoption: Mechanical engineers familiar with VS Code already know the paradigm; onboarding is easier.
-
Technical debt: Avoiding shell lock-in preserves strategic flexibility. If better IDE foundations emerge, switching is plausible.
-
Maintainability: Keeping patches minimal and tracked means future upstream rebases don't accumulate breaking changes.
-
Hybrid future: Desktop (Code-OSS) + Web (Open VSX + web-compatible extensions) from day one; no separate maintenance nightmare.
-
Extensibility: Customers and partners can eventually write extensions for their own workflows without modifying the core shell.
Implementation Specifics for Code-OSS Path¶
Fork Strategy¶
- Upstream tag: Pin to a specific upstream release (e.g., v1.98.0 released January 2026).
- Patch modules: Track all fork changes as numbered patch files in a
patches/directory. - Rebase cadence: Evaluate upstream quarterly; rebase if security or critical features warrant it.
- Minimal changes: Only modify for branding, extension gallery wiring, and enterprise policy defaults.
Extension Pack Structure¶
- rapiddraft-core: Workspace, run, and artifact management.
- rapiddraft-cad: 3D viewer, custom editor for CAD formats, geometry highlighting.
- rapiddraft-workflows: Workflow canvas, step execution, run timeline.
- rapiddraft-review: Findings panel, geometry-anchored comments, issue lifecycle.
- rapiddraft-ai: AI assistant, tool-driven actions, proposal UI.
- rapiddraft-plm: PLM browser, item/revision picker, URI scheme handlers.
Private Registry¶
- Open VSX approach: Use Open VSX infrastructure (Eclipse Foundation) for private extension hosting.
- Alternative: Self-hosted registry (Verdaccio + custom metadata) if stricter control is needed.
First-Party Extensions as Competitive Advantage¶
All first-party extensions are shipped with the distribution and cannot be disabled. This ensures consistent workflows while allowing customers to add their own extensions on top.
Detailed Comparison Tables¶
Deployment Posture¶
| Aspect | Electron | Code-OSS |
|---|---|---|
| Desktop availability | Yes (native binary) | Yes (native binary) |
| Web availability | Requires separate React build | Yes (web version + same extensions) |
| Auto-update mechanism | Electron auto-updater | Native installer + update channels |
| Signing & notarization | Required (macOS/Windows) | Required (macOS/Windows) |
| Portable/offline install | Yes | Yes |
Feature Development Velocity¶
| Feature Category | Electron | Code-OSS |
|---|---|---|
| Command palette & keyboard shortcuts | Must build from scratch | Inherited, battle-tested |
| Settings/preferences UI | Must build from scratch | Inherited, extensible via JSON schema |
| Keybindings & profiles | Custom implementation | Inherited, standard |
| Source control integration | Must build | Inherited from VS Code |
| Snippet system | Must build | Inherited from VS Code |
| Theme system | Custom CSS | Inherited, standardized |
| Custom 3D viewer | Direct DOM rendering | Webview (more sandboxed, safer) |
| AI assistant | Custom LLM UI | VS Code AI extensibility API (built-in) |
| Multi-workspace support | Must design | Inherited from VS Code |
Recommended Go-Forward Path¶
Start with Code-OSS fork. Rationale:
-
Faster to radically different UX: VS Code's extension model is powerful enough to support the five-surface cockpit (CAD, Review, Workflows, AI, Releases) without monolithic shell changes.
-
Lower long-term cost: Upstream rebases remain manageable; product grows as extensions, not as shell patches.
-
Dual-shell readiness: Desktop IDE + browser classic can both run the same extension pack (via web version).
-
Enterprise realism: Customers with legacy VS Code investments can plug RapidDraft extensions into their existing codebase.
-
Investment safety: If the fork approach hits a blocker, pivoting to Electron or other shells doesn't require abandoning the entire backend and extension architecture.
Next Steps¶
- Evaluate Code-OSS licensing and distribution: Confirm trademark usage, distribution rights, and private registry approach.
- Design extension pack API contracts: Define the surface between shell and extensions (URI schemes, commands, view containers).
- Build one pilot extension: Workspace browser or workflow runner to validate the approach.
- Plan private registry infrastructure: Decide between Open VSX and self-hosted; procurement any needed services.
- Set upstream rebase cadence: Establish a schedule (quarterly) and process for evaluating upstream changes.