Hacker News new | past | comments | ask | show | jobs | submit login
Electron 6.0 (electronjs.org)
190 points by fnordsensei 6 months ago | hide | past | web | favorite | 268 comments

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?

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

> The ones you provided all break the "transferable skill" requirement (React native a bit less so but still).

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

I am not sure what do you even mean by that. I am not talking about lazyness. I am talking about opportunity cost. Learning an application framework takes time. There is the language, the api, the architecture best practices, the design processes. You might want to learn about accessibility, responsiveness, cross platform issues, software packaging/distribution/update management.

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.

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

A regular user certainly isn't going to say "I want my Slack app to be built with a lean framework that uses less resources". But they very well might say "It's really frustrating that my new computer is so sluggish all the time", without knowing why.

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. (With the ability for the user to say "yes, I'm editing a 4-hour movie, don't warn me about this app again".)

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.

Microsoft did something similar for every browser that wasn't Edge.

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.

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

Does Atom provide a GUI, ER or UML designer out of the box?

I don't know. Atom is too slow for me as well. I generally use VS Code or just VIM.

  > 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.
Once I wanted my desktop's features in a phone. Now I want my phone's features on my desktop.

"want", for sufficiently well-chosen values of "want." ;-)

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.

This reminds me of the 'dir' test my friends and I used to gauge computer speed in the DOS era. Listing directories was so common its speed was easy to notice and compare to other machines.

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

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.

Average machines in 2006 were mostly desktops with hard drives of 80/120/160GB. Average machines in 2019 are mostly laptops with 500GB/1TB of storage in many cases much much faster ssds. This is less than one order of magnitude in the last 13 years. I personally would like to use that extra space for useful tools and multimedia not bloated chat apps.

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.

Jetbrains was terribly slow, terribly memory hoggy — far worse than VSCode (which is insanely fast I will note).

I think instead you should hope they do remember those.

Try to load VSCode with the same set of plugins that InteliJ has out of the box and then see how it actually behaves.

I don't know if it's improved, or if it's just my newly-acquired fast computer, but PyCharm (JetBrains with a Python sock puppet on its hand) has been pretty great, at least for the smallish projects that I've been working on.

They are doing more than vscode/slack though, so it is understandable that lots of ram is needed.

Jetbrains is paid and has probably a larger team behind it. Building those cross platform desktop apps is the business model of their company. Of course they should pick something else than electron. They hire developers that will have the java skills needed to build it.

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

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.

And yet, QT picked JS for the language of its state of the art widget library.

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.

But just for the GUI. The rest of your QT application could be written in highly tuned assembler, if you wanted to go that route…

Qt apps break all the way to being unusable on my windows system when plugging in an external display or RDPing to the machine. I use Kleopatra, Electrum, Qbittorrent, VLC, they all have scaling issues where the text and icons does not scale correctly with the buttons and other components.

Is your external display a much higher dpi than your built in screen and are we basically talking about desktop OS being shitty about handling mixed dpi?

External display has a lower dpi. I don't know if it's the OS or something else but it only happens with QT apps which makes me avoid them if possible.

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

This is a valid opinion but a bit extreme as is. If the competitor lacks some features that would save you days vs a few minute of execution, you are trading your limited CPU, memory, and bandwith for your (unlimited?) own time.

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.

Nor do they know which app is eating their resources.

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.

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.

Their guide for getting your discord token is broken afaik.

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.


Can you explain this comment?

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

> NOTE: Revery is a work-in-progress and in active development!

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.

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

There is a world beyond people who throw their notebook into the trash after 3 years. There are still plenty of users with 128 GB or even 64 GB. Now imagine Windows taking 30 GB out of these 64 before you even start installing any apps. Those people absolutely care about 500 MB.

Also if you're running 64gb hdd there's no way that you're running Windows version that takes 30gb

Actually yes. Walmart sells a few dells with 64gb eMMC and win 10 (30gb+)

This is such bullshit, who the hell runs 64gbs of hdd. Budget laptops 6-8years ago already shipped with at least 300gb hdds.

Plenty of laptops were released with small SSD's thou, probably still are.

You can, today, walk in to a Best buy and buy a Windows 10 machine with 64 or 128gib mmc. You can buy them in most US department stores and people do buy them.

When the switch the SSD came the price per GB was high and machines/ssd actually went as low as 30GB.128/256GB ssd are still very very common.

The newest(2019) macbook air ships with a 128GB SSD ¯\_(ツ)_/¯

