JS is a necessary evil on the web, but why inflict such pain to yourself when you’re able to use something else?
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.
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.
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.
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.
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
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.
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/
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.
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.
Additionally, Xamarin is older than VueJS.
And Mono was a thing before .NET Core came into the scene.
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.
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.
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.
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.
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.
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+
Think C# rather than jquery.
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.