Embedded Chromium with the Dart VM (like Electron)

[John Ryan]

Electron is the platform used to create apps like Atom and Slack.  It's most interesting feature is that Electron apps have access to multiple WebKit windows, and can also take advantage of of node.js libraries.  In addition to that, there are also platform-specific APIs for notifications, menu bar, dock etc.  

Here's a list of some Electron apps:

https://github.com/sindresorhus/awesome-electron

And this is a comparison with a similar platform, NW.js:

http://tangiblejs.com/posts/nw-js-electron-compared

So as far I as I can tell, there are currently 3 ways to achieve this:

1. use the chrome package to create a Chrome app https://pub.dartlang.org/packages/chrome

2. use a thin dart wrapper around Electron, i.e.  https://github.com/rwl/electron

3. Fork / rewrite Electron with an embedded Dart VM

I'm curious if anyone else has given thought to this, and if Flutter plans to support Desktop applications.

Cheers! 

-John

[Benjamin Strauß]

https://groups.google.com/a/dartlang.org/forum/#!topic/misc/9NuTuBrGeZI

[Matthew Butler]

Yes, this has come up before. However it's important to note that it is highly unlikely you'll see #3 happen, unless undertaken by someone in the community. The Chromium with the DartVM (Eg: Dartium), is actually being changed to no longer have the Dart VM itself but rather a wrapper around js interop. Maintaining the full VM in Dartium was a significant undertaking, and since there are no longer any plans to provide the VM in the browser at all going forward, and to always be a compile-to javascript language for the client side then it didn't make sense to continue the enormous effort involved with patching Dartium with each new release. 

My thoughts would be #2 if you wanted to specifically target the electron platform. Particularly has the DDC matures it will be much easier for that type of interop to happen, along with the new js interop libraries.

Regarding Flutter, I believe there was an official statement that indicated they had no immediate plans to support Desktop applications, but that it would be potentially possible for community members to implement and get working (possibly with a little help/guidance from the Flutter team) 

[Daniel Danilatos]

+1 was just thinking about electron + dart

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Alan Knight]

Just a minor point - it's not that Dartium is being changed not to have a Dart VM. There's still a Dart VM there, the difference is that the bindings to the DOM are being done via JS Interop rather than via C++ calls.

[Kasper Peulen]

@Alan Knight

Trying to understand, does that mean the the dart:html library will use js interop?

Kasper

[Alan Knight]

Yes. And this is what's shipping now. If you look inside the dart:html library in current Dartium, you'll see code like

  _NamedNodeMap get _attributes => wrap_jso(_blink.BlinkElement.instance.attributes_Getter_(unwrap_jso(this)));

where wrap_jso and unwrap_jso convert between the JsObject and the dart:html representation. We were worried about the performance impact of doing this, but remarkably it's been hardly noticeable. And it both reduces the amount of C++ code we have to maintain enormously and means that we're writing to stable JS APIs rather than internal C++ ones that change frequently.

[John Ryan]

#2 would be the easiest to implement (and maintain!), but it would just be a wrapper around node.js, whereas #3 could use dart:io

[Steven Roose]

So that means that it would still be possible to have something that provides both dart:html and dart:io?

Consider Deuterium to be an Electron fork that instead of 

Electron runs Node.js together with Chromium to create a shell for the app, and this allows Electron to do lower level interactions with the OS in a way normal browsers can’t.

would be

Deuterium runs dart:io together with Dartium to create a shell for the app, and this allows Deuterium to do lower level interactions with the OS in a way normal browsers can’t. 

 

If you see how much effort Google invests in Flutter to make Dart usable for Native Mobile apps by building a platform from the ground up, I guess this would be much less work because most of the groundwork is already there (being Dartium, Dart VM io and Electron).

Being able to use Dart for both server code, web apps, mobile apps and desktop apps, would make it very appealing to developers!

[Benjamin Strauß]

It would be much less work to update Flutter to run on desktop machines. You would also have a rendering pipeline that is way more efficient and saner to program in than the web platform.

The Blink/Webkit architecture is basically 15 years old. I never understood why someone would want to use "clunky" browser engines to build desktop applications. Maybe this will change with Mozilla's servo engine which is a brand new system built for modern hardware.

[Filipe Morgado]

