You Might Not Need
Electron

Electron is a powerful way to access computer resources with web technologies that cannot be accessed through the browser. Unfortunately, it can cause a lot of friction in packaging releases and upgrading clients on different platforms.

You might be surprised about the browser functionality available to create a very close to native experience. Many open source projects make these features easy to use. For offline first applications, many browser based open source solutions exist.

Some reasons why you may need to use Electron:

A few examples of native-like capabilities available on your browser:

  1. Offline content
  2. Persistent client-side data/database
  3. Background sync
  4. Gamepad API
  5. Web Notifications API
  6. Page Visibility API
  7. Vibration API
  8. Battery status API

1. Offline content

Service workers are a way to allow any website to intercept XHR requests and serve any arbitrary content. The first time you load the page, the service worker is installed. The next time you load the page is more interesting: the service worker is activated before the first page is served, and thus the service worker can serve any/all content, regardless of anything else. No internet connection required.

Think of it like an web server sitting between your web page and your server, on the client. It can serve text, binaries -- you name it.

Because of the massive security ramifications of creating a persistent interceptor of all requests, you must use HTTPS to install a service worker.

Many different tools exist to allow you to use service workers more easily:

Support for service workers is very promising, and not too bad currently.
You can check browser support at isserviceworkerready.

2. Persistent client-side data/database

You are probably familiar with sessionStorage and localStorage. They're great because of their simplicity, but they're also limited because of that.

You may have heard of IndexedDB. All you need to know about it is that it is a NoSQL database in the browser. The API is very low level (and pretty bad), so you should not use it directly. Luckily, some very smart people in the open source world have created some wonderful abstractions on top it.

Here is a list of solutions, ordered high-level to low-level:

3. Background sync

Background sync is not well supported, but it's trying to solve a hard problem: Deferring actions until the user has stable connectivity.

Think of a chat application in which the user is offline, send a message, and closes the page. When the user gains internet connectivity, that message will be sent, regardless of if the page is open or not!

Check out a Background Sync introduction here.

4. Gamepad API

For when you need to access user inputs beyond the keyboard, check out the Gamepad API. When you are building an HTML5 game, consider implementing it to make your game seem even more native.

MDN Introduction

5. Web Notifications API

Web notifications are a great way for a chat application to notify the user of events in a web application.

The most common example is a chat application where the user gets a new message and needs to be notified.

For the best user experience, integrate this API with the Page Visibility API to only send notifications when the chat application is not visible to the user.

6. Page Visibility API

The page visibility API can allow for very subtle user experience improvements in your app. Say you are building a chat application that uses the Web Notification API, Vibration API, or plays a sound. With this API, you could only do that when the page is not visible, reducing annoying and unecessary 'pings' when you already have the user's attention.

MDN Page Visibility API

7. Vibration API

The vibration API provides yet another way to get the user's attention upon an event.

Unfortunately, it is being abused by some sites and advertisers.

8. Battery status API

This API could be useful for reducing usage when the battery is low.