6 ms·

I'm curious why there's so much node/electron negativity circulating. (Although I guess asking for positivity when it comes to electron is a bit of a stretch :P

I'm curious why there's so much node/electron negativity circulating. (Although I guess asking for positivity when it comes to electron is a bit of a stretch :P)

mej10 10y ago
There are more and more applications based on it -- negativity increases along with popularity.
teamhappy 10y ago
Trivial apps depending on 14+ million lines of code is not a good thing. Edit: @michaelmior I think you know what I mean.
- michaelmior 10y ago
  I think a good terminal emulator is far from trivial. Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.
  - Jtsummers 10y ago
    https://www.openhub.net/p/putty https://www.openhub.net/p/putty Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code. EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
    - destructionator 10y ago
      I wrote a terminal emulator <https://github.com/adamdruppe/terminal-emulator> https://github.com/adamdruppe/terminal-emulator> and use it daily so it is good enough for me at least... clocks in at ~15k lines (including the gui helper lib). The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
    - deleted 10y ago
      [deleted]
  - alaroldai 10y ago
    Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's around 111K lines of Objective-C, with around 38K more lines split across Python and C++).
    - michaelmior 10y ago
      Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.
      - themartorana 10y ago
        I agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.
      - teamhappy 10y ago
        > I'm just saying that LOC is a fairly useless metric for evaluating software. That's just not true. Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.) Rate of change is another very useful metric.
      - tomc1985 10y ago
        How so? It affects load time, understandability, binary size, dependency payload... I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse. When you're moving fast and in your flow, it gets to be really annoying.
        michaelmior 10y ago
  - e12e 10y ago
    git clone git://git.suckless.org/st cloc --quiet st http://cloc.sourceforge.net v 1.60 T=0.09s (45.8 files/s, 56588.2 lines/s) ------------------------------------ Language files blank comment code ------------------------------------ C 1 497 253 3654 C/C++ Header 2 40 124 313 make 1 13 2 45 ------------------------------------ SUM: 4 550 379 4012 ------------------------------------ [ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]: apt-get source sakura (cloc sakura) Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code... [1] https://bugs.launchpad.net/sakura https://bugs.launchpad.net/sakura ]
    - michaelmior 10y ago
      Sure. I wasn't arguing that millions of lines of code are necessary for a terminal. Thanks for the pointer to Sakura though! I quite like it and I might have to give it a try :)
- jahewson 10y ago
  How many lines is the JDK? or .NET, or libcpp?
  - teamhappy 10y ago
    LLVM: 1.5 million (I assume libc++ is less than 500k) OpenJDK: 6.8 million .NET: 10.5 million Source: https://www.openhub.net/ https://www.openhub.net/
- sgrove 10y ago
  I agree, but I'd take it a step further - the 15+ million Lo(memory-unsafe!)C for the unix kernel other (all?) trivial apps sits on is also not a good thing.
  - teamhappy 10y ago
    I agree with your larger point (I think) but for what it's worth: Most of those 15+ million lines are drivers you don't use.
Zolomon 10y ago
I believe it has to do with the amount of performance lost in the overhead with the electron stack versus a native implementation. Please correct me if I'm wrong.
- michaelmior 10y ago
  For the majority of applications, I'd imagine there's a negligible performance difference. Besides, any app built on Electron will run infinitely faster than one which wasn't built at all since the developer didn't want to learn another language. I'm not saying Electron is suitable for everything, but I think it has its place.
  - city41 10y ago
    I still question Electron for "commercial quality" apps. The Electron runtime by itself is about 100mb. I've built an internal Electron app for work and for that it's absolutely fantastic.
  - asdf1234 10y ago
    > negligible performance difference Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life. None of this is negligible.
    - mitchty 10y ago
      On top of this, chrome/chromium versus safari is another 1-2 hours of battery. I think people vastly underestimate the energy requirements of web technologies.
    - woah 10y ago
      On which OS?
    - klibertp 10y ago
      On the other hand, my Emacs starts up in more than thirty seconds. To fully start up it needs to read some 2k loc of my own ELisp code and hundreds of thousands loc of required libraries. I use Emacs as a Jabber client, Python and Clojure development environments, file manager, image and pdf viewer, HTTP server, spreadsheet and note-taking app and (polyglot) Literate Programming environment. And that's just the beginning of what it can be used for. In other words, giving Emacs as an example of small and fast, natively written application is a bit unfortunate. Not to mention most of Emacs is written in ELisp, so the "natively" part is not even factually correct.
