Hacker News Reader

Comment by adamnemecek | Hacker News Reader

This is like 10 years too late. This could have prevented electron.

Electron is the third wave, before we had MSHTML and XUL.

Just like its predecessors I give it one or two years more max, then it will fade away like they did.

Most interfaces created through web technology would be incredibly hard and slow to do using pyside/pyqt. We take for granted the non-blocking aspect of javasript where in python in order to make a slick interface would require to deal with threads/GIL in a much slower interpreted language compared with javascript running on V8.

Qt (Qt Desktop) bindings for python are welcome. But, it's not a suitable for a viable replacement for electron. Maybe Qt Quick, but even qt quick has some decisions that can make incredibly uncomfortable to use in large applications.

We have asyncio now to handle things in a non-blocking way with async/await. Someone just needs to write an implementation of asyncio.AbstractEventLoop that hooks into the Qt event loop.

And then they need to write an async version of everything you might want to use. And then they're done!

No, async versions of everything are already being written, based on asyncio. You just need the glue for using it with Qt.

but.... 10 years ago there was PySide 1 which was the exact equivalent of this except with the 10 years ago Qt version

The licensing was weird iirc.

People use Electron because of web technology and also the abstractions available there like React, not because any dynamically-typed language would've sufficed.

In fact, Python is at a disadvantage here anyways because it's not async by default.

What's so important about being async by default to build desktop applications? Offloading slow tasks to a background thread is not at all harder and actually allows you to use more than one cpu core.

Threads avoid the need of callbacks/promises/async/await and they're also cheap and performant unless you need to spawn >10k of them, which seems very unlikely in a desktop applications.

Being async by default is an advantage when you need to handle hundreds of thousands of tasks, all of which are mostly waiting on I/O, which is something that can happen on server side applications, and almost never on the desktop.

Python is really in the same category as JavaScript as far as being asynchronous is concerned.

You make it sound like that would have been a good thing. Why?

Electron is bloated

Reply on news.ycombinator.com