> Electron ends up being the technology of choice for so many desktop apps.

probably because of the large number of JS only developers.

JavaScript is a language that's neither abstracted from the basic programming concepts nor its syntax is alien. Most of the people who picked it up can learn many other mainstream programming languages in a week, if not a weekend. Add 1-2 more weeks and they're writing GUI code.

Yet, they don't.

JavaScript is popular for pragmatic reasons (a.k.a. "it delivers results"), so is PHP. They aren't the best languages, but developers who choose them aren't simpletons who can't code in other languages.

So much this.

I work primarily in JS and PHP.

They are both deeply, deeply flawed (though I have learned to love JS's good parts, while I still hate PHP).

I have programmed in many languages - Java, Python, Scheme, and Bash are all ones I've worked in professionally, and I've spent plenty of time in Emacs Lisp. This doesn't touch on the ones I've tinkered with for fun.

JS and PHP are not the best languages, but they work, they're everywhere, and they're usually what your client already has in place.

Changing languages rarely delivers any actual business or end user value.

So, I work in what the client has.

JS will long outlast PHP, because it's such a massively deployed language and browsers can effectively never remove support for it.

PHP may slowly die out, since it's strictly on the backend, where you can choose your language.

JS is eternal.

I think of "front end" as meaning "executed in browsers."

How are you using it?

I will never ever ever work with PHP again. It's dead.

While I hope never to work with it, in what concerns the tiny set of PHP files on my web site, it is alright.

I’d say electron became popular thanks to HTML, not JavaScript. IMO HTML is by far the “easiest” to use GUI framework because it is so unconstrained. It will end up a mess, but eventually you can get the result you want. This is not the case with native frameworks which come with a larger sets of rules on how they can be used.

I beg to differ, having been doing GUI coding since a couple of decades.

Guess what, what in most of them I never had any issues to center elements, or create fake UI elements out of list items.

Also layout managers were already a thing back in 2000.

I did UI development for quite a while too, and in my experience having very specific layouts (and look) in HTML is easier than in frameworks I used (Gtk, Qt, UIKit...).

Main difference is that HTML has affordances to size elements "upwards" whereas in other toolkits you need to do this manually (e.g.: estimating text size is a thing, in html you don't need to care about this)

Now, this also encourages original layouts which are untrue to platforms which is not a good thing imo.

You also don't need to estimating text size in QML, XAML, Forms, VCL, and when you need it is hardly any different than dealing with CSS fonts.

I very much doubt that is a major reason. Language itself is rarely the issue, unless you're reusing code from other parts of the project (which many projects are, e.g. VS Code with Monaco).

I have spent far too much time on HN recently in related discussions.

Having access to libraries like React and its huge ecosystem is a big plus for productivity (example vs. Qt at https://news.ycombinator.com/item?id=23154315).

Building custom UIs is also very easy with the flexibility that HTML provides (https://news.ycombinator.com/item?id=23164595), even though it can be done with other technologies (and there are some examples of that).

I think people would switch if it had Apple money behind it.

Qt is pretty good but QtQuick can be fairly barren in some areas i.e. if you want a embedded spreadsheet you're out of luck unless you make your own.

> Qt is pretty good but QtQuick can be fairly barren in some areas i.e. if you want a embedded spreadsheet you're out of luck unless you make your own.

Hey, have you checked out https://github.com/ec1oud/spreadsheet.qml?