Time to deliver new features matters. Skill reusability matters. This is the economic reality that makes electron attractive to all the people that decide to use it to build software.

The alternative to electron is not always a leaner different framework. It may also be not building software because you don't have the resources and skills needed.

e.g. An end user using Discord and Slack has to download 2 Electron applications (~500MB of disk space) and this is for a chat app, Ripcord [0] can do both with less RAM resources and disk space.

> The alternative to electron is not always a leaner different framework.

You can have both, there are newer frameworks popping up such as Flutter, React Native and Reason Native.

[0] https://cancel.fm/ripcord/

I didn't say that there are no other frameworks. The ones you provided all break the "transferable skill" requirement (React native a bit less so but still).

If you prefer to install ripchord instead of discord and slack nothing prevents you for doing so. Let me write a few comments about it:

- it made sense building it for the author because those two services already existed and already had enough users. Also the author has the skills needed to build it.

- it won't be free

- it is not feature complete compared to the reproduced services

So it might attract users depending of the perceived gain from a faster software vs its price and the missing features. It also has to win over all the people that have already installed the slack & discord clients. If it gains significant market share there are 2 risks: intentional api breaking changes by slack & discord, and them redoing/optimizing their client to win back the lost users. Most probably: they don't care about the client part. They are selling a service and this new client might make some of their users happier.

So we see that even though ripchord exists, it does not mean that electron hasn't helped in making two new services available. The ripchord author might be able to reproduce a client with a better tech, but that doesn't mean he has the skills to create a whole new offer (market research, sales, backend administration, etc).

edit: format

At this point what you have can't even be called skill, on?

If you skim a tutorial and release an unmaintanable mess because you lacked experience with your tools users are not going to forgive you because thank god you did not use electron.

You might have some time to learn all this. Or not. Maybe you are busy finding funds. Maybe you are pitching companies to get your first prospects.

It might not be the future you or I want, but it is the future that the majority of end users want. Market forces don't always work for getting users what they want (see privacy) but in this case the money is talking. Slack's desktop app is a classic example of being a memory hog, but Slack has been enormously successful.

Don't Apple already do something similar for battery hogs? May be misremembering, but I'd have thought a similar principle applied.

Half the challenge of course would be dissuading the vendor from excluding their own apps from these notifications.

But yes, on OS X, the battery drop-down will list any apps that are consuming significant amounts of energy. For me these are constantly Chrome and Intellij IDEA.

Well, JetBrains is one of few choices that's even more of a hog than Atom.

  > There seems to be an opportunity here for platform vendors like Microsoft
  > or Apple to be a bit more aggressive about "this application is what's
  > slowing you down" notifications.

Every time you hear someone complain about how their new PC is so slow to do $trivial_task, think again. Most users unfortunately don't know any better, nor have the inclination to teach themselves to.

Modern OS's don't really have an equivalent to that. Probably because usage has become more fragmented.

uTorrent is perhaps another bad choice.

uTorrents first public beta release was in late 05 Qbittorrent was released in early 06.

By the time about anyone was aware of uTorrent Qbittorrent was already a thing and as good. uTorrent went on to become first proprietary and ultimately ended up installing malware on users system and mining coin whereas Qbittorrent is still awesome.

Slack with its famously crappy performance and battery destruction is probably another bad choice to make the case although I hear its improved lately. Maybe wait another year to use it as an example so people have time to forget how much it sucked.

I would totally stay with comparing say visual studio code to visual studio and hope your audience doesn't remember Emacs and Jetbrains products are also cross platform without electron.

I think instead you should hope they do remember those.

I wouldn't say that emacs is a shining exemple of desktop UI. Everything is based on text buffers and keyboard commands. I don't see this type of application getting the same scale of adoption as vscode or slack (and this comes someone who has used emacs as an editor for python and org mode files for 3 years).

I don't hate Electron. I just won't trade _my_ limited CPU, memory, and bandwidth for _your_ inabilility to learn Qt. Your Qt using competitor will get my business.

Not to mention a lot of QT apps bundle the entire thing as well, so I have in my PC several versions of qt5win.dll and friends, many exactly the same.

Furthermore QT apps are not a guarantee of fast programs, and often the interfaces look horrible.

I fail to see a huge difference in programming methods, even if the QT runtime clocks at about 50mb instead of 500mb.

Here is an example: https://imgur.com/a/RZZK7nA

The hardware industry has trained them to think, "This machine is slow. It must be getting old. Time to get a new one!"

In reality, they've probably just accumulated applications that run in the background and/or put less developer time into constraining resources.

I was able to find it by:

1. Go to discord

2. Control + Shift + I

3. Application Tab

4. Storge/Local Storage/discordapp.com

5. Refresh with Control + R

