Skip to content

Research bounded Electron migration candidates #313

Description

@0monish

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?

Activity

  1. self-assigned this
    on Sep 26, 2026
  2. 0monish commented on Sep 26, 2026

    @0monish
    MemberAuthor

    Research 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 dev migration path.
    • KEL-237 owns bounded compatibility evidence and must not be replaced by a new scoreboard or broad compatibility claim.

    Current public-app check

    1. 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
    2. 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
    3. Element Desktop — defer for the first bounded proof.

      • The desktop repository is now folded back into Element Web's apps/desktop structure 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

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions