The list of examples isn’t very compelling. Extensions should be things that can’t be done in Javascript.
theamk 4 days ago [-]
Disagree, Electron-based apps are known for being memory and CPU hogs; if we want our laptops to run cool and for batteries to last a long time, we need to move things to native code.
I think the "new protocol" example is particularly good one - things like IPFS run complex daemons under the hood and might access gigabytes of data, while their interface to browser is relatively simple: a channel which takes small requests and returns medium-sized responses. It's ideal case for moving to native code.
(Of course it has its own downsides too, like losing ability to run same codebase on the web. So far, I've been avoiding Electron's usage by running web versions instead - Slack-on-the-web is just as featureful as Slack-in-Electron, but shares memory with my main browser. But for other applications, native code should be a plus)
moomin 4 days ago [-]
We're talking desktop apps here. Why should they be written in Javascript?
eyjafjallajokul 4 days ago [-]
This is a technical decision some developers make because they're well versed in Javascript, or because their business can only fund the management of one codebase, or because there's libraries that add massive convenience functions to their development. Or because they believe that their UI needs to have a consistent experience. Or <insert reason X, Y, Z here>...
This whole article is about Chromium and Electron. I am not sure what the purpose of your question is.
mschuster91 4 days ago [-]
Assuming the glue code to the native OS (i.e. things like actual local file access, access to hardware, raw network sockets) has roughly the same interface across all the major platforms, you only need one code base and it will run on anything capable of running a web browser - phones, tablets, fancy tablets and other embedded devices, all common computer operating systems, game consoles, whatever. All the hard work of maintaining a common runtime environment is abstracted to the underlying browser framework, and the best is, whenever the browser framework gets ported to some new platform,
your app will get support for that platform as well for virtually no effort and expense.
I get why people are upset at that (especially the sometimes significant performance issues), but I also get why many applications went down the "Electron everything" route. In the end people who know C++ well enough to be able to deal with cross-platform bullshit are expensive and coding for cross-platform is a nightmare. There's a reason why there aren't many "top dogs" left.
snarfy 4 days ago [-]
A quick glance at the headline makes me think this is about electron spins in elemental chromium. I know, naming things is hard, but c'mon people.
3 days ago [-]
noratetil2000 2 days ago [-]
[dead]
Elfener 4 days ago [-]
The blue effect on the right side makes the page very laggy for me.
4 days ago [-]
mwkaufma 4 days ago [-]
[flagged]
kelvinjps10 4 days ago [-]
[flagged]
alekratz 4 days ago [-]
[flagged]
4 days ago [-]
Rendered at 00:16:09 GMT+0000 (Coordinated Universal Time) with Vercel.
I think the "new protocol" example is particularly good one - things like IPFS run complex daemons under the hood and might access gigabytes of data, while their interface to browser is relatively simple: a channel which takes small requests and returns medium-sized responses. It's ideal case for moving to native code.
(Of course it has its own downsides too, like losing ability to run same codebase on the web. So far, I've been avoiding Electron's usage by running web versions instead - Slack-on-the-web is just as featureful as Slack-in-Electron, but shares memory with my main browser. But for other applications, native code should be a plus)
This whole article is about Chromium and Electron. I am not sure what the purpose of your question is.
I get why people are upset at that (especially the sometimes significant performance issues), but I also get why many applications went down the "Electron everything" route. In the end people who know C++ well enough to be able to deal with cross-platform bullshit are expensive and coding for cross-platform is a nightmare. There's a reason why there aren't many "top dogs" left.