-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathindex.html
159 lines (90 loc) · 8.88 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>You Might Not Need Electron</title>
<link rel="stylesheet" href="public.css">
</head>
<body>
<a href="/" class="header"><div class="youmightnotneed">You Might Not Need</div> <div class="electron">Electron</div></a>
<main>
<p><a href="https://www.electronjs.org/">Electron</a> 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.</p>
<p>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 <a href="http://offlinefirst.org">offline first</a> applications, many browser based open source solutions exist.</p>
<p>A reason why you may need to use Electron:</p>
<ul>
<li>Direct TCP and UDP networking.</li>
</ul>
<p>A few examples of native-like capabilities available on your browser:</p>
<ol>
<li><a href="#offline">Offline content</a></li>
<li><a href="#database">Persistent client-side data/database</a></li>
<li><a href="#background-sync">Background sync</a></li>
<li><a href="#gamepad">Gamepad API</a></li>
<li><a href="#notifications">Web Notifications API</a></li>
<li><a href="#visibility">Page Visibility API</a></li>
<li><a href="#vibration">Vibration API</a></li>
<li><a href="#battery">Battery status API</a></li>
<li><a href="#bluetooth">Web Bluetooth API</a></li>
<li><a href="#usb">Web USB API</a></li>
<li><a href="#serial">Web Serial API</a></li>
<li><a href="#midi">Web MIDI API</a></li>
<li><a href="#file">File System Access</a></li>
</ol>
<h2 id="offline">1. Offline content</h2>
<p>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 <em>before</em> the first page is served, and thus the service worker can serve any/all content, regardless of anything else. No internet connection required.</p>
<p>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.</p>
<p>Because of the massive security ramifications of creating a persistent interceptor of all requests, you must use HTTPS to install a service worker.</p>
<p>Many different tools exist to allow you to use service workers more easily:</p>
<ul>
<li><a href="https://github.com/GoogleChrome/sw-toolbox">sw-toolbox</a>, built by the Google Chrome team, abstracts the service worker into a more expressive router, more akin to Express.</li>
<li><a href="https://github.com/GoogleChrome/sw-precache">sw-precache</a>, also built by the Google Chrome team, is built for more simple use cases of just caching files for offline use.</li>
<li><a href="https://github.com/NekR/offline-plugin">offline-plugin</a> for Webpack creates a service worker file that caches your files.</li>
</ul>
<p>Support for service workers is very promising, and not too bad currently.<br>You can check browser support at <a href="https://jakearchibald.github.io/isserviceworkerready/">isserviceworkerready</a>.</p>
<h2 id="database">2. Persistent client-side data/database</h2>
<p>You are probably familiar with sessionStorage and localStorage. They're great because of their simplicity, but they're also limited because of that.</p>
<p>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.</p>
<p>Here is a list of solutions, ordered high-level to low-level:</p>
<ul>
<li><a href="http://hood.ie">Hoodie</a> 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.)</li>
<li><a href="https://pouchdb.com">PouchDB</a> 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.</li>
<li><a href="https://localforage.github.io/localForage">localForage</a>, 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.</li>
</ul>
<h2 id="background-sync">3. Background sync</h2>
<p>Background sync is not well supported, but it's trying to solve a hard problem: Deferring actions until the user has stable connectivity.</p>
<p>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!</p>
<p><a href="https://github.com/WICG/BackgroundSync/blob/master/explainer.md">Check out a Background Sync introduction here.</a></p>
<h2 id="gamepad">4. Gamepad API</h2>
<p>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.</p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API">MDN Introduction</a></p>
<h2 id="notifications">5. Web Notifications API</h2>
<p>Web notifications are a great way for a chat application to notify the user of events in a web application.</p>
<p>The most common example is a chat application where the user gets a new message and needs to be notified.</p>
<p>For the best user experience, integrate this API with the <a href="#visibility">Page Visibility API</a> to only send notifications when the chat application is not visible to the user.</p>
<h2 id="visibility">6. Page Visibility API</h2>
<p>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.</p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API">MDN Page Visibility API</a></p>
<h2 id="vibration">7. Vibration API</h2>
<p>The vibration API provides yet another way to get the user's attention upon an event.</p>
<p>Unfortunately, it is being abused by some sites and advertisers.</p>
<h2 id="battery">8. Battery status API</h2>
<p>This API could be useful for reducing usage when the battery is low.</p>
<h2 id="bluetooth">9. Web Bluetooth API</h2>
<p>The Web Bluetooth API provides the ability to connect and interact with Bluetooth Low Energy peripherals.</p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API">MDN Page Web Bluetooth API</a></p>
<h2 id="usb">10. Web USB API</h2>
<p>The USB interface of the WebUSB API provides attributes and methods for finding and connecting USB devices from a web page.</p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/USB">MDN Page Web USB API</a></p>
<h2 id="serial">11. Web Serial API</h2>
<p>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.</p>
<p><a href="https://wicg.github.io/serial/">W3C Specification for Web Serial API</a></p>
<h2 id="midi">12. Web MIDI API</h2>
<p>The MIDIAccess interface of the Web MIDI API provides methods for listing MIDI input and output devices, and obtaining access to those devices.</p>
<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/MIDIAccess">MDN Page Web MIDI API</a></p>
<h2 id="file">13. File System Access</h2>
<p>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.</p>
<p><a href="https://wicg.github.io/file-system-access/">W3C Specification for File System Access</a></p>
</main>
<footer><a href="https://github.com/aeharding">Made by @aeharding</a> — <a href="https://github.com/aeharding/youmightnotneedelectron">Edit on Github</a></footer>
</body>
</html>