Understand the process model

An Electron app is not one JavaScript environment.

The main process is the application coordinator. It owns lifecycle, creates windows, calls native APIs, and has Node.js access. If it blocks or crashes, the whole application is affected.

Each BrowserWindow loads web content in a renderer process. The renderer owns DOM events, interface state, and drawing. Treat its input as you would treat input from a web page.

The preload script runs in the renderer process before page code. With context isolation, it has a separate JavaScript world and can expose a narrow API through contextBridge.

Desktop Notes will follow this ownership map:

renderer              preload bridge             main
--------              --------------             ----
form input      →     saveNotes(notes)      →    validate and write file
button click    →     exportNotes()         →    show native save dialog
note list       ←     loadNotes()            ←    read and validate file
new-note event  ←     onNewNote(callback)    ←    native menu click

The arrow is a trust boundary. Values are copied across IPC; the processes do not share ordinary objects or a call stack.

Keep CPU-heavy work out of the main process too. For this small app, file operations are asynchronous and short. Larger computation can move to a utility process or worker rather than freezing every window.

Before implementing a feature, write down which process owns it and why. If the answer is “the renderer because it was convenient,” inspect whether the feature touches the computer or private data.