deleted 10y ago
[deleted]
sehr 10y ago
They're slow, big, and outrageously inefficient. Most electron apps also come with this weird web influenced "I'm kinda native y'all trust me" UI design which makes it even worse. My battery and eyes simply can't stand the things.
- michaelmior 10y ago
  Interesting. I haven't experienced the slowness of Electron apps. And outrageously inefficient doesn't really matter to me if it's efficient enough for me not to notice any slowdown.
  - elmigranto 10y ago
    I think he meant inefficient in terms of battery power.
  - jackmott 10y ago
    But if we are going to accept the computational inefficiency, what do we gain for it? If our only answer, collectively, as developers, is the richness of the ecosystem, then perhaps we should be moving our time and energies to make a rich ecosystem in either a language/runtime environment that performs better (C/Rust/OCaml/Whatever) or one that encourages correctness and/or speed of development. I know some people think javascript is the latter, and I can't prove them wrong, but I suspect that is not true.
  - nojvek 10y ago
    Electron means your app runs on Mac + Win + Linux without much effort. It could also potentially run on the web browser. That is a huge sell.
- ank_the_elder 10y ago
  I have tried to edit a file with a little bit of long JSON that came from a server (less than 50K) and atom completely froze trying to display it. This was two weeks ago. I've ditched Atom entirely.
random28345 10y ago
> I'm curious why there's so much node/electron negativity circulating. "There are only two kinds of languages: the ones people complain about and the ones nobody uses". --Bjarne Stroustrup I'm pretty sure that applies to language runtimes as well. > Although I guess asking for positivity when it comes to electron is a bit of a stretch I like to stay current, and in this charged environment, I'd be shocked if anode runtime wasn't at the nucleus of every accelerator. I'm sure Dijkstra is half-spinning in his grave.
- pbiggar 10y ago
  Your puns are glorious!
jackmott 10y ago
Well for instance, Atom and VSCode have ~50ms (or ~49x) more input latency than editors written in C (source: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ ) But maybe we are willing to accept 50x worse performance and higher memory requirements and slower startup time because the language is nice and guarantees correctness....Well no, it is javascript, not Haskell or Lisp. So, what is the win here? Why have we collectively decided javascript is a good tool for making applications for the desktop?
- Azkar 10y ago
  Well now when someone removes left pad from npm your whole terminal can break.
  - joshmanders 10y ago
    No it can't. After that whole fiasco npm has made it so packages once published cannot be removed after a 24 hour window without npm manually doing it on your behalf, that is to make sure this instance never does happen again.
- codemonkeymike 10y ago
  I can't agree more, There is no reason that editing text files would need a full web browser which is buggy and slow. Many of these javascript apps which are replacing native apps use 500mb of ram, at some point you will have 5-10 of these things churning memory and consuming battery life and cpu cycles. (Note Atom, HyperTerm, Chrome, Slack, and Kitematic is already 5 browser apps)
- johnfn 10y ago
  * We've decided to use JavaScript because the community is there. Go ahead and write an IDE in Haskell - have fun rewriting all the libraries that already exist in JavaScript and soliciting for open source contributions when a tiny fraction of all programmers can understand it. I love Haskell and lisp, but you have to face the facts. * TypeScript is actually a good language, and gives pretty darn good correctness guarantees. * Your benchmark does not test against VSCode, which is much faster than Atom.

I'm curious why there's so much node/electron negativity circulating. (Although I guess asking for positivity when it comes to electron is a bit of a stretch :P)

mej10 10y ago

There are more and more applications based on it -- negativity increases along with popularity.

teamhappy 10y ago

Trivial apps depending on 14+ million lines of code is not a good thing. Edit: @michaelmior I think you know what I mean.