6. Token will appear, quickly copy it.

I don't understand what personal information is contained in a discord token, or who it is being given to in this example

Cross-platform desktop apps with Reason

Recreating all widgets is a huge task and such a framework needs a lot of dev momentum behind it to be usable in production. I really like everything Revery promises but right now it's just not an option for anything beyond simple apps for personal use.

End users do want it as seen by the commercial success of Electron based products, including completely free products like VSCode even when Sublime and Visual Studio exist.

Features and functionality almost always overrule performance. I'd rather wait a little longer to do something than not be able to do it at all.

My main laptop has 4GB ram. I cannot afford to use 500mb for a chat app. Beside, did you even go outside? A lot of people cant afford (or dont need) a computer with more than that. For example lets see in a community where having a lot of ram matters. In the Steam Community, around 12% of people have 4GB or less. https://store.steampowered.com/hwsurvey#cat0_stats_row

If you need more power, that's fine. But does an administrative assistant, or a lawyer, for that matter? Give me old-fashioned desktop applications, and I can compete with you at hundreds to thousands less per head. How many people doing that does it take to make a software engineer's time worth the trouble?

It's worth mentioning that this madness is mostly an issue in the JS community; everyone else is getting along just fine. And, as with npm, react, angular, electron, etc. etc. the JavaScript programmers act like these issues - already solved countless times elsewhere - are universal constants.

This is the old problem: the middle manager can wave a sheet of paper around saying, "my team used an agile electron methodology to disrupt the plastic fork industry!" or whatever, and get rewarded. He cannot, however, explain that by using something else, he saved long-term technical debt, maintainability, etc. because those costs are not immediately visible.

I'm kind of hopeful for flutter. God willing, it will solve our problems...

I attribute this mainly to the younger generation of developers, most of whom have never experienced computing with fewer resources, nor have any idea of the amount of resources something should take. That can partly be blamed on education and the "premature optimisation" argument that still gets thrown around as a random excuse to do something terribly inefficient.

I attribute this to the older generation of OS developers and project managers and CEOs, who have not offered easy to use, powerful tools to create cross platform applications.

If the programming language is not memory managed, it doesn't matter (so anything C or C++ based is out).

If it's not cross platform, it doesn't matter (Win32, WPF, Cocoa, etc.).

If the priorities of its developers keep shifting, it doesn't matter (Qt from the old Qt widgets to the new declarative ones).

If it doesn't support high DPI or responsive design, it's out.

And I say this as a middle-aged developer, my first PC was a Pentium 1 and I've also used home computers from the 80's.

The incentives for OS creators are to create walled gardens. Which they've done successfully. But because of that, they can't also bitch and moan about "slow cross platform applications" when they do everything they can to kill or hinder cross platform stacks.

This happened nearly a decade ago.

1. More value used to be placed on efficiency.

2. As time went on, the value of powerful, cross-platform tools and platforms became more obvious.

3. Since this was later in the evolution of the industry, the people who made it happen were a different generation that didn't prioritize efficiency.

That is to say, perhaps there's no fundamental reason you couldn't have the nirvana of efficiency and portability (best of both worlds), and it's just that no community of developers has actually aimed for that.

I'm using a lot of Electron apps today. Including VS Code. Because it's so much more productive than anything else I've used before.

I bet you have a very powerful computer. Because you value your time.

My private computer is much less powerful, but still runs noticeably smoother because I don't put any junk on it.

(I cannot, for the life of myself, figure out why applications on Windows cannot play audio consistently without jitter. Might be McAfee or some other corporate shit.)

Perhaps CPU speed/memory is not quite there yet for Electron to be viable in most projects, but nobody is taking away your ability to fiddle bits. Why does it have to be one or the other?

A JS developer can get access to writing their first 'native' client. If it is too slow, perhaps she will investigate a more memory efficient way. Or perhaps its good enough for the current use case.

Some paradigms will be dead ends, but experimenting with higher level languages and libraries is what moves us forward.

It's equivalent to kicking and screaming in the late eighties that this 'Python' is not efficient and a waste of time.

Specialized industry software have a (moderate) liberty of picking a platform. They can say that they work only on Windows, or Mac, or a flavor of Unix if necessary, based on various market factors and major clients. They can atleast release for one major platform, and hold out for other platforms until they are really big enough.

On the other hand, general purpose software (editors, messaging, etc) – they need to be everywhere. Android, iOS, Windows, Linux, Mac – at the very least. Because users already are multi-device. Even in the best case, a single user wants his/her important apps to sync between phone and laptop. Your general purpose app is dead on arrival if it does not support atleast two platforms.

Comparing these two is like apples and oranges.

Why not? Onshape is browser based, and quite a few mechanical engineers and the 3D printer community seem to be happy with how well it works.