Electron is also problematic for memory usage.

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

I'll turn that question around. Wouldn't it be nice, not to mention cost-effective, to be able to do an office job on a Raspberry Pi? Fifty to seventy bucks a head, all in, and you have a machine that was plenty fast enough 15 years ago. When you commit to giant apps, you commit to hardware that costs twenty to fifty times that amount.

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?

I do. Not necessarily because of dick space but because this bloat on applications with rather limited functionality usually comes with being memory hog, sluggishness and otherwise unpleasant experience.

Your comment has a typo that I suspect you'd like to fix before your window expires...

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

It's not windows. If you stop everything from running on startup (which means looking in 6 different places) and your CPU is being cooled well, windows itself can run very smoothly.

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.

I know it’s not your main point, but python wasn’t a thing until the nineties (released in 1991 if I trust Wikipedia) and would have been almost always not efficient and a waste of time and resources at that point in time given the state of hardware (also considering that python wouldn’t have been the optimized version that it is now)

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.


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

You cannot possibly suggest that TK is a better alternative to anything.

God, or Swing! Please, for the love of all that is good, do not show this list to any manager. Ever.

Swing is quite good.

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.

Is it really that much worse than HTML, JS, and CSS? The DOM is generally a mess and CSS isn't easy to use.

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

Why not?

How do you make a good looking app with Tk? I know about Tile and Ttk, but how can I even trust those when the Windows look and feel they mention is that of Windows XP? Launched in 2001, abandoned by Microsoft in 2014 (!)



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.

There is no common definition of "good looking".

Ask people off the street instead of HN developers who like to pretend their undesigned weekend project looks good just because it almost works, and you'll find consensus more common than you think. Or even better, how unanimous the consensus is on what looks like shit.

True, but there is a common definition of "outdated". Tk looks outdated.

Design is expensive and not always an important part of a desktop application which should "do the job".

If it's internal software, yes. If you're making it for a mass market, it's a super important part.

I'll take a slower, better looking Electron app over a faster, dated looking Tk app any day.

Function follows form, I see.

How about a dated looking Electron "app"?

It doesn't work with my IME last I checked.

Sciter [0], for example. It's similar to Electron, but not compatible with web standards. And 1/10 resource consumption.

0. https://sciter.com/


Cross-platform desktop apps with reason

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

Among the easiest and best supported is Qt. I think Flutter is also going to serve that space decently well (although in a more Electron-like fashion, meaning no/barely any integration into the platform-specific UX, while Qt imitates OS widgets).

https://en.wikipedia.org/wiki/Chromium_Embedded_Framework is support linux, windows and macos

With CEF you can write your business logic in a better language, but the UI suffers from the same problems as Electron since it's basically the same thing.

Language-independent: - IUP (supports Windows, GTK+, and Motif) - libui (supports Windows, macOS, and GTK+)

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

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


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

This is a baseless distinction from User point of view.

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

Only if they provide an electron app, to which then yes it is a 'desktop app'.

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

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?

It's cross platform almost out of the box.

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.

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

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

The ease of providing a styled user interface. In the 2000s, this was something everybody wanted to archive, the term for it was "rich user interface". Already back then, embedding a HTML widget seemed an easy way to archive that.

Qt has been supporting CSS-like styling of your native applications for quite a while now.

It's pretty hard and has a lot of problems. It's definitely not as easy as css and doesn't have as many options for styling. Sometimes, when you change one property, 5 other unrelated properties will change as well, and you need to manually set them. CSS is much easier to get a consistent theme for an application.

Ironically one of the big complaints against Java was that it didn't look native. Then not looking native became a feature.

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.

> People choose iTunes, because features.

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.

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

Same here, Notepad++ as well.

> Per our support policy, 3.x.y has reached end of life.

3.0.0 was released 10 months ago. If the current frequency of releases stays constant any version reaches end of life after about 9 months.

Churn equals progress. Burn the infidel.

Oof. I thought it was surprising to see 6 out already. . .

Electron does not have a LTS branch ?

They have "Stable" releases:


I'm guessing their LTS is whatever Google's released to an extent. Google Chrome is the basis for Electron, it would be a bad move to be over a year behind Chrome, which would lend to poor support from Google Chrome's dev team. At least that's my take on it, I'm not involved with either project. Maybe someone else here has better input over the matter.

They support the last three major releases, and that's it. So right now that's 6.x.y, 5.x.y and 4.x.y. A new major release is released about every 3 months.