michaelmior 10y ago
I think a good terminal emulator is far from trivial. Edit: I'm not sure I do know what you mean. I agree that building trivial apps in Electron probably doesn't make sense. But my terminal emulator is something I spend most of my day using. If building that on top of 14 million lines of C++ gives me a better piece of software, I'm all for it.
- Jtsummers 10y ago
  https://www.openhub.net/p/putty https://www.openhub.net/p/putty Perhaps not as feature comlpete, and not my daily use terminal emulator, but it's only 110k lines of code. And it's not just a terminal emulator, that's just one thing it does in that 110k lines of code. EDIT: I was going to look up others but I'm distracted by other obligations. My point being: Terminal Emulators aren't actually that complex.
  - destructionator 10y ago
    I wrote a terminal emulator <https://github.com/adamdruppe/terminal-emulator> https://github.com/adamdruppe/terminal-emulator> and use it daily so it is good enough for me at least... clocks in at ~15k lines (including the gui helper lib). The biggest complexity is dealing with legacy terminals... and you can really just target the handful of xterm features programs actually use and get something working without a huge amount of code.
  - deleted 10y ago
    [deleted]
- alaroldai 10y ago
  Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's around 111K lines of Objective-C, with around 38K more lines split across Python and C++).
  - michaelmior 10y ago
    Maybe it's not better. That wasn't really my point though. I'm just saying that LOC is a fairly useless metric for evaluating software. Especially from an end user perspective.
    - themartorana 10y ago
      I agree with you, with regards to the end user caring or not, but there aren't many tech-unsavvy people using terminal emulators on the regular. So when Putty and iTerm2 both weigh in between 100-200k LOC and this is in the 14m LOC space, it's difficult to not make the presumption that that's a lot for a terminal emulator.
    - teamhappy 10y ago
      > I'm just saying that LOC is a fairly useless metric for evaluating software. That's just not true. Most open-source people want to be able to read, audit, fix, and (if it comes to it) maintain other people's code. 14+ million lines of code make this virtually impossible. (To be fair: Electron-based apps aren't the best example for the point I'm trying to make.) Rate of change is another very useful metric.
    - tomc1985 10y ago
      How so? It affects load time, understandability, binary size, dependency payload... I personally hate the load times. Node apps always seem to need to think for a second or too. Sublime Text v VSCode is pretty bad. Sublime Text v Atom is even worse. When you're moving fast and in your flow, it gets to be really annoying.
      - michaelmior 10y ago
- e12e 10y ago
  git clone git://git.suckless.org/st cloc --quiet st http://cloc.sourceforge.net v 1.60 T=0.09s (45.8 files/s, 56588.2 lines/s) ------------------------------------ Language files blank comment code ------------------------------------ C 1 497 253 3654 C/C++ Header 2 40 124 313 make 1 13 2 45 ------------------------------------ SUM: 4 550 379 4012 ------------------------------------ [ed: Actually, this get even more extreme for the terminal I actually use everyday, sakura[1]: apt-get source sakura (cloc sakura) Gives a total of 2490 lines of code, of which 2380 are C, the rest is CMake, make and Bourne Shell... that is cheating of course, as sakura uses libvte: which clocks in at ~45K lines of C - and a total of ~103K loc all together. Still a far cry from millions of lines of code... [1] https://bugs.launchpad.net/sakura https://bugs.launchpad.net/sakura ]
  - michaelmior 10y ago
    Sure. I wasn't arguing that millions of lines of code are necessary for a terminal. Thanks for the pointer to Sakura though! I quite like it and I might have to give it a try :)
jahewson 10y ago
How many lines is the JDK? or .NET, or libcpp?
- teamhappy 10y ago
  LLVM: 1.5 million (I assume libc++ is less than 500k) OpenJDK: 6.8 million .NET: 10.5 million Source: https://www.openhub.net/ https://www.openhub.net/
sgrove 10y ago
I agree, but I'd take it a step further - the 15+ million Lo(memory-unsafe!)C for the unix kernel other (all?) trivial apps sits on is also not a good thing.
- teamhappy 10y ago
  I agree with your larger point (I think) but for what it's worth: Most of those 15+ million lines are drivers you don't use.

Zolomon 10y ago

I believe it has to do with the amount of performance lost in the overhead with the electron stack versus a native implementation. Please correct me if I'm wrong.

michaelmior 10y ago
For the majority of applications, I'd imagine there's a negligible performance difference. Besides, any app built on Electron will run infinitely faster than one which wasn't built at all since the developer didn't want to learn another language. I'm not saying Electron is suitable for everything, but I think it has its place.
- city41 10y ago
  I still question Electron for "commercial quality" apps. The Electron runtime by itself is about 100mb. I've built an internal Electron app for work and for that it's absolutely fantastic.
