
Electron.Net: Build cross platform desktop apps using .NET core and ASP.NET core - minaandrawos
https://github.com/ElectronNET/Electron.NET
======
alkonaut
Can't we just make a proper, easy to use portable desktop application
framework please? I really don't care what language is used so log as JS is
avoidable (It can still be a compilation target so it could even be JS), and I
can make a snappy desktop app that takes 10 not 100mb.

I'm not even sure which one I'm hoping for at the moment. Xamarin seems to
have bet fully on mobile. Avalonia looks nice but feels like it would need
some enterprise backing.

~~~
jcelerier
> Can't we just make a proper, easy to use portable desktop application
> framework please?

Qt ticks all your marks (though the "easy" part is through QML which is a
superset of JS), + mobile, (+ one day web maybe [https://msorvig.github.io/qt-
webassembly-examples/window_ope...](https://msorvig.github.io/qt-webassembly-
examples/window_opengl/window_opengl.html) though that's fairly experimental).

~~~
IshKebab
Yeah unfortunately it fails at the "10 MB" bit. Hello world in QML is like 50
MB.

Also you can't statically link the GPL version which is just a bit of a pain.

I agree if it allowed static linking and wasn't huge it would be perfect. Even
so there aren't any better alternatives, but it sucks you can't make something
as small and portable as e.g. putty.exe, or depends.exe.

~~~
jcelerier
Qt is under LGPL which allows static linking:
[https://www.gnu.org/licenses/gpl-
faq.en.html#LGPLStaticVsDyn...](https://www.gnu.org/licenses/gpl-
faq.en.html#LGPLStaticVsDynamic)

This way, you can get under 20 megabytes:
[https://youtu.be/mbs3-XE0HNE?t=1180](https://youtu.be/mbs3-XE0HNE?t=1180)

Sadly I don't think it's possible to have at the same time "portable"
(including to platforms without UIs at all, like DirectFB on linux) and small.
Putty and depends.exe aren't portable at all.

~~~
rlp
LGPL does not allow static linking. From Qt's legal page:

In case of dynamic linking, it is possible, but not mandatory, to keep
application source code proprietary as long as it is “work that uses the
library” – typically achieved via dynamic linking of the library. In case of
static linking of the library, the application itself may no longer be “work
that uses the library” and thus become subject to LGPL. It is recommended to
either link dynamically, or provide the application source code to the user
under LGPL.

~~~
jcelerier
Please read the link I posted, which comes from the people who created the
LGPL license:

> If you statically link against an LGPL'd library, you must also provide your
> application in an object (not necessarily source) format, so that a user has
> the opportunity to modify the library and relink the application

The only thing that matters from the point of view of the LGPL is that your
users are able to update the LGPL parts in your app. This is possible with
static linking. Else for instance how would LGPL be possible with languages
that don't even have a notion of linking (eg script languages), or which only
allow static linking ?

See also :
[https://stackoverflow.com/a/15322678/1495627](https://stackoverflow.com/a/15322678/1495627)

~~~
IshKebab
That's quite an ambiguous area of the LGPL. Qt is a C++ app so linking it with
the `.o` files from your app is going to be extremely difficult. I'm not sure
it would qualify for the LGPL and anyone who says it is is frankly just
guessing. The language is not clear and it has never been tested in court (and
probably won't ever be).

I certainly wouldn't base a business on that risky interpretation, and the one
business that I have been in that used the LGPL version of Qt dynamically
linked it. It's just less risky (plus you don't need to build it yourself
then).

------
lwansbrough
I think this highlights the need for Microsoft to open source Edge’s new
rendering engine. I’d love to be able to use the renderer in .NET Core for a
whole host of applications (including rendering dynamic HTML to OpenGL) but
unfortunately EdgeHTML has remained closed source! With many components of the
.NET stack being open sourced, and even some of the Edge stack, I had high
hopes for seeing the rendering engine open sourced as well too - but no such
luck.

Can anyone on the Edge team comment on this? There would be so many major use
cases for this in .NET. Currently we have to use CEF but I really don’t like
being forced to delegate work to Chrome - it further secures Chrome’s place as
“the only browser”. Not to mention the Edge team would likely receive many
benefits from open sourcing the project in the way of pull requests, even if
this is a little more managerial overhead.

This has been requested on MS’ UserVoice site. Would love to see it get some
love. [https://wpdev.uservoice.com/forums/257854-microsoft-edge-
dev...](https://wpdev.uservoice.com/forums/257854-microsoft-edge-
developer/suggestions/18543541-make-edgehtml-layout-engine-open-source)

Also, what I'd love to see would be some sort of UI subsystem that _all_
vendors target. Something built on a protocol that can be implemented in any
language, and communicated to by any other language. That way all browsers'
HTML renderers would target the same UI subsystem, and any UI framework could
choose to either target HTML or the UI subsystem itself, as well. That UI
framework (if it targets the UI subsystem) could then be run in a different
context (say a JS engine running in .NET) and its output could be routed to a
.NET implementation of the UI subsystem. This would allow any components built
in any language to interface and work together using a common protocol, and as
long as you can host the language a given UI framework is built in, you can
use it to create UI elements in whatever platform you want. I see this as
being _THE_ solution to JS/web/UI stuff - there's tons of amazing developments
happening there, but we can't use them in the desktop world. I'd like to see
that change, and in a way that doesn't require running an entire browser
inside a desktop app.

~~~
manilafolder
Regarding native cross-platform UI frameworks, isn't this what Xwt is supposed
to be ([https://github.com/mono/xwt](https://github.com/mono/xwt))? There's no
XAML non-sense and it's an object-oriented approach to building your UI,
similar to Windows.Forms.

The primary benefit to it over something browser-based is start-up time. Since
it's ultimately using native assemblies and there's no web server that needs
to be spun up causing start-time lag.

Is anyone using Xwt? The NuGet packages for it are up-to-date (but don't have
very many downloads), and the official forum for it seems very dead.

~~~
hacker_9
Not XWT, but it's worth checking out Eto.Forms as it's very robust, uses
native components, and you can build UIs using straight C#.

~~~
LemurMadness
I just spent some time working with Eto.Forms (based upon your recommendation,
thanks!). It looks pretty nice and seems straight-forward. I also appreciate
that it officially supports F# in addition to the regular C# and VB.NET.

Unfortunately, it doesn't support .NET Core/Standard yet. The lead dev, Curtis
Wensley (@cwensley), is currently working on supporting it and said that he
hopes to have to completed in time for the Eto 2.4 release, per their Gitter
chat
([https://gitter.im/picoe/Eto?at=59d65ab4177fb9fe7e41ff9e](https://gitter.im/picoe/Eto?at=59d65ab4177fb9fe7e41ff9e)).

Another interesting detail is that Avalonia seems to be using Eto's parser
implementation. And Eto is (will?) using AvaloniaUI's (the parent of Avalonia)
monomac implementation.

------
pknopf
This reminds me of the project I am currently working on.

.NET/QML [https://github.com/pauldotknopf/net-core-
qml](https://github.com/pauldotknopf/net-core-qml)

Not quite production yet, but it will be soon. I'd love to here some input.
You can check the unit tests for how things are working currently.

At a certain point, I will also implement a Qml debugger in visual studio
code.

~~~
LemurMadness
I really like this approach, particularly since it allows a clean separation
between the responsibilities of designing the UI and writing the back-end
code. The UI designer can still wire up events and design them in Qt Creator
(maybe using placeholder events?) but then the .NET dev can write the back-end
stuff for it.

~~~
pknopf
Exactly.

The tech-stack perfectly slices responsibilities. That is what really
motivated me to do it. Seemed like peanut butter and jelly.

Also, performance. Anything beats electron.

------
roryisok
I was really excited when I saw this because I thought someone had finally
brought us a .net alternative to electron, using xaml. Unfortunately this
seems to be electron but with a .net webapp running in the background? You
still need node and webkit for the UI it seems. If that's what this is, it was
already possible to do with edge.js and electron so I'm not sure what
advantage there is here.

~~~
cm2187
Agree. To me the solution will be webassembly. I entertain the hope that there
will be a .net runtime for webassembly, in which case you will be able to
write a full cross platform application without having to write a line of
JavaScript. Won’t be XAML+.net but will be HTML+.net.

~~~
roryisok
Even web assembly would still require a full webkit / browser instance though.
UWP or WPF apps that run XAML don't have a browser instance (unless they use
webview) and the memory footprint is much much lower than the equivalent
electron app. I'd like to see cross platform xaml so I can build a .net core
app with a GUI that will run on Mac or Linux.

~~~
LemurMadness
It looks like there's two options for cross-platform XAML UIs:

* Prism [1], which doesn't seem to support .NET Core. It was originally created by Microsoft Patterns & Practices, but then open sourced it. It's now community maintained. It looks like it's still being actively developed as there was a merge 4 days ago.

* Avalonia [2], which supports .NET Core but is still in alpha.

[1]
[https://github.com/PrismLibrary/Prism](https://github.com/PrismLibrary/Prism)
[2]
[https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia)

------
FlorianRappl
I don't get this thing. Why do you need to run a webserver an render webpages
when we have more powerful alternatives for cross-platform apps?

Also if you need interactivity you need JS anyway, so you can switch your
server side rendering to client side rendering, thus eliminating the need for
this wrapper anyway.

Maybe I am missing something (and if someone tells me I am missing .NET libs
then my response is Edge.js,
[https://github.com/tjanczuk/edge](https://github.com/tjanczuk/edge)).

------
seanzer
Is this a framework built on top of electron? Is there an ASP.NET server
running in addition to the electron processes? It's just serving pages to the
electron renderer processes, and there's an api bridge over socket IO to
invoke electron methods from .NET-land? ...mindblown...

~~~
seanzer
cool, but unfortunately not what I was expecting

------
kristiandupont
Ok, I normally find myself disagreeing with HN every time Electron comes up.
Basically, I think the upsides are worth the size and performance tradeoffs.

However, this seems to be almost an entire server deploy as well as a complete
renderer all in one package. That _does_ seem excessive to me for a desktop
app.

~~~
shakna
> However, this seems to be almost an entire server deploy as well as a
> complete renderer all in one package. That does seem excessive to me for a
> desktop app.

That's precisely what Electron is. So what's the difference if you're okay
with one?

~~~
kristiandupont
Does this not include node as well as .net core?

~~~
shakna
Electron itself includes node. That's not a difference.

------
moomin
This is amazing and frustrating at the same time. The biggest problems, both
of which are I think unavoidable, are the necessity to be aware of
serialization and the version lock.

~~~
seanzer
keeping up with electron api changes is going to be a nightmare

------
edwinyzh
What you need is [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)
for cross, native app development.

Here is a list of programs built with Lazarus/FPC:
[http://wiki.freepascal.org/Lazarus_Application_Gallery](http://wiki.freepascal.org/Lazarus_Application_Gallery)

~~~
velobro
Why comment at all if you're simply going to ignore the article and advertise
something else?

------
lucaspottersky
so, could somebody make a quick summary of what's currently available for
building desktop apps (self-contained that doesn't require the user to install
a runtime)?

~~~
AlexeyBrin
FreePascal executables. AFAIK, a compiled FreePascal GUI app does not need the
user to install a runtime. I assume Win32 apps also runs on different versions
of Windows without installing a runtime.

------
hacker_9
This is a pretty neat idea, but I see no tests for the code or any sample
usage. Looks like there's still a lot of work to do.

------
amelius
I'm still looking for something like this that works with Python.

Python is huge in numerical libraries (numpy/scipy) and deep learning. But it
is lacking in UIs. Yes, there's PyQt, but Qt is GPL'ed, making it impossible
to use at our shop. And wxPython feels really archaic to use.

------
msoad
Can someone explain what is this? Why someone might need this??

~~~
slowmotiony
I don't think there is currently any easy way to build a GUI app using .NET
Core. This might come in handy for such projects.

~~~
roryisok
I can't find any GUI info here, I'm assuming that you still need to use
html/CSS on top of webkit on top of node.js which then runs .net core in
another process

~~~
seanzer
It just enables you to serve pages from an ASP.NET server running locally. In
the client code, you get access to nodejs apis, in the server code, you can
call electron apis using the api bridge

------
pjmlp
Please use Xamarin.Forms or Avalonia instead.

------
Steveorevo
Why not use GitHub's native Electron? Just remember what Microsoft did to Java
with JNI. Assimilate. Resistance is futile.

~~~
breakingcups
This project doesn't appear to have anything to do with Microsoft other than
the fact that it uses .NET.

Your comment is not only uncalled for, it's also very off-topic.

------
asp_net
I really like that. Re-using the existing Electron platform and _not_
reinventing the wheel and making it usable with .NET underlying is really a
good thing.

People, XAML is dead. Get over it ;-).

