You’ll set up Tailwind in an Electron project, configure your project, style the components, and optimize the development workflow. This is perfect for developers who are looking to combine Tailwind's utility-first CSS framework with Electron's cross-platform capabilities.

Table of Content

• A Quick Overview of Electron

• What is Tailwind CSS?

• Why Electron and Tailwind Work So Well Together

• What We’ll Build?

• Prerequisites

• How to Initialize an Electron Project

• How to Integrate Tailwind CSS with Electron?

• How to Use a Tailwind Component Library – a Practical Example

• Let’s Test FlyonUI JS Components

• Conclusion

A Quick Overview of Electron

Electron is a framework that lets developers create desktop applications for Windows, macOS, and Linux using familiar web technologies like HTML, CSS, and JavaScript, along with Node.js for backend features.

It's open-source, MIT-licensed, and completely free to use – whether you're building personal projects or commercial apps.

In this guide, we’ll look at why so many developers and companies choose Electron for building modern desktop apps.

What is Tailwind CSS?

Tailwind CSS is essentially a utility-first framework for styling web interfaces. Unlike frameworks that provide full-blown, pre-designed UI components, Tailwind offers a comprehensive set of single-purpose utility classes. You apply these classes directly to your HTML elements, which means you can rapidly build out custom layouts and designs without diving into separate CSS files.

The big advantage? Precision and flexibility – you can assemble unique, responsive interfaces by combining these classes however you see fit, all while keeping you markup lean and maintainable.

Why Electron and Tailwind Work So Well Together

Electron uses HTML, CSS, and JavaScript to build desktop applications. Essentially, it runs a web app in a desktop shell. This makes it easy to integrate modern frontend tools like Tailwind CSS.

Tailwind's utility-first approach allows you to style interfaces directly in you HTML, which can speed up UI development. Instead of writing custom styles or managing large CSS files, you apply predefined classes directly to elements. This aligns well with Electron's structure, where layout and styles are tightly connected within the same HTML environment.

Tailwind also provides sensible defaults and a consistent design system out of the box. This helps you prototype and build visually consistent desktop apps faster. While some familiarity with CSS is still helpful, Tailwind's approach can reduce the overhead of setting up and managing styles, especially in smaller or design-light projects.

Together, Electron and Tailwind offer a straightforward path to building desktop apps.

What We’ll Build?

In this tutorial, we will create a basic Electron desktop app styled with Tailwind CSS and improved with FlyonUI components. You don’t need any prior experience with Electron or Tailwind.

By the end of the guide, you'll have:

• A working desktop window (Electron)

• Styled UI with Tailwind CSS

• A reusable button component

• A fully functional modal dialog powered by FlyonUI

This will provide a solid base for building more complex apps in the future.

Prerequisites

Before we dive in, make sure you have the following:

• Basic knowledge of HTML, CSS, and JavaScript. You don’t need to be an expert, but understanding how to structure HTML and use basic JavaScript will help you follow along.

• Familiarity with Node.js and npm. We'll use npm (Node Package Manager) to install dependencies and run build commands.

• Node.js installed on your machine. You can download it from nodejs.org.

• A code editor. I recommend Visual Studio Code.

• Terminal / Command Line Access. You’ll need to run commands in the terminal to set things up.

How to Initialize an Electron Project

Let’s set up a basic Electron app from scratch. This will launch a simple desktop window that loads an HTML file, serving as the foundation for your UI.

1. Create Your Project Folder

First, open your terminal and create a new project folder:

mkdir my-electron-app
cd my-electron-app

This creates a new folder called my-electron-app and changes the directory to it. This folder will be your project workspace.

2. Install Electron

Next, install Electron as a development dependency:

npm install electron --save-dev

This will add Electron to your project’s node_modules and update your package.json file.

This command installs Electron as a development dependency. Electron allows you to build desktop apps across different platforms using web technologies like HTML, CSS, and JavaScript.

3. Configure package.json

Update your package.json to point to a file named main.js, and add a script for easily starting the app.

Edit your package.json like this:

"main": "main.js",
"scripts": {
  "start": "electron ."
}

• "main" defines the entry point of your Electron app (the main process).

• "start" is a shortcut to launch the app using npm start.

4. Create main.js

Create a file named main.js in your root folder and add the following code:

const { app, BrowserWindow } = require("electron/main");

const createWindow = () => {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
  });

  win.loadFile("index.html");
};