To quote the official stance: "If an application has exceptional circumstances and needs to stay on an unsupported series of Electron, developers can silence the end-of-support warning by omitting the final release from the app's package.json" [0]

[0] https://electronjs.org/docs/tutorial/support#supported-versi...

Considering how electron applications are deployed "exceptional circumstances" covers every single electron app in existence.

Appreciating the contrast with the 512-byte OS posted today.

Its a valid point, the average computer in the Western world is at least 4GB.

However when I was in South Africa a few years back they were still running with XP and < 2GB RAM with HDDs that I saw in a school and hotel.

Ok, hardware components are cheaper and easier to come by but we shouldn't stop caring about system resource usage.

Also most apps are not the only app running on my system. I might have 16Gb, but I'm currently running multiple browsers with multiple tabs each, a PDF viewer, a spreadsheet application, a music app, an IDE, multiple terminal windows and a search program (Everything).

Spotify manages to use only ~150MB. If it tried to use 1GB I would replace it since I have more important things competing for my limited RAM.

If they're using old PCs running deprecated versions of Windows then they long ago stopped caring about resource usage and efficiency (energy usage and operator time) and are instead optimising for hardware cost. It's no reason to favour this or that platform for development.

> instead optimising for hardware cost

I imagine a big reason that they're on old hardware is cost - just because it's relatively cheap for someone in the West to get a decent modern machine at a reasonable cost doesn't mean that it's the same everywhere, especially when there's big disparities in the purchasing power of the native currency vs. the sellers/manufactures currency. It's not so much an optimization, I imagine most users on legacy hardware don't choose to be, it's more likely that they can't afford more modern hardware or it isn't available for them to purchase.

Another huge reason for users to stay with older operating systems (especially in business and government) is dependencies on legacy software - if an organization relies on software that has never been updated after Windows 95/XP and doesn't function on later versions then they're going to be stuck using legacy machine configurations until the process can be changed to something else.

> stopped caring about resource usage and efficiency (energy usage and operator time)

How do you know that they don't care about how efficiently they can use a machine for whatever they're doing? It's a baseless assumption.

Even if your user percent that's stuck using older hardware/operating systems is in the single digits, that isn't an excuse to ignore their requirements IMO. Doing so is a sign of sloppy engineering, akin to designing a new mode of public transport, for example, that doesn't cater for disabled people.

Or the discussion in the Blender 2.8 thread about it still being only slightly over 100 MiB

Every time I hear about Electron, I have mixed feeling about it, is it :

* one the best thing that happened to desktop software as it enable web developers to build desktop portable app

* one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume

What are your opinions ?

The latter, I have a 3GB laptop. Almost any application I use that is electron makes my laptop scream for help (fan spinning furiously) and freezes it up.

I have to kill the application before it consumes everything.

Electron applications like VS Code are an exception and slightly gives me hope.

Does anyone know what makes VS Code an exception to this?

Going to be working on an Electron app, so I'm curious about what optimizations have been made there.

It’s likely just sheer difference in quality of engineering. For most companies that choose Electron, performance was never of any value in the first place and that’s reflected in the engineering regardless of how/what it’s written in. It just happens that bad code is much more egregiously bad with JS/Electron than with other stacks.

I can't speak to VSCode, but I've been probably a hard use case for Electron development as I work in an industry without a ton of resources to throw at development, limited time, and less supportive environment for development (in spite of a pressing need to keep up).

I've found keeping as precious little of the work in the render process as possible has helped a great deal. Send everything to the main process and use the event/messaging system to update the state. Then things that you're used to doing to maintain application performance in a web browser apply. Keep the compute in the back as much as possible.

