As an alternate approach for .NET desktop apps, Electron.NET[0] is a variant of Electron that adds a dotnet backend. Build your UI in the HTML/CSS/JS flavor of your choice and then implement the functionality backing that UI in C#.

Electron.NET is relatively new and I just yesterday published what I think is the first boilerplate sample for it (using React/Typescript/MobX) [1] (note: my sample app currently looks terrible because there’s exactly zero CSS applied, I was hoping to get some of that added later this week having gotten the functional details working first. The demo in the Electron.NET repo replicates the stock Electron demo, if you’d like to start your explorations with pretty first).

[0] https://github.com/ElectronNET/Electron.NET

[1] https://github.com/yoDon/Electron.NET-React-Typescript-MobX

Both projects eventually use the Chromium renderer, just with .NET bindings, so all you're doing is introducing a whole new framework dependency in order to make development a bit easier.

While I love the concept (and C#/.NET in general), this is yet another performance hit for end users.

In the case of Neutronium, the framework follows standard MVVM with WPF controls. It can bind same data context as standard wpf component so there is a very smooth learning curve

You don’t have to use Electron if you don’t want to, and end users don’t have to use apps if they don’t like the performance characteristics of the apps. That said, there are a lot of very well liked apps being built very quickly on the the Electron framework, and those of us who like C# can do so even more happily using Electron.NET. So to tl;dr this answer to your comment, yes, it’s 100% about introducing the desired framework dependency to make development easier.

What I don't understand is: If Electron apps can be compiled to be cross-platform out of the box, why use an Electron binding for .NET that makes it inherently locked into Windows (without jumping through fancy hoops for other platforms)? I wrote a lot of Windows-only freeware on .NET over the years, and there's just no reason for it that I can see, if the core component of an app is cross-platform by default.

> Why use an Electron binding for .NET that makes it inherently locked to Windows

You’re a couple years behind on cross platform support in dot net and completely missing the cross platform support in Electron/Electron.NET. Zero hoops to jump. Electron.NET apps just work, out of the the box, on macOS and Linux, in addition to on Windows. Today.

I don't think this is cross-platform:

Cross Platform? (Closed): https://github.com/NeutroniumCore/Neutronium/issues/14

And it looks like all the examples reference .net 4.5, which isn't .net core: https://github.com/NeutroniumCore/Neutronium/search?p=1&q=NE...

That's not Electron.NET which is what the parent was referring to.

Cross-platform capability is not the only possible motivation to use something like this. Personally, it interests me because I don't see WinForms/WPF/UWP as viable, so right now the web stack is the only capable high-level UI toolkit on Windows. On MacOS, you can still get by with native.

For an app I'm working on, I'm exploring the possibility of a shared core in C#, with the UI layer rendered with the web stack on Windows, and with Xamarin.Mac (native binding for .NET) on MacOS.

The discussion two weeks ago was very similar to this one.

Electron.Net: Build cross platform desktop apps using .NET core and ASP.NET core | https://news.ycombinator.com/item?id=15616638

Serious question as a .NET developer...

Why? What's the advantage?

My first thought would be to skip the .NET and just use JavaScript all the way down. Or skip JavaScript and just go .NET all the way down.

Second thought would be to just go typical client-server, which is what I think I'm basically seeing here?

The advantages aren't clear to me.

Microsoft has so mismanaged WPF over the years that most developers want nothing to do with it. That means the dot net world lacks any sort of real UI building capability, forcing us int HTML/CSS/JS front ends (at least until Mono goes live with their WebAssembly port of dot net, at which point we can write our front ends in C# again, hopefully not far into 2018)

Not at all!

I will gladly use Win Forms, WPF or UWP over anything resembling Electron.

I'm dealing with slick and pretty consumer apps.

Getting winforms to be pretty is not reasonable. With WPF, you can get the pretty, and then trying to get it to perform reasonably where no browser would break a sweat will drive you to distraction.

And UWP, well don't get me started. Perpetually half-baked, trying hard to push a design system (whatever they're calling metro these days) that isn't popular, isn't thought through, and is so low in information density that I can't even imagine pulling off Spotify with it. And you end up shackled to the Windows Store, the sandbox, and a mobile-style execution lifecycle.

I have been doing mostly WPF/UWP the last four years and hardly got any performance or L&F complaints.

Yes, sometimes the default template is not the best, but with a bit of game development skills it is quite easy to improve it, all the way down to metal.

With the browser one needs to find the magic browser specific CSS properties incantation, with the hope of having a set of divs accelerated by the browser engine, without any control how it actually happens.

Microsoft's attention seems to be elsewhere.

It is in UWP.

10 years ago everyone was resiting Windows 7, any XP was the best OS on Earth.

Now 10 years later, it is the same song with Windows 10 and Windows 7 as protagonists.

It's hard to beat WinForms for cranking out a quick and easy UI on Windows.

Kind of.

VCL is also quite good, in spite of how things went for Delphi and C++ Builder.

Nothing prevents you to use WPF/UWP with visual designer and code-behind, just like Forms.

Where WPF/UWL loose in simplicity is when you want to start customizing L&F or use the standard DataGrid.

VCL was the best back in the days when I used Delphi 5/6, it's kinda sad if it's still true that VCL is still a front runner after a decade of near stagnation by whoever owned it at any given point.

I'll admit though that the only IDE I've used that I like as much as Delphi 6 is Intellij.

WinForms is essentially “inspired” by VCL, through Anders Hejlsberg I guess. As are some parts of C#. WPF otoh is inspired by corporate brain damage.

> WPF otoh is inspired by corporate brain damage.

Not at all, WPF is like having a monoid in the category of endofunctors for UI programming.

Its concepts of UI Lego style building blocks, with templates, commands, mvvm, multi-binding, storyboards..., might be hard to grasp if one is happy with plain code-behind snippets, but once one gets it, it is quite powerful way to write large scale UIs.

I don't know any of that terminology or category theory in general, but I'd like to assure anyone who cares that you really don't have to to get the elegance and power of WPF. It was a steep learning curve sure, but totally worth it. As far as visual control, elegance, and development-pleasure, I think it far surpasses WinForms, the Android UI toolkit, Cocoa, and the web stack. (Though XAML is annoyingly verbose.)

The only reason I stay away is because of the performance issues, and the opaque ways in which performance degrades.

> WPF is like having a monoid in the category of endofunctors for UI programming.

Takeaway: I will start using WPF right after I get a solid grasp on category theory. That will happen "very soon".

It might be powerful, but if something goes wrong it’s impossible to debug. That alone negates all of its advantages to me. I don’t like magic I can’t debug or see source code for.

>the dot net world lacks any sort of real UI building capability

Off the shelf, yes. But third party providers like Devexpress and Telerik have stepped into that gap and now produce some very polished component suites that sit on top of Winforms. At a cost, of course, and more geared towards the enterprise market.

I've used component suites like these in new .Net desktop products and without fail they're received well.

Under no circumstances would I use WinForms for something I have to release to the public in 2017. It was a great API upon release. It's an awful call today, when DPI scaling and similar "this was written with something past Windows XP in mind" concerns are at the forefront.

And, unlike something like Electron.NET (which I wouldn't use either, because I'm not scared of TypeScript, but whatever, I get the reasoning), you're bolted to Windows and Windows alone. Maybe you have no MacOS users, but most folks would like to have those users. If only because they tend to spend more money on software.

Windows forms was the coolest thing I’d ever seen back in 2002, and it’s still my go to for a little window with a couple buttons, but the HTML/CSS ecosystem has so blown past it in the past 15 years that even built on a terrible foundation (CSS when I want Xaml) and a terrible language (JS when I want C#), HTML/CSS still ends up looking like the right choice to me for anything really sophisticated UI/UX wise.

My main product is largely WinForms and the UI was quick and easy to develop.

The two downsides that stop me using it now are poor high dpi support and lack of decent cross platform support.

High DPI support is available on .NET Framework 4.7.

https://docs.microsoft.com/en-us/dotnet/framework/winforms/h...

EDIT: Typo

That’s 4.7, not 7.

Thanks.

What?!?

.NET is one of the technology stacks with better UI designers.

Except for Anvil, there are hardly any Web tools able to compete with what Blend is capable of.

A lot of developers don't want to write the core (and sometimes complex) business logic in Javascript, and thus this allows writing client applications that take advantage of all the .net framework with strict compile time checking that is better than Typescript.

On the other hand of the coin a lot of developers in the frontend and design related space are experienced with HTML, CSS, and some javascript and therefore it gives the same advantage that Blend gave for WPF, it makes it easy for frontend folks make the application look good while the C# folks can make an application function well.

Yeah, I can't see any reason to do this.

Now that I'm not working in the .NET world anymore, the one thing I really miss is WPF, as soon as I'm touching any html/css. Never had any issue with z-index or something not displaying the same way on another browser because whatever is not supported.

WPF/UWP are a dream compared with jungling HTML, CSS and JavaScript, while trying to keep them behaving the same across all required browser versions.

WPF and Winforms are already well suited for Windows UI. If you want snappy UI: Winforms; If you want cute designer UI: WPF.

I agree with you, why would you want to go to the land were CSS is awesome (https://ih0.redbubble.net/image.30416963.4324/sticker,375x36...). The only reason I see is that you are already proficient in CSS quirks and special cases, I am not sure that it is a good reason.

yodon is correct Microsoft has neglected WPF during the last year, and as the same time the javascript commutity was growing fast and hard. So why Neutronium? 1) There is much more javascript/HTML UI components maintened by the community available. Consider for example fantastic library such as D3.js. 2) MVVM is a great pattern but it can be cumbersome to write binding with converters, etc.. With Neutronium, you can use Vue computed for example and reach the result faster. 3) There is much more HTML/CSS designers than WPF designers.

I wrote a .Net assembly analyser/visualizer: https://github.com/NeutroniumCore/CodeDependencyScanner based on Neutronium and D3.js, sincerelly writing a similar software shoudld be an herculean task.

Avalonia [0] is a cross-platform XAML-like UI library for .NET that supports Windows, Linux, and Mac via their native UI toolkits.

0: http://avaloniaui.net

Isn't this what Electron is for? Why do this?

Is there anything similar for Java and electron?

DotVVM has Electron support. Have you looked at it?

or just like, use Electron and cut out the dependency on .NET

Better yet, use .NET and cut out dependency on Electron.

if the whole point of the lib is to run html/js/css in a desktop-friendly app, you don't need .NET for any of it. yes, I've worked with both and worked with the browser interfaces for .net as far back as 1.0. It's simply not needed.

Don't, please.

=> "or just like, make your application barely maintainable and increase RAM consumption ten/hundred times".

right. like using any browser engine bound to a .net instance doesn't do the same. I'd like my bike shed bright effing magenta, please.