Hmm, just a quick clarification for the first approach. It says that the replay operation may then introduce significant load on the primary node. Is this because when new nodes are added, the logs have to be dumped to the new slave nodes from the beginning, and the IO to do so is expensive, possibly interfering with normal operation of the master node?
I'm glad you like it! I think such an installer feature could be added in by integrating with https://github.com/loopline-systems/electron-builder, I'll see if I have time in the next few days to add this in before school starts.
When I am working on projects, I would often have hundreds of tabs open (figuratively speaking) with reference material and whatnot, and my browser tab bar would end up being a gigantic mess. I just thought it would be handy if I could keep certain web pages that are important (such as Facebook Messenger / Whatsapp etc.) separately from the mess to facilitate easier navigation when switching between windows.
I do agree with you on that, and there should be some form of Chromium that can be shared across applications to reduce the bloat of such packaged apps. Perhaps this is an issue with the architecture of Electron itself, which requires all such apps to contain their own version of Chromium?
I wanted easy cross platform compatibility with minimal code, and Electron seemed like a good choice across for apps across Windows, OSX and Linux.
On OS X, a little Cocoa application in Objective-C using the system WebKit framework would probably do the trick.
On Linux, a little GTK application in C using WebKitGTK would probably work.
On Windows... I don't know. I know from firsthand that embedding the IE engine via the WebBrowser ActiveX control really sucks. I'm going to see if the WebKit WinCairo port is any good these days.
If we must use CHromium, then the Chromium Embedded Framework is worth a look. It's a DLL, so in principle, it can be shared between applications. You'd still need some platform-specific code to create the window containing CEF, though.
All these "little native applications" require lots of work. If I want to share these "little applications" with people that do not share my OS, I am forced to make at least 2 different versions of the "little application"... then maintain them.
Good enough, is good enough. Yes, the web is not as performant as native... the question becomes; is it good enough? The bonus in wrapping Chrome is that I don't have to dive into 3 or more system level API's to get a "little application" up and running.
Cookies are isolated to the app it is built for, and right now the application name is the unique identifier for the app. You're right in that the application data should be segregated, and I'll look into a more robust method of uniquely identifying each app that is built.
Yeap, you can specify different build options such as OS (osx, windows, linux) and processor architecture and pass it to a friend, but the main idea is that it simplifies the process for you and automatically detects your current platform.
Actually, I originally intended this mainly to wrap single page web apps that tend to avoid using the back button and instead providing their own navigational controls on the page itself, so I did not include them in the UI. However, if desired, these basic navigational controls (back, forward, reload etc.) can be found in the application menu.
Thanks for the feedback about the icon issue, I'll take note of that!
Yeah, that was one of the main concerns I had when I was developing this, it would be lovely if the app itself could automatically source and add them in automatically. It's really a hassle to manually add teh images, but I'm not really familiar with how to convert them into the appropriate format in Node.js in a quick and easy way. Will look into this in a future update!
The common tools available to scrape Ajax Web Apps would be PhantomJS and CasperJS. During the process of making a Node.js web app, I wanted to build such a scraper within the Node.js environment itself, but most of the libraries available for Node are simply interfaces to the PhantomJS process on a low level and rather complex for simple scraping needs.
I wanted to be able to tell my headless browser to click elements, fill forms, on an abstracted level like CasperJS, so that scrapers can be built quickly, and hence I built this npm module on top of node-phantom which can be quickly integrated into other node modules.
