6 ms·

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

by ajxs 7y ago

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 7y ago
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 7y ago
  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 7y ago
  > 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 7y ago
    But you're using the browser already!
  - ShinTakuya 7y ago
    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 7y ago
      I don't see how. Those libraries are already loaded anyway because they're used by the OS and native apps.
sixplusone 7y ago
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 7y ago
  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 7y ago
    >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.
hutzlibu 7y ago
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.
bgrins 7y ago
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.
marmada 7y ago
Is js actually slow? I thought with all the money invested in it, JS was one of the fastest dynamic languages out there.

by ajxs 7y ago

pault 7y ago

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 7y ago
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 7y ago
> 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 7y ago
  But you're using the browser already!
- ShinTakuya 7y ago
  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 7y ago
    I don't see how. Those libraries are already loaded anyway because they're used by the OS and native apps.

sixplusone 7y ago

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

hutzlibu 7y ago

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.

bgrins 7y ago

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.

marmada 7y ago

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