direction and ideas?

[gabrielcsapo]

Setting this issue up as a talking point.

It is possible to run chromium on;

iOS https://blog.chromium.org/2017/01/open-sourcing-chrome-on-ios.html Android https://www.chromium.org/developers/how-tos/android-build-instructions

So porting the electron APIs to work with a mobile version of chromium should be straightforward.

Thoughts on initial beta or alpha versions of this?

Porting the Cocoa stuff should be an easy move to do first since Cocoa is the windows manager for iOS (plus Cocoa Touch)

@vasyl-shumskyi @zeke @shubham2892 @janeasystems @dmikey

adding you guys as I see you are watching this repo

[gabrielcsapo]

@nfischer I saw that you are on the Chrome team, would you know anyone who would be interested in this?

[vasyl-shumskyi]

cool. thanks for adding me.

[gabrielcsapo]

seems like some discussion was started about mobile here https://discuss.atom.io/t/electron-on-ios-android/18223/11

[nfischer]

We don't focus too much on electron over at the chrome team. Building chromium for Android is definitely an option though (although you'll need a powerful machine to compile it yourself). These steps are mostly up to date.

I work closely with the Chrome for Android team, so feel free to ping me with questions and I can direct you to the right docs.

[davidsharp]

I don't see what problem this solves that Cordova doesn't. And by trying to match the existing API, I can only imagine how much of it will work slightly differently/not at all, and the lack of features mobile app developers expect. Having worked with Cordova, I've had to deal with iOS webviews fraught with weird quirks. Maybe Chromium on iOS solves some of this, but I'm struggling to see how this will be much better in this regard.

