[pjmlp]

No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS.

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.

[greenhouse_gas]

The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet).

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.

[pjmlp]

XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean.

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.

[oblio]

JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS.

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.

[pjmlp]

JavaFX surely runs on iOS, just not for the "I want everything for free" crowd.

http://gluonhq.com/products/mobile/

> XAML is not 100% the same everywhere, anyway.

Hence XAML Standard,

https://github.com/Microsoft/xaml-standard

[s73v3r_]

"While your Electron app will be tweaked to make a Cordova app that runs on iOS."

And be incredibly shitty.

If you care about your users and their experience, you won't write apps in JS to begin with.

[pjmlp]

My point of view is that if it is to be done with the Web stack, then by all means it should be delivered to whatever browser the user likes to use on their platform.

Anything else should take advantage of the native UI/UX tooling.

[realharo]

>last time I tried C++ with mingw on Windows I had a horrible time installing libraries

msys2 (http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.

[sime2009]

Web technologies have some unique non-technical qualities which trump the technical arguments:

* Standards based with no single entity or company "owning" it.

* Multiple mature competing implementations.

* Massive support across the industry and a huge ecosystem.

[pjmlp]

You mean like those "Works in IE/Chrome" standards?

I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.

[Sawamara]

You have to actively ignore the web's landscape in the past 5-6 years to state something like this.

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.

[pjmlp]

Really?

https://ishoudinireadyyet.com/

https://www.webcomponents.org/

https://hangouts.google.com/

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.

[sime2009]

The vast majority of current web development project don't need to go anywhere near the bleeding edge "still in development" browser APIs.

Your argument makes no sense in the year 2018.

[pjmlp]

Depends, if they are trying to compete with native apps or not.

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.

[megaman22]

Hey, some of us are still out here having to support IE 7... Glaciers move faster these days than some corporate clients.

[NoGravitas]

And yet, I still frequently run into web applications that only run in Chrome. Mostly COTS enterprise products.

[rimliu]

You have extra word in your second point. There is norhing mature. If anything webtech rushes implementation of some feature just so the checkbox “we can do it too” is ticked and that’s it.

[lobster_johnson]

Do you know of a Qt app that looks and feels fully native on macOS and Windows and maybe iOS and Android?

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.

[realharo]

Having done a lot of React development (in TypeScript), and recently dealing more with Android, I disagree.

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.

[lucideer]

If they were "much better", devs wouldn't be flocking to Electron. If there's something amiss, claiming there isn't with hand-waves brushes whatever issues there are under the carpet.

[yorwba]

You also have to consider where the users are coming from. If you only have experience in web dev, obviously you are going to choose the framework that lets you do what you always did and get a desktop app in the end.

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.

[1] https://github.com/chriskiehl/Gooey

[pjmlp]

I bet the majority of those devs are web devs without any experience in native frameworks.

[s73v3r_]

Devs aren't flocking to Electron. JS developers are.

[netzone]

Really, I agree that there are probably better markup options, but still, there's a reason people choose Electron over the alternatives. For me, personally, that reason is the ease of prototyping - the time it takes for me to have something in front of me that looks good and works easily is so much less using something like Electron.

[klez]

Ok, but from an engineering standpoint I see this as a bit shortsighted.

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?

[pjmlp]

They don't know better.

Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.