Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming.
And no, I would rather not have an interpreted (or dynamic) language if I can help it.
Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.
Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions.
I feel that there's a catch-22 somewhere here :)
So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink.
Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.
But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input?
The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5).
Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.
Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.
They're supposed to. They're fitting in with the OS's native look and feel. And that's a GOOD THING.
So, by the logic of making your complements a commodity, what is FogCreek trying to make a commodity of with Glitch? Are they trying to make "building apps" (and thus "getting into programming") a commodity so they get more users to StackOverflow?
Also, does anyone have any good material to suggest on this topic? I'd like to learn more about it and learn how to be able to recognize the things for what they are: complements or products.
Well but then there's a big missed opportunity there, isn't it? I mean, it sounds like a principle like that would apply to most scenarios, unless you are too small to even think of making an impact on your complements markets with your financial power. In that case, sure.
Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...
[1] https://steveperkins.com/using-java-9-modularization-to-ship...
* incomplete
* immature
* not up to date
and definitely out-of-tree, aka not maintained by the folks that make the original toolkit.
Would you bet your company on those bindings?
And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember.
Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.
What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10.
> java --list-modules | grep aot
> jdk.aot@9-Debian
If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT.
Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).
Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship...
>If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).
Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.
The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.
Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way.
Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.
0 - https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602
A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil.
https://github.com/zserge/anvil
Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI.
I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look.
We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true.
I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
What I see from UX/UI people is that consistency means an app has the same look and feel across OS platforms and the web, and it matches the corporate house style/identity.
The idea that apps should be consistent with the platform they are running on is completely dead. Even the OS platforms themselves don't have a consistent look and feel in any given version. Not to mention that that metaphorical fish has been flipped in the pan so many times that it has just disintegrated.
No one cares about consistency with OS platforms except us nerds on forums like this.
you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody.
Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines.
And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
Making desktop apps look and feel like web apps.Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.
Never mind that if it's your sole job, you have to demonstrate value and that often leads away from generic solutions.
People browse Stack Overflow and hacker news differently too. There is no set of rules that are generic AND usable in all these cases.
And you do not read a Medium.com article the same way you set something up with your goverment in a goverment website, browsing through hundreds of options.
Not that I believe that the amount of different interaction patterns is justified on the web; the lack of almost any kind of standard widgets just made this a free-for-all bikeshedding design space. In the long run, I doubt that your measurably superior solution to editing an entry in a grid is better than using the same pattern in every data grid.
Quite often I'm reminded of readability tests using different fonts, where the one people liked best often wasn't the one with the best reading comprehension. If you're picking a font for your OS, there was little choice and the customer probably bought it already. On the web, they can go to <rival product #341> because that uses Helvetica Neue and not Akzidenz Grotesk.
1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users.
2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently.
3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model.
So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.
Swing is unusable and ugly.
Just look at and try to use a Swing file picker.
...
Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings.
And thus any glorified WebView reigns supreme.
For example I love the Telegram desktop app.
As funny anecdote, CSS Grid was originally proposed by XAML team.
Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms.
Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
http://gluonhq.com/products/mobile/
> XAML is not 100% the same everywhere, anyway.
Hence XAML Standard,
And be incredibly shitty.
If you care about your users and their experience, you won't write apps in JS to begin with.
Anything else should take advantage of the native UI/UX tooling.
msys2 (http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
* Standards based with no single entity or company "owning" it.
* Multiple mature competing implementations.
* Massive support across the industry and a huge ecosystem.
I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.
Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.
https://ishoudinireadyyet.com/
https://www.webcomponents.org/
Also, to use those standards, one needs to have access to latest browser versions, which never happens beyond controlled environments.
So typical web development always needs Modernizr, Babel, Polyfills (when possible) around.
Your argument makes no sense in the year 2018.
Of course if they just stick with the ideal model of hypertext documents, with a little bit of JS, it doesn't make sense.
As for web apps, I am ok with them, provided they run on the browser I have already installed, instead of faking native apps.
I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform.
I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.
Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited.
Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.
If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron.
And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort.
I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development?
I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?
Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.
Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.
That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO)
It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance.
I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve.
We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.
Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain.
The less said about the security complexity the better.
And I'm saying all of that as someone that uses these daily and enjoys it.
BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not.
Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base.
It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood.
Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good.
This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.
QML?
Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc.
There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).
Really? How many programs supported Linux before electron?
Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?
The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
Xamarin.Forms has no relationship to WinForms.
It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there.
Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross...
There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML:
I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc.
Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
Tables are just unstyled boxes with an alignment rule. Not very high level.
Buttons are provided by the host OS, HTML and CSS have nothing to do with their default style or behaviour, and if you start styling them you basically revert to working from unstyled boxes.
If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice.
Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
On the web the role of desktop UI frameworks is distributed between third party frameworks such as Bootstrap which is great because those are optional.
I haven't worked with the windows frameworks you mention to compare directly to them.
React Native doesn't use HTML/CSS at all for rendering.
I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :)
----
I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI):
We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly:
- Layout (the big one, IMHO) with something like https://yogalayout.com
- The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls.
- Dispatching, events and similar stuff, that is not visual.
Then finally, the rest can be fully native:
- Controls
- Drawing
- Animations
- Call to native libs
----
The big question is what to use for coding this. I'm using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with http://elementscompiler.com
Wish to have a coding partner to do this :)
Also there are existing projects like https://github.com/ptmt/react-native-macos
I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
Funny that QML looks alot like the JavaFX script that was abandoned
I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.
I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.