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?
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'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.
"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.
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.
That is a huge sell.
Edit: @michaelmior I think you know what I mean.
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.
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.
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.
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.
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.
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
------------------------------------
apt-get source sakura
(cloc sakura)
OpenJDK: 6.8 million
.NET: 10.5 million
Source: https://www.openhub.net/
Please correct me if I'm wrong.
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.
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.