5 ms·

This cannot be understated. It really can't. The programmer in me will always be drawn to small, lightweight code that gets the job done while using minimal res

This cannot be understated. It really can't. The programmer in me will always be drawn to small, lightweight code that gets the job done while using minimal resources. But that programmer is an algorithmic designer, which doesn't often need to deal with the realities of UI, graphics card drivers, or cross-platform compatability. Electron is popular precisely because it enables developers of nearly any skill level to solve real world problems without investing the additional time to become a systems engineer. And the truth of the matter is that there are many more real world problems that need solving. Computers are cheap, humans are expensive. When performance matters, by all means, hire the expensive programmers and code it from scratch. Do it "right." But doing it at all is often the only thing that needs doing, and for those problems, Electron is often, begrudgingly, the best choice.

sametmax 10y ago
Honestly I will be able to accept the resource consumption in the long run. But the use of JS everywhere is the real hard part for me.
- dottedmag 10y ago
  WebAssembly and languages compiled to JS make it immaterial.
  - millstone 10y ago
    I'm not sure how. WebAssembly is more limited than JavaScript (e.g. no access to DOM), and also more limited than native code (e.g. much more limited threading story).
    - uryga 10y ago
      I thought they were working on adding DOM stuff too?
      - stymaar 10y ago
        They are. And they are also working on having full multi-threading (thanks to SharedArrayBuffer).
    - cryptarch 10y ago
      I wonder how long after the WebAssembly DOM API becomes stable tbe first Rust-based "server and client written in one language" frameworks start popping up.
  - sametmax 10y ago
    It has the potential to do so, but I'm waiting to see it for real before calling it. Right now it's just not the case.
flukus 10y ago
> which doesn't often need to deal with the realities of UI, graphics card drivers, or cross-platform compatability. What makes you think desktop programmers have to deal with graphics drivers? How is electron any better than desktop toolsets worse at dealing with the realities of UI work?
- zeta0134 10y ago
  For the graphics question, it really depends on how you define a desktop programmer. Most video game developers need to work with graphics at some point, and a great deal of professional creative software uses GPU acceleration. Whether you deal with the drivers directly or not, you're going through them, and end up bitten by weird bugs and platform inconsistencies in testing. (Why are my drop shadows pink? Oh, this is a known issue with Intel HD 4000 on OSX... that sort of thing.) To be fair, Electron doesn't solve this problem, and neither does any toolkit really, it just shifts the responsibility to the framework, rather than the application developer. As for electron being better than existing toolkits as far as UI development? I don't think that's a fair assessment in either direction. It's a right tool for the job thing. Electron's real strength is that it's web-based, so it's familiar to existing web developers. In that respect, it's a bit easier to use if you already know web technologies. But, it's not terribly good at native integration (Electron apps tend to feel like web apps because they are), and resource consumption is abysmal because it's going through the browser layer, and we all know Chromium isn't light on RAM usage. Other toolkits are far better at handling native platform integration and can be much more lightweight. Again here, "better" is a really tough thing to define, as every team and project is going to have different priorities.

sametmax 10y ago

Honestly I will be able to accept the resource consumption in the long run. But the use of JS everywhere is the real hard part for me.

dottedmag 10y ago
WebAssembly and languages compiled to JS make it immaterial.
- millstone 10y ago
  I'm not sure how. WebAssembly is more limited than JavaScript (e.g. no access to DOM), and also more limited than native code (e.g. much more limited threading story).
  - uryga 10y ago
    I thought they were working on adding DOM stuff too?
    - stymaar 10y ago
      They are. And they are also working on having full multi-threading (thanks to SharedArrayBuffer).
  - cryptarch 10y ago
    I wonder how long after the WebAssembly DOM API becomes stable tbe first Rust-based "server and client written in one language" frameworks start popping up.
- sametmax 10y ago
  It has the potential to do so, but I'm waiting to see it for real before calling it. Right now it's just not the case.

flukus 10y ago

> which doesn't often need to deal with the realities of UI, graphics card drivers, or cross-platform compatability. What makes you think desktop programmers have to deal with graphics drivers? How is electron any better than desktop toolsets worse at dealing with the realities of UI work?

zeta0134 10y ago
For the graphics question, it really depends on how you define a desktop programmer. Most video game developers need to work with graphics at some point, and a great deal of professional creative software uses GPU acceleration. Whether you deal with the drivers directly or not, you're going through them, and end up bitten by weird bugs and platform inconsistencies in testing. (Why are my drop shadows pink? Oh, this is a known issue with Intel HD 4000 on OSX... that sort of thing.) To be fair, Electron doesn't solve this problem, and neither does any toolkit really, it just shifts the responsibility to the framework, rather than the application developer. As for electron being better than existing toolkits as far as UI development? I don't think that's a fair assessment in either direction. It's a right tool for the job thing. Electron's real strength is that it's web-based, so it's familiar to existing web developers. In that respect, it's a bit easier to use if you already know web technologies. But, it's not terribly good at native integration (Electron apps tend to feel like web apps because they are), and resource consumption is abysmal because it's going through the browser layer, and we all know Chromium isn't light on RAM usage. Other toolkits are far better at handling native platform integration and can be much more lightweight. Again here, "better" is a really tough thing to define, as every team and project is going to have different priorities.