- asdf1234 10y ago
  > negligible performance difference Using Atom or VS Code instead of Emacs cuts my battery life by a few hours. The Spotify desktop app that uses a ton of JavaScript is also horribly inefficient and has a big impact on battery life. None of this is negligible.
  - mitchty 10y ago
    On top of this, chrome/chromium versus safari is another 1-2 hours of battery. I think people vastly underestimate the energy requirements of web technologies.
  - woah 10y ago
    On which OS?
  - klibertp 10y ago
    On the other hand, my Emacs starts up in more than thirty seconds. To fully start up it needs to read some 2k loc of my own ELisp code and hundreds of thousands loc of required libraries. I use Emacs as a Jabber client, Python and Clojure development environments, file manager, image and pdf viewer, HTTP server, spreadsheet and note-taking app and (polyglot) Literate Programming environment. And that's just the beginning of what it can be used for. In other words, giving Emacs as an example of small and fast, natively written application is a bit unfortunate. Not to mention most of Emacs is written in ELisp, so the "natively" part is not even factually correct.

deleted 10y ago

[deleted]

sehr 10y ago

They're slow, big, and outrageously inefficient. Most electron apps also come with this weird web influenced "I'm kinda native y'all trust me" UI design which makes it even worse. My battery and eyes simply can't stand the things.

michaelmior 10y ago
Interesting. I haven't experienced the slowness of Electron apps. And outrageously inefficient doesn't really matter to me if it's efficient enough for me not to notice any slowdown.
- elmigranto 10y ago
  I think he meant inefficient in terms of battery power.
- jackmott 10y ago
  But if we are going to accept the computational inefficiency, what do we gain for it? If our only answer, collectively, as developers, is the richness of the ecosystem, then perhaps we should be moving our time and energies to make a rich ecosystem in either a language/runtime environment that performs better (C/Rust/OCaml/Whatever) or one that encourages correctness and/or speed of development. I know some people think javascript is the latter, and I can't prove them wrong, but I suspect that is not true.
- nojvek 10y ago
  Electron means your app runs on Mac + Win + Linux without much effort. It could also potentially run on the web browser. That is a huge sell.
ank_the_elder 10y ago
I have tried to edit a file with a little bit of long JSON that came from a server (less than 50K) and atom completely froze trying to display it. This was two weeks ago. I've ditched Atom entirely.

random28345 10y ago

> I'm curious why there's so much node/electron negativity circulating. "There are only two kinds of languages: the ones people complain about and the ones nobody uses". --Bjarne Stroustrup I'm pretty sure that applies to language runtimes as well. > Although I guess asking for positivity when it comes to electron is a bit of a stretch I like to stay current, and in this charged environment, I'd be shocked if anode runtime wasn't at the nucleus of every accelerator. I'm sure Dijkstra is half-spinning in his grave.

pbiggar 10y ago
Your puns are glorious!

jackmott 10y ago

Well for instance, Atom and VSCode have ~50ms (or ~49x) more input latency than editors written in C (source: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ ) But maybe we are willing to accept 50x worse performance and higher memory requirements and slower startup time because the language is nice and guarantees correctness....Well no, it is javascript, not Haskell or Lisp. So, what is the win here? Why have we collectively decided javascript is a good tool for making applications for the desktop?

Azkar 10y ago
Well now when someone removes left pad from npm your whole terminal can break.
- joshmanders 10y ago
  No it can't. After that whole fiasco npm has made it so packages once published cannot be removed after a 24 hour window without npm manually doing it on your behalf, that is to make sure this instance never does happen again.
codemonkeymike 10y ago
I can't agree more, There is no reason that editing text files would need a full web browser which is buggy and slow. Many of these javascript apps which are replacing native apps use 500mb of ram, at some point you will have 5-10 of these things churning memory and consuming battery life and cpu cycles. (Note Atom, HyperTerm, Chrome, Slack, and Kitematic is already 5 browser apps)
johnfn 10y ago
* We've decided to use JavaScript because the community is there. Go ahead and write an IDE in Haskell - have fun rewriting all the libraries that already exist in JavaScript and soliciting for open source contributions when a tiny fraction of all programmers can understand it. I love Haskell and lisp, but you have to face the facts. * TypeScript is actually a good language, and gives pretty darn good correctness guarantees. * Your benchmark does not test against VSCode, which is much faster than Atom.