https://www.onshape.com/

Maybe we can, maybe we can't. Regardless, no one has done it.

I'm still holding out on a ReactNative-like solution for all platforms, independent of language. Eg, some type of RPC bridge is opened between a process and a window, and it creates native widgets for each proper platform in the same way ReactNative does; except with no care for the originating language that the process is written in.

Maybe one day.

We're working on a crossplatform app that runs on macOS, Windows, Chrome OS, Android, and iOS.

The UI runs on a webview provided by each platform and it's the same codebase for all 5 platforms. The native layer is as thin as possible, but there is some functionality we've had to repeat in each platform.

The macOS app weights 15MB. A hello world in Electron weights over 100MB. I think we've done pretty good.

The previous version used Electron for Windows and macOS, and Cordova for Android and iOS. This allowed me to do the 5 platforms on my own but introduced many problems.

All the best for your endeavours.

Thanks, the same to you!

Personally I'm a fan of C# with WPF, but while C# is decently cross-platform with .net core WPF is Windows only.

Swing https://en.wikipedia.org/wiki/Swing_(Java)

QT https://www.qt.io/

TK https://docs.python.org/3/library/tkinter.html

wxWidgets https://www.wxwidgets.org/

A good manager will ensure everyone has actually read Filthy Rich Clients, is aware of Swing theme component libraries and never does IO on the UI thread.

And for bonus points, that the team gets hold of an Java AOT compiler to native code.

Of course JFX is probably a better option now days but for a small GUI if you avoid layout managers like GridBagLayout (built to work with a WYSIWYG) and you are on the JVM seems like an easy option to me

http://tktable.sourceforge.net/tile/screenshots/windowsxp.ht...

https://www.tcl.tk/man/tcl8.5/TkCmd/ttk_intro.htm

I wouldn't base any commercial product I'd make on Tk, if it was meant for a large audience. Internal tools where you get to tell you users: "shut up and use the ugly app cause management already paid for it", ok, there you can use it. Otherwise... no.

How about a dated looking Electron "app"?

0. https://sciter.com/

Cross-platform desktop apps with reason

Language-dependent: - Lazarus/LCL - Common Lisp/McCLIM

https://www.infoq.com/presentations/autocad-webassembly/

What you can do in a browser you can do in Electron App as well because Electron embeds the browser!

Autodesk's demo is in a web browser, good luck trying this when you're offline.

  Imagine if I were to write a 'next-gen' CAD program or an
  alternative 3D modeling program in Electron.
  I'm not so sure if the manufacturing or the games industry
  would take a second look at that

What's the benefit over using a native GUI library?

You rely on Chromium which is battle-tested and have frequent updates

You can hire web developers to sketch, prototype, deliver your GUI. You can connect it to your own website.

You can let your users creates plugins and scripts more easily with web technologies.

You already have most of the codebase if you want to run a Light version of your software online as a SaaS or free app.

Chromium has been battle-tested and was wounded severely. Embedding it in your application will not automatically add the regular security patches to it.

Web tech is highly dynamic and gives you the ability to change your product very quickly, deliver the value and it is quite cheap in comparison to c++ analogs.

On the other hand, one of the biggest competitors outright states thet their software needs 16gb+ of RAM* I guess Electron wouldn't make much of a difference.

[*] https://www.materialise.com/en/software/magics/product-infor...

As VSC is vastly successful, the analogy with manufacturing or gaming industry obviously does not hold: the software development 'industry' does not only take a good look at VSC, it has already accepted it as viable product.

So Microsoft is right in investing into great IDE features rather than reducing VSCs resource footprint.

I assume that similar arguments can be made for every popular Electron-based application.

> Can't we do better than this?

Honestly the answer is probably no. People just don't understand how much work goes into something like this. Who is going to, or even can, spend the time and money to do it?

Personally, I dislike the idea of Electron apps and the slight increase in input lag and lack of customization, so I never install them on my personal computer (I just use the website, since that is essentially all the app is anyways), but I can see that for most people it makes sense to trade off efficiency for feature development in this case.

Not while priorities are inverted. Right now, the priority is not on the end user so much as it is on developer productivity and iterating as fast as possible.

There are lean and snappy text editors out there. People choose Evernote and Word, because features. There are lean and snappy audio players out there. People choose iTunes, because features.

There's lean software out there, and there's bloated software our there. Right now, it's (often) the bloated software is popular. Popular software is tautologically popular because it's what the most people use.

This is inaccurate. They don't get to choose iTunes.

Also, a lot of the more popular Electron apps are not as feature rich as some of the native apps, so I don't agree with your assessment. I think they're popular because the people who do seem to like them are loud enough to sway opinion.