Using Electron vs. Offline HTML5 for an offline application - html

When looking up Electron and Offline HTML5, I have found it difficult to make a decision between which one to use for a project.
Assuming that a user will have to go to a certain website to download the Electron application, and would have to go to the same website to get the Offline HTML5 loaded, what are the pros and cons between using one over the other?
Some that I could think of:
Offline HTML5 can be updated without the user consciously updating their application by just making the user go to the online page again.
Electron would eliminate the need to code around multiple browser/browser version dependencies and quirks

It really depends on your exact requirements. The following is a list of everything that I came up with:
electron supports module system (i.e. require) both in main and renderer processes.
electron provides you access to OS APIs (e.g. fs). Without such many node modules will not work in the JS runtime of the browser (e.g. ip).
updating your app with electron is as easy as sending an http request. (or even better as described here)
an HTML 5 offline app requires a browser and the user might just give it IE6.
electron integrates with native desktop environment (see dialog, power-save-blocker, shell or even app for some examples)
electron enhances some of HTML5 APIs such as file API
electron lets you modify the default behavior of underlying chromium. For example you could intercept all URLs with file scheme and modify them on the fly*.
In short if you want your app to have a good native integration and act deterministic (i.e. no browser quirks) I suggest choosing electron.
*electron-jade for example takes use of protocol API to compile all files ending with .jade on the fly without the need to prior compilation.
DISCLAIMER: I am the developer of electron-jade.

Related

How to pass requests from browser to an external application

If you have Steam installed, following links such as steam://link will result in Chrome suggesting to launch Steam:
How can I achieve the same effect for a custom app with a custom handle? Where is this behavior documented?
Are you referring to an external mobile app or an external desktop app?
Here most likely your Steam App supports deep linking via URI Schemes, which is a common flow for being able to open apps from the mobile web.
If you wish to develop an app that supports that, you need to refer to the deep linking documentation for the platform where you develop your app.
Basically deep linking with URI schemes means that the browser tries to redirect to the steam://link scheme, and if there's an installed app which declared that this scheme can open it - deep link occurs.
The scenario to support that really depends on the platform you are targeting.

What cross-browser technology do you use in your web applications to manipulate on client machines?

