Hacker News Reader

Comment by rvz | Hacker News 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?

View on HN

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.

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.

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/

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

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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

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?

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.

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.

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

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

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.

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

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.

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.

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.

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.

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

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

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.

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

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

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.

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.

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.

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)

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.

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

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

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

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.

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

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

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

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.

JFX https://openjfx.io/

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

QT https://www.qt.io/

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

wxWidgets https://www.wxwidgets.org/

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 (!)

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

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

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

There is no common definition of "good looking".

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

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.

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

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

Cross-platform desktop apps with reason

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

0. https://sciter.com/

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.

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?

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.

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.

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.

Reply on news.ycombinator.com