The very same can be said about people looking down on Electron. Most of them can't write decent native apps to begin with.

I used all of win32, Qt, GTK, wx and Cocoa to name but a few. They all suck in one way or another. Suggesting people are poor native developers for refusing to learn these frameworks completely disregards the fact that most people using these frameworks are bad developers to begin with.

For the average application going native will easily triple your development time and costs for absolutely no noticeable performance difference.

> If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?

What if the only difference between the web and desktop apps are that the desktop app can open local files while the web app downloads them? Are you going to write two apps in that case? This would be a mediocre economical choice at best as you're more than doubling the production costs for a difference nobody is going to care about.

Sublime text still smokes Atom and VSCode in the performance arena.

Why isn't everyone using Spacemacs then?

Visual Studio is much, much slower than all of them yet its still an incredibly popular IDE for some reason. It has endless flaws, one of them being its still 32-bit and often crashes on larger projects. (The last game I ported to the PSVita would hang VS for minutes sometimes, often ending with out-of-memory errors, we'd reboot VS between every profiling session.)

For a good chunk of users, features and ease of use are more important than performance (especially when most of the time it really, really doesn't matter for an editor.)

Because people don't know any better, shun anything that isn't their pet technology and generally sit on the wrong end of the Dunning-kruger effect.

That is not a useful indicator. There's a reason that 'editor-wars' is a running joke.

This was the exact problem I needed to solve that led to my first Electron app.

Needed to recursively crawl a directory and generate a report on all pdfs found and the total pages in each pdf.

It seemed silly to learn a new language and ui kit when I could glue together some wen technology over a weekend and make it happen.

http://designbymobi.us/how-i-built-my-first-desktop-app-in-3...

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

HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

[Citation needed]

Sorry, JavaScript may have gotten lucky being the lingua franca of the web, and it might not be perfect or even great, but it's "good enough" for most purposes these days.

If it were "terrible" you would expect at least one compile-to-JS [1] to have gained a non-trivial amount of traction by now. The supersets of JavaScript like Babel, TypeScript, and Flow are more popular than "not terrible" languages like ClojureScript, Elm, etc.

1. https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

There is more there than dynamic typing.

Ruby and Python do not fit it.

1 - Or, in the case of Python, mostly dictate.

It's fine to have some kind of option for data whose type isn't known until runtime. This stuff happens, and languages that insist there's no such thing make dealing with it more difficult. But this is the rarer case! Why optimise for it rather than for the more common one?

Dynamic typing isn't optimization; dynamic typing without any static analysis is the utter lack of optimization.

    > It feels like forcing a square peg into a round hole because the 
    > developer is seemingly unwilling to consider more appropriate
    > technologies outside of their comfort zone

It just makes you feel good to dismiss other people as lazy or unwilling to venture outside their comfort zone, but that's more of a revelation about how you view others.

oh do us a favour, that's just YOUR opinion