It doesn't require it, that's just what they choose, and it has little to do with the language. (Besides, if you actually observe them—and ignore what they tell you about liking JS—then it's clear that most of them hate their preferred language.) Languages and the bindings that a particular runtime exposes are orthogonal. You can have GTK apps written in JS, for example, or you can write a program in JS that compiles into a binary that runs on a microcontroller[2].
This is much more of a problem with the culture of Electron and the adjacent NPM ecosystem than it is anything else. Conflating the source of these problems is a great way to tank any would-be activism meant to solve them.
1. <https://en.wikipedia.org/wiki/GNOME_Shell>
2. <https://github.com/Moddable-OpenSource/moddable/blob/public/...>
I will do a bit more reading up on this.
Cheers!
It is readable unlike php, dynamic as root from lisp, wide use and hence accessible.
But given its original history and neglect, it takes decade to fix all issues it presented in other area.
Still I would not dismiss it. Yes it is slow. But it is not Java type.
It can be better is the motto.
That is a good thing, yes.
But TBH I wish Eich had just embedded Lisp in Mozilla instead.
> wide use and hence accessible.
"Everyone uses it" is not a good argument for anything at all, really.
> it takes decade to fix all issues it presented in other area.
Well, yes, it has had a lot of R&D done upon it to make it quicker, but again, that is not an endorsement.
> Still I would not dismiss it. Yes it is slow.
It seems to me that in the 2nd sentence there you contradict your own previous sentence.
> But it is not Java type.
What is so wrong with Java?
More OSes support JVMs than support Javascript. JVMs have few requirements and can even run on DOS. JVMs too have a ton of R&D into making them faster and better. There is rich tooling and support to make Java apps scale, such as Enterprise Service Buses, e.g. JBoss FUSE, which allows apps with clashing namespaces to run on the same host at the same time, and even communicate.
There are tools for writing native UIs for Java apps.
I would rather have Java apps than a Javascript one, frankly. At least with Java apps, one JVM in your OS supports all your apps, whereas JS needs one per app, or even one per window or tab in some apps.
> It can be better is the motto.
That is not a good motto. That is in fact a really bad one.
And the VBScript threat was later, from Microsoft doing it in IE3. If I'd missed the Netscape 2 boat, it's likely VBScript would prevail (Netscape 3 was originally 2.1, and 4 was originally 3 but delayed a year; find "Collabra-driven" in https://www.jwz.org/doc/groupware.html).
My #1 annoyance these days, because it is so egregious, is Electron apps.
I guess because the only language some programmers know is Javascript, of which I know little but what little I know places it marginally above PHP in intrinsic horror.
So people write standalone apps in a language intended for tweaking web pages, meaning that to deploy those apps requires embedding an entire web browser into every app.
And entire popular businesses, for example Slack, do not as far as I can tell have an actual native client. The only way to access the service is via a glorified web page, running inside an embedded browser. Despite which, it can't actually authenticate on its own and needs ANOTHER web browser to be available to do that.
Electron apps make Java ones look lean and mean and efficient.
Apparently, expecting a language that can compile to native machine code that executes directly on a CPU, and which makes API calls to the host OS in order to display a UI, is quaint and retro now.
And it's perfectly acceptable to have a multi-billion-dollar business that requires a local client, but which does not in fact offer native clients of any form for any OS on the market.
It's enough to make me want to go back to DOS, it really is. Never mind "nobody will ever need more than 640kB"... if you can't do it in 640kB and still have enough room for the user's data, maybe you should reconsider what you are doing and how you are doing it.