Cordova has a lot of problems and is in no way a perfect solution (the plugin ecosystem's a mess, for example), but so far I've not seen anything to suggest that this would be a better solution. I've seen much more promise in endeavours such as React Native and NativeScript, relying on JavaScript engines, but completely cutting out the use of webviews for app development.

My main concern, however, is the use of standard Node libraries, which I believe is much more integral to Electron working across multiple platforms than Chromium.

[chrisekelley]

@davidsharp - getting Electron-based applications such as Beaker browser running in Cordova is a focus of mine now. I created cordova-node-plugin recently, which is used in Bunsen browser, our team's attempt at getting Beaker browser functionality working on Android. I'm using a node lib that @mafintosh created for node-on-android. It's early days; Bunsen isn't completely wired up yet to the simple node http server it runs, but the basic plumbing is roughed in.

[gabrielcsapo]

@davidsharp my thoughts on this were to have a discussion on that basis. What is the main advantage of using electron over native GUI libraries like, gtk, cocoa, wpf, etc. My thoughts are that it allows quick prototyping and reuse of code that was used for a web application but has the power of being able to run "natively." I think that same conversation can be said about using electron on mobile. native library support would be tough on iOS, but Android might prove to be a bit little easier.

In my opinion on web views, specifically to your point in iOS, Apple has continuously made them more performant and added support for necessary features that the community has asked for. UIWebView, WKWebView etc

Electron has a low barrier to impact to add extremely useful functionality for the desktop, that might be able to bleed into mobile in some regard.

@davidsharp to continue the conversation, the basis of this repo could simply be adding node support for mobile OS's such as iOS, Android and Window's Phone. Rendering any sort of needed UI could be done in that variants embedded browser of choice.

[nfischer]

adding node support for mobile OS's such as iOS, Android and Window's Phone

Not sure if this matters, but Chrome for iOS uses Safari's JS engine, not V8. This is unlikely to change any time soon.

Chrome for Android uses V8 just like desktop platform.

[gabrielcsapo]

@nfischer yeah that is why my first thought was to port chrom(e|ium)? to those mobile devices because a large use case is just on v8.

I am trying to find documentation on how exactly how native interactions take place like for example how would fs be used on a mobile device (https://github.com/nodejs/node/blob/master/lib/fs.js)

At NodeSummit they were talking about n-api and how cool it would be, seems like that could help for a mobile environment. (/ more cross platform)

• https://github.com/nodejs/nan this could be useful in the case of native module support.
• https://medium.com/the-node-js-collection/n-api-next-generation-node-js-apis-for-native-modules-169af5235b06 (this is promising)

[davidsharp]

I think fs more than anything highlights the fact that this can't simply be a drop-in without making assumptions about other people's apps. Both iOS and Android have specific expectations and permissions in regards to where apps can read from and write to, and whether or not the OS believes it can delete without the app/user's knowledge, it's the nature of sandboxed mobile apps. Mobile apps aren't just developed differently, they play by different rules.

The links you've shared definitely show promise in the direction, but overall I think that simultaneously matching the Electron APIs and Node APIs, without caveats that require developers being aware of dozens of electron-mobile specific issues (most likely leading to changes in the app) is an impossible task. Maybe this is a non-issue, maybe you expect developers to make these changes. As a developer, I expect to have differences between iOS, Android, PC and Mac, and that's something I've had to deal with. I've also had to deal with plenty of 'drop-in' solutions that only add more dependencies and more potential points of value.

My issue is primarily with what your key goal actually is, as such I can't be invested in the idea. Is it for one-to-one parity with Electron for desktop OSes? Or is it a React Native-esque "learn once, write anywhere"? Or is it simply an exercise in building an Electron-inspired Cordova-like while also learning from the mistakes of Cordova?

[arcanosam]

@davidsharp I would like to add and see the comments of everyone about your questions at end, about what option could be the simple path to achieve the goal: electron making mobile apps (android preference)

sorry if I may sound much simplistic, but I think start simple it's the better start...

Thanks for all, love the discussion about.

[kinnalru]

What about running electron in chrooted environmrnet on android(debian ex) with remote access to gui through VNC? Or with virtual x-server xvfb?

[gabrielcsapo]

@davidsharp @arcanosam something simple would be best, edge cases and further comparability would be awesome, but probably not supported until either n-api becomes possible and we can package runtimes for mobile that way.

@kinnalru would be interesting, where would the gui be hosted?

[kinnalru]

I thin in Linux Deploy android app direction: https://play.google.com/store/apps/details?id=ru.meefik.linuxdeploy And using electron as dedicated instance without gui :). But i don't know about chrome, node and electron arm support.

[davidsharp]

@kinnalru, that definitely sounds interesting, but does it solve any problems the electron-mobile project might have? Sounds as if it would create more barriers for both developers and users.

[gabrielcsapo]

@kinnalru I agree with @davidsharp, good idea, might be a different end goal then this project has in mind.

[gabrielcsapo]

Does anyone have an interesting way we can start making this thread into actionable items?

[Ad5001]

Relaunching the discussion (note that I'm not a c++ dev). THink what do you really want to do first. Would electron-mobile be a compiler? A node module having the electron api ported to one of the mobile plarfoms? Or something else?

[gabrielcsapo]

@Ad5001 wonder if it would make sense to have an abstraction of the electron API's and figure out what would be targetable for each mobile operating system?

[davidsharp]

@gabrielcsapo, I think the issue with the Electron API is that while we're talking about hybrid apps in both desktop and mobile cases, a lot of desktop concepts don't match up with mobile concepts. For example, while they both have things like notifications, mobile lacks windows, menu bars and right-click context menus. My worry is that we have this API, that is identical to the Electron API, but behaves in the same way only loosely. This would add a lot more of the burden back onto the dev to relearn something they already know, which makes the concept of matching the Electron API kinda pointless.

That said, maybe if we took aspects of the API– say we have support for clipboard, dialog, notification, powerSaveBlocker, protocol, and any others we could reasonably closely follow without unexpected behaviour– and give no support, or stub out, for ones that make no sense as a whole (BrowserWindow, Menu, etc), we could offer similar alternatives that give mobile-expected behaviours.

[Ad5001]

@davidsharp I think the BrowserWindow would be the most important. Maybe not caring about width and height and make it fit the the device screen. Because IMO without BrowserWindows, electron looses all it's strength. Android webview is based on chrome so it should behave the same as on desktop OSes. But what about iOS Safari webview?

But about the unexepcted behaviors, it's up to the app dev to check theses and adapt his code.

Also a support for shell's openExternal and openItem would be possible with the open with behavior on iOS and Android.

@gabrielcsapo Sounds resonable to me.

[davidsharp]

@Ad5001 Sure, the main BrowserWindow would need some kind of polyfill-type solution, but they're such different beasts that you can't just pretend they're the same because you'll find more differences than similarities.

Really, what are you expecting to be the common use case for it, because multiple windows isn't a thing on mobile as it is on desktop. I've done similar things in Cordova apps, but for external one-off pages, managing multiple pages in an Electron-like way is something I wouldn't encourage, hence why BrowserWindow is not the same as and should not be treated as the same as a mobile implementation of the main window.

[davidsharp]

We should be leveraging Electron's tech and design principles, not crowbarring everything it offers into a different environment. I think specifically supporting some and not all of Electron's APIs is better than pretending to support them all but only half supporting them. Otherwise we're off to a bad start and our goal is a broken product.

How Electron Mobile's BrowserWindow-like should function is up for debate, but I think it's backwards for it to try to replicate Electron.

[gabrielcsapo]

@davidsharp @Ad5001 so the decision to support the api's given by Electron, by either shimming or reducing the functionality of those API's.

Should our first course of action be setting up the repo in terms of contribution guidelines, CoC, etc?

[Ad5001]

@gabrielcsapo Agreed. We shuld also choose a code style and still the original question isn't solved. What do we want to do. A cordova plugin?

[gabrielcsapo]

@Ad5001 I think following the same paradigm as electron, which would build a native package for each deploy environment would make the most sense. Thoughts? If we are going to have the least amount of friction using something like standard will help reduce the amount of code style squabbles that would be introduced.

[davidsharp]

The way I see it, it should be a Node module in a similar vein to Electron, Cordova, React Native, etc.

I also agree with using standard, but specifically for the fact that Electron is already using it.

[dmikey]

Running V8 code would be against Apple's terms. You can run on the JSC though, or run mostly everything through WKWebView's JS bridge, and expose the node api through it. So there would be a little bit of stuff to flesh out if you didn't want to bring in React-Native's (likely the most work done) code.

But you wont be able to run Node/V8 directly (at least not yet) your choices for App Store submission are JSC (electron paradigm) or WKWebKit (nw.js paradigm).

[gabrielcsapo]

@dmikey this is good to know. Would bringing in React Native code seem like overkill? It seems using something that already has cross platform support would be more beneficial then building it from scratch, as for a POC right now.

[davidsharp]

@dmikey, maybe I'm wrong or maybe it's been clarified, but I was under the impression that this was on the case if you're providing a web browser (ie, if we were to display external pages), whereas providing it as a way of rendering your app would be fine. At the very least there's a vague potential loophole.

It's definitely come up as a discussion point around the Cordova community, so there might be some reading around that.

I wonder how much mileage there is in leveraging work from React Native though. However these non-Node/V8 solutions likely loses a number of the gains I imagine we'd hope to achieve.

[orangemocha]

But you wont be able to run Node/V8 directly (at least not yet) your choices for App Store submission are JSC (electron paradigm) or WKWebKit (nw.js paradigm).

You'll be able to run Node-ChakraCore on iOS, which thanks to its interpreter complies with Apple's restrictions. As demoed here.

Android builds with v8 are already available at https://github.com/janeasystems/nodejs-mobile. We are going to publish the iOS build there by the end of this month (September).

[gabrielcsapo]

@orangemocha would you be up to talking about how we can integrate nodejs-mobile with electron ideas?

[orangemocha]

@gabrielcsapo : Sure. I must admit that I don't have much experience with electron, but I think it would be an interesting conversation to have.

[gabrielcsapo]

Is there anyone up to help get some things written down and put in the repo so we can start moving forward?

[Ad5001]

But we still haven't figured out what to use. Maybe nodejs-mobile as @orangemocha suggested?

[gabrielcsapo]

I think if that has the ability to run on iOS, that is half the battle. Android seems to be an easy target.

[TheDiamondYT1]

i just wish i could get V8 to compile on Android 😂

[gabrielcsapo]

@TheDiamondYT1 nodejs-mobile can’t run on android?

[TheDiamondYT1]

Yes it can

[gabrielcsapo]

Does anyone think we should open an issue against electron to petition them to abstract the interface to a external class that we could then use for electron mobile? Something like electron core?

[orangemocha]

FYI, we have made the first full release of Node.js for Mobile Apps (a.k.a. nodejs-mobile), for both Android and iOS, including binary downloads, plugins for React Native and Cordova, and all the source code.

You can read the announcement here.

[Ad5001]

File not found?

[orangemocha]

Apologies. Link updated above ^

[gabrielcsapo]

wow props @orangemocha! This could be a really useful venue to build electron-mobile on top of! What does everyone think?

[miaulightouch]

read the node fork using in electron, it seems no too much differrent. nodejs-mobile? LGTM.

just saying, run interpreter on ios would be very funny. I check both chakracore interpreter and v8 on my mac, interpreter is slower about 10 ~ 30 times than v8.

[damusix]

DO IIIITTT!!!! 💣

[avaer]

I'm interested in working on this, at least for Android.

Several people already have node running quite well on Android (e.g. https://github.com/modulesio/node-android-lib), and Chromium has long been a first class citizen. So what's the blocker for full electron?

[gabrielcsapo]

Anyone have thoughts on https://node-os.com landing on mobile? They have done some really impressive work already.

[qwertyquerty]

So is work going to start on this?

[davidsharp]

I think it's still unclear what Electron Mobile will be, or even what people want it to be. Everyone's excited about getting started, but what is the actual goal here?

Some of the tech shows real promise here, but tying it to the Electron name seems like a misstep. Fundamentally the APIs of Electron serve a different purpose to those necessary for desktop. I don't believe it's advisable to try and build a 1:1 Electron on mobile, but utilising the great work that others are doing to create something that allows Node-based app development as a basis for something similar to Electron, seems like a worthwhile endeavour.