Why do you speak English when you could be speaking French? Because it's what you know, and lucky for you it's everywhere and you don't need to learn French.

I'm making some assumptions about you as a person but you take my point I hope. People use JavaScript over other languages because they already know it and, hey, look, you can use it anywhere. Sure, it might be more efficient to go and learn python or C++ or assembly or whatever but most people are happier to leverage the skills they already have than go and learn a new language for one app.

I'm a JavaScript coder by profession and in my extremely limited spare time I want to build things, and if i use JavaScript it maximizes my time.

Exactly. People mock me for using Python and MongoDB at hackathons but I have won my first Hackathon cause I spent my time getting code done and not thinking too hard about it.

Exactly. What did you win with out of interest?

I participated in this years TADHack Mini in Orlando:

http://blog.tadhack.com/2018/03/12/tadhack-mini-orlando-2018...

It was a lot of fun and the first time we ever worked with any Telecoms / VoIP companies. Also planning on competing on TADHack Global this time joining forces with another team. Didn't win much since others won as well, apparently you could use all the vendors, we only used one.

TADHAck Global is this year in October for anyone interested: https://tadhack.com/2018/global/

Attendance to hackathons deserves mocking in its own... :)

Can you please explain why? Genuinely curious.

The first two bad things that come to mind: squeezing free time from developers and making hype out of it for peer pressure.

I don't know about that, this one was at the college I used to work at before and I got to mentor two young developers and I continue to mentor one of them. Not everything is as bad as people might think, and some developers work different from others. We saw some amazing projects out of TADHack Mini.

Lastly: Nobody has our code but we ourselves. It really depends on who hosts the Hackathon and the purpose of it. We've heard of businesses being bootstraped directly out of this specific Hackathon.

Also, "you can use it anywhere" really does apply to Javascript in a way that it doesn't to other languages (at least, not until there's full WASM<->DOM integration and a good set of compilers that uses that).

But don’t you believe in using the right tool for the job?

JavaScript is barely acceptable on the web, but again it’s a necessary evil as you can’t easily use anything else.

But why use an inadequate tool on the desktop? The perceived time you save upfront would backfire later on.

Now I’m not saying go and spend a year learning another language just to make a side project (by all means use JS or whatever you’re familiar with), but if you’re making a production-grade app, PLEASE use the right tool for the job and it ain’t JS.

I, for one, am sick of JS & Electron contaminating apps I use daily like Spotify, Slack, Signal, Telegram, etc. I wouldn’t mind it too much if this was a niche thing and there were alternatives, but there aren’t. JS on the desktop should die.

The right tool for the job is very opinionated. Clearly an awful lot of desktop devs think js is the right tool for the job because electron is everywhere and projects like this very one we're commenting on exist.

My opinionated view on "the right tool" comes down to the distinction between foreground and background apps.

I do think electron is not the right tool for the job when it comes to Spotify, because Spotify is something that mostly runs in the background and should be super performant.

On the other hand I use vscode all day every day, and I'm happy for it to use as much ram and cpu as it does because its always in the foreground - it's the main thing I'm using when I use it

Edit: I should add I think we need to find more comparisons to continue this electron debate though. Vscode is always the hero and slack and Spotify are always the villain

I'm there with you being sick of Electron apps on the desktop. The problem is, compared to the JS ecosystem, GUI apps development on desktop with any native technology I know is super bloated, slow and crappy. While I've just started trying to use Elm recently, and the speed of iteration when using it totally amazed me, so that now I cannot longer say that I don't understand why people do that. As much as it pains me.

I couldn't agree more. Ever since switching from Slack to wee-slack I have never run out of memory on my laptop, which used to be a problem every once in a while when running so many instances of electron.

Also Telegram (at least the Linux desktop client) is not electron, it is QT. Maybe some problems that people link exclusively to electron are not limited to just that platform.

I don't really think JS is bad. I actually prefer it to most languages.

It's fast, concise, flexible, and has lots of modern features. It has some weak spots, but all languages do. When people are so ideological about the language it tells me they either haven't used it much or they are unrealistic about flaws in other languages.

> haven't used it much

I actually used it, and hated it quite a bit (although ES6 solves most of my gripes with it).

I understand and appreciate the necessity of JS on the web. JS is also the perfect tool for that job as it’s been designed with the web & browsers in mind, closely tied to HTML & CSS, and while it has overheads those are a necessary evil in an environment where it’s commonplace to execute untrusted code.

But it’s however completely inadequate for the desktop. Your users already trust you since they run your binary Electron wrapper, so the “untrusted code” argument goes out the window. You’re basically taking on an extreme overhead (in terms of battery life and RAM usage) for no benefit at all. HTML/CSS is not that great either, IMO native elements provided by the OS deliver a much better UX and actually behave consistently across the entire OS.

> you’ve got the freedom to choose from dozens of lovely languages that actually are a pleasure to use?

Well there's your problem. If my choice is to wrap my existing SPA in electron in one day vs a 6 month make-and-maintain-a-copy-in-another-language, then I think the choice is obvious.

Then you have a dozen languages to choose from? All of them are lovely except JavaScript? That sounds pretty biased. If I'm going to write a desktop application and take advice from strangers, I need to know that my advisor completely understands where I'm coming from and where I'm trying to go. I don't want to get burnt because a hater is trying to give me unthoughtful "literally anything but" bad personal vendetta advice thinly vailed with technical concern trolling.

