At this point it's like somebody saying "English is a terrible language". Yeah sure but what else are you going to use?

Ugh, why can't everyone just speak a real language, like Korean. Agglutinative languages are where it's at.

> I can never see the point of comments like these. Not one person who reads that will have his mind changed.

I wasn't expecting to change anyone's mind with that. There are more robust programming languages that don't have the same inconsistencies and idiosyncrasies and encourages better practices in general (even though it is true than you can write terrible code in any language).

> No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.

That is true, but consider that the end product is not necessarily meant to be most convenient for the developer. Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives. I have read in the past that Electron also posed some difficulties for screen readers, for example (although I'm not sure if that is still the case), which might not be something that impacts you as the developer, but which can make it harder for someone to make use of your software.

This means absolutely nothing. Otherwise everyone would be using Haskell, Coq or Agda. I'm willing to bet your favorite language has an insane amount of flaws as well (hint - they ALL do, otherwise we'd have converged to the "one true language" as an industry long, long ago.)

You can make an argument to say C++ is terrible, Java is, Ruby is, Python is, and it means absolutely nothing other than showing of your own insecurities. You can build great and mediocre things in any language and any platform. People do every day.

Also, if the developer is not one of the users of the software, you've already thrown a good chunk of quality out the window right there. You're simply not going to have the vision required to build the optimal user experience.

> Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives

Usually the choice for the user is between "have an electron app in a month" and "have native app in a year", most users prefer to not wait, and when native app comes in a year, electron app will have much more polish, and run acceptably on new hardware.

The issue is not about 'protecting poor users'.

Most electron apps are quick experiments, to test out an idea without spending too much resources on it.

If idea is great, and performance is an issue, and there are enough users to get a team of highly skilled developers to work on it, they'll create native app, replace electron version (and then embed js vm to support plugins:).

    > but consider that the end product is not
    > necessarily meant to be most convenient
    > for the developer.

Sorry, but life isn't fair. Everything including software involves trade-offs, and perhaps ones that you would not have made yourself.

For that reason, your post along with the blog post comes off as a tantrum. And if users really cared about these things, then surely you'd be able to swoop in and capitalize on it. But we both know that's not happening.

>> JS is a terrible programming language

> I can never see the point of comments like these.

At minimum, I think the hope is that js-only programmers become aware that there are alternatives. And hear that the people who use those alternatives often find them better.

The arrogance in it, though, is that because people who like JS are "obviously" wrong, the reason must be that they don't know (enough) other programming languages or don't know them well enough.

I have used a number of different programming languages before JS, a couple of them more extensively and for a longer time than JS. I like JS. I understand its flaws. I also understand that all programming languages are terrible in their own unique ways -- I have accepted JavaScript's terribleness and a lot of it is addressed by ES2015 and beyond. I prefer JS's terribleness over that of other languages.

I like to make fun of PHP programmers the same way, but I understand that there are PHP programmers who are able to see beauty in PHP or have found their own perspective of PHP which makes it less terrible than the alternatives. I'm not one of them but I can relate to them. It's called empathy. OP lacks it.

First, X-only programmers are obviously wrong, whatever is the value of X.

That said, yes, somebody ought to love JS in a not blind way. Big numbers work that way. If that's you, I don't think those comments are for you. All languages have different flaws, every flaw relevance varies by context, and contexts are incredibly subjective. Yet, some contexts are much more common than others, and many people preach in support languages that are harming them because they don't know any better.

I did C, C++, Java, PHP, VBA and JS and can't tell why so many people have constant beef with JS. I mean especially after all major platforms have adopted ES2015.

For me, IO in JS is still kind of a hack. It still imposes an structure on my code that is different from the one I want.

IO in what? The browser? Node? If you mean node, what IO specifically? `http.createServer`? `fs.readFileSync`? `fs.createReadStream`? `fs.open`? `fs.readFile` with node callbacks? Promises? Streams? Observables?

Without context it sounds like you saw a bunch of nested callbacks in a Node.js example and judge the entire language based on that.

You'd be surprised how many people I've met that enjoy JavaScript. Nearly everyone I've met that hates JavaScript either didn't bother to learn it ("It's just a scripting language") or is just upset that they can't use their favourite programming language all the time (this is how we ended up with CoffeeScript, Sass and Haml and why everything in the Java world is eventually wrapped in XML).

I've seen enough different use cases and teams and programming languages to understand there's no point in being arrogant about language choice: if a team already knows a given language, it is most likely the right tool for the task, unless the benefits of replacing it are worth the overhead of properly switching to and gaining competence in another language.