The coolest thing about electron is that it blurs the line between "Node" and "Browser." Here is a Node.js module that typically doesn't work in the browser, but runs as expected in Electron:
var natural = require('natural')
console.log(natural.LevenshteinDistance('one', 'one'))
Example output:
It also means that, during development, we can have the full range of Chrome DevTools at our fingertips: debugging, profiling, Network requests, etc.
Maybe this concept could eventually grow into a larger platform like Cinder or Plask. It could be used to build various rich media experiences (art installations, prints, games, etc) that seamlessly integrate libraries like three.js (browser) and node-opencv (node).
A quick proof of concept shows this isn't too far off. The demo reads an image from disk using fs
, processes it using WebGL shaders, and saves the new HTML canvas to a file. It's in "interactive" or development mode (using hihat), so that reloading the source will re-run the program. But the end product would just run once, eg:
shaderize ./original.png --frag ./grayscale.glsl --out foo-gray.png
Other tools could leverage SVG rendering, Speech recognition/synthesization, WebAudio, Canvas2D, GamePad APIs, DeviceMotion, WebRTC, video playback/processing, etc. Or, Electron-specific APIs like taking a screenshot of the page (could be useful for testing purposes).
Some areas that still need to be figured out:
- most use cases of Chrome/Electron are focused on larger GUI apps like Atom, Slack, etc that stay open until the user closes them, and ask for input via GUI (like an Open Dialog)
- getting Chrome/Electron to run "headlessly" is a bit clunky
- using
browserify
orwebpack
rather than Electron's standard node integration is desirable to take advantage of transforms and loaders- these bundlers will not resolve
require('fs')
correctly window.require('fs')
still works, but this is not good since Node.js modules will not work correctly- it can lead to some surprises since both Browserify and Electron are doing some magical things to make your Node.js code work
- these bundlers will not resolve
- how to pass user options/flags to the Electron instance?
- having a better
process
shim:process.argv
,process.cwd()
should work correctly
- should the bundler respect the browser field or not?
- is it possible to handle
process.stdin
andprocess.stdout
for things like piping images around? - will this ever work on a server?
I can't help having the feeling that you're trying to solve a problem created by yourself. So everyone moved code to node.js and couldn't easily run it on the browser -for a multiple variety of reasons-, and now we have to figure out how to bridge the gap created when doing so.
It's what I consistently fail to understand about the node.js ecosystem. You say "Here is a Node.js module that typically doesn't work in the browser". What does Natural do that is so sophisticated that can't run on a browser? I know it's an example, but it illustrates perfectly the point. Your demo example, the only thing stopping it from running on a browser is access to the filesystem.
IMO, ideally we should strive for having the same host and native objects on every JavaScript environment. The big problem right now is direct access to filesystem, although I admit that that's an "old-fashioned" way of thinking, since mobile platforms work a bit differently. But the key aspect of the problem remains, we're limited in the browser for security reasons to very useful things.
Being realistic, I think this is a problem mostly for us, developers; and that users are not that worried about clicking a dialog, selecting a file, running a process, clicking to download. That's barely happening in the world of mobile anymore. To us developers, working constantly with data files and assets, it's a pain and we really want to automate the process.
I think the solution is not Electron, cool as it is, but Chromium/Firefox/etc themselves: allowing a Developer Mode or even better, releasing a Developer Edition with full access to the OS. It would be like running a GUI-enabled node and it would be glorious.