What about good ol' QT?
I think they are still unmaintained and also are lacking the community around it. I think GitHub embracing Chrome-wrapped-apps was a significant move, since no other company did something similar for desktop javascript applications.
Maybe we will need to wait a bit more, until some of the big tech companies realises that having better QT / GTK bindings and build tools, examples, proper documentation will benefit a lot the company and the community around it. Until then, we are stuck.
Learn a new language (Python/C++/other) in order to learn and use a different framework (Qt)? Thanks for your advice I'll down tools right now and get on with that using my time the way I want to.
(Actually I've never developed anything using Electron yet, though some personal projects may get implemented that way in future should they ever get off the ground)
I fully understand much of the criticism of Electron and similar: the results are rather bulky in terms of both package size and memory use (and if you aren't careful sometimes CPU use) which can add up to quite a performance hit if running a number of small apps/tools that are large because of the framework. For interactive (or script-called) non-resident utilities startup time can be a significant issue too.
But there are a lot of entitled people out there who seem to be of a mind that because they don't like Electron (for those reasons or whatever else) they have the right to demand that developers stop using it. If you don't want to use an Electron driven application then the solution is to not use that Electron driven application. There are no doubt alternatives out there. If not then the deep knowledge you have that makes you an expert on why it would be better developed other ways should allow you to write your own and compete.
This is true for both paid-for services like this (show them who is boss by collectively voting with your wallets) and free and/or open source options (in which case making demands of the creator/maintainer seems even more egregious IMO).
</rant>
Cmon tho, any competent engineer can switch between languages without many issues.
Not really IMO. If users don't like it, they can usually use something else.
A point I didn't make clear at all is "you have used Electron, eww" is a poor judgement. "It is too slow for my needs, look at this benchmark" or "it takes too much RAM, look at the problem this causes" or "it takes a while to load, look at this metric that shows the effect it has on me" are all valid and constructive criticisms. "I don't like part of what, to me as a user should be a black box, is made with" isn't (if it works for you, it works, if it doesn't for a practical reason then it doesn't, how it is made and how the maintainers might solve your issue if they chose to address it is their problem). If going from a fellow developers PoV then by all means give constructive critique but "you use Electron, you a stupid" (a tone I've seen a fair few times) isn't that, and as a developer if you want an X made a different way go make an X that way (or, back to user-land, go find one made that way, there will probably be other options).
> Even if it’s forcing a square peg in a round hole?
This can be a problem created by switching language (or framework, or other) without sufficient acclimation time: you end up using the new tools like they were your old tools, which might produce something that works badly because the new options are not optimal for that construction pattern or at least that pattern does not use the other tools to their best advantage. Have you never heard the pained yelps of "but... that just isn't Pythonic!" or similar?
> Cmon tho, any competent engineer can switch between languages without many issues.
Depending on experience level, that is rarely without at least some context switching cost even if you are already familiar with what you are switching to. Maybe you are a natural star engineer for whom this is as close to zero as makes no odds, but most of use are not quite that perfect!
That seems to be one of the main drivers behind Electron's popularity, others being easier cross-platform support (or at least the perception of that) and the vote of confidence in its stability from the likes of MS using it in their products (primarily VSCode in MS's case).
What would be your alternate suggestion, and why? (genuine question rather than a rhetorical dig: I plan to tinker with Electron for a couple of projects soon so if there is something better (or simply that is a suitable alternative to consider) out there I'm not aware of, I'd like to be made aware)
* package management and modules actually work
* huge ecosystem of packages
* ability to use native code modules in needed
* has webassembly too
* runs a huge range of other languages. It can fill a role similar to the JVM and .Net runtimes in this respect.
Meanwhile, Python versioning of plugins is really broken, unless you use virtual environments. Maven seems to be fairly hard to integrate with IDEs (Eclipse seems to come bundled with a separate one, not sure about IntelliJ). Most other package managers I use don't have enough packages to be as useful.
It is not broken - you ARE supposed to use virtual environments. I would say its is much saner than nodejs ecosystem where every conflict is being solved by having multiple versions of overlapping dependencies.
I've also had a compilation problem on Windows caused by Python not being installed (IIRC, the SASS package needed gyp, which uses Python). That was exceptional: I expect npm packages to install without issue, although I'm still bothered by how many dependent packages every tool seems to need.
Let me guess, no `iseven` package?
> * huge ecosystem of packages
This is satire, right?
NPM (both the tool, and the repository of packages it pulls from) are a joke to anyone outside the NodeJS bubble of Stockholm syndrome.
A company that was given $8M in venture capital and can't find more than two people to work on the main way people interact with their service, cannot be taken seriously.
Remember when everyone found out that the progress bar made NPM install packages 3x slower?
Then lets get into the actual 'ecosystem'.
The community actively encourages and embraces the sort of culture and decision making that leads to an entire module to do what you can do with this: `$foo % 2 === 0` (i.e. 'is even')
You would type more characters just requiring the module than you would just using the modulo operator.
Then you find out the same author published another module that literally just calls the other one and negates the returned result.
Let that sink in: a module, to do nothing more than prefix a function call with a `!`.
No fucking surprise the 'ecosystem' is huge. What other people call "writing code" NPM module developers look at as another opportunity to bump their ridiculous package count e-penis.
You can use NPM and NodeJS if you want, you can even "like" them. But don't for a second think that the community and practices of that environment are "good" by any comparison.
Qt had pretty good Java support with Qt Jambi. But nobody cared and they cancelled the product.
But pyqt apps are way faster than electron
If you think Python and JS are about the same speed then it is because of Qt itself, but certainly not because of CPython.
Citation needed. As I've said numerous times before, saying one language is faster than another is pointless. You have to give a full context around it. What particular scenario is CPython slower than V8?
While it's true that a pure CPython tight loop will be slower than one in V8, I have a hard time imagining that being the bottleneck of desktop applications.
Never thought about it this way but you're right. I could very well write an interpreter for C that's slow as molasses and I'd be willing to be that no one will try it and say "C is slow."
It doesn't seem like languages that are already interpreted get that courtesy, though. V8 isn't the only JS engine, after all.
A desktop app would not see any difference. A sysadmin script neihter. Data analystics is made using numpy/scipy/pandas. Web sites bottleneck are incredibly rarely the server side scripting language, and when it is, you go rust/go.
But for our current debate, electron VS PyQT, well yes, the C++ does the heavy lifting and you get to use Python only for the stuff it is good at. Win-win.
The problem with using PyQT is making an exe or making fancy graphics is harder than in electron.
Everything else, and I do mean everything else, is easier and more performant with PyQT.
However, the real problem with PyQT is that Python is relatively garbage compared to JS and that's why it's not nearly as popular as JS.
Ehhh V8 is pretty competitive with C for number crunching. Where are you getting that 50 times figure from?
If you're using parallelism for non-IO-related reasons, then in either language, you'll probably end up using multiple processes rather than multiple threads.
V8 has been running many many laps around cpython for the use cases I have been using it for, and PyPy has generally been slightly slower.
well it might in relative terms, but a pyqt app is almost certainly going to be an order of magnitude faster than electron.
This will allow you to fully interoperate Qml and .NET (Mono/.NET Core/Full Framework).
I'll take slightly more complex syntax over untraceable dynamic weak typing of JS.
How many times have you got random undefined?
I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.
In order to be safe we need simplicity. We need to move the main part of the program to compilation time to have static checks. We need to write comprehensive tests on the parts we leave to the runtime. We need to check inputs at every stage.
We need to be very very careful when using concurrency.
In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.
OTOH C++ is a different beast, it is complex, it has many fine-points to master.
I'd say programming in Go and using QT could be a good choice, if you're considering memory safety above all things.
I think it is very odd that you argue for C, which has the concept of undefined behavior, which is much, much worse than any kind of failure the memory-safe languages without static types can offer.
> In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.
Bold claim, they still fall victim to undefined behavior:
https://www.cvedetails.com/vulnerability-list/vendor_id-97/O...