[ajxs]

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.

[pault]

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.

[judge2020]

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.

[ajxs]

> 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.

[pault]

But you're using the browser already!

[ShinTakuya]

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.

[Narishma]

I don't see how. Those libraries are already loaded anyway because they're used by the OS and native apps.

[bgrins]

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.

[hutzlibu]

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.

[sixplusone]

Unfortunately OS/WM/DE makers didn't provide a common API, so now web browsers are the "Lowest Common Denominator" for cross-platform apps.

[FussyZeus]

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.

[sixplusone]

>why Toyota Corollas and Ford F-150's don't use the same engine

Yeah, they're now a weaker (browser) engine bolted on with adapters to the gui engine. Everyone gets to go through the js bottleneck.

[FussyZeus]

To continue the metaphor, it's like every car has the same crappy transmission.

[HeWhoLurksLate]

More like Electron adds its own crappy transmission to whatever you had already

[twgrp]

Qt exists.

[mc3]

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.

[ajxs]

> you can hire web devs to make a desktop product

This is a bug, not a feature.

[buboard]

Its also slow and bloated. You get what you pay for

[pmoleri]

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.

[weberc2]

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.

[mc3]

Not nearly as snappy as notepad++/sublime, which are in turn not as snappy as Vim.

[buboard]

There are a ton of cross-platform GUI libraries

[st1ck]

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.

[1]: https://github.com/status-im/react-native-desktop [2]: https://github.com/kusti8/proton-native

[weberc2]

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).

[jcelerier]

> 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.

[weberc2]

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.

[jcelerier]

> 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.

[sixplusone]

But this is part of the problem. I should have said "provide standard API" above. These libs aren't standard.

[ajxs]

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.

[marmada]

Is js actually slow? I thought with all the money invested in it, JS was one of the fastest dynamic languages out there.