Isn't this the kind of thing we've been looking to move away from?
I personally think that this modern trend of implementing, or even worse -porting-, important functionality in Javascript is very worrying. There was another recent controversial discussion of Electron on HN where I and many others shared our reservations about badly Electron apps perform overall. They're disproportionately resource intensive, shred battery life, hog resources etc.
I don't think that deprecating XUL is a bad thing, but is moving to another JS based solution really a good idea?
I've been a supporter of Firefox for a long time and intend to continue to do so. I tend to favor lightweight programs and while I want to continue to give FF my support, I'm concerned with how bloated and slow it's becoming.
The problem with electron isn't JavaScript, it's running an entirely seperate instance of an infamously memory hogging web browser, that comes with an enormous amount of features that aren't utilized by the application. The JavaScript runtime itself is not going to cause noticable slowdowns or memory use, especially so if you already have one running anyway as is the case for Firefox.
The Chrome "apps" feature is turning out pretty well for me when using it for YT Music and YT TV, it runs in the same process as the existing chrome tabs do, and you can have dedicated windows for them in Windows/MacOS.
> running an entirely seperate instance of an infamously memory hogging web browser
Without looking at the source-code: Doesn't this problem still exist, just in a different form? You're still running some kind of browser instance to render the UI, rather than using native methods.
Yes, but this is the UI of a browser. Arguably it could be more efficient to do it this way as you can strip out some of the libraries used for the native rendering.
There are pros and cons to using web tech for the application UI. To be clear, the old XBL code was already using JS/DOM, so the most obvious pro in this case was that it didn't require completely rewriting Firefox from scratch (which hasn't historically worked out well). I also expect that dogfooding web technologies means we can improve the tooling and web standard implementations in Gecko.
Regarding performance, this work didn't regress anything. Performance is measured on every commit and staying at least at parity was a requirement for the project.
But with firefox, you intend to use HTML and JS in the first place.
I doubt that the cost to also render the firefox UI is significantly higher that having it native.
This is an odd offshoot issue that comes I think from the larger movement towards web-based applications and hosted "services" replacing bespoke desktop apps.
I have to say I feel a bit old hearing developers say "well why didn't the OS developers provide common APIs for creating applications?" which in my mind, is asking why Toyota Corollas and Ford F-150's don't use the same engine. The answer being they were two entire universes, and still are to a great degree.
That being said, while it is desirable to have standard API endpoints that are accessible, and while standards in general are a Good Thing(tm) to have, it does get a bit tiresome to hear different companies like Spotify[1], especially of that scale, bemoaning that they simply "must" use frameworks like Electron to build their applications because developing for individual platforms is just too expensive. If you want your application available on multiple platforms, and you want it to be a good experience to use, then you should be developing bespoke applications for them. That's just... logic, to me.
Yeah, it's more work. But to take a crap ton of web-content, shove it in a .app file and distribute that is massively wasteful, lazy, and results in what that kind of effort typically nets: bad experiences.
For example: I absolutely LOVE the Atom editor. It's a fantastic tool to use. That said I've had to give it up because it was simply killing my Mac's performance, a brand new, 2019, 15" Macbook Pro would sit there spinning it's fans up whenever it was on the screen, for a text editor. A feature rich text editor to be sure, but this thing can play 4K movies without even running the fans. A text editor should not strain it. I can't help but feel Electron is playing a role here.
[1]: I have no idea if Spotify uses Electron. I just know they've complained about this before.
I think Electron is popular because you can hire web devs to make a desktop product. With JS you can write code that runs on your server (NodeJS) desktop (Electron), browser and mobile app (Cordova). It's not a great experience but it is good for rapid development, easier hiring of skills (just need some web devs!) and the code reuse might be helpful for bug reduction.
Bloated, yes. Slow, no. You start at a not so low binary size and memory footprint, but that's it. VS Code is an awesome IDE built on electron and it's really snappy.
VS Code has not been snappy for me. Especially with large screen sizes and lots of widegets. For example, if I close the left-hand pane and shrink the window, performance improves considerably.
Last time I checked (a year ago), only Qt supported all 5 major native platorms: Linux/Mac/Windows and Android/iOS. Maybe also React Native, if you count [1] (Qt backend) or [2] (libui). Now it looks like Flutter started to support desktop recently. And that's it, I think.
As someone who loves the idea of a good cross platform GUI, there simply aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but manageable. You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) or use a leaky Python binding (that still segfaults), but you can build things that don’t look awful. As far as I know, this is the only cross platform GUI tool for which this can be said (except for the browser-based solutions, of course).
> You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator)
Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...). If your editor does not support resolving empty macros it does not support C++ at all anyways.
This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break.
That's what you get with Qt absent the moc (meta object compiler).
Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.
So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.
> This misses my point. If I create a language and assign different semantics to the Python AST,
but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.
C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.
> Your editor cannot autocomplete those signals/slots like Qt Creator.
what do you mean ? signals and slots are just plain functions, there is no magic to understand ; the only thing that QtCreator does is to display a different icon in the autocompletion toolbox.
Do you have an example of an IDE that is not able to autocomplete a signal ? VS is able to, vscode is able to, Xcode is able to, code::blocks is able to, hell even notepad++ in all its "non-intelligence" manages to.
> Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.
I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.
Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.
> I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.
My point does make sense, you're just missing it.
First of all, my point is that Qt is a poor developer experience--that its interface is bastardized is merely evidence. Further, even if it were not bastardized, it would still be awful because it's C++ (insane build tooling, no package management, poor error messaging, no memory safety, enormous feature matrix, etc etc etc; all of this has been covered elsewhere ad nauseum, no need to repeat those arguments here). There's a long tail of additional issues with Qt that contribute to its unpleasantness, but there's no point in diving into them here.
Secondly, your stateful library functions example doesn't fit my criticism because stateful functions are part of the C++ language spec while signals and slots are not.
> Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.
If that was the case, gcc and clang would not be able to build Qt files. Yet the following compiles without issues :
No, it just means that Qt is valid C++, not that the two have equivalent semantics (which is necessary for Qt to be exactly C++ and not a bastardized version thereof, which is what we are debating). If I we’re wrong and you were right, the moc would be purely optional; it would serve no purpose, and Qt programs compiled with moc would behave exactly as those compiled without.
I don't think that really excuses the use of Electron. Cross-platform GUI frameworks like Qt/GTK+ already exist to resolve this issue. This problem was already solved before Electron came around. All Electron did was lower the bar.
