Hacker News Reader

Comment by michaelmior | Hacker News Reader

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)

View on HN

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/ )

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?

Well now when someone removes left pad from npm your whole terminal can break.

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.

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)

* 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.

> * TypeScript is actually a good language, and gives pretty darn good correctness guarantees.

TypeScript's main focus is IDE tooling, not correctness. Here is an example on how generics are unsound in TypeScript: http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.htm...

If you want to write JavaScript with a type system focused on soundness, you should give [flow](https://flowtype.org/) a try.

I don't think that anyone argued TypeScript is 100% sound, nor is that a meaningful goal to hit. I find TS to be a solid language that gives me reasonable confidence in my code. (The tooling is also great!)

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

Your puns are glorious!

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.

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.

I think he meant inefficient in terms of battery power.

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.

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.

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.

Trivial apps depending on 14+ million lines of code is not a good thing.

Edit: @michaelmior I think you know what I mean.

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.

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.

I wrote a 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.

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++).

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.

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.

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

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.

I was talking more about how it affects end users. Understandability of the code and dependencies are irrelevant in this case. Load time is important, but LOC is only a proxy for that metric. It's not totally unreasonable to imagine a well-written app with twice the code start faster than a poorly written one.

  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 ]

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 :)

How many lines is the JDK? or .NET, or libcpp?

LLVM: 1.5 million (I assume libc++ is less than 500k)

OpenJDK: 6.8 million

.NET: 10.5 million

Source: https://www.openhub.net/

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.

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.

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.

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.

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.

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

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.

On which OS?

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.

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

Reply on news.ycombinator.com