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:
- Low-level APIs, like node-serialport
- Complex filesystem access
A few examples of native-like capabilities available on your browser:
- Offline content
- Persistent client-side data/database
- Background sync
- Gamepad API
- Web Notifications API
- Page Visibility API
- Vibration API
- 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:
- sw-toolbox, built by the Google Chrome team, abstracts the service worker into a more expressive router, more akin to Express.
- sw-precache, also built by the Google Chrome team, is built for more simple use cases of just caching files for offline use.
- offline-plugin for Webpack creates a service worker file that caches your files.
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:
- Hoodie is an opinionated framework to build web applications that work offline out of the box. (They're currently in the middle of building the next major version.)
- PouchDB is a very powerful client-side database that can replicate with CouchDB. It is great because of its browser support. It has adapters for IndexedDB, WebSQL, localStorage, in-memory, and more, which means it can fall back onto the most ideal adapter for the browser. It has a wonderful API and great documentation.
- localForage, built by Mozilla, is a very simple localStorage-esque API with adapters to things like IndexedDB, allowing for better performance that is non-blocking to the UI.
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.
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.