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.
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
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
Very nice. I have used both WPF/XAML and QML and definitely find QML's model much more intuitive (anchors make things so much easier). Looking forward to trying it out!
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.
Well the point of this project is to allow someone to use .net in the background, although this is already possible with the edge.js project (nothing to do with the edge browser)
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.
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.
DOM interaction and Garbage Collectors are still a heavy research topic within the WebAssembly community, and aren't part of the MVP [1]. Plus MS would need to create a custom C# -> WASM compiler as they don't use LLVM internally. All this means you are probably going to be waiting at least another 5 years before you can compile .Net GUI apps straight to the web.
No doubt you'll find lots of attempts on github, but no business will touch it unless it's an offical compiler with Microsoft's backing, who continue to release updates and provide support for it.
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.
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.
Javascript's not the worst part of Electron (performance/size-wise). HTML+CSS is. See the imperfect, but much better, experience with React Native on mobile.
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...
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.
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.
> This would allow any components built in any language to interface and work together using a common protocol
No it wouldn't? How would a C++ app run my managed control built in C#? Or my JS page run components written in Rust, Java and Clojure? Unless you are expecting all of the runtimes to be bundled with the app/page too, in which case good luck with your file size and startup time...
This is obviously true. That being said, it would enable opportunities for developers to use controls where a bridge can be made. For example, if your C# library can be made into a Windows Runtime component then it could be run by C++, and I'm sure there are other ways of running C# code in C++ as well. JS would obviously be limited - it would be as limited as it ever has been.
It won't be long before one can write Rust or Java or Closure and have it compiled to web assembly. At such time, you'd be able to have your components run alongside JS as I described.
For me, the main thing is that scrolling on a touchpad in Windows feels extremely "off" on Chrome and Firefox, while Edge manages it perfectly. Additionally, Edge has lower power consumption than Chrome.
While this works, it's very limited in terms of HTML feature support. Not something you can give to a web developer and say "here use this to make a JS app."
It was not intended as a glib answer -- can you provide any aspect of the given requirements that are not met by X11? It is an interesting exercise to consider it as an alternative to Electron.
"Not hard to use" was not mentioned, but definitely correlates with popularity. Apple and Microsoft do not target it as a business decision, but X11 is available on both of these platforms with commercial support.
> nobody writes UI code that talks directly to X for obvious reasons
Nor would I expect them to; there are libraries to simplify that. I was pointing out the existence of a cross-platform UI protocol; X11's plight and your immediate visceral rejection provide additional insight into how well an idea like this works out in practice.
The trouble is not in finding a solution that works on desktops for Linux, macOS and Windows -- we have that already 10 times over.
What is needed is a protocol which can be targeted by the average JS UI framework creator. It needs to be fairly light weight, and exist mostly as a layer below any sort of framework. If that's X11, so be it, but I haven't seen it running in a browser before.
One such use case would be a JS library which handles the protocol at a fairly low level, allowing someone to create a custom ReactJS renderer which targets the protocol instead of the DOM. Hook up a protocol receiver in your favourite native language, and now you've got native UI driven by React + JS.
Watching how Microsoft manages this project may give an additional insight into how ideas you are suggesting would fare. (It doesn't seem to be a tire fire or anything from initial impressions.)
I shared it primarily because it is an open-source UI project managed by Microsoft that has to support an "API" that is cross-platform, but it also meets this portion of your original criteria:
> 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
As an aside, I recommend you include some details summarizing reasons for rejecting existing solutions when initiating future discussions so all participants can begin on the same page.
I assume EdgeHTML isn't open source because it isn't fully new like Chakra. For example, the first Edge versions had the same select box rendering bugs as Internet Explorer 11 had.
Regarding native cross-platform UI frameworks, isn't this what Xwt is supposed to be (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.
But one big difference between Xwt and Xamarin Forms is that Xwt supports Linux via GTK (GTK1, GTK2 & GTK3) whereas Xamarin Forms does not.
Xamarin Forms also requires different code for different targets, such as:
// Android
Forms.Init(this, null);
var androidFragment = new MyFormsPage().CreateFragment(this);
// iOS
Forms.Init()
var iosViewController = new MyFormsPage().CreateViewController();
// UWP
Forms.Init(e);
var uwpElement = new MyFormsPage().CreateFrameworkElement();
It's all floating out there right now but maybe by end-of-year ("Q4 2017") there will be something solid. This uncertainty promises enough to keep people like me from evaluating alternatives.
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).
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.
AFAIK, Edge’s rendering engine relies on DirectX 11, Direct2D and DirectWrite. These are huge and depend on other Windows-specific stuff. There are open alternatives (OpenGL/GLES, OpenVG, Pango, Skia, etc.) but these are not as good.
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.
Standard WinForms and/or Java isn't too far off what you're describing if you're willing to install runtimes, but I know that's not what you're looking for and I see your point.
The difficulty is that people used to agree (and at varying times, sue each other) over which metaphors to use. The desktop platforms are growing further apart on this front.
Linux has so much work-in-progress happening at any one time that sustainable fusion is closer than a finished and implemented Wayland. Windows is still pushing a "modern" UI metaphor that no-one can stand. Apple has to my knowledge never shown any interest in what you're proposing at all.
That leaves the option of creating another UI layer on top for the app to sit in, and Electron/HTML5 isn't a terrible fit for that.
Maybe trying to get rolling with LLVM and emscripten to run the Electron logic is your answer, or Typescript if it helps ameliorate some of the JS qualms for you.
"The difficulty is that people used to agree (and at varying times, sue each other) over which metaphors to use"
I think you hit the nail on the head. A UI common library should not provide metaphors but direct access to the renderdable elements, their layout routines, etc. A proper UI library would resemble a modern 3D game engine more by its interface.
The level where UI metaphors step in would be built on top of this basic substrate.
There are oh-so-many projects out there trying to use this pattern but for some reason they've not reached popularity.
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.
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.
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.
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 ?
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).
then when people use the browser they get the same experience as native, not the other way round where people expect a native app and are given a browser masquerading as an app.
But if you use qt you're already cross platform and native. Why force the user to fire up a webkit instance to parse your JavaScript when you could code in python or java?
There's some promising early stage projects in Rust world. They're all building on WebRender (firefox's new renderer), but without the DOM/JavaScript bit.
Isn't delphi procedural just like e.g. Swing/AWT or Windows Forms? (Been a long time since I worked with Delphi).
I think XAML/XUL and similar declarative GUIs are better.
No. (Caveat, last version I used was version 5 from 1999.)
Delphi forms are in one of two formats.
1) Binary serialization of the form data (this is the older versions, pre 4/5)
2) A textual representation.
The code for a Delphi form was pre-XML, but it looked like a set of standard markup. There were resources (Form, Button, Edit, Label - these types of control) and they were laid out in a hierarchical developer readable form in blocks. The form code was streamed to/from the file (the files were embedded as resources in the Eve, and the form was read and re-constituted at runtime as well as design time.) Borland made a massive deal about the "two way editing" one could do to the forms. The developer was able to cut and paste controls, and the controls were cut/copied as straight text, which could be pasted to notepad (for example) IIRC.
The usual problem is that the various cross-platform UI toolkits not only fall into the uncanny valley but also only support one programming language best (in this case, Pascal). Only the incentives of the biggest cross-platform browser vendors align in such a way that they pursue native UI effectively.
"It feels like devs now want to write apps without spending any real effort on them."
I think what people are fed up with, is to spend effort learning the "method du jour" of putting a button on a screen and updating the view on a click.
This is pretty much a solved problem, and has been since MVC was invented in the 70s (not saying it's perfect, but it does the job). So there should be an easy an portable way of doing it for decades now.
QT seems to be the kind of framework, but it's C++ so i won't qualify it as "easy".
It's even worse than that. It makes apps expensive and slower to develop across platforms, makes different version more complicated to maintain and keep in sync, creates more attack surface, etc. And even from a non technical point of view, there is a consistency of experience across platforms point of view. There are very good reasons to have fully cross platform apps that you develop only once.
And in general, I don't think developers are being lazy by going for higher level languages like java, c# or python. Ease of use has a lot of value, particularly if the underlying problem you are trying to solve isn't simple.
The last thing is forward compatibility. If I write an objective-c app, it will only be compatible with apple's platform. Say a new kind of platform appears that takes a significant market share (AR?), there is a lot of value in your app being compatible with this platform without needing even to recompile it, just because the cross platform framework you use will be ported to that platform.
I rather have a portable application that takes advantage of the best features on each platform that it runs, than the minimum common denomitor that is the web.
Ergo developers taking the easy route to the expense of user's overall UI/UX.
Thankfully all web based mobile OSes bombed so far.
I totally agree that html+javascript isn't a good answer to cross platform (for the reasons you mention, and because of javascript's own merits). But the ability to develop an app once and run it on multiple platforms is long overdue. And any effort in that direction is welcome. Having to learn 10 different languages and UI frameworks isn't a solution.
that was my position for the last 7 years about hybrid vs native on mobile. but with the recent slowdown on new features on mobile, i'd say even the common denominator is probably largely sufficient for 99% of the apps.
> _It_ makes apps expensive and slower to develop across platforms
Can you clarify specifically what you mean by _It_ there? Maybe (working backwards up the comment chain...) C++, Qt, MVC, "writing apps without spending any real effort", duplicating "applications across multiple OS and hardware architectures" (my vote for most likely), Xamarin.Forms, "easy to use portable desktop application framework", or something else?
If you use Qt and QML, you can write most (or all) of your application using JavaScript.
I was experimenting a few weeks back, and was able to put together a Hacker News reader app using only JavaScript and QML.
Granted, it was a fairly simple app; but once I knew what I was doing, the QML/JS combo didn't feel any slower to develop with than the React-based web stack I'm familiar with.
> I think what people are fed up with, is to spend effort learning the "method du jour" of putting a button on a screen and updating the view on a click.
The bajillion constantly changing web frameworks says that people are perfectly delighted to spend the effort to learn the "method du jour" to do those things.
You didn't get the memo? You're supposed to jot down some half-formed ideas, pipe that through some cognitive services apis, pipe the results of that into webpack, and run the resulting mess in a docker container. Boom, magic!
It would be nice if GNUstep (http://www.gnustep.org/) received much more attention. GNUstep is a free software implementation of the OpenStep API (which Apple's Cocoa API is based on), and GNUstep is available for *nix and Windows. The OpenStep API has already been shown to be cross platform; back in the days when NeXT, Inc. existed, it sold an implementation of the OpenStep API and development tools for Windows NT called OPENSTEP Enterprise (see http://i.imgur.com/I7VivtO.jpg for a screenshot). After Apple bought NeXT, Apple renamed OPENSTEP Enterprise "Yellow Box for Windows" during their Rhapsody efforts. However, in 1998 Apple's business strategy shifted from maintaining NeXT's cross-platform support for OpenStep to devoting NeXT technology solely to the Mac. This is what killed OpenStep as a cross-platform development technology.
GNUstep could have picked up from where Apple left off in 1998 to be a major contender in cross-platform software development. Indeed; it could have attracted former OpenStep developers who liked the cross-platform nature of the API and were stranded when Apple stopped development of Yellow Box for Windows. But for various reasons GNUstep's development and adoption has been slow, and alternative APIs such as QT and GTK ended up winning out in terms of popularity. But I don't think it's too late to promote GNUstep, especially now when a vocal minority of Mac power users are increasingly becoming discontented with the state of the Mac and are looking for high-quality alternatives.
As an on-and-off Mac developer, I absolutely love Cocoa as a development platform. I did look into using GNUstep as a tool to base a cross-platform version of a Mac app on, but agreed that it just never quite made it. But I'd love that kind of API to be available cross-platform.
I've had good luck so far with Xamarin.Mac + traditional WPF for macOS and Windows respectively, with a PCL containing 90% of the shared code. Xamarin.Mac doesn't seem neglected to me, and the forums are decently active for support.
Xamarin.Mac is the project emcompassing bindings from Cocoa (i.e. native macOS) to Mono/.NET, the interface with Xcode for building Cocoa UIs, and Visual Studio for Mac (previously called Xamarin Studio). Essentially, Xamarin.Mac allows you to build C# applications that run on macOS with native macOS user interface elements. See e.g. https://blog.xamarin.com/your-app-on-66-million-macs-c-sharp...
Xamarin and C# are great, I will use them for the next desktop + mobile project. I was looking at this option for a long time and the acquisition by Microsoft added enough confidence in the future of the stack.
No, it can be used under the LGPL, which is fairly different (eg no problem for proprietary apps). Electron uses Blink which should also be covered under LGPL (eg for instance: https://chromium.googlesource.com/chromium/blink.git/+/maste...) and it's not a problem for anyone.
Swing covers almost every use case (JavaFX as well and has a more modern feel). While people like to complain about Java, it is easy to follow and gets the job done. Other languages are available on the JVM that could also leverage Swing/JavaFX, like Clojure.
The main problem with Avalonia is that it's still in alpha. It looks like a good solution, though, so definitely something to keep an eye on if you're looking for a solution that doesn't require running a web server and render for the UI.
It's starting to look like PWAs will be soon powerful enough for mobile and Windows cross-platform development. I'm somewhat hopeful that maybe we'll finally start to see more PWA APIs and Electron/Electron-esque desktop integration APIs converge.
those guys are making progress
https://github.com/AvaloniaUI/Avalonia
Though I wish they didn't choose xaml/wpf way which is pretty much over engineered imho. React like api would be awesome.
I wish they hadn’t picked GTK+. This brings huge technology stack with it, required a desktop subsystem for no reason, and is focused on the CPU rendering.
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.
All Electron apps do - that is what the Electron framework is: a bundle of Chromium for the front-end and Node for the back-end (where here front/back are UI/internals rather than client/server as they are in an online web application).
> 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?
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.
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).
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)?
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.
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.
137 comments
[ 2.6 ms ] story [ 173 ms ] threadNot quite production yet, but it will be soon.
.NET/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.
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.
Your comment is not only uncalled for, it's also very off-topic.
[1] http://webassembly.org/docs/future-features/
https://github.com/kg/ilwasm/ [2015]
Unfortunately, more proof of concept than anything
* 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 [2] https://github.com/AvaloniaUI/Avalonia
Mac desktop support is in preview (https://blog.xamarin.com/preview-bringing-macos-to-xamarin-f...), and Linux and WPF backends are in development. So ... almost there!
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...
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.
No it wouldn't? How would a C++ app run my managed control built in C#? Or my JS page run components written in Rust, Java and Clojure? Unless you are expecting all of the runtimes to be bundled with the app/page too, in which case good luck with your file size and startup time...
It won't be long before one can write Rust or Java or Closure and have it compiled to web assembly. At such time, you'd be able to have your components run alongside JS as I described.
> Currently we have to use CEF [https://cefsharp.github.io]
https://bitbucket.org/geckofx
What benefits would an open-source Edge provide to developers that the combination of Chrome and Firefox don't already?
PS. 100% managed C# HTML renderer: https://github.com/ArthurHub/HTML-Renderer
[edited]
Thanks! This is a real differentiator.
It it unfortunate that Microsoft does not currently allow hosting of the Edge renderer "by design".
https://stackoverflow.com/questions/31773359/add-new-microso...
While this works, it's very limited in terms of HTML feature support. Not something you can give to a web developer and say "here use this to make a JS app."
Like the X Window System?
"Not hard to use" was not mentioned, but definitely correlates with popularity. Apple and Microsoft do not target it as a business decision, but X11 is available on both of these platforms with commercial support.
> nobody writes UI code that talks directly to X for obvious reasons
Nor would I expect them to; there are libraries to simplify that. I was pointing out the existence of a cross-platform UI protocol; X11's plight and your immediate visceral rejection provide additional insight into how well an idea like this works out in practice.
What is needed is a protocol which can be targeted by the average JS UI framework creator. It needs to be fairly light weight, and exist mostly as a layer below any sort of framework. If that's X11, so be it, but I haven't seen it running in a browser before.
One such use case would be a JS library which handles the protocol at a fairly low level, allowing someone to create a custom ReactJS renderer which targets the protocol instead of the DOM. Hook up a protocol receiver in your favourite native language, and now you've got native UI driven by React + JS.
https://github.com/Microsoft/react-native-windows
Watching how Microsoft manages this project may give an additional insight into how ideas you are suggesting would fare. (It doesn't seem to be a tire fire or anything from initial impressions.)
> 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
(The work has already been done to host React/JavaScript cross-platform alongside .NET: see Edge.js http://tjanczuk.github.io/edge/ previously mentioned elsewhere in this thread. http://www.hanselman.com/blog/ItsJustASoftwareIssueEdgejsBri...)
As an aside, I recommend you include some details summarizing reasons for rejecting existing solutions when initiating future discussions so all participants can begin on the same page.
You're right that X is actually suitable of the use-case as described, though that use-case itself is faulty.
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.
https://blog.xamarin.com/glimpse-future-xamarin-forms-3-0/ (2017May)
But one big difference between Xwt and Xamarin Forms is that Xwt supports Linux via GTK (GTK1, GTK2 & GTK3) whereas Xamarin Forms does not.
Xamarin Forms also requires different code for different targets, such as:
Xamarin Forms Gtk# Backend - https://github.com/xamarin/Xamarin.Forms/pull/1174
It's all floating out there right now but maybe by end-of-year ("Q4 2017") there will be something solid. This uncertainty promises enough to keep people like me from evaluating alternatives.
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).
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.
I don’t think they’ll be useful for anything.
AFAIK, Edge’s rendering engine relies on DirectX 11, Direct2D and DirectWrite. These are huge and depend on other Windows-specific stuff. There are open alternatives (OpenGL/GLES, OpenVG, Pango, Skia, etc.) but these are not as good.
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.
The difficulty is that people used to agree (and at varying times, sue each other) over which metaphors to use. The desktop platforms are growing further apart on this front.
Linux has so much work-in-progress happening at any one time that sustainable fusion is closer than a finished and implemented Wayland. Windows is still pushing a "modern" UI metaphor that no-one can stand. Apple has to my knowledge never shown any interest in what you're proposing at all.
That leaves the option of creating another UI layer on top for the app to sit in, and Electron/HTML5 isn't a terrible fit for that.
Maybe trying to get rolling with LLVM and emscripten to run the Electron logic is your answer, or Typescript if it helps ameliorate some of the JS qualms for you.
I think you hit the nail on the head. A UI common library should not provide metaphors but direct access to the renderdable elements, their layout routines, etc. A proper UI library would resemble a modern 3D game engine more by its interface.
The level where UI metaphors step in would be built on top of this basic substrate.
There are oh-so-many projects out there trying to use this pattern but for some reason they've not reached popularity.
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... though that's fairly experimental).
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.
This way, you can get under 20 megabytes: 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.
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.
> 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
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).
There's always PyQt which works cross platform
100MB/app is in the range of "I am not going to download it" unless I have a damned good reason to. Doubly so for updates...
Calibre (https://ic.tweakimg.net/ext/i/1324631500.jpeg)
Spyder (https://github.com/spyder-ide/spyder)
Orange (https://orange.biolab.si/screenshots/)
QGIS (https://live.osgeo.org/_images/qgis_style.png)
OpenShot (http://www.openshot.org/static/img/gallery/clip-overview.jpg)...
https://kivy.org/#home
We should just go back to Delphi, it was/is one of the best ways of doing GUIs.
Delphi forms are in one of two formats.
1) Binary serialization of the form data (this is the older versions, pre 4/5)
2) A textual representation.
The code for a Delphi form was pre-XML, but it looked like a set of standard markup. There were resources (Form, Button, Edit, Label - these types of control) and they were laid out in a hierarchical developer readable form in blocks. The form code was streamed to/from the file (the files were embedded as resources in the Eve, and the form was read and re-constituted at runtime as well as design time.) Borland made a massive deal about the "two way editing" one could do to the forms. The developer was able to cut and paste controls, and the controls were cut/copied as straight text, which could be pasted to notepad (for example) IIRC.
Recent discussion: Why I use Object Pascal | https://news.ycombinator.com/item?id=15490345 (2017Oct:268points,233comments)
As for the rest, sorry for being so blunt, but it is just not wanting to learn.
We we were writing applications across multiple OS and hardware architectures for ages now.
It is easy, no, as it requires actually putting some effort into a proper architecture and OS/hardware abstractions, but it is surely doable.
It feels like devs now want to write apps without spending any real effort on them.
I think what people are fed up with, is to spend effort learning the "method du jour" of putting a button on a screen and updating the view on a click.
This is pretty much a solved problem, and has been since MVC was invented in the 70s (not saying it's perfect, but it does the job). So there should be an easy an portable way of doing it for decades now.
QT seems to be the kind of framework, but it's C++ so i won't qualify it as "easy".
And in general, I don't think developers are being lazy by going for higher level languages like java, c# or python. Ease of use has a lot of value, particularly if the underlying problem you are trying to solve isn't simple.
The last thing is forward compatibility. If I write an objective-c app, it will only be compatible with apple's platform. Say a new kind of platform appears that takes a significant market share (AR?), there is a lot of value in your app being compatible with this platform without needing even to recompile it, just because the cross platform framework you use will be ported to that platform.
Ergo developers taking the easy route to the expense of user's overall UI/UX.
Thankfully all web based mobile OSes bombed so far.
As consultant and polyglot developer, using C++ and eventually something else for the view isn't a problem at all.
And it doesn't have to be C++, there are other portable native languages to choose from.
Also web developers don't have any issue changing frameworks or languages that compile into JavaScript, almost every month.
Can you clarify specifically what you mean by _It_ there? Maybe (working backwards up the comment chain...) C++, Qt, MVC, "writing apps without spending any real effort", duplicating "applications across multiple OS and hardware architectures" (my vote for most likely), Xamarin.Forms, "easy to use portable desktop application framework", or something else?
http://qmlbook.github.io/en/ch04/index.html
it's really easy
I was experimenting a few weeks back, and was able to put together a Hacker News reader app using only JavaScript and QML.
Granted, it was a fairly simple app; but once I knew what I was doing, the QML/JS combo didn't feel any slower to develop with than the React-based web stack I'm familiar with.
The bajillion constantly changing web frameworks says that people are perfectly delighted to spend the effort to learn the "method du jour" to do those things.
GNUstep could have picked up from where Apple left off in 1998 to be a major contender in cross-platform software development. Indeed; it could have attracted former OpenStep developers who liked the cross-platform nature of the API and were stranded when Apple stopped development of Yellow Box for Windows. But for various reasons GNUstep's development and adoption has been slow, and alternative APIs such as QT and GTK ended up winning out in terms of popularity. But I don't think it's too late to promote GNUstep, especially now when a vocal minority of Mac power users are increasingly becoming discontented with the state of the Mac and are looking for high-quality alternatives.
Original announcement is here, and macOS support was recently added. Language development seems pretty slow, though. http://www.red-lang.org/2016/03/060-red-gui-system.html?m=1
They should have used something like this instead for backend: https://github.com/memononen/nanovg
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.
See https://en.wikipedia.org/wiki/Electron_(software_framework) along with the official docs (though the official docs don't state this construction quite as plainly, it doesn't hide the fact).
This could actually be faster since C# is faster language than Node.
That's precisely what Electron is. So what's the difference if you're okay with one?
People, XAML is dead. Get over it ;-).
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).
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.
Here is a list of programs built with Lazarus/FPC: http://wiki.freepascal.org/Lazarus_Application_Gallery