My hope is on Flutter alone.

With configurable imports (being developed, I think), one could maybe target both mobile and the web using the same api, Flutter's, without changing anything in our apps.

A lot of people love HTML/CSS (maybe because they don't know anything else), but it is, IMO, a dinosaur, too big to ignore, but it comes from another era, is clunky, slow and anything but productive, unless you're very experienced.

P.S. Servo is becoming a marvel, but it still runs the dinosaur.

[Joao Pedrosa]

Hi,

The browser has popularized a way of building applications that can be hard to ignore when creating new UI toolkits, so that's why even though new UI toolkits get created, they end up resembling the API pipelines found in the browser. I was a few months ago creating a new UI toolkit and I found myself struggling with the idea of trying to match some of the APIs found in the browser, for example. I watched the beginning of the Flutter presentation video when they talk about the Flutter rendering engine, and I found out that we ended up with some similar approaches to those things. Of course, Flutter was inspired by React which was itself somewhat inspired by the browser... the main difference being that the rendering is more straightforward, but then we may also lack the scripting language (Javascript) that helped to make the browser popular in the first place. So even though we may create new UI toolkits that approach what the browser offers, we may lack the Javascript part of the equation. Also the browser's flexible font rendering can be hard to match with less advanced toolkits.

Cheers,

Joao

[Michael Francis]

Do you have a link to the video you are referencing?

[Benjamin Strauß]

Javascript did not help to make the browser popular. The browser helped to make javascript popular. Nobody cares about javascript because it's a good language.

Flutter has Dart. I don't see how that is a disadvantage over Javascript.

[Joao Pedrosa]

Hi,

It was this one: https://www.youtube.com/watch?v=UUfXWzp0-DU

Cheers,

Joao

[Steven Roose]

It's on the Flutter homepage. I saw it too recently. On my phone right now.

You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/LxeOKqtL4n4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to misc+uns...@dartlang.org.

[Lex Berezhny]

On Tue, May 31, 2016 at 11:51 AM, Joao Pedrosa <joaop...@gmail.com> wrote:

Also the browser's flexible font rendering can be hard to match with less advanced toolkits.

Flutter was born from Chrome sources. I don't know for sure if the font handling code is still the same but if the Flutter team replaced it with something else I expect that they would at least make it as good as or better than the Chrome version.

The GitHub flutter/flutter repo is mostly the Dart source behind Flutter. The Chrome lineage is in a different repo:

https://github.com/flutter/engine

That's where you will find skia, mojo and other C++ libs that are/were shared with Chrome.

 - lex

[kur...@gmail.com]

[Reviving the old thread instead of creating new one]

Were there any progress on Flutter desktop support by the Flutter team or by the community? 

If no, what is the implementation complexity? I am looking for an alternative to Electron framework.

Thanks,

Kurman

--

[Günter Zöchbauer]

I don't know about implementation complexity, desktop just doesn't have enough priority currently to get any resources assigned.

[Lex Berezhny]

To elaborate a bit on what Günter said... There is a Linux desktop unit test runner for Flutter, so being able to compile and run Flutter on Linux is not a problem. The part that's missing is the window dressing to actually show something using your favorite window manager and support mouse/keyboard interaction. Also, which window manager would it use? All of them? Seems like a big community effort.

Someone with Gnome/GTK, KDE/Qt, etc, experience can probably add desktop support as a community project. It just hasn't happened yet.

Relevant code: 

https://github.com/flutter/engine/blob/1fed16fb25f3f7afc8303116d6ef707c4043c127/shell/platform/linux/main_linux.cc#L74

^ You'd have to implement a RunInteractive version of that function :-) And provide all of the mouse/keyboard input  mapping between the window manager and Flutter and also implement a window frame, etc. Seems rather labor intensive (but straight forward?) and then it would need to be maintained to keep up with Flutter changes.

 - lex

[kur...@gmail.com]

Interesting, thank you for the detailed response. What is the approach in Chrom(e|ium) world and how much of it can be re-purposed here? 

As far as my immediate needs, dart2js+Electron looks as more sensible route right now.

Kurman

[Günter Zöchbauer]

dart2js+Electron was reported to work a few times
there is some package on `pub` AFAIR for some abstractions to be able to use APIs not provided by the browser as far as I remember.