thoughts / proof of concept

about.md

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 or webpack 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
• 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 and process.stdout for things like piping images around?
• will this ever work on a server?

already works on a server :) xvfb-run electron-spawn app.js

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.

What does Natural do that is so sophisticated that can't run on a browser?

A few examples of Node features that won't work in the browser:

• APIs for targeting OS details
• executing child processes like git
• APIs for file system IO (which is breaking Natural)
• bindings for C libraries like freetype or OpenCV

If the browser had full Node.js integration like Electron, even if it was just behind a Chromium switch, everything would "just work" and there would be no need for Electron. (Though it would still be useful for system tray, Save/Open dialog, etc...)

That is probably the best case scenario, but I'm not sure it will happen any time soon.