Then I have to pick one of 12 languages? I don't need "well literally anything but", I need a well written set of tutorials and/or case study demonstrating that one option is superior to JS and is written to bring JS devs to an understanding of if the tool being presented is what they need to use or not.

Normally I would agree, but GUI development with Vue is such a lovely experience. It takes advantage of many of the newer JS features to make this possible (automatic data binding via property get/set interception, for example). As a consequence it's hard to imagine providing the same in another, better language.

.NET has been doing it since 2008.

Is this something that's had good crossplatform support since 2008 or more recently?

No, it is something that has been doing "automatic data binding via property get/set interception, for example" since 2008, so it is easy to see it in an language that isn't JavaScript.

Additionally, Xamarin is older than VueJS.

Yeah, I've worked with XAML and such in .NET-land. DependencyProperties are nowhere near as painless and transparent as the state of things in Vue. Doing computed propeties, trying to use converters in a sane way, setting up templates for repeated items - all quite clunky and arcane. This falls out of doing interception at the library level rather than the language level, I think.

It would be a bigger deal if it was not windows only.

Xamarin never was Windows only.

And Mono was a thing before .NET Core came into the scene.

ES6 (or 7) is a much better language than a bunch. Adding in the types through flow or typescript, and now it's a pragmatist's heaven.

Incredibly pragmatic, which is perhaps the most important thing possible.

an approach that assesses the truth of meaning of theories or beliefs in terms of the success of their practical application

You can have your ideal language, we'll just keep building great stuff in a good enough language.

> Great stuff

Like what? A chat client that uses 1+ GB of RAM and melts batteries faster than a flamethrower? No thanks!

It almost looks like this Electron/JS trend was started by CPU manufacturers who realised that current CPUs have more than enough power for everyday tasks, and needed a way to create demand for even faster CPUs. I’d say Electron (and JS in general) was pretty effective at that.

> manufacturers who realised that current CPUs have more than enough power for everyday tasks, and needed a way to create demand for even faster CPUs

Lol.

It's a common trend across software. Try comparing office 2003 to office 2013. Office 2003 starts instantly on a modern desktop and uses minimal RAM. Office 2013 takes a good four or five seconds to fire up and uses a few hundred mb memory. And they both do exactly the same thing. With cpu speeds and ssd proliferation there's no incentive to keep things low footprint any more.

> It's a common trend across software.

Not at this scale though. Office 2013 uses maybe 2x or 3x the amount of RAM compared to Office 2003.

A chat client like Slack routinely uses up to 1GB while a native equivalent would use 100MB or less. We’re talking about a 10x increase here - that’s unacceptable.

Have you sources for this 10x claim? Do you actually have a native slack client that uses 100mb because I'd love to see it.

Slack is essentially fancy IRC, so we can take any IRC client as a baseline for how much RAM it should really use.

Let’s take HexChat (https://hexchat.github.io/) for example - it does most of what Slack does, plus has advanced features not available on Slack like a Lua, Python & Perl plug-in API. It used less than 100MB or RAM after running for days on a Linux machine.

Slack is usually well into the GB of RAM after running for a few days.

> Slack is essentially a fancy IRC

The keyword here is fancy. Hexchat is an IRC client, sure, but it is minimalist. That would be like comparing a text file to a PDF and asking why the PDF needs so much more RAM when they're basically the same.

I feel like you're mutating the argument from "electron uses 10x RAM compared to native apps" into "an IRC client doesn't need to use so much RAM"

The proper comparison would be either a full, feature complete native Slack client with all the same bells and whistles that runs under 100mb, OR an electron port of hexchat with its text only interface that uses 1GB+

Well, I would understand a chat client taking more RAM should I ask it to pare & display some HTML, or videos, or PDFs. I'm not. I'm using Slack just like IRC - 3 users and a single channel even. No images, no videos, no HTML, no link previews, etc. That thing still absolutely melts down my CPU and RAM.

I get what you're saying, but we already know that electron (specifically embedding a whole browser with DOM) is the culprit. There are some native UI toolkits with bindings available for NodeJS, if slack was refactored to replace electron with one, it would probably peak at 2x as much RAM than HexChat rather than averaging 10x to 100x.

100x now? You're saying there are electron apps in the wild using 10GB of memory? I was trying to argue that the 10x claim was an exaggeration but you've just leapfrogged that.

That's what Vuido is for, now there's no Electron.

ES6 an typescript are wonderful languages and have little resemblance to the jquery-esque JavaScript era.

Think C# rather than jquery.

But you could just use C# instead on the desktop, and be happier.

The world's largest computing markets dont use desktops. India and China are 80% mobile traffic. These people have never seen a desktop or a laptop in their life, but use the web and mobile apps with a lot of comfort.

The JS developer ecosystem is very popular as a consequence of the mobile-first ecosystem. And I think it is a great thing that desktop SDK are evolving to be JS first.

Are there good cross platform UI solutions in C#?

Xamarin.Forms and Avalonia.

Avalonia has no accessibility support, so it's unusable for blind people via screen readers, among others.

Yes, it is very important, yet unless it is a government project, it gets ignored by project delivery acceptance requirements.