กระบวนการเบื้องหลังและตัวทำงาน

Imagine your desktop app freezing when you click a button or perform an action. Frustrating, right?

A responsive UI (User Interface) means your application remains smooth and interactive, even when doing heavy work in the background.

This lesson explores how to offload tasks to keep your Electron app feeling snappy and fast for your users.

In web browsers and Electron's renderer processes, JavaScript typically runs on a single thread. This is often called the main thread.

This thread handles everything: rendering the UI, responding to user input, and running your JavaScript code.

If a long-running computation happens on the main thread, it "blocks" it, making your app unresponsive and causing the UI to freeze.

To avoid freezing the UI, we can use Web Workers. They allow you to run scripts in the background, separate from the main thread.

Think of a Web Worker as a separate JavaScript execution environment that doesn't interfere with your UI.

They are perfect for CPU-intensive tasks that don't need direct access to the webpage's DOM (Document Object Model).

Let's see a simple example of offloading a "heavy" calculation to a Web Worker.

First, you'd create a file named worker.js containing the worker's logic:

Now, in your Electron renderer process (e.g., within your index.html's <script> or a linked renderer.js), you'd use this code:

Try running this example:

Web Workers communicate with the main thread using a simple message-passing system:

• postMessage(): Used by both the main thread and the worker to send data.
• onmessage event handler: Used by both sides to receive data. The data is available in event.data.

Messages are copied, not shared, meaning complex objects are serialized and deserialized. This ensures data integrity between threads.

While powerful, Web Workers have some limitations:

• No DOM Access: Workers cannot directly manipulate the webpage's Document Object Model (HTML elements).
• Limited APIs: They don't have access to some browser APIs like window, document, or parent.
• Local File Access: Direct access to local files (e.g., using Node.js fs module) is not available in a standard Web Worker.

For tasks requiring these, you might need a different approach or to pass data back to the main thread.

Electron's main process, and renderer processes with Node.js integration, can use Node.js Worker Threads.

These are different from Web Workers:

• They have full Node.js API access (e.g., fs, http).
• They can be used in the main process to prevent blocking the *entire* Electron app.
• They are ideal for CPU-bound Node.js tasks.

Worker Threads are crucial when your background tasks need Node.js capabilities.

Here's how you might use a Node.js Worker Thread to perform a heavy computation that also uses a Node.js feature (like reading a file, though we'll simplify for the example).

First, create worker_node.js:

Then, in your main process or a renderer with Node.js integration:

Try running this example:

How do you decide which type of worker to use?

• Web Workers:
  • Best for CPU-bound tasks in the renderer process.
  • Cannot access DOM or Node.js APIs.
  • Good for calculations, data processing that doesn't need system access.
• Node.js Worker Threads:
  • Best for CPU-bound tasks in the main process or renderer process with Node.js integration.
  • Can access all Node.js APIs (e.g., file system, network).
  • Good for heavy Node.js operations without blocking the UI or main app logic.

Great job! You've learned how to keep your Electron applications responsive:

• The main thread handles UI and can be blocked by heavy tasks.
• Web Workers run JavaScript in the background, separate from the UI, for CPU-bound tasks without DOM access.
• Node.js Worker Threads also run in the background but provide full Node.js API access, suitable for main process or Node.js-integrated renderer tasks.

By effectively using these tools, you can build Electron apps that feel fast and smooth!