Skip to content

Multi-Threading Architecture

DeskGap starts Node.js in a new thread to keep Node.js from blocking the UI. The node thread runs the entry script and has access to all the Node.js API, but there is no DOM access. A DeskGap app starts one node thread.

JavaScript scripts executed inside the browser window can directly access DOM and manipulate the UI. They are running in a UI thread. Scripts in UI thread have no direct access to Node.js or any native resources just like normal browsers, but unlike browsers, a global object window.deskgap is available to UI scripts.

The node thread and the UI thread are analogous to the main process and the renderer process in Electron.

Communication Between the Node Thread And UI Threads.

DeskGap provides two ways for UI threads to communicate with the node thread:

  • messageUI and messageNode (analogous to Electron’s ipcRenderer and ipcMain) for sending messages.
  • asyncNode (to be documented; analogous to Electron’s remote but in an asynchronous style) for requiring CommonJS modules, invoking methods and accessing properties.

Synchronous And Asynchronous Dispatching

Most UI-related APIs (like constructing a window, or load a html file) in the node thread dispatches an action synchronously to the UI thread. In others words, these APIs are blocking and will wait until the UI thread finishes. The delay may not be noticeable to users but Node.js in DeskGap is not a suitable place for running a web server in the production.

Due to the lack of related functionalities provided by the system’s webview, UI threads do not have any API that synchronously dispatches actions to the node thread. All messages and invocations from UI threads are asynchronous dispatched to the node thread. So things like remote in Electron can never happen.