app.whenReady().then(() => {
  createWindow();

  app.on("activate", () => {
    if (BrowserWindow.getAllWindows().length === 0) {
      createWindow();
    }
  });
});

app.on("window-all-closed", () => {
  if (process.platform !== "darwin") {
    app.quit();
  }
});

This is your main process. It creates and manages the app window while loading your HTML file.

5. Create index.html (Renderer Process)

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'" />
    <title>Hello from Electron renderer!</title>
  </head>
  <body>
    <h1>Hello from Electron renderer!</h1>
    <p></p>
    <p id="info"></p>
    <script src="./renderer.js"></script>
  </body>
</html>

This is the frontend (renderer) of your Electron app. You can use standard HTML, CSS, and JavaScript here, just like in a browser.

Optional: Create a renderer.js file if you want to add JavaScript interactivity.

6. Run the Electron App

Now, create a file called main.js in the root of your project. This is the main process that starts your Electron app:

npm start

This command runs the app using the script you set up in package.json. A desktop window should open, displaying your HTML content.

How to Integrate Tailwind CSS with Electron?

For this guide, we’ll be using the Tailwind CLI approach.

The Tailwind CLI is a command-line tool that allows you to generate and compile Tailwind utility classes directly into a CSS file. You don’t need complex build tools like Webpack or PostCSS. This makes it perfect for simple projects like Electron apps, where you’d want minimal setup and quick styling. The CLI also has a --watch mode that automatically rebuilds CSS when files change. This feature helps you stay productive.

1. Install Tailwind CSS

First, install Tailwind CSS. Make sure Node.js is installed as well, then run:

npm install tailwindcss @tailwindcss/cli

This command installs Tailwind and its CLI tool as a development dependency in your project. We’ll use the CLI to build and monitor our Tailwind styles.

2. Set Up Tailwind CSS

Create a input.css file with the following content to set up Tailwind:

@import "tailwindcss";

This line instructs Tailwind to generate all its utility classes into one output file, which we’ll compile next.

3. Add a Build Script

Then update your package.json to include a build script:

"scripts": {  
 "watch:css":"npx @tailwindcss/cli -i ./input.css -o ./output.css --watch",
}

This command watches your input.css file and continuously builds a compiled CSS file (output.css) whenever it detects changes. You’ll include this file in your HTML.

4. Link output.css in index.html

Open your index.html file and add this inside the <head>

<link href="./output.css" rel="stylesheet">

Then compile Tailwind CSS with this command:

npm run watch:css

This step includes the compiled Tailwind styles in your Electron app UI.

5. Compile Tailwind CSS

Run this script to start watching for changes and generate your CSS:

npm run watch:css

Keep this process running in a terminal window. It updates output.css live as you work.

6. Update the UI with Tailwind Classes

Replace your <body> content with this example layout:

<body class="flex items-center justify-center h-screen bg-gray-100">
  <button type="button"
    class="py-3 px-4 inline-flex items-center gap-x-2 text-sm font-medium rounded-lg border border-transparent bg-purple-600 text-white hover:bg-purple-700 focus:outline-hidden cursor-pointer focus:bg-purple-700 disabled:opacity-50 disabled:pointer-events-none">
    Hello Tailwindcss
  </button>
</body>

7. Run the Electron App

Run the electron server with this command:

npm start

Your Electron window should now open with a well-styled button in the center, thanks to Tailwind CSS.

How to Use a Tailwind Component Library – a Practical Example

We are going to use FlyonUI, an open source Tailwind component library. It includes a mix of utility classes in addition to JavaScript plugins. FlyonUI draws ideas from daisyUI but also from Preline, and combines flexibility and simplicity. It also helps you build interfaces that respond well and appear consistent.

1. Install FlyonUI

You can install FlyonUI with the command below. Make sure Node.js is installed, then run:

npm install -D flyonui@latest

Installs FlyonUI into your project as a development dependency, making its CSS and JS functionality available for integration.

2. Add FlyonUI as plugin in the input.css:

@import "tailwindcss";
@plugin "flyonui";
@import "./node_modules/flyonui/variants.css"; /* Needed for JS components */
@source "./node_modules/flyonui/dist/index.js"; /* Needed for JS components */

• @plugin "flyonui" injects FlyonUI’s semantic classes into your build.

• The @import includes custom variants created for the JS Components.

• The @source line is required for the classes used in the js gets generated.

3. Include FlyonUI JavaScript for Interactivity

Right before closing the </body> tag in your HTML, include:

<script src="../node_modules/flyonui/flyonui.js"></script>

