Item — HN Reader

It's kind of interesting to see this release and previous ones mention 'performance fixes' (V8 and Blink does all the work) that it brings, yet the job postings for desktop software engineer requiring Electron experience also put data structure and algorithms and what I see here is a runtime that is very expensive in both space + time complexity. It makes no difference in using a different language with a faster runtime to combat this.

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. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time.

Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?

17 comments

Imagine reading the sentence: "Imagine spacex building a rocket with cheap plastic. Why us working in the disposable fork industry are still using this crap material!". And then you realize that this comment gathers a lot of support from the disposable forks engineering community.

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.

That might be the case economically, but this isn't the future that I or end users want, look where this has gotten modern desktop development, you now have sluggish, slow, bloated applications vying for end user's resources.

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 can't say about you, but your claim about what end users want is quite strong. End users want all the features (including performance) for free and then pick the currently available option that looks best suited for them.

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

> That might be the case economically, but this isn't the future that I or end users want

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.

Disk space has increased by orders of magnitude. Downloading an additional 500MB Of stuff seems like a completely worthwhile trade off for me if it means that the application I’m using is supported on Windows, Mac, and Linux, as opposed to the previous situation where uTorrent was a Windows only app, Transmission was a MAC only app, and then after many years they came over to the other side but with half baked functionality, and no where in there was a Linux option (or if it did arrive, it was even later). Compare that to Slack, or VS Code, which were available on Windows, Mac and Linux almost immediately, all while maintaining feature parity.

This is what I tell people who post "See what I made" when it's written in Electron.

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.

I agree with you, but man oh man I have not had a good time with react native. We made a tiny little mobile application in it, and due to various libraries exploding with every minor release, I wound up spending hours upgrading and patching and screwing around whenever we needed to add some tiny feature, which inevitably required some kind of update. I don't know if I just got unlucky with my choice of packages, but it's soured me to the whole platform.

The average end user does not care or even think about what the app they are using is made with.

As ripcord is only free during the beta period, I don't think you'll find many "end users" who would want to pay for it. The vast majority of Discord users being Gamers with big disks and plenty of RAM. Maybe some of the more technically inclined Slack users might consider switching, if they find the alternatives aren't missing too much functionality

I want to thank you for making me aware of Ripcord. So far I'm very impressed with it.

https://github.com/revery-ui/revery

Cross-platform desktop apps with Reason

> "isn't the future that I or end users want"

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.

Who really cares about 500mb on a laptop?

The difference is that Visual Studio 2010 was buggy as hell and is still a better option than... Honestly, every editor I've seen used on JS. It mostly stayed out of the way. It didn't hang when I moved the mouse, for God's sake. I think OP's point is that we're suffering needlessly, which is hard to refute when there were better options around nearly a decade ago.

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.

I think that is something that tends to be underestimated. The reason Electron is popular is because of the success rate in creating things. While projects that are trying to be better takes far longer or fails outright, making them less common. So it isn't necessarily that people are choosing so much as surviving.

You're absolutely right, electron won't die until something better exists. Not something better in terms of performance or technical debt, something better in terms of quickly bring a cross-platform gui to market.

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

But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time.

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

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.

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

This happened nearly a decade ago.

Point well taken, but I think it can be both:

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've been programming for close to 30 years, starting on a Z80 BASIC with 48 KB of RAM (I'm from a poor country, this is what we had in 1990).

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.

At work, I have a very powerful computer because of resource hogs that work makes me use (Rails, Webpack, React, McAfee, Slack, Windows).

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

VS Code is my primary experience with Electron and it performs incredibly well for me. So I don't really see what all of this fuss is about.

This is such a boring argument that both enforces gatekeeping, and lacks any idealism about the future of our industry.

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.

When a team is short on developer time and code readability is paramount, premature optimization can be a hindrance. But like most things in life, the truth is in the middle: teams should strike a balance between competing priorities rather than throwing around the premature optimization argument.

> 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. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu 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.

> 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

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/

> Can't we do better than this?

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.

> Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?

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.

Kudos for trying out a better path without Electron fat.

All the best for your endeavours.

The approach of using a web UI is valid (even Apple uses it with Apple Music on desktop) but the problem with Electron is how much bloat it adds.

Thanks, the same to you!

There are better alternatives, in almost every possible way. The problem is they aren't that popular. And you can't reuse code (and coders) with web version of your app.

What are the better alternatives?

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

Alternatives that are supported cross platform? That’s the only reason I would potentially consider Electron.

It has been already achieved by Autodesk, they moved their 30-year-old Auto CAD software to work in the browser.

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

Although a monumental achievement from Autodesk, that is not a _desktop application_ that is a web app.

As a PWA, not Electron fat.

  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

Could be possible if electron was only used for the GUI, and the core of your app would be a C++ chromium widgets. Do it!

> Do it!

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

actually game industry are adopting the web like desktop app (in launchers and other client parts (events, etc) using CEF for example).

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.

Mixed feelings about this. On one hand, I've used to work for a company that made software that processed models for 3D printing, and optimizing internal memory structures was an important part of it, as big modes routinely hogged all the memory on our own workstations.

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

Nobody forces you to use Visual Studio Code, vim and emacs are still around.

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.

An app is better than no app at all. Your "can we do better" scenario means that most of the electron apps we currently have would not exist, especially on an os like Linux. Memory is cheap. CPU is cheap. Disk space is beyond cheap. Developer time and motivation are extremely expensive. Let's see, which one should we optimize for? Yes, for cad, 3d, and games this probably isn't the right tool. But those apps are rare. For most apps, it seems to be. Are you going to pay thousands of dollars for your text editor like people to for cad? Or even $60 for it but buy millions of licenses like videogames sell? No, you're not. You likely expect these tools to be free but insist on criticising the underlying tech. Why not fork these apps yourself and rewrite them natively? Sure is better than the developer deciding not to make the app because cross platform development is too expensive or they don't have the time to learn swift, objective c, c#, and c++ to create "proper" cross platform apps. This argument is frankly tiring and beat to death. If you don't like the apps, don't use them. No one is holding a gun to your head.

Something like Electron isn't primarily for CAD programs or 3D modeling, it is for "information" applications. That is what many millions of dollars have gone into developing and educating people about web technologies.

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

I think the difference is CAD is already expensive in memory and CPU time, so any increase would likely be very noticeable. With IDE's and messaging clients, pretty much any computer can run even the most inefficient ones fairly well since they aren't doing anything super resource intensive, so it makes sense to prioritize feature development over efficiency improvements which wouldn't really affect the end user very much.

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.

> Can't we do better than this?

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.

This is an inaccurate model. As an end user, I want the developers to be super-productive and iterate quickly so they can add the features I want. The priorities of end users are what you dislike. We choose "this has the features I want" over "this is lean and snappy".

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.

We can do better than this. That's why I paid for SublimeText.

Same here, Notepad++ as well.