(I have a problem with Google Chrome improvements that will drop support for my current solutions.)
I work on project where I move desktop system to an Intranet web application.
The crucial requirements are:
to move desktop system to a web application
to reproduce every single functionality from the desktop system in the webapp
While 95% of work requires creating casual web application, there is one thing which is non-standard to handle: my application must perform some actions on the client computer. These includes:
connecting with libraries
launching desktop apps
file manipulation in background
The example scenario is to integrate my system with some machine in the lab. I have to integrate my web application with drivers on client computer via DLL (desktop app did this, so my app have to do this as well).
Theoretically scenarios of the desktop actions may vary and I just want to implement some interface that will handle all the "client-machine" job the desktop app has done, so there is no need to work on every single scenario (but of course every scenario should be tested).
My solution was Java Applet. It worked. But then Google Chrome decided to drop support for NPAPI plugins, so in September'15 Java plugin (and my applet) won't be supported (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html).
So my another solution is Java Web Start. It works. But now Google Chrome decided to drop support for background operations of external protocols (https://code.google.com/p/chromium/issues/detail?id=348640), so from Google Chrome 45 my Java Web Start solution won't be supported.
(Both above solutions work on Firefox and IE.)
The question:
What other technology can I use to interact with a client machine from my web app?
Other remarks:
I am reluctunt to write my own PPAPI plugin or Chrome Extension - I prefer one solution working on all major browsers.
I know that StackOverflow community does not like discussions about technologies, so please focus on describing possible solution to my problem.
We struggled with a similar problem as we need to connect/access electronic devices over JNI->DLL. The only technology where this is currently possible are applets. Period. (And even that is tricky since certain combinations of browsers/java versions/operating systems do not work or have problems, but this is another story...)
There are web technologies like HTLM5, JScript which can replace some functionalities of applets however in certain scenarios (like yours) there is no current alternative available - and you named some of those:
connecting with libraries like *.dll, *.so etc.
file manipulations
launching applications
And doing that across browsers and operating systems!
Solutions?
Tell your users that certain browsers can't be used (like Chrome and
Opera Next)
Write individual plugins for each browser (which probably is beyond your budget ;-)
Did you consider writing standalone application(s) in form of an executable file? The user must download and run it however e.g. java or plugins also need to be installed. But then there is the security aspect of that (downloading an and executing an executable file) - certainly not an easy decision
Have a look at FireBreath 2 - (just read about it in some posts, however didn't try it)
There are lots of discussions on SO to this topic so take a read:
alternative technologies to replace applets
applet alternative launch from browser
alternatives to java applet to launch microsoft office applications
alternative-java-applet-network-drive-access
what are the alternatives for java applet to launch client programs using chrome
alternative of npapi plugins for flash java applet
python alternative to java applet
npapi alternative for live file editing
... and many, many more!

Is it possible to combine chrome extension and chrome native client and distribute them as single unit

I would like to create a new Chrome extension which will be distributed via Chrome store. I also would like to port some code parts of this extension to native code and to use Chrome's native client for it.
So my questions - is it possible to create solution which
comprises of two components - Chrome extension (e.g. can embed content scripts to third party sites like google.com) and native client (e.g. run some native code).
should have these two components be able to interact with each other e.g. via message passing (https://developer.chrome.com/extensions/messaging)
is distributed via Chrome Store as a single unit.
Thanks in advance.
There are two similarly named but quite different technologies.
Native Hosts. Those are separate programs, that cannot be distributed in the Web Store, and talk to your JavaScript with Native Messaging, a variant of standard Messaging API.
Native Client modules (NaCl/PNaCl). Those work like browser plugins, and they can be bundled with the extension.
Note that they are sandboxed from the system - the idea here is performance gain or non-trivial non-HTML UI inside the browser.
Inside your extension, you create an <embed> element that creates an instance of your native code module. JavaScript code can interact with (P)NaCl code with DOM events.
This page contains a guide on using NaCl in Chrome Apps, and mentions that the same applies to extensions. I haven't seen any better documentation, so you'll need to experiment and search around a bit.

Can I make calls to APIs such as youtube-dl and ffmpeg from a chrome-app?

First of all, I haven't started the implementation of the system I'm about to describe, as I didn't want to commit on implementing something I did not know if was possible.
So, what I'm trying to achieve is to build a chrome-app to download the audio from certain websites (e.g. youtube and soundcloud) using youtube-dl, post process it using ffmpeg and then upload it to a cloud service via some api. The reason I want to do it via a chrome-app is because I could do all the work on the client side (no need for servers) and I'd have the ability to insert javascript into the pages using content scripts, which would make the app pretty simple to use (I could create buttons such as 'download song' and stuff like that).
Although I have already read the documentation explaining the NaCl Technical Overview and some of the Application Structure, I still am not sure as to whether I would be able to make these calls via some C/C++ module or if I would get denied due to security reasons.
To summarize: considering that the user has the needed dependencies in his system (youtube-dl, python, ffmpeg and etc.), is it possible to make calls to third party APIs such as the ones described before via a chrome-app using NaCl ?
Thank you all in advance,
Chrome apps are normally sandboxed.
Less so than extensions - they can reach much more system resources via app APIs.
But still, what you mention is executing libraries / utilities out of browser, and it's not normally allowed.
(P)NaCl is tightly sandboxed in this regard. See this old question, it still applies: you can only use 3rd-party code that compiles into NaCl along with your app, not just link to a library. There are some library ports to NaCl, but it's not automatic.
Normally, a few years back you would use a mechanism like NPAPI to reach out and use a library out of browser. It's deprecated, and won't work anymore. In its place, Chrome offers a pipe-like (through stdio) connection to an external program called Native Messaging. You could use it to perform operations with system-level libraries and tools, but the downside is that you can't bundle the native host with your app, you'll need a separate installer.

Embedding The Dart VM In A Desktop Graphical Stand - Alone Application

So I am writing a cross-platform (so far plans for Windows and Ubuntu) application for both the web and desktop.
This application
is expected to at times be moderately graphically intensive and perform a substantial amount of file IO. I am writing it in Dart. Which may seem like a
"funny" choice given the circumstances, however I did not want
to deal with any heavy API's or have two code bases (NaCl and GCC with two different libs).
In short I am using Dart to interact with an HTML web page, and noticed the Dart VM does
not interact with a webpage unless you are in Dartium. But I want a "desktop application" as well as a web application which eliminates Dartium as a choice, so alternately I plan to use a Qt Webview to make it look like a desktop app, but what I am wondering is would it be worth it to go through the trouble of embedding the Dart VM into my app? In doing so would it easily enough to get the Dart VM (running a dart script) to interact with the page in the Qt Webview (I am a bit new to Dart)? Thanks for reading!
Dartium will eventually be merged with Chromium, allowing your DART applications to run inside chrome directly as a web technology.
Once that merges, you can take advantage of the new Chrome Apps which allow you to have a desktop version of your web technologies. As such, you won't need to use Qt Webview, or embed dartVM into your native application; just use Chrome Apps.
~Main