This script enables the interactive behaviors for FlyonUI components, such as overlays, modals, and dropdowns.

4. Use a FlyonUI Component

For example, update your UI with:

<body class="flex items-center justify-center h-screen bg-gray-100">
  <button type="button" class="btn btn-primary">
    Hello FlyonUI
  </button>
</body>

• The .btn and .btn-primary classes come from FlyonUI—giving you styled, semantic components without crafting custom CSS.

Why It Matters

• Cleaner Code: FlyonUI’s semantic classes make your templates more readable and maintainable compared to verbose utility classes.

• Interactive Without the Overhead: Easily add dynamic features like modals or accordions through FlyonUI’s JS plugins—no need to code them from scratch.

• Effortless Styling: FlyonUI builds on Tailwind’s utility approach, so you can customize components with familiar classes instantly.

Let’s Test FlyonUI JS Components

To show how FlyonUI works, we’ll test one of its JavaScript-powered UI components, the Modal. Modals are common UI elements that grab user attention for alerts, confirmations, or extra information without moving away from the current page.

Why Test the Modal?

Testing the modal helps you:

• Check that FlyonUI’s JavaScript components load and work properly within your Electron and Tailwind setup.

• See how simple it is to add interactive features using FlyonUI’s built-in classes and data attributes.

• Understand how the modal responds to different screen sizes and how the UI reacts to user actions like opening and closing dialogs.

How to Test the Modal

Copy the following example code into your index.html file. This button will open a modal dialog with some placeholder content:

We’ll use this Modal example for testing. Copy the following code in your index.html:

<button type="button" class="btn btn-primary" aria-haspopup="dialog" aria-expanded="false" aria-controls="basic-modal" data-overlay="#basic-modal">Open modal</button>

<div id="basic-modal" class="overlay modal overlay-open:opacity-100 hidden overlay-open:duration-300" role="dialog" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h3 class="modal-title">Dialog Title</h3>
        <button type="button" class="btn btn-text btn-circle btn-sm absolute end-3 top-3" aria-label="Close" data-overlay="#basic-modal">
          <span class="icon-[tabler--x] size-4"></span>
        </button>
      </div>
      <div class="modal-body">
        This is some placeholder content to show the scrolling behavior for modals. Instead of repeating the text in the
        modal, we use an inline style to set a minimum height, thereby extending the length of the overall modal and
        demonstrating the overflow scrolling. When content becomes longer than the height of the viewport, scrolling
        will move the modal as needed.
      </div>
      <div class="modal-footer">
        <button type="button" class="btn btn-soft btn-secondary" data-overlay="#basic-modal">Close</button>
        <button type="button" class="btn btn-primary">Save changes</button>
      </div>
    </div>
  </div>
</div>

After updating the file, restart your Electron app:

npm start

Here’s the result:

Conclusion

You can use Tailwind CSS and Electron to build desktop applications that look good and operate well on different devices. This adds to Electron's many functions and Tailwind's good styling system, letting you stay productive and utilize clean design methods.

The full code and more details are in the repository here: ts-electron-tailwindcss.

I have written this tutorial with the help of Pruthvi Prajapati, an experienced Tailwind CSS developer.

We just published a course on the freeCodeCamp.org YouTube channel that will teach you all about using Electron, React, and TypeScript to build robust desktop applications. Created by Niklas Ziermann, this comprehensive course covers everything from setting up your development environment to implementing advanced features like data visualization, secure communication, and custom window frames. By the end of this course, you'll have the knowledge to create polished, feature-rich desktop apps with Electron, all while writing clean, type-safe code in TypeScript.

The course begins with an introduction to how Electron works, showing you how it integrates with Node.js to create native-like applications. You'll then set up React, followed by Electron, ensuring that your project is ready to handle front-end rendering and system interactions. TypeScript is introduced early in the course, helping you enforce strict types, which leads to fewer errors and a more maintainable codebase. Once your environment is configured, you’ll dive deeper into the inner workings of Electron, setting up Electron-Builder for packaging and distribution, and making developer experience (DX) improvements to streamline your workflow.

From there, the course explores more advanced features, such as reading system resources and securely communicating between your app’s front-end and back-end. You'll also learn about Inter-Process Communication (IPC) and how to make it type-safe, ensuring consistent and secure data transfer. The course even includes sections on data visualization, an important skill for developers building apps that need to display complex information in an easily digestible format.

