6 ms·

Let's be clear, I dislike slow apps, I think current behemoth web pages size is a monstrosity and every time I start an electron app (minus the excellent vscode

Let's be clear, I dislike slow apps, I think current behemoth web pages size is a monstrosity and every time I start an electron app (minus the excellent vscode), I scream in my head. Yet. Most electron app I tried have a ratio result/effort far better than any other solutions for the dev.

zeta0134 10y ago
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.
panic 10y ago
Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the program more frequently than the developers make changes to it. For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wasted, which is about 25 8-hour days, or five 40-hour weeks).
- BHSPitMonkey 10y ago
  Who is funding the developer? Why should they spend $5k (plus the opportunity cost of not using that dev's time on more fruitful pursuits) on 2 weeks of micro-optimization so that their 10,000 users will each experience a speedup so small they'll never even notice (and certainly never pay extra for)? How do you justify that expense?
  - panic 10y ago
    I'm making a more abstract argument that doesn't have anything to do with money. The time people spend using a piece of software shouldn't be worth less than the time developers spend writing it.
    - BHSPitMonkey 10y ago
      Okay, but under those conditions your argument can only be applied to a more abstract reality that isn't the one we actually live our lives in.
    - nemothekid 10y ago
      The time developers spend writing a piece of software is worth what people are willing to pay for it. It has everything to do with money - if the person using the software isn't willing to spend more for 200ms less in startup latency, it probably won't happen.
  - flukus 10y ago
    > How do you justify that expense? It makes it harder for your competitors to offer a better product.
flukus 10y ago
> Most electron app I tried have a ratio result/effort far better than any other solutions for the dev. This is more about the experience of the developer. Anyone familiar with GTK or Qt (possibly others) should be able to bang out a UI pretty quickly, in many cases it will be much simpler than HTML+js+CSS. With Visual Studio you could slap together a win32 app pretty quickly. But for some reason we decided we had to coddle developers who only know javascript.
- reitanqild 10y ago
  Cross-platform was mentioned upstream. Microsoft finally seems to be learning now but I think it will still be a few years before people start creating cross-platform desktop sw in visual studio, if ever.
  - flukus 10y ago
    I think their intention is to make VS cross platform but not to provide a cross platform UI stack themselves. Even if they made any of their UI stacks cross platform, it wouldn't be particular compelling compared to something like qt (or GTK if you don't care about cross platform).

zeta0134 10y ago

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.

panic 10y ago

Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the program more frequently than the developers make changes to it. For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wasted, which is about 25 8-hour days, or five 40-hour weeks).

BHSPitMonkey 10y ago
Who is funding the developer? Why should they spend $5k (plus the opportunity cost of not using that dev's time on more fruitful pursuits) on 2 weeks of micro-optimization so that their 10,000 users will each experience a speedup so small they'll never even notice (and certainly never pay extra for)? How do you justify that expense?
- panic 10y ago
  I'm making a more abstract argument that doesn't have anything to do with money. The time people spend using a piece of software shouldn't be worth less than the time developers spend writing it.
  - BHSPitMonkey 10y ago
    Okay, but under those conditions your argument can only be applied to a more abstract reality that isn't the one we actually live our lives in.
  - nemothekid 10y ago
    The time developers spend writing a piece of software is worth what people are willing to pay for it. It has everything to do with money - if the person using the software isn't willing to spend more for 200ms less in startup latency, it probably won't happen.
- flukus 10y ago
  > How do you justify that expense? It makes it harder for your competitors to offer a better product.

flukus 10y ago

> Most electron app I tried have a ratio result/effort far better than any other solutions for the dev. This is more about the experience of the developer. Anyone familiar with GTK or Qt (possibly others) should be able to bang out a UI pretty quickly, in many cases it will be much simpler than HTML+js+CSS. With Visual Studio you could slap together a win32 app pretty quickly. But for some reason we decided we had to coddle developers who only know javascript.

reitanqild 10y ago
Cross-platform was mentioned upstream. Microsoft finally seems to be learning now but I think it will still be a few years before people start creating cross-platform desktop sw in visual studio, if ever.
- flukus 10y ago
  I think their intention is to make VS cross platform but not to provide a cross platform UI stack themselves. Even if they made any of their UI stacks cross platform, it wouldn't be particular compelling compared to something like qt (or GTK if you don't care about cross platform).