And depending on the task, offload compute to a native module [if you're capable and] if the expense between NodeJS <> native module is worth it (more intense compute tasks).

There's probably more and more experienced advice out there, but this is my experience so far.

If I recall correctly, VS Code bundles its own Electron that Microsoft's team has spent considerable time & effort optimizing for it.

Pretty sure they forked electron. Not sure what they did to it. Also they probably drop down to native for a lot of tasks.

No. They are even contributing to upstream Electron - and they did this before Github was acquired by Microsoft.

They just run more efficient software on top of electron than others do.

Imagine if desktop developer wanted to go into web development. I assume he would learn HTML, CSS, JS. Why cannot web developers wanting to create desktop app learn new languages and SDKs? I've spent many years as a web developer, and a bit fewer years as iOS developer. Now I am back with web again, but I still thing way too much of the recent trends are being optimized for the developers at the cost of users.

Thanks to Electron I was able to build an app for Win, Mac, & Linux. Had there not been electron, my app would be only for Windows and no one else.

I strongly suspect I'd never be able to bring the level of polish I could with HTML & CSS to the UI through the standard SDKs -- so the resulting app would be a much worse user experience as well.

The amount of time I'd have to spend learning a new SDK would basically put me off, and I'd likely never have created this app.

Instead I have over 700 people who have purchased my app (~2 purchases per day over the past half year) - https://videohubapp.com/

Never be able? C'mon, your app is basically one of the Qt samples dude.

Sorry for using "never" -- certainly I could spend a lot more time learning the tricks that could get me close.

But UI is not essential for a functioning app, and if the time costs of building a good UI are too high (a lot of new learning and problem solving) I'll spend less time on it.

What "sample" are you talking about? Is this the kind of thing you're comparing my app to? https://doc.qt.io/qt-5/examples-graphicsview.html

That's a Qt Widget example, you should look at Qt Quick for a way to build more modern-looking interfaces. With Qt Quick user interfaces are described in QML, a declarative markup language, and you can write most (or all, if you want) the business logic in Javascript. See for instance:


(Edit: by no means I'm saying that your work is trivial to replicate, apologies if this comment came across like that - just wanted to point out that there's more to Qt than Qt Widget.)

Thank you for the direct link. Over the years I've glanced at Qt, I've been discouraged by the amount of work I'd need to do to accomplish even trivial things that I can with HTML.

The original reply I made was to point out that startup costs decrease number of people starting. Unless you know Qt already, your first project will take much longer than using technologies you already know. It's not at all clear how long learning would take.

I know I can climb the mountain, but I'd rather not. This isn't to discourage others from doing it, it's to explain to those who don't understand why many people prefer to stick to Electron.

I think he's referring to this sample (https://doc.qt.io/qt-5/qtdoc-demos-photoviewer-example.html) - replace Image by VideoPlayer, tweak the ui, make some menus, add a few interactions and you're good to go from what is visible on your screenshots - were I still a freelancer I would maybe have quoted two weeks for that ?

They're dismissing your work as trivial because there's a sample that does the first 1% of what it takes to build, polish, sell, and support an app that people actually use. Same kind of person who thinks all the projects that died in their ~/Code folder are "almost done".

More likely this one: https://doc.qt.io/qt-5/qtmultimedia-multimedia-video-qmlvide...

Simple QML viedo player.

The main thing that Electron does is solve most of the platform abstraction issues. The only contender that comes close to this is Qt.

However, if you want to hire Qt developers, that's a much smaller pool and then you also need to pay Qt license fees for each one.

If you want to develop truly native applications, now you need to maintain builds for Windows, Mac OS and perhaps even Linux. You need developers familiar with all of these native frameworks.

Optimizing for developers isn't necessarily worse for users, if they can get more done in less time, users benefit. It's just not so obvious. No user will ever complain about a product they aren't using because it won't ship until next year with half the features.

There's also Lazarus/Freepascal [1], which has platform support and GUI capabilities for pretty much every CPU/Platform under the sun.

[1] https://www.lazarus-ide.org/

You don't need to pay Qt license fees if you don't do secret modifications to the Qt library itself.

This is not the only issue with LGPL code, but fair enough: commercial development is possible without paying for the license.

Are you sure you don't need to pay about 5k€/seat/year for commercial development?

You don't need to pay at all. Comparison is here: https://www.qt.io/download

Basically, you need to link dynamically or provide object files. You can't use commercial modules too. But that's only a small portion of Qt anyway.

Yep, paying just gets you extra Qt features and allows you to make the whole application closed source. The community version requires you to keep the Qt portion of the application under the LGPL, but you can still keep the rest of your application closed source and just link agains the Qt code.

Microsoft has a zillion native SDK developers. Recently they replaced their native Visual Studio installer with an Electron based one.

That should tell you something.

That isn’t how big companies work. The decision about what to use is up to the 5 or so developers working on an app. Microsoft doesn’t force specific languages or frameworks across all of their devs, and the native SDK devs are working on their own projects.

Based on other things MS is doing, it tells me they're hiring a lot of young developers who only know web tech and don't give a damn about the user experience.

It sure does. It says MS is still pushing bloat.

Web & JavaScript is really great platform for quick prototyping and when you're doing UIs, it's all about being able to iterate fast.

It might change a bit with Flutter & SwiftUI but I still find web & CSS to be a better authoring model.

Note that I've been doing (native) desktop programming before so I can compare.

You understand that many Electron projects are FOSS, right? I understand what you're saying about optimizing for development rather than users, but if Electron didn't exist many of these projects wouldn't exist. If you see a project that you feel would be better as a native app, why don't you build it and release it as FOSS?

Haven't we had enough opinions on Electron, for and against, to last several average lifetimes?

@dang should start stickying his comment with links to every previous Electron release submission for people who want to replay all the belabored arguments (dismissals) again and again.

It's great tool for personal use, to write quick single purpose UIs in webtech that can access DB directly, without the need to write the backend or much with REST APIs.

For personal use, you also don't need multiple runtimes for multiple electron apps. You can just use the single shared one (or even system one; for example archlinux has electron installable via pacman), reducing memory use.

It's also pretty good tool to write your own UI for other people's websites.

> own UI for other people's websites ... // ... single purpose UIs in webtech that can access DB directly

Can you point to some good examples of these use cases?

I use pg-promise for DB and UI is a bunch of vanilla JS.

You can get data with XMLHttpRequest inside electron from any origin and then just process the returned document with regular web apis.

Sorry, I don't have anything public.

That Electron fad will eventually die as HTA and XUL did before it.

With my Web developer hat, I see the future as PWAs and if you really need more than Web APIs allow, by all means create a local daemon that uses whatever browser the user has installed.

All my uses of Electron are forced upon me, if native versions are available and I am allowed to choose, native wins.

PWA is the opposite of what I want. I want signed packages/manifests with well defined content (plus binary transparency). Not each application shipping its own downloader code which caches an ill defined set of files locally.

No mention of Wayland support, which means that desktop applications like Skype and Signal will continue to have a poor user experience on GNU/Linux unless you use Xorg. Using these applications with fractional scaling in Wayland is a bit rough—I guess we are waiting for Google to land patches upstream of Electron in Chromium?

Have you noticed any issues with XWayland aside from the DPI scaling? I find it pretty seamless on a standard-DPI (or a little higher) monitor.

It depends on Chromium but as I understand it is being worked on.

I once drove a huge refrigeration truck across Australia. The full cooling system was running all the way, although storage was howlingly empty, save for twenty liters of drinking water, kept there because the fridge in the driver's cabin had broken down.

Electron always reminds me of that trip.

I love that analogy. The fridge in the driver's cabin is a web widget in a traditional toolkit, for instance https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdown... The large cooling system which requires a substantial amount of fuel is Electron.

It is totally me, seeing as how many electron projects there are, but I have never been able to make anything with it. Not even a POC, I have found it very complex.

I have a hobby project in Electron but agree, the forced separation of "main" and "renderer" processes with multiple methods of influencing each other (ipcMain/ipcRenderer, remote, webContents.executeJavascript/send), and the further splitting of the renderer process into multiple similarly-named substructures (webFrame, webview, BrowserWindow, webContents) is a lot to get one's head around right off the bat and make stick, especially if you're the sort who wants to survey and disambiguate all the facilities of the platform beneath you before starting to code, rather than just trusting tutorials and tweaking code snippets towards some degree of satisfaction if and when they 'just work'.

On the Rich Hickey "simple vs easy" scale, Electron is very much leaning to the "easy" side.

If you have a working website it takes like 5 lines of code and random electron guide to actually do a POC. If you want to have a standalone APP, you need to have locally working SPA app. That requires rather deeper familiarity with current JS build stack.

Here's a very simple and terrible example. Nothing happens except the time is updated every second in the render process. This runs at 90.3 MB RAM usage on my machine and builds to 165.7 MB.

It's about as bare of a reference as you might find. Have at it. (Also there's no Readme, just consult the package file. I only threw this together when I was finding my way around it this spring)


