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.<p>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.
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.<p>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.<p>This has been requested on MS’ UserVoice site. Would love to see it get some love. <a href="https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/18543541-make-edgehtml-layout-engine-open-source" rel="nofollow">https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...</a><p>Also, what I'd love to see would be some sort of UI subsystem that <i>all</i> 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 <i>THE</i> 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.
This reminds me of the project I am currently working on.<p>.NET/QML <a href="https://github.com/pauldotknopf/net-core-qml" rel="nofollow">https://github.com/pauldotknopf/net-core-qml</a><p>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.<p>At a certain point, I will also implement a Qml debugger in visual studio code.
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.
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?<p>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.<p>Maybe I am missing something (and if someone tells me I am missing .NET libs then my response is Edge.js, <a href="https://github.com/tjanczuk/edge" rel="nofollow">https://github.com/tjanczuk/edge</a>).
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...
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.<p>However, this seems to be almost an entire server deploy as well as a complete renderer all in one package. That <i>does</i> seem excessive to me for a desktop app.
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.
What you need is <a href="http://www.lazarus-ide.org/" rel="nofollow">http://www.lazarus-ide.org/</a> for cross, native app development.<p>Here is a list of programs built with Lazarus/FPC: <a href="http://wiki.freepascal.org/Lazarus_Application_Gallery" rel="nofollow">http://wiki.freepascal.org/Lazarus_Application_Gallery</a>
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)?
I'm still looking for something like this that works with Python.<p>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.
I really like that. Re-using the existing Electron platform and <i>not</i> reinventing the wheel and making it usable with .NET underlying is really a good thing.<p>People, XAML is dead. Get over it ;-).