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.
A reason why you may need to use Electron:
- Direct TCP and UDP networking.
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
- Web Bluetooth API
- Web USB API
- Web Serial API
- Web MIDI API
- File System Access
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.
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.
9. Web Bluetooth API
The Web Bluetooth API provides the ability to connect and interact with Bluetooth Low Energy peripherals.
10. Web USB API
The USB interface of the WebUSB API provides attributes and methods for finding and connecting USB devices from a web page.
11. Web Serial API
The Serial API provides a way for websites to read and write from a serial device through script. Such an API would bridge the web and the physical world, by allowing documents to communicate with devices such as microcontrollers, 3D printers, and other serial devices.
W3C Specification for Web Serial API
12. Web MIDI API
The MIDIAccess interface of the Web MIDI API provides methods for listing MIDI input and output devices, and obtaining access to those devices.
13. File System Access
This API enables developers to build powerful apps that interact with other (non-Web) apps on the user’s device via the device’s file system.