If you happen to know Angular, it takes 1 minute to have something working: https://github.com/maximegris/angular-electron

The thing I built has enough code you can learn from to get you farther: https://github.com/whyboris/Video-Hub-App

Also check out nw.js which is like Electron, but you start in browser context instead of node.js context. Also consider running a node.js server and launching existing chrome with chrome --app=http://localhost or iexplore -k http://localhost

I've read a tutorial that creates a small desktop application using nw.js and vue, and the package size was 233 mb. This made me decide to use Electron after all.

here it is: https://dev.to/n_tepluhina/building-a-desktop-app-with-vue-n...

Agreed. I think NW.js is great (https://github.com/nwjs/nw.js). Especially the binary blob feature which can be used to compile JavaScript to V8 bytecode, and obfuscate portions of your source for security purposes.

That's my impression too. It seems like a lot of the "native development is hard, so I use Electron" have never once used native C# with Visual Studio.

Or they might not have the bandwidth to deal with n different builds. I've written UIs in native motif, x, mfc, Android, and iOS, but with modern HTML & CSS (especially in the last couple years with flexbox, grid, canvas, svg support) and TypeScript it seems like there's new goodness daily.

That said, I'd love a divorce from Electron if something else would give me a system tray, node runtime, and seamless upgrades, supported cross-platform.

When all you have is Javascript, everything looks like a nail

Visual Studio. That's a deal breaker right there.

With Electron runtime you can just write a text file on any of the supported platforms and you have a working, running desktop app. No compilation needed.

No need to install SDKs, deal with builds, project files, etc.

I don't think it's very complex. Only look at the target users! :-)

