> Electron is not a simple adhesive, but a careful design > >> Electron enables you to create desktop applications with pure JavaScript by >> providing a runtime with rich native (operating system) APIs. This doesn’t >> mean Electron is a JavaScript binding to graphical user interface (GUI) >> libraries. Instead, Electron uses web pages as its GUI, so you could also >> see it as a minimal Chromium browser, controlled by JavaScript. In Electron, >> the process that runs package.json’s main script is called the main process. >> Since Electron uses Chromium for displaying web pages, Chromium’s >> multi-process architecture is also used. Each web page in Electron runs in >> its own process, which is called the renderer process. In order to keep >> Electron small (file size) and sustainable (the spread of dependencies and >> APIs) the project limits the scope of the core project. Electron uses just >> the rendering library from Chromium rather than all of Chromium. > > As for JavaScript, Douglas Crockford said: "JavaScript is the world's most > misunderstood programming language. JavaScript is becoming better than ever. > I mean such as ECMAScript6 (Module, Class, generator, Promise) ECMAScript7 > (async await)."
Heh, that JS hype reminds me of ol-time tobacco ads: [buzzwords](http://languagelog.ldc.upenn.edu/nll/?p=30359), distractions, excuses for bad habits... It doesn't negate the [central points](http://paulgraham.com/disagree.html) of the criticism, that NodeJS and especially Electron **take badly structured, unreliable, syntactically ugly, and slow Web UI/UX technologies that everyone uses mainly because they have to, and needlessly spreads that cancer to a new domain where better technologies already exist**. JS is popular because it was the only choice for client-side scripting on a platform supported by pretty much every computer / smartphone user in the world. [Better](http://harmful.cat-v.org/software/node.js) [programmers](http://live.julik.nl/2013/05/javascript-is-shit) [than](http://www.davidarno.org/2010/05/18/why-javascript-is-a-toy-language/) [I](https://simpleprogrammer.com/2013/05/06/why-javascript-is-doomed/) [have](http://sircmpwn.github.io/2016/11/24/Electron-considered-harmful.html) [enumerated](https://medium.com/javascript-non-grata/the-top-10-things-wrong-with-javascript-58f440d6b3d8) [its many](https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because) [shortcomings](https://github.com/nanoant/WebFrameworkBenchmark). And ES.zomg.next is "not a safe cigarette" \- it's still a terrible programming language built on a terrible foundation, and throwing more layers over it doesn't make it good. Most colleges don't mind teaching bad technologies if that's what they think the marketplace demands; most software businesses don't mind using bad technologies if that's what they think the marketplace provides (thus making coders easier to replace); and most people just don't know better. I've done some informal automated analysis of language package ecosystems recently: NodeJS came on the bottom (and Haskell was on top) in package and meta-data coherence. Scriptkiddie NPM packages [breed like rabbits](https://en.m.wikipedia.org/wiki/R/K_selection_theory), with little regard to quality. There will always be fewer _Osteria Francescanas_ than _Taco Bells_... Electron is like a formerly-homeless guy who comes into money and now lives in a mansion, but still insists on making all furniture from milk crates and cardboard. Just because you can do something [doesn't make it a good idea](http://sircmpwn.github.io/2016/11/24/Electron-considered-harmful.html). And Electron not the first effort to do this (ex: [XUL](https://en.wikipedia.org/wiki/XUL) in 2006). You've previously made arguments from popularity, so compare the desktop market share of HTML/JS-pushers like XUL and Electron compared to real UI toolkits like GTK & Qt. Another reason to dislike Electron is it's only really good for Windows / Mac / Linux workstations with resources to burn. The only things that crashed on my Ubuntu laptop over the past year are Atom and VS Code (which I've only used for its top-notch Nim support). On lower-end / older / mobile devices you get [terrible speed](https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-performance-dec-2016/), wasted battery life, and there's no portability to other OS'es. I'm actually a BSD nerd, but these days mostly on the server, and I now use Android 2-in-1 client tablets for more battery life off-the-grid - Electron doesn't run on any of that... > In addition, you can also choose excellent TypeScript [...] TypeScript is more verbose than Nim, [is more restrictively licensed](http://copyfree.org/standard/rejected), and has far fewer features. It is [generally slower than Dart](https://benchmarksgame.alioth.debian.org/u64q/typescript.html) and [untyped JS](https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=typescript&lang2=node), and thus for binary targets it would be _A LOT_ slower than Nim. > > **Compiled is always better than interpreted**, because no code format will > > ever be simultaneously ideal for both human programmers and computers. The > > ideal programming language / compiler is the longest possible bridge > > between the human devs' coding comfort and the efficiency / correctness of > > the resulting binary. >> >> <!-- START of the part you've quoted without context. --> >> >> Computers becoming faster (including latency to a compile service in the >> cloud) should have encouraged smarter compilers instead of more interpreter >> / VM bloat. >> >> <!-- END of the part you've quoted without context. --> >> >> Most of the time we care little about execution efficiency (unless a piece >> of code is executed zillions of times), but it will become important again >> with IoT and beyond, as programmable nanotech robots become a reality. > > Today, distributed technology and big data processing technology has made > great progress. People can use thousands of machines to compute parellelly. > People are more concerned about logic algorithms, intelligent analysis and > visualization result. Who care it is a compiler or interpreter??? Your selective quoting has made it look like I was against VMs and run-time optimization of any kind (for which you can have libraries for almost any language), which isn't true. My main point was about the importance of smart compilers building a bridge from greater dev productivity to more correct and efficient executable code, the latter being particularly important for IoT / nanotech devices. Your response ignores my arguments and throws yet another distraction. [Squirrel!](http://www.urbandictionary.com/define.php?term=squirrel&defid=5962923) [[No pun intended.]](http://www.squirrel-lang.org) Now we jump from talking about IoT to distributed Big Data (even though like >99.9% of code is written to run on one device) - how does that negate my criticism of JS? Taking an uglier, slower, unsound programming language into distributed context doesn't change any of those shortcomings.
