Repository navigation
Research bounded Electron migration candidates #313
Copy link
Copy link
Closed
Labels
wayfinder:researchWayfinder research decisionWayfinder research decision
Description
Activity
- addedwayfinder:researchWayfinder research decisionWayfinder research decision
on Sep 26, 2026 0monish commented
on Sep 26, 2026 MemberAuthorMore actionsResearch resolution
Linear already contains the main migration research direction, and current public repository checks are consistent with it.
Existing Linear evidence
- KEL-10 established that compatibility work should be driven by measured real-app API demand rather than broad API-count goals.
- KEL-51 explicitly classifies VS Code as a later stress workload and names draw.io-, Zettlr-, and Element-class apps as more tractable early conversion targets.
- KEL-238 shows the currently implemented Electron lifecycle slice is real but still narrower than a general staged
keld devmigration path. - KEL-237 owns bounded compatibility evidence and must not be replaced by a new scoreboard or broad compatibility claim.
Current public-app check
-
draw.io Desktop — strongest first migration candidate.
- Active Electron desktop project.
- Current package metadata uses Electron 42.x and a relatively small desktop wrapper around an established web application.
- It still exercises real desktop concerns such as Electron store/context-menu/updater integration, so a successful bounded port would be meaningful rather than a toy.
- Public source: https://github.com/jgraph/drawio-desktop
-
Zettlr — strong second candidate.
- Active Electron + Vue application; current package metadata uses Electron 43.x.
- It is a richer local-first desktop workload and is likely to exercise more filesystem/window/menu behavior than the first KELD product spine.
- Better as a follow-on compatibility target after the renderer/native path is live.
- Public source: https://github.com/Zettlr/Zettlr
-
Element Desktop — defer for the first bounded proof.
- The desktop repository is now folded back into Element Web's
apps/desktopstructure and represents a larger collaboration/auth/media/update surface. - Useful later, but it adds more product-specific complexity than is needed to establish the first migration proof.
- Public source: https://github.com/element-hq/element-desktop
- The desktop repository is now folded back into Element Web's
Research conclusion
Use draw.io Desktop as the default first migration candidate, with Zettlr as the next fallback/second workload. Keep Element-class and VS Code-class applications outside the first migration proof.
This is a candidate-selection research result, not permission to begin compatibility implementation. The actual migration scope and allowed adaptations remain owned by the separate Wayfinder decision ticket and must route through existing Linear compatibility owners.
Metadata
Metadata
Assignees
Labels
wayfinder:researchWayfinder research decisionWayfinder research decision
Parent map: https://github.com/gyldlab/keld/issues/311
Question
Which small but legitimate Electron applications or representative workloads can demonstrate meaningful Electron-to-KELD migration within a bounded product slice, given KELD's current lifecycle surface and renderer/native gaps, and what would each candidate prove or fail to prove?