Additional topics covered in the course include customizing the tray and menu bar, enabling view switching, and creating custom window frames to give your app a unique look and feel. Security is also a major focus, with lessons on securing the app to prevent malicious attacks. To ensure that your application is bug-free, you'll also learn about testing, including end-to-end (E2E) testing and unit testing, which are critical for maintaining high-quality code as your project grows.

If you're looking to take your web development skills to the desktop, this course is the perfect opportunity to learn how to harness Electron, React, and TypeScript. Watch the full course on the freeCodeCamp.org YouTube channel (4-hour watch).

In this article, I'll share how you can avoid some of the mistakes I made when learning about Electron.js ?‍♂️. I hope it helps!

Note: This wont be a coding tutorial, but rather a discussion about my personal takeaways.

A couple of months back, I decided to focus more on building my side product, taggr. I was inspired to build it because of how many photos I have on my computer.

For those of us that keep a backup of their pictures, those collections often get so big and complex that they become a full-time job to manage. A mix of folders and sub-folders may contain instant messaging picture backups, hi-resolution pictures from your trip to Bali, your uncle's wedding, or last-year's bachelor party.

Always keeping such collections tidy is tedious (believe me, I have tried for years). It's also hard to discover the shots that you love the most, hidden deep within the folders.

So taggr is a desktop app that solves that problem. It lets users rediscover their memories while keeping their privacy.

I am building taggr as a cross-platform desktop application. Here I'll share some of the things I've learned about cross-platform app development with Electron.js that I wish I knew from the beginning. Let's get started!

Background

Before presenting my takeaways on this ongoing journey with Electron, I would like to give a little more background about myself and the requirements of taggr.

Every developer comes from a different background, and so do the requirements of the applications they develop.

Contextualizing the choices I made for this project may help future developers select the right tools based on their needs and expertise (rather than what is hyped out there – GitHub ?, I am looking at you).

