6 ms·

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 mak

by paxy 9y ago

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.

yodon 9y ago
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.
- andrew_ 9y ago
  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.
  - m_fayer 9y ago
    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.
  - yodon 9y ago
    > 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.
    - mikewhy 9y ago
      I don't think this is cross-platform: Cross Platform? (Closed): https://github.com/NeutroniumCore/Neutronium/issues/14 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=NETFramework&type=&utf8=%E2%9C%93 https://github.com/NeutroniumCore/Neutronium/search?p=1&q=NE...
      - nightski 9y ago
        That's not Electron.NET which is what the parent was referring to.
DDesmaisons 9y ago
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

by paxy 9y ago

yodon 9y ago

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.

andrew_ 9y ago
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.
- m_fayer 9y ago
  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.
- yodon 9y ago
  > 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.
  - mikewhy 9y ago
    I don't think this is cross-platform: Cross Platform? (Closed): https://github.com/NeutroniumCore/Neutronium/issues/14 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=NETFramework&type=&utf8=%E2%9C%93 https://github.com/NeutroniumCore/Neutronium/search?p=1&q=NE...
    - nightski 9y ago
      That's not Electron.NET which is what the parent was referring to.

DDesmaisons 9y ago

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