I wish exist a native renderer that could use a (saner, better) subset of html/css that fit the same use case, then let us use any better language for the logic.
Probably OpenGL toolkits are the idea, but it way to operate and looks are weird.
Qt perhaps is holding up the best, but I can see why people prefer Javascript's event model to Qt's.
Pointing out that old toolkits still exist doesn't necessarily help when people expect more from their toolkit now.
It can't be performance, because Electron is slow. It's not conservative power usage, because browsers are power hungry. It's not disk space or memory usage either.
Nor is it a native-looking UI. Nor security. Nor privacy. Nor accessibility.
The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
NPM, even if it has plenty of do-not-use-that-packages crap, is still far more furnished that Qt will ever be, for example.
> The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
One could say the same for the typical Qt developer that refuse to get serious in learning the web platform.
This has not been true for years now. There is a native port of Gtk that does not require an X server. Gimp is available natively, as are other Gtk apps (Gnucash, Deluge, etc).
Of course it's not.
> There is no reason to use JavaScript just so you can get a "cross platform GUI".
The main reason (imho) is that "JavaScript" (as you call it, but you should say "the web platform") is more future proof than "old toolkits".
Qt would be the best candidate for a "cross platform GUI", but you are relying on the [Qt company/nokia/whatever] for its continuation.
When you choose html/js you choose a standard used by virtually every single person with a computer nowadays. There is far less chance that html/js will be killed someday, like Microsoft killed WPF or like IBM made SWT an abandonware, because nobody is in that position and this whole World Wide Web thing rely on it.
How can JS be more future-proof than old UI toolkits when JS libraries and frameworks are constantly changing? Sure, nobody will kill HTML and JS, but that's not the point. Nobody knows how UIs will be built with web technologies in two years!
Edit: based on your reply below, it looks like I have to spell it out. GUIs are built with UI frameworks, not just with programming languages and markup languages. JS frameworks are so short-lived that one can't be sure if their code will still work in one year.
That is the opposite of future-proof.
Yes, it is the point. Nothing more, nothing less.
> Nobody knows how UIs will be built with web technologies in two years!
You can't say that things like es6/react/typescript/clojurescript will be plain gone in two years, there's too much real momentum behind these things.
Ok, so let me spell this out too (frameworks/librairies mixed):
- jquery: 10 years
- backbone: 6 years
- angular v1: 6 years
- ember: 5 years
- react: 3 years
Otoh, Qt5 with QML: 3 years.Quoting from wikipedia:
> Qt 5 was officially released on 19 December 2012. This new version marked a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role. The traditional C++-only QWidgets continued to be supported, but did not benefit from the performance improvements available through the new architecture.
Versioning your dependencies is good practice regardless of language and has been for decades. Javascript has enough cons, you don't have to resort to imaginary ones.
Not get me wrong, I don't like much JS/html apart as be hostage as everyone else to use it in the web, but is clear that as far to build the GUI is way more enjoyable than most GUI toolkit.
It can't be that web developers have been bitterly complaining about how poor HTML and CSS are at building UIs for years and years and suddenly it's become easy and enjoyable.
Actually it has become easy and enjoyable ;) Even for complex UIs.
Just think seriously about what a stack like es6/React/Redux brings on the table against plain old ES5, and you'll be struck by how well things have become.