JavaScript development in a nutshell. Source: [giphy](https://giphy.com/gifs/train-hype-FY2ew2Zii9VOE" rel="noopener).

As mentioned earlier, from the beginning I envisioned taggr as a cross-platform application. The app would perform all the required pre-processing and machine-learning computations client-side due to the focus on privacy.

As a one-person show, I wanted to be able to write my app once and ship it to different systems without losing my sanity.

From my side, I am a front end engineer in love with the web and JavaScript. I previously worked with Java and C#, but I enjoy the flexibility that the web provides and its vibrant ecosystem.

Having experienced first hand the pain of using tools like Eclipse RCP to build client-side apps before, I knew I didn’t want to work with that tech again.

In short, my stack requirements for taggr boiled down to something like the following:

• It should provide cross-platform support, ideally at the framework level. ?
• It should allow me to write the code once, and tweak for each platform if needed. ?️
• It should enable access to machine-learning capabilities, regardless of the host environment, without specific runtimes to be installed. It should be painless to set up. ?
• If feasible, it should use web technologies. It would be great to leverage my existing knowledge. ?

As you can see, the requirements do not read as: I should use React with Redux, observables, and WebSockets. Those are lower-level implementation details, and they should be decided upon when and if the need arises.

Pick the right tool for the job rather than picking a stack from the beginning, disregarding the problems at hand.

So, after furious googling, I decided to give Electron a try. I hadn’t used that framework before, but I knew that many companies were using it successfully in products such as Atom, VS Code, Discord, Signal, Slack and more.

Open-source and with out-of-the-box compatibility with both the the JS and Node ecosystems (Electron is build using Chromium and Node), Electron.js was an attractive tool for the work at hand.

I won't go too much into detail regarding the rest of the stack, as I repeatedly changed core parts (persistence and view layers) when needed, and it falls out of the scope of this article.

However, I would like to mention Tensorflow.js, which enables running training and deploying ML models directly in the browser (with WebGL) and Node (with C bindings), without installing specific runtimes for ML in the host.

So back to Electron – thinking it was perfect, the fun began. ??

Enough talk about the background. Let’s dive into the takeaways.

1. Start small (and slow) ?

This is not a new concept, but it's worth bringing up periodically. Just because there are a ton of awesome starter projects with Electron available, it doesn’t mean that you should pick one right away.

Wait. What?

Slow is smooth, and smooth is fast. — Navy saying

With convenience comes complexity

While those starters include many useful integrations (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), they also have their issues.

As an Electron newbie, I decided to go for a lean template that included the basics for ‘creating, publishing, and installing Electron apps’ without the extra bells and whistles. Not even Webpack in the beginning.

I recommend starting with something similar to electron-forge to get up and running quickly, You can set up your dependency graph and structure on top to learn the ropes of Electron.

When the issues come (and they will), you will be better off if you build your custom starter project rather than picking one with +30 npm scripts and +180 dependencies to begin with.

That said, once you feel comfortable with Electron’s basis, feel free to step up the game with Webpack/React/Redux/TheNextHotFramework. I did it incrementally and when needed. Don’t add a realtime database to your todo app just because you read a cool article about it somewhere.

2. Mindfully structure your app ?‍♂️

This one took a little longer to get right than I am happy to admit. ?

In the beginning, it may be tempting to mix up the UI and Backend code (file access, extended CPU operations), but things get complex quite fast. As my application grew in features, size, and complexity, maintaining one tangled UI+Backend codebase became more complicated and error-prone. Also, the coupling made it hard to test each part in isolation.

When building a desktop app that does more than an embedded webpage (DB access, file access, intensive CPU tasks…), I recommend slicing the app into modules and reducing the coupling. Unit testing becomes a breeze, and there is a clear path towards integration testing between the modules. For taggr, I loosely followed the structure proposed here.

On top of that, there is performance. The requirements and user expectations on this matter may vary wildly depending on the application that you are building. But blocking the main or render threads with expensive calls is never a good idea.

3. Design with the threading model in mind ?

I won’t go too much into detail here – I'm just mainly doubling down on what is awesomely explained in the official docs.

In the specific case of taggr, there are many long-running CPU, GPU, and IO intensive operations. When executing those operations in Electron’s main or renderer thread, the FPS count dips from 60, making the UI feel sluggish.

Electron offers several alternatives to offload those operations from the main and renderer threads, such as WebWorkers, Node Worker Threads, or BrowserWindow instances. Each has its advantages and caveats, and the use case you face will determine which one is the best fit.

Regardless of which alternative you choose for offloading the operations out of the main and renderer threads (when needed), consider how the communication interface will be. It took me a while to come up with a interface I was satisfied with, as it heavily impacts how your application is structured and functions. I found helpfull to experiment with different approaches before picking one.

For example, if you think WebWorkers message passing interface may not be the easiest to debug around, give comlink a try.

Sponge Bob knows best. Source: [giphy](https://giphy.com/embed/jV4wbvtJxdjnMriYmY" rel="noopener)

4. Test ❌, test ❌, and test ✔️

Old news, right? I wanted to add this as the last point, due to a couple of anecdotal ‘issues’ I recently faced. Strongly linked to the first and second points, building your custom starter project and making mistakes early on will save you precious debugging time further in the development.

If you followed my recommendations for splitting the app’s UI and Backend into modules with a clean interface between the two, setting up automated Unit and Integration tests should be easy. As the application matures, you may want to add support for e2e testing too.

GPS location extraction ?️

Two days ago, while implementing the GPS location extraction feature for taggr, once the unit tests were green and the feature worked in development (with Webpack), I decided to try it in the production environment.

While the feature worked well in development, it failed miserably in production. The EXIF information from the pictures was read as binary and processed by a third-party library. While the binary information was correctly loaded in both environments (checked with diff), the third party library failed when parsing such data in the production build. Excuse me, ??

Solution: I found out that the encoding settings in the development and production environments set by Webpack were not the same. This caused the binary data to be parsed as UTF-8 in development but not in production. The issue was fixed by setting up the proper encoding headers in the HTML files loaded by Electron.

Funky pictures ?

When manipulating and working with images, you may think that if a JPEG ‘just-works’ on your computer, it is a valid JPEG. Wrong.

While working with the Node image processing library sharp, resizing some JPEG images crashed the app. After looking closely, the cause was incorrect JPEG images generated by Samsung firmware. ?‍♂️

Solution: setting up improved error boundaries in the app (ex. try-catch blocks), tweak the JPEG parsing module, and suspect of everything. ?️

Summary

The Node and JavaScripts ecosystems are blooming, with many powerful tools being created and shared every day.

The amount of options makes it hard to choose a clear path to start building your new awesome Electron app. Regardless of your frameworks of choice, I would recommend focusing on the following:

1. Start small and add complexity incrementally.
2. Mindfully structure your app, keeping backend, and UI concerns modularized.
3. Design with the threading model in mind, even when building small apps.
4. Test and test again, to catch most of the errors early on and save headaches.

Thanks for sticking around until the end! ?

taggr is a cross-platform desktop application that enables users to rediscover their digital memories while keeping their privacy. Open-alpha is coming soon to Linux, Windows, and Mac OS. So keep an eye on Twitter and Instagram, where I post development updates, upcoming features, and news.

One of the advantages of using Electron is that — since it’s cross-platform — we don’t have to worry about the operating system on which our application is going to be run.

However, sometimes we need our code to be OS-specific if, for example, we are going to be using the command console or need to retrieve some information about the system.

Having to write multiple ifs each time we want to have some functionality on a given OS seems like excess work. It quickly obfuscates the code, making it difficult to be understood and analyzed.

In order to keep the code clean and readable, we can create a little helper and remove the ifs and any “OS-related” logic altogether.

Implementing Platforms

const os = require('os');

const platforms = {
  WINDOWS: 'WINDOWS',
  MAC: 'MAC',
  LINUX: 'LINUX',
  SUN: 'SUN',
  OPENBSD: 'OPENBSD',
  ANDROID: 'ANDROID',
  AIX: 'AIX',
};

const platformsNames = {
  win32: platforms.WINDOWS,
  darwin: platforms.MAC,
  linux: platforms.LINUX,
  sunos: platforms.SUN,
  openbsd: platforms.OPENBSD,
  android: platforms.ANDROID,
  aix: platforms.AIX,
};

const currentPlatform = platformsNames[os.platform()];

const findHandlerOrDefault = (handlerName, dictionary) => {
  const handler = dictionary[handlerName];

  if (handler) {
    return handler;
  }

  if (dictionary.default) {
    return dictionary.default;
  }

  return () => null;
};

const byOS = findHandlerOrDefault.bind(null, currentPlatform);

// usage
const whatIsHeUsing = byOS({
  [MAC]: username => `Hi ${username}! You are using Mac.`,
  [WINDOWS]: username => `Hi ${username}! You are using Windows.`,
  [LINUX]: username => `Hi ${username}! You are using Linux.`,
  default: username => `Hi ${username}! You are using something different.`,
});

console.log(whatIsHeUsing('Maciej Cieslar')); // => Hi Maciej Cieslar! You are using Mac.

First, we see the platforms object which contains names of all supported operating systems. It is made only for convenience. We can then use platforms.WINDOWS instead of typing ‘WINDOWS’ each time into our object with handlers we pass to the byOS function.

Next, notice the platformsNames object. The keys are the result of calling os.platform(). The values are the keys from the platforms object. We simply map it to a more user-friendly name.

For example, when os.platform() returns win32, we map it to platforms.WINDOWS by calling platformsNames[os.platform()].

In currentPlatform, we save the platform that we are using right now, so then we can match it against a given object with handlers.

Implementing Releases

One might go even further and try to differentiate between releases of a given OS, for example, Windows 7, 8 and 10.

const os = require('os');

const releaseTest = {
  [platforms.WINDOWS]: (version) => {
    const [majorVersion, minorVersion] = version.split('.');

    // Windows 10 (10,0)
    if (majorVersion === '10') {
      return releases.WIN10;
    }

    // Windows 8.1 (6,3)
    // Windows 8 (6,2)
    // Windows 7 (6,1)
    if (majorVersion === '6') {
      if (minorVersion === '3' || minorVersion === '2') {
        return releases.WIN8;
      }

      return releases.WIN7;
    }

    return releases.WIN7;
  },
  [platforms.MAC]: () => releases.ANY,
  [platforms.LINUX]: () => releases.ANY,
};

const currentRelease = releaseTest[currentPlatform](os.release());

const byRelease = findHandlerOrDefault.bind(null, currentRelease);

// usage
const whatWindowsIsHeUsing = byOS({
  [WINDOWS]: byRelease({
    [WIN7]: username => `Hi ${username}! You are using Windows 7.`,
    [WIN8]: username => `Hi ${username}! You are using Windows 8.`,
    [WIN10]: username => `Hi ${username}! You are using Windows 10.`,
  }),
});

console.log(whatWindowsIsHeUsing('Maciej Cieslar')); // => Hi Maciej Cieslar! You are using Windows 7.

Now we can use os.release() to check for the system’s release.

We can split the resulting string and check the Windows version. A complete list can be found here. As for Linux/Mac, I didn’t really see how that could be useful, so I left it at releases.ANY.

In whatWindowsIsHeUsing you can see that we are only checking for different Windows’ releases if we are running the app on Windows.

You can see the code in the repository.

Thank you very much for reading! If you have better ideas on how to write OS specific code, share them down below!

If you have any questions or comments feel free to put them in the comment section below or send me a message.

Check out my social media!

Join my newsletter!

Originally published at www.mcieslar.com on August 28, 2018.

No webpack configuration or “ejecting” necessary.

I recently built an Electron app using create-react-app. I didn’t need to muck about with Webpack, or “eject” my app, either. I’ll walk you through how I accomplished this.

I was drawn to the idea of using create-react-app because it hides the webpack configuration details. But my search for existing guides for using Electron and create-react-app together didn’t bear any fruit, so I just dove in and figured it out myself.

If you’re feeling impatient, you can dive right in and look at my code. Here’s the GitHub repo for my app.

Before we get started, let me tell you about Electron and React, and why create-react-app is such a great tool.

Electron and React

React is Facebook’s JavaScript view framework.

A JavaScript library for building user interfaces - React
A JavaScript library for building user interfacesfacebook.github.io

And Electron is GitHub’s framework for building cross-platform desktop apps in JavaScript.

Electron
_Build cross platform desktop apps with JavaScript, HTML, and CSS._electron.atom.io

Most use webpack for the configuration necessary for React development. webpack is a configuration and build tool that most of the React community has adopted over alternatives like Gulp and Grunt.

The configuration overhead varies (more on this later), and there are many boilerplate and application generators available, but in July 2016 Facebook Incubator released a tool, create-react-app. It hides most of the configuration and lets the developer use simple commands, such as npm start and npm run build to run and build their apps.

What is ejecting, and why do you want to avoid it?

create-react-app makes certain assumptions about a typical React setup. If these assumptions aren’t for you, there is an option to eject an application (npm run eject). Ejecting an application copies all the encapsulated configuration of create-react-app to the your project, providing a boilerplate configuration that you can change as you wish.

But this is a one way trip. You can’t undo ejecting and go back. There have been 49 releases (as of this post) of create-react-app, each making improvements. But for an ejected application, you would have to either forgo these improvements or figure out how to apply them.

An ejected configuration is over 550 lines spanning 7 files (as of this post). I don’t understand it all (well, most of it, actually) and I don’t want to.

Goals

My goals are simple:

• avoid ejecting the React app
• minimize glue to get React and Electron working together
• preserve the defaults, assumptions and conventions made by Electron and create-react-app/React. (This can make it easier to use other tools that assume/require such conventions.)

Basic Recipe

1. run create-react-app to generate a basic React application
2. run npm install --save-dev electron
3. add main.js from [electron-quick-start](https://github.com/electron/electron-quick-start) (we’ll rename it to electron-starter.js, for clarity)
4. modify call to mainWindow.loadURL (in electron-starter.js) to use localhost:3000 (webpack-dev-server)
5. add a main entry to package.json for electron-starter.js
6. add a run target to start Electron to package.json
7. npm start followed by npm run electron

Steps 1 and 2 are pretty straightforward. Here’s the code for steps 3 and 4:

const electron = require('electron');
// Module to control application life.
const app = electron.app;
// Module to create native browser window.
const BrowserWindow = electron.BrowserWindow;

const path = require('path');
const url = require('url');

// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
let mainWindow;

function createWindow() {
    // Create the browser window.
    mainWindow = new BrowserWindow({width: 800, height: 600});

    // and load the index.html of the app.
    mainWindow.loadURL('http://localhost:3000');

    // Open the DevTools.
    mainWindow.webContents.openDevTools();

    // Emitted when the window is closed.
    mainWindow.on('closed', function () {
        // Dereference the window object, usually you would store windows
        // in an array if your app supports multi windows, this is the time
        // when you should delete the corresponding element.
        mainWindow = null
    })
}

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.on('ready', createWindow);

// Quit when all windows are closed.
app.on('window-all-closed', function () {
    // On OS X it is common for applications and their menu bar
    // to stay active until the user quits explicitly with Cmd + Q
    if (process.platform !== 'darwin') {
        app.quit()
    }
});

app.on('activate', function () {
    // On OS X it's common to re-create a window in the app when the
    // dock icon is clicked and there are no other windows open.
    if (mainWindow === null) {
        createWindow()
    }
});

// In this file you can include the rest of your app's specific main process
// code. You can also put them in separate files and require them here.

(Gist)

And for steps 5 and 6:

{
  "name": "electron-with-create-react-app",
  "version": "0.1.0",
  "private": true,
  "devDependencies": {
    "electron": "^1.4.14",
    "react-scripts": "0.8.5"
  },
  "dependencies": {
    "react": "^15.4.2",
    "react-dom": "^15.4.2"
  },
  "main": "src/electron-starter.js",
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject",
    "electron": "electron ."
  }
}

(Gist)

When you run the npm commands in step 7, you should see this:

You can make live changes to the React code and you should see them reflected in the running Electron app.

This works okay for development, but has two shortcomings:

• production won’t use webpack-dev-server. It needs to use the static file from building the React project
• (small) nuisance to run both npm commands

Specifying the loadURL in Production and Dev

In development, an environment variable can specify the url for mainWindow.loadURL (in electron-starter.js). If the env var exists, we’ll use it; else we’ll use the production static HTML file.

We’ll add a npm run target (to package.json) as follows:

"electron-dev": "ELECTRON_START_URL=http://localhost:3000 electron ."

Update: Windows users will need to do the following: (thanks to @bfarmilo)

”electron-dev”: "set ELECTRON_START_URL=http://localhost:3000 && electron .”

In electron-starter.js, we’ll modify the mainWindow.loadURL call as follows:

const startUrl = process.env.ELECTRON_START_URL || url.format({
            pathname: path.join(__dirname, '/../build/index.html'),
            protocol: 'file:',
            slashes: true
        });
    mainWindow.loadURL(startUrl);

(Gist)

There is a problem with this: create-react-app (by default) builds an index.html that uses absolute paths. This will fail when loading it in Electron. Thankfully, there is a config option to change this: set a homepage property in package.json. (Facebook documentation on the property is here.)

So we can set this property to the current directory and npm run build will use it as a relative path.

"homepage": "./",

Using Foreman to Manage React and Electron Processes

For convenience, I prefer to not

1. launch/manage both React dev server and Electron processes (I’d rather deal with one)
2. wait for the React dev server to start and then launch Electron

Foremen is a good process management tool. We can add it,

npm install --save-dev foreman

and add the following Procfile

react: npm startelectron: npm run electron

(Gist)

That deals with (1). For (2), we can add a simple node script (electron-wait-react.js) that waits for the React dev server to start, then starts Electron.

const net = require('net');
const port = process.env.PORT ? (process.env.PORT - 100) : 3000;

process.env.ELECTRON_START_URL = `http://localhost:${port}`;

const client = new net.Socket();

let startedElectron = false;
const tryConnection = () => client.connect({port: port}, () => {
        client.end();
        if(!startedElectron) {
            console.log('starting electron');
            startedElectron = true;
            const exec = require('child_process').exec;
            exec('npm run electron');
        }
    }
);

tryConnection();

client.on('error', (error) => {
    setTimeout(tryConnection, 1000);
});

(Gist)

NOTE: Foreman will offset the port number by 100 for processes of different types. (See here.) So, electron-wait-react.js subtracts 100 to set the port number of the React dev server correctly.

Now modify the Procfile

react: npm startelectron: node src/electron-wait-react

(Gist)

Finally, we’ll change the run targets in package.json to replace electron-dev with:

"dev" : "nf start"

And now, we can execute:

npm run dev

UPDATE (1/25/17) : I‘ve added the following section in response to some user comments (here and here). They need access to Electron from within the react app and a simple require or import throws an error. I note one solution below.

Accessing Electron from the React App

An Electron app has two main processes: the Electron host/wrapper and your app. In some cases, you’d like access to Electron from within your application. For example, you might want to access the local file system or use Electron’s [ipcRenderer](http://electron.atom.io/docs/api/ipc-renderer/). But if you do the following, you’ll get an error

const electron = require('electron')
//or
import electron from 'electron';

There is some discussion about this error in various GitHub and Stack Overflow issues, such as this one. Most solutions propose webpack config changes, but this would require ejecting the application.

However, there is a simple workaround/hack.

const electron = window.require('electron');

const electron = window.require('electron');
const fs = electron.remote.require('fs');
const ipcRenderer  = electron.ipcRenderer;

Wrapping Up

For convenience, here is a GitHub repo that has all the changes above, with tags for each step. But, there it isn’t much work to bootstrap an Electron application that uses create-react-app. (This post is much longer than the code and changes you would need to integrate the two.)

And if you are using create-react-app, you might want to check out my post, Debugging tests in WebStorm and create-react-app.

Thanks for reading. You can check out more of my posts at justideas.io

UPDATE (2/2/17). A reader, Carl Vitullo, suggested to use npm start instead of npm run dev and submitted a pull request with the changes, on GitHub. These tweaks are available in this branch.