Jokes aside, lack of basic code protection (aside of script minimization and/or obfuscation) it's that prevents me from using Electron/Atom/whatever. I know anyone could decompile a C# application easily, but I find the javascript case worst.

Do you know any commercial applications using any of these solutions? (I'm speaking of shareware / paid software, not "Whatsapp desktop" type)

PhotoStructure for Desktop runs on macOS, Windows 10, and Ubuntu Desktop, is packaged with Electron (I'm alpha testing 6.0.0 today), and will be commercially licensed when the closed beta ends.

I'm also preparing a PhotoStructure for Servers build that is electron-less, and uses either docker or snap (it's how I run it on my NAS). I'm looking for more beta testers for this headless build, if you're interested.

https://blog.photostructure.com/introducing-photostructure/ has more background and signup information.

Disclaimer: I'm the author.

Thank you. How do you cope with the code being visible inside the application drectory?

About PhotoSctructure: - Great application idea, sincerely. My photo library is a big mess and this sounds super handy. - May I recommend another icon? I find strange that PhotoStructure "for Desktop" has a cloud in it's icon :-) - Regarding being a tester, thank you, but my current file server is a very stripped down debian box right now (Fujitsu Futro S900).


The cloud bit is because it's going to support dweb/multi-user sharing (added in a version coming Any Day Now).

I'm testing it on an rpi 4, so if you've got ~> 2gb ram, it should run.

Awesome. Please, tell me how can I help at "luis at my-username-here dot com".

Thank you!

I built Video Hub App - open source but also for sale for $3.50 (with over 700 purchases in the last 1.5years)


https://github.com/whyboris/Video-Hub-App -- built with Angular

Thank you. My main concern is about protecting closed source software.

Great app, by the way.

GitKraken uses Electron and has both free and paid features.

Please, correct me if I'm wrong, as I don't know GitKraken enough.

It appears to be a free client for a paid service. Not the type of commercial software I was thinking of.

It's a desktop GUI for Git, along the same lines as Sourcetree. They've added stuff over time like various paid integrations and apparently a Kanban board, but it's always primarily been a Git GUI.

Mailspring is another one I can think of. It's a free email client that offers extra features for pay.

Visual Studio Code?

VSC isn't commercial, though it's probably narrowing the market for commercial IDEs.

there are few popular ones Slack, VSCode, Atom editor, etc...

Given the React Native for Windows talk at BUILD 2019, and their comparisation how it beats Electron, how Office and other teams are now adopting it, I still hope VSCode will eventually join the party.

They even did a nice graphic.

With UWP C++ being the reference point of 100%, UWP C# gets also 100% (thanks .NET Native), React Native 180% and Electron goes sky high above 700%!


This is how much everyone doing Electron apps is contributing to global warming, including VSCode team.

Seems like React Native is for Android, iOS and UWP (Windows), so no Mac or Linux, right?

Doesn't seem like a direct competitor with Electron then. Right?

There is ongoing support for React Native for Mac.


You got me there on GNU/Linux support, which doesn't mean it will not come later. They just need to decide which flavour of Linux desktop one is supposed to support in React Native.

You don't need to decide that much, since Qt works fine on GNOME and GTK works fine on KDE.

React Native will work on Mac through project Catalyst, Apple's way of supporting code written against iOS's UIKit to run natively on Macs.

Some initial work was already done to make React Native compile for this target: https://github.com/facebook/react-native/pull/25427

Not sure for Linux, but Mac has a fork of react native, and things are a bit slower now until we see what happens with UXKit.

Kind of hoping UXKit sticks a fork in RN, myself. (just my opinion)

I'm surprised microsoft isn't pushing xamarin instead of React Native for cross platform.

They address that during BUILD.

Xamarin for .NET devs, React Native for C++ devs (think Qt/QML).

The OP mentioned closed source electron products where the source code can be safely protected

Complex compared to what exactly?

I'm surprised Kivy [0] doesn't get more attention for desktop app development. Apps are developed in Python, it's cross-platform and MIT licensed. Running the hello world example uses just ~2.5% cpu and ~57mb memory on a 2015 mbp.

[0] https://github.com/kivy/kivy

It seems like you have three choices at the moment for desktop development (for non .NET) that I am aware of.

* C++ and GTK or other UI framework : hard but excellent performance.

* Java and Swing UI framework : easier but less performant.

* Javascript and Electron : easy but terrible performance.

Which one will prevail?

Lazarus is easier than the first two by far and you get self-contained native executables (no runtime requirements or extra DLLs, at least on Windows), native widgets (on Linux you can choose between Gtk and Qt, though the latter does need a "bridge" .so), very low memory consumption (think a handful of MBs for a very simple application and memory requirements do not grow much outside of your own use - to give a ballpark, i just opened Lazarus itself with a simple program and the task manager reports just 36MB of RAM use for the entire IDE) and very good performance.

From the development side you get WYSIWYG UI editing, an IDE that has deep understanding of the code and updates it "live" as you make modifications to the UI (and other "managed" components), very fast compilation times, a very mature and rich framework (which is also very stable as the developers almost never break backwards compatibility meaning your code will compile for years to come) and recently the IDE got an online package manager and installer (repositories existed for years but they were manual to install).

Also the entire IDE can run and be usable even on a first generation Raspberry Pi (though for comfort, especially with the UI designer, it is a better to use something slightly faster).

The negative side is that as it relies on native widgets, it is much harder to create custom themes. Though there are themeable controls available (especially if you are not against paying for them as there are a few companies selling commercial components for Lazarus). Personally i prefer native controls anyway.

Yeah Lazarus is really a RAD environment. Unfortunately I don't like Pascal nor Modern Pascal that much. My holy grail is something of the same quality but using C# which, for me, is the superior language by far.

What do miss from C# compared to Free Pascal? Outside of something like LINQ and lambdas i can't think of any other major difference between the two languages (and lambdas are WIP, i think they already work in the trunk), what do you have in mind?

Pascal has one great benefit, compiler is fast as hell - so fast that it could (incrementally) compile & launch your application in 2-3 seconds on Intel Celeron 333mhz.

Or at least this was true for Delphi, not sure about Lazarus

> you get self-contained native executables

Have you ever heard of static linking? Assuming you're using a GUI framework that has a sane license which allows that, it is rather easy to get "self-contained" native executables in most languages.

Lazarus is nice though: Delphi has always been an awesome RAD IDE and Lazarus brings cross-platform support to it.

Lazarus does use static linking for its own libraries and the license allows that. Yes you can do the same with other languages, but this was just a single feature among others, i'm not presenting every single one of them in isolation in a way where if you can find other languages/environments invalidate everything else, i'm presenting these features as a whole. If anything the self-contained part is a minor feature (and not universally available, it really depends on the backend, though for most OSes you can use one that has no external requirements).

Lazarus being much easier to use than the first two while requiring minimal resources and providing an advanced yet lightweight IDE (among other stuff) are more important IMO.

Lazarus could move on to a single window though. I find the free-floating windows rather annoying as they are hidden behind other windows more often than not.

You can configure it like that, i think the main reason that it isn't by default is mainly tradition as many people among the developers and community prefer the multiwindow setup.

But all you need to do is to install the AnchorDockingDsgn package (and optionally the sparta_DockedFormEditor package so that the form designer isn't floating but itself also part of the main window - yes the package names could be better).

I think they should ask you the first time you run it though. It already has a first time setup dialog anyway, showing two buttons with screenshots of the two setups shouldn't be that hard.

You can use docking packages to make it exactly like Delphi.

I have read the Free Pascal wiki about that right after wondering why they don't do that by default. I would like to add "... by default" in my original suggestion.

(Thank you for the hint though.)

Yeah, I feel that they should actually make it default. By the way, check out Codetyphon [1], if you don't know it already. That is one hell of a component and library collection, and it has a lot of added features for the IDE. Really bad Website, though.

[1] https://www.pilotlogic.com/sitejoom/index.php/downloads/cate...

I'd say that Javascript/Electron is easier if you come from a webdev perspective, from a tabula rasa point of view I highly doubt that the usual react/redux rigamarole that's often used is that easy. Not even sure if I like it that much better than ExtJS, and that's saying something.

Same goes for Swing, I didn't mind writing in it, but the framework parts aren't really easier than Qt etc. Java as a language has fewer footguns than C++, so if you include that, sure...

There's also FPC/Lazarus as a Delphi replacement (the original seems to be driven into the seventh layer of enterprise heck). Easy enough to create small-ish native UIs.

You have two extremes for GUI development. One is games, where everything is built from the ground up. The other is professional apps like office, photoshop where large dev teams with lots of money build tightly integrated GUIs for each platform.

Then you have the 95% of apps that just need an interface.

For close to four decades OS providers have actively fought against the development of a common cross platform GUI framework that was easy to use.

Now finally we have electron so we can use the only existing cross platform gui platform (html/javascript) that survived in spite of the big players attempts to kill it.

So electron/javascript will dominate. It’s not pretty but it’s the best we have.

I hope Flutter for desktop will prevail.


But I think they will focus on mobile first so the time when we can use Flutter for desktop programming is still far far far away.

Also you forgot, PyQt and PySide: easy but terrible performance.

I used PyQt and PySlide only on small projects but I don't understand why they would have terrible performance? The occasional call into Python code shouldn't bring down the speed from the Qt baseline.

> Javascript and Electron : easy but terrible performance.

Is performance that terrible though? VSCode works ok for me, is it more to do with how people use Electron rather than Electron itself causing the performance downgrade?

As mentioned in comments elsewhere in the thread, there are several newer projects that are trying to fill that need for performant, cross-platform desktop app development.

* Revery (language: Reason) - https://www.outrunlabs.com/revery/

* WebView (language: C/C++/Golang) - https://github.com/zserge/webview

* Dear ImGui (bindings exist for many languages!) - https://github.com/ocornut/imgui

* Flutter (language: Dart) - https://flutter.dev/

None have really stood out yet to replace Electron, but the future seems bright.

Qt & PyQt?

> [...] GTK or other UI framework [...]

Yeah but the list specifically mentions C++, which I think is part of the reason why this category is hard. Python on the other hand is definitely more entry level friendly but it's still Qt. This should be emphasised.

I think PyQt and PySide are in third category: easy but terrible performance.

PyQt and PySide take full advantage of the C++ Qt library. Performance is as good as a C++ native Qt app, as long as you have no logical bottlenecks in Python.

I hold out hope for Flutter. It was a great experience building an Android and iOS app (good API's, predictable results across a variety of devices) and should translate well to desktop development.

This is just a matter of belief unless there is open source code repo which demonstrates the perf comparison shown above by solving the identical problem statement in 3 different technologies.

Javascript and React Native has increasing desktop support. Both the Windows and macOS branches have been seeing a lot of development lately, especially given Microsoft's Office team's investments into React Native for cross-platform UI. To my knowledge, it is only the Linux React Native that is the most lagging right now, and has a ton of "Help Wanted signs" up.

Python and TkInter : always better than electron

can you style anything taht comes with TkInter? It looks ugly af if not

Yes, you can definitely make it way more ugly than default. :)

I haven't gotten past demos yet, but I'm intrigued by WebView [1] as an alternative to Electron.

[1] https://github.com/zserge/webview

I enjoy JavaFX much more than Swing but maybe my opinion is unpopular.

> Java and Swing UI framework : easier but less performant.

Using AOT compilation and not doing everything on the UI thread solves the performance issues.

there is also ActionScript 3 with Adobe AIR

One library that is trying to be the mid-term between native performance and ease of use is Revery[1].

[1] https://www.outrunlabs.com/revery/

Hopefully with Apple's Catalyst, there wouldn't be a single Electron Apps ( Ok apart from VSCode ) on my MBP.

If you want iOS or iPadOS, you need to be Native. And you can now port it to Mac with ease.

The days company ship crappy Desktop software with Electron needs to come to an End.

Almost two years ago I have created app (using Electron) that takes xlxs template and data files and generates bunch of xlsx files [1]. It was Electron 1.7.8 and now it is 6.0.0. I guess I need to check it out again.

[1] For curious: https://github.com/daliusd/xlsx-generator

You should add a screenshot in the readme.

Thank you. Done.

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact