Ask HN: Why aren't there any real alternatives to Electron? | Hacker News Reader

Ask HN: Why aren't there any real alternatives to Electron?

119 pointstentacleuno228 comments

I have to use Discord and Element on a regular basis (which both use Electron). They both use an unreasonable amount of RAM, and I feel this even more as my laptop is quite old and has 4GB of RAM.

I keep looking for alternatives to Electron, which wouldn't require such heavy resources to run, but my searches always seem to come up short. There are a number of solutions that are either dead or are not ready for production yet, such as React NodeGUI[0], Proton Native[1] or react-native-desktop-qt[2].

There's react-native-windows, but I'm not running Windows, and even if that did gain Linux compatibility it seems that they're quite focused on Microsoft-owned platforms.

Is "just stick Chromium into all your apps" seriously the best we can do as an industry? It's resource-inefficient to high heaven, not to mention that it's slow and doesn't integrate with the native platform styles at all. As a JavaScript developer, I'm quite surprised this is the best there is for cross-platform JavaScript development.

[0]: https://github.com/nodegui/react-nodegui [1]: https://proton-native.js.org/ [2]: https://github.com/status-im/react-native-desktop-qt

View on HN

Electron is absolutely unbeatable when it comes to being cross-platform. Because its core is the same as Chromium, every time Chromium, the biggest browser engine without question, is updated to run better, more stable on every platform, and big companies pump millions of dollars into it, Electron gets it "for free". Very hard to compete with that. Additionally, writing Electron applications has a relatively low entry point because it resembles writing web pages to some extent.

This means that software development is a failing discipline. All we can do is to come up with ever more ridiculous layers of complexity on top of mindboggling complexity, recursively. All of this is totally self-inflicted. The problem domains that our software needs to deal with are complex enough. But we keep piling on shit of our own making.

If this is what software development has become, then there's no way it won't end in total and utter disaster when people start to recognize the already all too common piss poor products that barely manage to do the absolute minimum and rebel against them. It may not be marketing department of the Sirius Cybernetic Corporation who'll be lined up against the wall first, but software developers when the revolution comes.

Crap. I'm now old enough to remember when computers were fast. :(

> This means that software development is a failing discipline.

Nah. It means many projects don't have strict performance requirements. Mediocre performance, high impact on battery life, slower startup times are OK for these folks. In return they gain cross platform support, quicker development cycles, etc.. There's nothing wrong with making these tradeoffs.

> There's nothing wrong with making these tradeoffs.

I would argue there's something wrong with giving customers a shitty experience.

Using Visual Studio as a native app felt quick, as if could really believe the metaphor that I was interacting with a predictable mechanical device that worked the same every time. VS Code I am constantly aware that I am interacting with a bunch of layers of sofware, like it might take 1 second or 10 seconds to do something.

Really? VS Code has been the best example of what Electron could be that I've seen. In practice it's just as responsive as Sublime Text 3 for files under 25MB.

VS Code is indeed one of the best Electron apps.

And it's also unpleasantly clunky and heavyweight, with unpredictable unresponsiveness as GP notes.

It’s been my daily IDE for a couple years and the only time it felt clunky or overweight is when I had installed a misbehaving extension. I remember feeling as you described, but after removing the bad extension it became snappy again.

I think they actually have a tool for discovering which extension is the bottleneck?

Even something as basic as code search is nightmarishly slow. I frequently resort to CLI tools when VSCode doesn't respond quickly enough. Thankfully it usually handles cancellation requests well so that I don't have to continue waiting for whatever god-forsaken process is running after I've already found my answer via other means, but I'm not going to pretend it isn't slow.

I've never had a full code search in VSCode run any slower than instant.

Either you have a massive codebase that outstrips every one I've ever worked on, or something is really busted there.

It must definitely is. I use it daily, and if you compare speeds with something native like sublime, every single task is slower in execution. Most might only be milliseconds slower but it is perceptible in over all feeling.

For me, I can live with it, but I definitely 'feel' it when I jump back into something native.

I opened Sublime yesterday and it absolutely screams in comparison to VS Code.

In my experience it depends how you use VSCode. For one project (and only a few well behaved extensions), even if it’s quite large, it can perform very well. Working in multiple projects the proscribed way (workspaces) comes with a variety of caveats. Multiple windows can increase CPU and RAM load pretty fast.

I have the complete opposite experience with VSCode versus Visual Studio.

Visual Studio feels like I am using a clunky old slow piece of software, to me. Takes forever to build and run the solution, hell it takes forever to even open a workspace.

Code feels blazing fast in comparison

Parent may have been referring told older Visual Studio versions, back before MS web-ified it into a slow pile of garbage.

Maybe I'm just pining for the old days, but Visual Studio 6 is still my favorite IDE of all time. Intellisense was fairly new and it only activated if you pressed Ctrl-Space. I didn't have little pop-ups and type-aheads trying to steal my attention and all I did was think about the C++ code I was writing.

This was around 1997, mind you. The build from the IDE still took almost 2 hours to complete.

As it stands now, I still use IDEs. I try to disable every "convenient distraction" feature they have, but I've had had to settle for the fact that I can't make them work the way I want.

It's not just VS, either. Every app has to have some attention-stealing, display obstruction mouseover. And it just seems to get worse and worse every year. So much noise for almost zero value.

IIRC, in one of more recent versions of VS, hovering over a method param will show the type of the param. The same info that's already declared to the left of the param.

How is this helpful at all?

Even worse: There doesn't seem to be a way to even fine tune this. I don't need prompts in my face 100ms after I hover over something. They might be useful after 2000ms. But it seems to be all or nothing. I've been using Mads Kristensen's Disable Tooltips extension to preserve my sanity.

If you want to see ugly, open the Azure portal sometime. Hovering too long (e.g. 200ms) over an element may open up a bigger dialog, and if you hover even longer, you get an even bigger dialog that blocks out other things that I might want to look at. It also has a nasty habit of clickjacking my intended target because of this.

I think a lot of this garbage comes from this idea that you need to keep the user engaged for whatever metrics. The problem is that although this is fine for adverts and social media sites, this is exactly what you don't want for productivity. Unfortunately, it seems like these people change jobs/teams and end up bringing this mentality with them.

Thanks for the tip about the Disable Tooltips extension. I'm using Visual Studio for a couple of projects and you've just removed one minor annoyance from my life and I appreciate it very much.

We use MyEclipse for a lot of our Java development and I found something in their latest release that gave me chills: selecting multiple lines of text in an editor will bring up a control to start a "CodeTogether" session. That can be disabled, but I really have to wonder about why selecting some code in my editor means that I need to "phone a friend."

The Azure Portal is absolutely spiteful. I've been using that as an object example of poor UI design for my junior developers. All of that work they've put in to make it responsive and I still have to hit F5 to see if my VM really started...

The Azure Portal is the next level of hell for users who need a responsive, out-of-the-way interface to do their work.

There is a trend to make UIs more and more noisy every release, to the point where you have to be engaged on everything.

Example #1: When I quit a Teams meeting, I randomly get asked to rate the meeting (unwanted behavior), instead of going back to the last application I have open (desired behavior)

Example #2: When I edit an Azure DevOps wiki page and paste a link into the text editor, I expect no other behavior than the typical paste behavior. Instead, I get a vestigial popup which steals focus and prevents me from typing or moving the cursor with the up/down keys until I hit Escape. Imagine if you have to link to multiple pages to this wiki. It completely kills my productivity by over 50%.

Example #3: When I use the mobile version of the Vivaldi browser, closing a tab should just bring me back to the last tab. It does that, but then has a pop-down dialog telling me I closed the tab, blocking the bottom of the browser. Dumb.

Example #4: Screenshots in Android. Instead of just flashing the screen once to indicate the screenshot was taken, it now adds more context-related garbage to the bottom left corner of the screen, sometimes blocking controls. Really dumb.

Example #5: Opening a Teams meeting. I click on the Outlook reminder to open the calendar invite, then click on Join Teams Meeting that brings Teams to the foreground, then opens the meeting window. It takes multiple clicks and open windows to just join a simple meeting, as well as multiple clicks to close all the open windows I don't need. I guess the idea of one click, one windows is too hard to figure out.

I wouldn't be so angry about this if there was a way to just disable some of these anti-features. And it's never just one thing. It when you use multiple applications during the day and you can never get into any kind of flow. It's just interruption after interruption, with zero regard to cohesiveness.

It's unfortunate that some UI/UX designers really do believe that the stuff that the FAANGs are doing is good design, because they end up perpetuating it through other software with little regard to the user or context.

The MongoDBCompass client comes to mind. It's a gigantic beast of an Electron application that takes almost 30 seconds to load up on first start. Simple things like CTRL-A will not select all the text in a textbox, but the entire rendered webpage instead. Or double-clicking some value in a document will shift the interface around and put it into editing mode, when all you want to do is just copy a value.

I have it on good authority from the MongoDB Compass product manager that latest versions of Compass load in around 5 seconds :-) Still an Electron app.

God, I hope so.

I've been going back to Robo3T lately. Sure, it has it's own UI/UX issues, but it doesn't feel like I'm fighting the tool all the time on really basic UI/UX stuff. And it loads up in less than a second. Never thought I'd see the day where I'd actual prefer a Java desktop app over something else.

Yawn.

What's important to the majority of computing tasks is boring, doesn't need super computer sppeds or IoT sized products This lament is really narrow sighted.

Resources are cheap for the majority

This doesn't scale though. My mouse needs an always running Electron app. And the app suspends itself somehow everytime my computer is locked or the screen sleeps. This leads to a 30 second wait while it awakens when I get back.

Now if every device and app is built on Electron with such minimal effort then I'm not sure even resurrecting Moore's Law could keep up.

So you bought and are using a mouse that takes 30 seconds to wake up from sleep, and are using that as the justification for why Electron is bad?

The point is not one anecdote alone. It's the trend my example highlights. IME it's hard to buy a feature rich device without needing to run more and more electron apps. Or have a tech job without such apps. This cannot scale to everything even if physics weren't standing in the way of significant die shrinks.

EDIT: Forgot to mention that if I configure the device to do 'hardware' assignment then it's not as bad a problem. (Yet at the cost of some flexibility.) So it suggests that the software level bindings are being loaded through this Electron abomination.

I don’t see how you can call it a “trend” when I can’t think of a single mainstream device with such a requirement.

What's a high quality programmable gaming mouse that doesn't require an app to manage it?

Core functionality for all these devices will work perfectly well without an app.

For functionality that does need additional configuration (like extra buttons, RGB colors), you will have to install a companion app and use it once.

There's no case where a peripheral will be non-functional unless a heavy electron app is permanently running alongside it, as the parent comment alleged. If there is, it is absolutely not the standard.

I mean yeah you buy bad products and they’ll be bad… They’d manage to fuck that up in native land as well. Seems orthogonal.

Getting harder to buy products that don't suffer from these kinds of problems as Electron enables producers to cheap out on software development at the cost of user time and energy.

Ah so 2008. Was not caused by rampant fraud in banking, its just that many people bought bad products. In fact that explains away any injustice that ever happened!

> Resources are cheap for the majority

Sure, if you're OK with running only one or two applications at a time.

Also, if applications were written with care toward performance/resources, imagine how much more those applications could do?

One thing I learnt when programming long time ago was that having an abstraction for things fundamentally different wasn't a good idea. I was looking for an abstraction that would make tcp and udp look the same, but I wanted the benefit of udp on udp and tcp on tcp.

If you think about ui in OSes, they are different, quite a bit. Still similar in some way, but different.

Given that, one solution when you have similar things that are actually different (e. g. PS3 and PS5 are both consoles that run videogames, from the same company, but are incompatible),is to ship a vm. Make things run there and use it.

Chromium is that VM.

Computers are still fast when they need to be fast (data processing or other stuff). But you don't need any note taking or food ordering app to be lightning fast so why care ?

Why should my note taking app or food ordering app be consuming resources that more important apps could be using?

> This means that software development is a failing discipline. All we can do is to come up with ever more ridiculous layers of complexity on top of mindboggling complexity, recursively. All of this is totally self-inflicted. The problem domains that our software needs to deal with are complex enough. But we keep piling on shit of our own making.

Awwhhh why so glum? This sounds so alarmed, so fraught & bleak!

I don't see anyone as having a bead yet on what the final destination is, on what is right or perfect. I see change & innovation & exploration as necessary, ongoing, and this layering of platforms atop each other is part of that larger bigger quest for us all to learn what serves ourselves well, to figure out how we align.

Overall these Adapter layers are quite performant, quite fast, and they isolate rather than leak complexity quite effectively. Electron's doesn't have to invent a ton of stuff to create this pleasant, familiar environment for developers or users- the operating system is simply not that relevant, is easily adapted, by a pretty boring regular programming language (Node.JS) and the world's most popular multimedia page/resource system (the browser).

Right now, yes, we have the web platform as a layer above native in many cases, but I'm not sure that that is so alarming. Maybe it's transitional? The early smartphones were both enormously web first, decided to use something great rather than reinvent: the Palm Pre and original iPhone (which was webapps only). In modern times, there's ChromeOS, and Palm's webOS continues under new stewartship, mainly on TVs. If the complaint is layers of complexity, maybe we just need to get rid of proprietary & legacy platforms, & embrace the common, shared medium that all computing has. Or find new unifying better platforms!

In general, I see these new platforms as being extremely liberating, as helping reduce the complexity developers have to mess with, by offering a set of well-defined standards & well known constraints & behaviors. Rather than a complicated, particular OS tied to some specific devices, with it's own quirks, with ever evolving platform capabilities & changing toolchain

> If this is what software development has become, then there's no way it won't end in total and utter disaster when people start to recognize the already all too common piss poor products that barely manage to do the absolute minimum and rebel against them. It may not be marketing department of the Sirius Cybernetic Corporation who'll be lined up against the wall first, but software developers when the revolution comes.

Again I think moderation is good council here, but I also agree in principle that there is some awareness software can be a bit of a disaster, and it's visible that sometimes updates & "improvements" serve external interests not the users.

Where I differ is I see Electron as a fairly hopeful, possible open future for computing, that does embrace users, more so than most software. Most software is not malleable, not adaptable. Electron, on the other hand, offers the very slick, open ended DevTools Protocol for most every app, which allows users control & automation & expansion of software. We can write some userscript & change the behavior of webplatform & electron systems, which is hugely powerful, is a far fairer shake & far more liberty than most computing platforms, where apps are usually compiled down, fixed in form & nature.

This second paragraph really brings me back to where we started: I don't think we have a bead yet, as a larger world. It feels like there's so much discovery, so much understanding to develop. What makes me hopeful is groups like https://wicg.io , which try to understand & consider how we might do better, which work to build open standards for the internet, for our shared multimedia platform, as a community, securely. There's so much further for all computing to go, so much we need to do to better serve users. I don't see anyone has having a strong lock on that, it feels like there's more to learn & become than there is that we've locked down, by far, so I am hopeful & excited & happy to see us staying malleable, working to unblock innovation at all levels, in all computing. Electron is a great & positive force here, albiet I look forward to other projects listed in the comments such as Tau providing similar-ideas with slightly-different execution.

I think this answer does not emphasize the main point enough.

It's not about the quality of chromium at all, only ubiquity.

Web developers are cheap, its easy to port website's code and slap UI on it. That is the _main_ point.

The manager for whom electron is an option is least bothered by chrome being technically solid foundation. His motive is using cheap webshits and ticking a box.

Doesn't help other cross platform toolkits are either outdated, or immature, or in a weird position like Qt.

Our industry always optimized for some sort of local maxima. From a purely engineering perspective, scripting languages, or hacky UNIX/C glue, or weak typing, would not have made sense at all. But they sticked, because they fulfilled immediate commercial needs.

I don't know if this phenomenon is prevalent in other disciplines of engineering or there is a common name for it.

Webshit? really dude.

I started off as a desktop publisher, moved up to graphic designer in the creative hub of my country, doing 3d design and video editing, from there I moved to animation and then to user interface design. throwing around 'webshit' is elitist at best and derogatory at worst. As if lack mental ability to do your job? Can you do mine?

You dont see any of us throwing around 'backend-bellend' when talking about fellow programmers.

respect the field, we are all in it.

Doesnt change the fact that 70% of web developers are shit at their job.

70% of every field is shit at their jobs.

We don't call it 'webshit' because the people are shit, we call it that because the product is shit. A pile of garbage abstractions built on other garbage abstractions all ultimately trying to make a document viewer into an application platform.

Instead of acknowledging that there are talented programmers in JS you doubled down and cite a number made up from your mind that says 7 out of 10 JS devs are shit. I dont think all backened devs are arrogant, but I know one is.

> It's not about the quality of chromium at all, only ubiquity.

Bingo.

I don't understand why people keep failing to learn this lesson.

Java became popular because Sun drove it to become default installed on lots of enterprise computers. Python later became popular because if you had a standalone computer you had "batteries included" so you had the same stuff always installed.

And what people keep forgetting is that Electron is the low friction way of supporting Linux and macOS--whom most programmers would mostly like to ignore. If you write your app in Electron, you write on Windows, claim you support Linux and macOS and then ignore them.

Java became popular on server side because alternatives were much worse (either lacking static typing like Perl or harder to develop like C++) AND Java was cross-platform. Back in those times, servers weren’t just x86+Linux boxes they are today, but had distinct os-es and CPU architectures.

I think chasing after 'Pretty UI' in the web have resulted in making customers falsely equate pretty/shiny UI with high quality/reputation. Then the software developer have no other choice but to replicate the same web UI/UX on the computer with a browser engine based GUI system like electron.

OP, Me and many others here probably wouldn't mind an immediate mode GUI for an app on their computer which consumes very less memory as we know what electron does, But an average consumer couldn't care less about what electron is as long as the software does what it's supposed to do.

Then again it didn't start with electron, Java GUI applications would make 32GB memory machine crawl like 4GB anyways. Just run couple of IntelliJ sessions for few days and Linux would suddenly kill Java, IntelliJ, XServer and thereby GNOME shell with it for good measure.

I would go further in that desktop apps are now "second class" citizens so Electron is "good enough".

Everybody who can solve their task using a web browser will do so. If they can't, then they will switch to Electron grudgingly. And only if that doesn't work will they do something else.

Tcl/Tk was cross-platform 15 years ago, and you could make it really pretty. It is lightweight, too. Did people forget?

This! An arrangement unlikely to change anytime soon.

And what happens when Google decides to move in a different direction and drop development of Chromium? It's highly unlikely but Google does have a track record of dropping projects and products for the most obscure and obtuse of reasons.

Fork Chromium?

I've been assured by Hacker News that this is effectively impossible for any entity without Google's resources or budget.

I mean, Microsoft tried to build a Chrome killer (Edge) put real money and talent behind it, and failed.

So now Edge is a Chromium fork, which is sad.

> Microsoft tried [...] and failed.

They didn't fail, they quit. You can't build something as enormous and complex as a modern and performant web browser that keeps up with modern standards for only 3.5 years.

They did the same with Windows Phone but worse, since they had to reset development twice or three times and there was a growing ecosystem of third party apps that got tossed around.

That's not trying. Microsoft doesn't try, they make very brief attempts and then give up just as soon as people start paying attention to them.

> They didn't fail, they quit. You can't build something as enormous and complex as a modern and performant web browser that keeps up with modern standards for only 3.5 years.

Not so fast. Edge was more "performant" but Google, specifically YouTube, screwed them.

Microsoft has seen this before from the other side, namely "Windows isn't done until Lotus won't run".

True that. I think a large corp such as Microsoft would gladly sponsor Chromium were Google were to abandon it. It is also suicidal to fork the Linux kernel but you do it if the necessity arises such as Android.

Isn't Android striving to minimize its changes to Linux kernel?

We'll just go back to KHTML.

There are great alternatives. I used Python and Qt to create my file manager fman [1]. It's a tool that needs to start quickly so Electron was not an option [2]. I open sourced my build system for creating cross-platform desktop apps with this stack in minutes [3]. For a quick tutorial, see [4].

1: https://fman.io

2: https://fman.io/blog/picking-technologies-for-a-desktop-app-...

3: https://build-system.fman.io/

4: https://github.com/mherrmann/fbs-tutorial

Isn't QTs licence quite expensive for commercial products?

As long as you adhere to the terms of the LGPL, you can use QML in commercial products for free. There are some add-ons that are distributed under the GPL 2 or 3, though.

You can use this page[1] to navigate the licenses for Qt.

[1] https://www.qt.io/product/features

Tauri is certainly not dead, and with a security audit in progress and a stable release in its fourth RC, it's surely very close to 'production ready'.

https://github.com/tauri-apps/tauri/releases/tag/tauri-v1.0....

Currently using this with Svelte to build a cross platform video editor and and my experience so far has been amazing..!

Yep I also use it with Svelte for a couple of side project tinkerings. Great combination IMO, but I think it was an excellent choice to just have a vanilla JS (TS rather, I suppose) API on the client side and let people use whatever they want, without pushing any sort of suggestion or framework plugin.

I'd be interested in learning a bit more about how you've integrated Tauri with video playback. I have a synchronised video player tool[1] that I've built in Electron for the e-sports community. When I was investigating technology to use to build it, I was really set on using GStreamer as I could share a clock between all of the videos to ensure the synchronisation was perfectly accurate.

Electron hasn't been too bad, I've been able to construct a quick prototype which will prove if people are interested in what it does. I'd ultimately like to build a native app though.

[1] https://github.com/Rodeoclash/vodon-pro

Having used tauri for multiple projects I can say, it's absolutely worth paying attention too.

Thanks! I'll have a look. Looks promising :)

I’m not a JS developer, so take this with much salt, but one that caught my eye was SciterJS [1]. It is built using Fabrice Bellard’s QuickJS engine [2], and appears to be very efficient. Definitely has great potential I think. See previous discussion here: [3]

[1] https://github.com/c-smile/sciter-js-sdk

[2] https://bellard.org/quickjs/

[3] https://news.ycombinator.com/item?id=24797423

Sciter is great. It's similar to Electron but very light on resources. The creator is very active on the forums too. It'd be great to have a GUI/widget toolkit that would look native across all platforms but also work be valid HTML/CSS/JS on current browsers. It really feels like there is a lot of potential for sciter to take over.

Thinking of writing an app in Sciter. I’m doing a mixin approach with my own custom backend against Sciter pre-built dll.

What would you say is the pros and cons of Sciter?

Is it so lightweight as it claims?

Pros: It is as light weight as it claims (at least when I did a basic test I was more than happy). Seamless deployment, no setup or dependencies or anything. For instance I'm using Rust and it was the only front end that _just worked_ when I started a year or 2 ago. The creator is very active and very helpful on the forums. He will answer your questions and give you the solution you need, but also give you a more proper solution, if applicable. It appears cross platform support _just works_ as well, but I haven't tried yet. It's nice that it's HTML, CSS, and JS so you can share knowledge among projects.

Cons: Not as much documentation and help online as you might be used to from larger projects, but the documentation and samples are good enough if you're willing to grep and dig a little. It doesn't have the same parity as exiting browsers, so some existing web frameworks (like bootstrap) won't work (at least I couldn't get it to work). No debugger that can step through JS that I can find. But it does have "inspector.exe" which is like a simple Developer Tools from browsers to see the HTML with an active JS interpreter.

The problem with alternative implementations like SciterJS is the compatibility is not 100% and you loose access to the rest of the ecosystem. All of the js libraries will be hit or miss.

Not having access to the js libraries seems like a feature rather than a bug. With rare exceptions, third party code written in javascript distributed via npm is a liability.

> *third party code is a liability

FTFY :)

At this point its hard to come up with interesting arguments. I don't like electron as much as the next guy, but if you ever tried to develop a desktop app you can easily appreciate Electron for what it is.

Anyway heres some other choices might be viable these days: - Flutter desktop https://flutter.dev/multi-platform/desktop - Jetbrains Compose https://www.jetbrains.com/lp/compose-mpp/

IMO immediate mode guis should be option as well, like imgui, egui. (But afaik you basically throw accessibility out of the window)

Worth noting that learning Flutter means learning the language Dart, which is good for pretty much exactly one thing: writing flutter apps. If a friend was seeking to achieve proficiency in either frontend web tooling for the purposes of writing an electron app versus learning Dart, I know which _I'd_ recommend to said friend given the long term marketability of each.

for what it's worth I recently tried Flutter out and despite having never used Dart I kind of.. could just write it. It feels like the most unopinionated Algol type language ever and I've you've ever written Java or C# or JS it's very natural to pick up.

It bothered me so little that overall Flutter seemed way simpler to me than the web-tech stack because I had also very little experience with web apps.

I'm mainly a js developer these days, and I'd agree with that. At a language level, sure, Dart is quite easy to pick up. For every language though, I find the much harder part of being proficient is learning the ecosystem/best practices.

> learning Flutter means learning the language Dart

I think any current experienced software developer can easily switch between 3 or 4 popular languages, and pick up Dart quickly too since it's not that different from everything else out there. Dart is not Brainfuck or Lisp.

But would I want to insert Dart among one of those 3-4 languages just to make Flutter apps? I doubt it.

Canonical is using Flutter for many apps in Ubuntu Desktop, including the installer.

[0]https://github.com/orgs/canonical/repositories?q=&type=all&l...

The Lagrange browser for Gemini[0] was built in C with and it's cross-platform thanks to SDL. It's still possible.

[0]https://github.com/skyjake/lagrange

Everyone forgets about accessibility. Sure you can imagine just rendering various widgets to the screen but then coming up with a cross platform accessibility model that works with users’ existing tech is always pushed to the far off future. The amount of work done on platform native ui kits is astounding and web is the only platform I‘be used that can remotely come close.

Even though Compose Desktop is still Alpha, I think you can probably make something viable with it, after having tested it out a while.

You can use JavaFX or QT (with c++ or python) but they are no match for the eye candy that is to be had with html5 and css3. It's your job to integrate with the platform style, you have the flexibility to do so.

Resource usage is a problem but has become manageable over the years. See how pretty and efficient VSCode is. And honestly thank God we have electron, before that a truly cross platform ecosystem was limited to Java and that abomination Adobe AIR.

> Resource usage is a problem but has become manageable over the years. See how pretty and efficient VSCode is.

Has anyone else noticed that, in defense of Electron, everyone always trots out this one example, but... that's it? Like, where are all these other magnificently efficient Electron apps? If it's that easy, surely there must be others. And yet...

It's an easy example because everyone knows of it, and many have used it. There are tons of others, probably more niche.

For instance, I'm quite happy with Obsidian too, it's fast and snappy.

QML or QWidgets + QSS let you style things as much as you can on the web. The DX is great, their IDE is world class and resource consumption is low.

The only reason Electron is popular is that company who shoot at multiplying their revenue need to have web apps - which brought up the demand and salaries of web developers. Web developers being in such a high demand means that people will learn more of web stuff over native.

At the beginning of my career I was equally doing as many Qt projects as web projects. Nowadays, when I'm targeting only the better paying clients, I do pretty much only web. The developer experience in Qt is significantly better than anything web related (even after QML got introduced).

Jobs in C++ / Qt pay significantly less than what I'm getting. Same for most Haskell / Rust jobs.

If the choice is dealing with the pile of crap that web development is and making less money, I'd go with the money.

Things are changing in regards to Haskell / Rust, thanks mainly to cryptocurrency. The amount of money generated by the speculation in the crypto world and the fact that a few projects use Rust / Haskell means we're finally getting decently paid jobs using nice languages.

Using Qt now for a fairly simple app and it's got a lot of friction if you really want multiplatform. Updates are such a pain and Qt Creator can't seem to manage maintaining my settings for even the smallest patch version updates. (Thus requiring lots of fiddling each time or working around its wonky defaults.)

>Resource usage is a problem but has become manageable over the years.

I'd add that when VSCode started to gain popularity it was common for a dev system to have only 8~16 GB of memory. In most cases that's now more than doubled.

> In most cases that's now more than doubled.

Really? I still find it difficult to get a laptop with more than 16 GB of memory.

13" MBP maxes out at 16 GB. 14" does have 32 for $500 more, which might be ok for a company but is certainly a lot for me to spend personally just so I can run Electron apps comfortably. Non Apple laptops are similar.

If I'm buying a laptop instead of a Desktop, its for the ability to conveniently bring it with me when I'm not at home. For that, 13" is my preferred form factor. So at least Apple and Dell laptops, I have not seen one with more than 16 GB. I feel its unreasonable to expect me to sacrifice physical comfort just so apps can be written to use Electron.

Buying a gaming laptop, you can easily get 32GB RAM without paying a premium.

If you want a MacBook Pro M1 with 32GB RAM, the total cost is easily twice.

'Buying a gaming laptop, you can easily get 32GB RAM without paying a premium'

I appreciate gaming laptops, but it cannot be a requirement to run some basic electron apps that very user needs day to day.

Why should it take more RAM to run teams htat it does to edit 8K video?

It doesn't require 32GB RAM to run an Electron app, and it doesn't require a gaming laptop.

This is a response to how 32GB RAM is not as common in branded laptops (ThinkPad, MacBook Pro) as we'd like.

Perhaps you mean it shouldn't take 8-16GB RAM to run an Electron app?

It appears from this thread that 4GB RAM is often not enough.

That's great for devs, but what about the end-user? They're likely not all on the latest Macs with gigabit fibre.

Qt's QML is both declarative and reactive, and even lets you program in JavaScript or TypeScript. It also uses a tiny amount of memory and it's really fast. It's the closest thing to the React and Electron model while still being fast and efficient.

There are some suggestions, on Mozilla's suggestion platform Mozilla Connect, for turning Gecko into something like Electron[1][2].

In the past, Mozilla ran the Positron project, which was an Electron-like library on Gecko[3].

[1] https://connect.mozilla.org/t5/ideas/create-an-alternative-t...

[2] https://connect.mozilla.org/t5/ideas/ability-to-embed-gecko-...

[3] https://github.com/mozilla/positron

> Is "just stick Chromium into all your apps" seriously the best we can do as an industry?

Yes. What other rendering engine are you going to use? If your answer is anything but a web browser rendering engine, then consider that any serious UI toolkit in 2022 is certainly going to need a WebView UI component: so if you want the WebView UI component to be consistent across platforms (you want this), then you will have to bundle a web rendering engine anyway. In that case, why not just use the web rendering engine as your main rendering engine?

There’s nothing wrong with Electron as a concept. The issue is with either: blink being under optimized for this use case, or bad Electron apps.

> What other rendering engine are you going to use?

the native window environment?

> any serious UI toolkit in 2022 is certainly going to need a WebView UI component

citation needed. why do slack and discord - communication applications - need a web view component?

> In that case, why not just use the web rendering engine as your main rendering engine?

because, aside from the frankly obscene memory usage, it adds so much to the binary (mIRC used to fit on a floppy), it’s slow, is bad for battery usage, it doesn’t look in line with native apps, and it’s a huge attack vector.

> the native window environment?

I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that".

The idea that app developers have resources, skills and manpower to build ~3-7 UIs using ~2-3 different stacks – for exactly the same app – is imo more preposterous imo than assuming most users have enough ram to run a chrome+node instance.

The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps.

Yes, Electron hogs resources. I am personally using Tauri, which has a much lower footprint. Importantly, I can write my app once.

> I'd rather build an app that doesn't require me to start with the question "which OS and window environment are you using?" followed by "sorry, we couldn't afford to build for that".

i can’t help but feel your catastrophising a bit here. in any case, you have options that would greatly ease pains of this sort, wx, QT, SDL, etc. there are many. the point is that the problem with electron isn’t UI abstraction in general, just this particular implementation of it.

> [it’s safer to assume] most users have enough ram to run a chrome+node instance.

so in an effort to avoid saying that you “couldn’t afford some feature”, you’re presuming that users can afford the resources for another multi-gigabyte ram hog, which is most likely, for all intents and purposes, a pretty wrapper around JSON getters and setters?

> The failure of standardizing UI has led to this. Electron is a stop-gap, a good one. As a Linux user, I am very happy that Electron exists, otherwise I would have far fewer apps.

strong disagree here. i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI.

sorry if that’s come across as inflammatory, it’s not intentional. i guess i get a bit irrationally upset when i see i can trigger a full page refresh of what should be a native application when i hit CTRL+shift+R.

> sorry if that’s come across as inflammatory

No worries at all. If everyone shared my opinions I'd go somewhere else (or question my sanity). Also, I'm triggered by unnecessary bloat as well.

> electron absolutely did not standardise UI.

Of course not!

> you have options that would greatly ease pains of this sort, wx, QT, SDL, etc

Yes, but they really need to work on web too, if you have a web app that shares code with the native one. Otherwise you still have two UI stacks. I was seriously considering flutter, but dart is a small ecosystem and most importantly if Google pulls their support it will almost certainly die.

Web tech isn't perfect, but it's very mature and standardized. Sure, you can bloat your app/page, but if you are just moderately responsible things are very snappy. Today, you don't even have to use JS with wasm. Tauri allows me to use web tech with much lighter weight OS webviews and no Node.

> you’re presuming that users can afford the resources for another multi-gigabyte ram hog

If your crud like app is anywhere near 1GB in ram, there are other issues. Electron adds maybe 200Mb overhead, the rest is the web app itself. App bloat is a separate issue.

> i’d bet that electron and it’s ecosystem exists strictly only because of the abundance of engineers proficient in javascript. electron absolutely did not standardise UI.

Bingo. We have a glut of developers who only really know web tech, and when they decide they want to do something for the desktop they just go with what they know instead of learning something different. The argument about portability that people make in support of Electron-based stuff doesn't hold up when you see that there exist cross-platform tools for other languages. At the end of the day, the tech world is crawling with JS developers who appear to be unmotivated to learn something other than JS (or one of its transpiled cousins).

> they decide they want to do something for the desktop they just go with what they know instead of learning something different

Shouldn't the burden of proof be reversed? If the stack works, why relearn in a different stack? The HN crowd loves to shit on web developers for not being good enough even at their own domain, yet at the same time encourage them to learn new tech. Proficiency takes time.

As for the environment itself, web has the best inspect/debugging experience by far, an extremely capable and flexible layout engine and accessibility built in. It's also not controlled by a company, and has ubiquitous platform support.

Obviously there's a network effect, which to a large extent led to this situation. But it also makes sense to learn today. If I was advising a junior it'd be criminally myopic to suggest learning Qt instead of web.

> the native window environment?

This means you’ll be limited to the intersection of features of each platform native rendering engine.

On the other hand you get the union of all bugs and performance issues over each native rendering engine on each platform.

Text will be a particular nightmare, what browsers do in terms of pixel consistent yet native-feeling text rendering and input is a miracle.

> citation needed. why do slack and discord - communication applications - need a web view component?

Perhaps those apps specifically don’t use it, but it is a standard component and all modern UI toolkits are expected to have one because many apps do need this functionality.

> This means you’ll be limited to the intersection of features of each platform native rendering engine.

> On the other hand [...]

we already live in this world. electron utilises the same APIs you would use. it doesn’t have a back way around these, and is subject to the same bugs and issues from the windowing system would be.

it might be tempting to suggest here that electron devs can mitigate issues themselves and remove the need for that work on your part, but now you need to update your app: shared libraries aren’t exactly in fashion right now, so every electron based app needs updated.

that in itself has a bunch of issues/consequences. if nothing else, it’s incredibly wasteful.

> citation needed. why do slack and discord - communication applications - need a web view component?

YouTube/SoundCloud/Spotify/etc embeds would need a webview component if Discord was a native desktop app.

so we can lose local browse history, have to maintain two separate login session to each respective service (repeat for slack too, where appropriate), all just to have the video or song play in the same window..?

well, fine, if that’s what’s required. all of the platforms have webview components, i believe.

> it’s a huge attack vector.

I'm confused by this phrase. Wouldn't it have a 'huge attack vector space' ? I never really understood that phrase.

Vector is being used here in the epidemiological sense, not the mathematical sense.

vector is like an angle and a magnitude, perhaps you mean attack surface, which is the integral of known attack vectors.

> There’s nothing wrong with Electron as a concept.

I'm mainly avoiding it because I want to make an app I can use (after all, I'm primarily making this for myself), and not just have a desktop app for... someone. My laptop only has 4GB of RAM, so Electron is off the cards for what I need.

This always frustrated me with Slack. It has often been the thing running on my computer using the most RAM, yet Slack is never the primary tool I'm using the computer for. That is, communication is always a secondary thing to support my work doing something else or to allow me to do that something else in a team. Its about that other work though, not the communication. Maybe some day soon I'll have a laptop with 32 GB of RAM and there will be more spare resources available for Slack to eat, but until then, I really dislike running Slack.

So yeah, I still greatly prefer desktop applications to use native UI's and prefer to avoid browser applications where I can. But its becoming increasingly hard.

Of course, I, too, am building browser things, since that's what the industry seems to demand, so I'm not really helping the situation. I do keep meaning to learn Flutter though.

> This always frustrated me with Slack. It has often been the thing running on my computer using the most RAM, yet Slack is never the primary tool I'm using the computer for. That is, communication is always a secondary thing to support my work doing something else or to allow me to do that something else in a team.

Same with me, but s/Slack/Microsoft Teams. I personally find it absolutely horrendous to use and wouldn't recommend it.

> Of course, I, too, am building browser things

Same. That's what I'm primarily familiar with, especially React. I hope some day we have something like React Native for desktop, where it integrates with the native widgets of the platform (Qt, perhaps?) and you just integrate them with your app through components... like React Native on mobile. It's such a shame this space isn't being properly explored yet.

I'm not even sure that laptops are still sold with 4GB of RAM? You have a very niche usecase.

How is 4GB RAM installed a niche use case?

If this is the route software development is intended to take where every app is going to consume +4GB RAM good luck running multiple apps at the same time or running it on a smaller form factor.

It is truly bizarre that we are moving away from the desktop PC to smaller form factor but at the same time pushing technology that requires a desktop PC.

It lists 37 here [1]. Pretty sure people are still buying them.

https://www.mediamarkt.nl/nl/category/_windows-laptops-64106...

I can say a lot of people only uses computer for typing papers or watching movies - bigger display and storage. My cousin does everything else on her phone.

I wish I wasn't poor. Hoping to get a laptop with a bit more later on.

What range of memory usage are you going for? You could maybe look into using Electron solely for the GUI and using C/Rust/Go for the backend. Haven't done anything like that myself but from what I've read it's a decent compromise.

I'll take anything under 300/500MB as a win, though I admit under the circumstances that's going to be very tight.

The Web is semantically consistent across platforms. There's no need to use the exact same rendering code on every platform.

Look I get the idealism but being able to target a single version of a single browser at a time is vastly simpler than dealing with every browsers quirks and missing features.

> There’s nothing wrong with Electron as a concept.

There is nothing wrong with Communism as a concept.

Nack in the real world, open Whatsapp desktop and scroll though any chat dense with images, it takes me over 40 minutes to acroll back 1 year on a 12-core ryzen.

On Telegram Desktop, native client, this takes 30 seconds.

If you think this spitefull disregard of end users is justified, you live in cloud coocoo land

I would say, use native webviews, eg. WKWebView on macOS.

But unfortunately it comes with occasional bugs that are impossible to fix for app developers, so if you want complete control you can't use it

You could use a webview shared at the system level, so you don't have in memory 4 different browser engines.

I think the part "if you want the WebView UI component to be consistent across platforms (you want this)" is a reference as to why a built in webview won't be good enough.

Browsers themselves don’t do this for security snd sandboxing reasons. Each tab is another instance.

But operating systems are free to map the same read only memory pages (e.g. program code) into different process address spaces. This is an optimization that running processes are generally completely oblivious of. But it only works when e.g. the program code is mapped into memory from the same file. If every program has a private copy of the same library (even if it's bit for bit identical), the operating system doesn't have enough information to pull this off.

Each tab is a partial instance. There are still many resources that are shared globally for performance and memory use reasons.

> Why aren't there any real alternatives to Electron?

Because it's not as easy as it seems to create a proper cross-platform framework. And even if there was an alternative, these days you often need rich text, images, videos, etc. all of which are essentially HTML pages. So you'd end up adding a webview anyway, which is getting quite close to being Electron.

And I think that's the key - why create an "alternative" to Electron if you end up bundling webviews, ffmpeg, libpng and so on. It might be a bit smaller in size than Electron but not enough that it matters.

Tangehtial comment: I do not use the Discord Electon app, but use it as a pinned tab on Firefox.

I would not trust a full browser running on my machine on which I have no control and they can mine whatever telemetry data they want.

>There are a number of solutions that are either dead or are not ready for production yet, such as React NodeGUI[0], Proton Native[1] or react-native-desktop-qt[2].

Just looking at your 3 examples, I notice they all depend on Qt ... and hence the Qt UI components instead of the more familiar HTML/CSS of Electron.

So the code ends up looking like:

  const { QLabel, QMainWindow } = require("@nodegui/nodegui");
  const win = new QMainWindow();
  const label = new QLabel(win);
  label.setText("Hello world");
  label.setInlineStyle("color: green; background-color: white;");
  win.show();
  global.win = win;

So the idea of programmers having to learn a bunch of unfamiliar QXxx() like QLabel() etc -- will be a tough sell to gain mindshare. Yes, it's Javascript instead of C++ but the QXxx() will still create a lot of friction for adoption. Also, a dependency on the Qt framework may be worse than Chromium for various strategy/technical/license reasons.

>Is "just stick Chromium into all your apps" seriously the best we can do as an industry? It's resource-inefficient to high heaven,

The complaints about "resource-inefficient" attract a lot of agreement but also ignore the productivity of the developers that get to leverage their existing knowledge of Chromium-based components.

If whatever alternative to Electron has SuperiorResourceEfficientTechnology also comes with unacceptable extra friction (aka learning curve) for adoption, it will then also lose to Electron.

> also ignore the productivity of the developers

And that is the problem. We're living in a world where it's considered acceptable to make millions of users waste quadrillions of CPU cycles and petabytes of RAM every day (pennies, really) so that a relatively small number of developers can be more productive.

When you don't have many users, the time and money you save by being more productive might still outweigh the combined cost to the users, so your app is still a net benefit to the world. At a certain point, though, if you're lucky enough, you will begin to push a heck of a lot more externalities onto your users than you're saving internally. (I'm looking at you, Slack.)

Unfamiliar... for whom?

Are we at the point where all developers, or all GUI developers, are expected to be familiar with HTML/CSS/JS/DOM concepts?

The QT stuff is familiar to me (from python mostly), but I have only very barebones knowledge of HTML/JS and almost none of the DOM and CSS.

>Are we at the point where all developers, or all GUI developers, are expected to be familiar with HTML/CSS/JS/DOM concepts?

Unfortunately, yes, and we've been there for a while.

>The QT stuff is familiar to me (from python mostly), but I have only very barebones knowledge of HTML/JS and almost none of the DOM and CSS.

Feel free to join the rest of us dinosaurs out on the patio to watch the world burn.

>Unfamiliar... for whom?

For the web developers who want to re-use their existing frontend skills of Javascript+HTML+CSS to create cross-platform desktop executables ... instead of learning a different GUI toolkit such as C++ QT, or C# Winforms WPF, or Java SwingGUI, Pascal Delphi, etc.

The op's links of Electron alternatives based on Qt do offer re-use of Javascript skills but I guess that's not enough of a compelling value proposition to gain mindshare.

As the creator of a desktop app (https://beekeeperstudio.io) I can tell you there's no way I'd have been able to do it without electron. No way.

Electron let's me provide feature parity for three platforms on a nights and weekends time budget. Plus the whole Vue ecosystem is available to me.

The question is not why do you use electron. The question is why is that the only viable choice goven to you

You have react wrappers for all of those (hell, some already include React in the name, so they are the wrappers), so you really don’t have to learn unfamiliar syntax, just a bunch of new components.

>, so you really don’t have to learn unfamiliar syntax, just a bunch of new components.

Even with React wrapper, consider the differences and additional learning curve:

Example from https://react.nodegui.org/docs/guides/styling :

  import React from "react";
  import { Renderer, Text, Window } from "@nodegui/react-nodegui";
  const App = () => {
    return (
      <Window>
        <Text style={textStyle}>{"Hello World"}</Text>
      </Window>
    );
  };
  const textStyle = `
    color: green; 
    background-color: white;
  `;
  Renderer.render(<App />);

Compare with example from https://reactjs.org/docs/hello-world.html :

  ReactDOM.render(
    <h1>Hello, world!</h1>,
    document.getElementById('root')
  );

Maybe the Qt-based Nodegui even with the more accessible React syntax -- is still too much friction for wide adoption. Yes, everybody wants lower cpu & ram usage but that goal always competes in the marketplace of ideas with DX Developers' Experience. The DX of leveraging existing knowledge is a bigger priority to many devs. Does replacing QXxxx() with <Unfamiliar></Unfamiliar> really change the equation to adopt the Qt alternatives to Electron?

Since you're not applying color to the browser sample and are inlining the component, a more apples to apples example would be:

  import React from "react";
  import { Renderer, Text, Window } from "@nodegui/react-nodegui";

  Renderer.render(
      <Window>
        <Text>Hello World</Text>
      </Window>
  );

which really doesn't seem any worse to me, especially given that in most React code I've seen, outside of the simplest apps and the fundamental components, you build up custom components anyway instead of doing everything with HTML equivalents.

>which really doesn't seem any worse to me,

I wasn't trying to compare noisy lines-of-code so your simplification still doesn't change the underlying issue: unfamiliarity and not being able to leverage existing knowledge/libraries in the Electron/Chromium landscape.

In this perspective, the "<Window><Text>" is already "worse" to many devs even if you reduce the source code line count to be the same.

In an ideal world, developers wish for this (unrealistic) technology:

- No need to change any code or learn any new knowledge and just effortlessly recompile with NewTool and then the executable magically runs 3x faster with 3x less memory and cpu usage.

But such tools don't exist so we end up with the following tradeoff and reality of prioritizing costs:

- You can make your executable use X less resources and be more efficient -- if you expend this extra mental cost of Y

And that "Y" cost ends up being extra friction that many developers don't want to do. (E.g. use React-Nodegui-Qt instead of Electron.)

So the answer to "Why aren't there any real alternatives to Electron?" ... ends up being: "There _are_ alternatives to Electron but developers don't want to pay the _costs_ of switching."

> In this perspective, the "<Window><Text>" is already "worse"

I disagree, because most of my react code is already components rather than raw HTML tags. I'm already using component libraries that provide widgets and such. I'm already using component libraries that are applying styles. I only use raw HTML tags when I'm building such a component from scratch.

My point is that when writing a React UI, developers are already used to using custom components and used to learning to use them. Just because the components are modeled after Qt's widgets instead of Material UI, BlueprintJS, React Bootstrap or what have you, doesn't really change much. They all already have their own idioms and API's and learning them isn't hard.

> In an ideal world, developers wish for this (unrealistic) technology:

Sure. In an ideal world, such a thing would exist and life would be awesome. Sadly, we don't live in that world. Java tried it and failed. I'm not saying that the current state couldn't be improved, because of course it can, I'm just saying that I don't believe the Qt-based React wrappers are such a big deal as you seem to be suggesting.

> if you expend this extra mental cost of Y

Leaving aside the React wrappers, using alternative UI technology is only extra mental cost because you're unfamiliar with it. I found switching to web to have extra mental cost after doing native development years ago too. You get over it quickly enough, as you learn the new tools. Of course I would love if there was a single tool that worked for all cases, just like you.

> So the answer to "Why aren't there any real alternatives to Electron?" ... ends up being: "There _are_ alternatives to Electron but developers don't want to pay the _costs_ of switching."

Yes, absolutely agree.

>I disagree, because most of my react code is already components rather than raw HTML tags. [...] My point is that when writing a React UI, developers are already used to using custom components [...] Just because the components are modeled after Qt's widgets instead of Material UI, BlueprintJS, React Bootstrap or what have you, doesn't really change much. They all already have their own idioms and API's and learning them isn't hard

If the above is true, your disagreement and all the supporting arguments (custom components) for React-Qt you listed can be summarized to "zero learning effort compared to Electron". That would mean that using Qt-based alternatives to Electron would really be free of switching costs.

But that's not happening out there in the marketplace of ideas so there must be an extra hidden cost somewhere in React-Qt that you're (inadvertently) underselling. Some possibilities:

- Even if the higher-level Electron custom components are <unfamiliar> tags that must be learned, there is value in web devs being able to see (copy/modify) the underlying HTML rather than Qt components. HTML components has more survival characteristics than Qt components. This bubbles to higher levels of custom components.

- wider ecosystem of libraries, hooks, code samples to copy-paste from web, etc that grow from HTML survival characteristics.

- Electron without React/Vue/Angular (raw HTML) is more familiar to web devs than Qt QXxx()

- Chromium runtime has extra capabilities (e.g. play media formats) that's not available in Qt runtime

So proposing that learning React-Qt is "different-but-irrelevant-because-it-is-actually-equal-effort" to Electron/Chromium is missing something about the switching costs. Otherwise, devs could just effortlessly switch to React-Qt and get resource-efficient executables and positive vibes from fellow devs for free.

Unpopular but a valid alternative is a wxWidgets application using the wxWebView component - very similar to Electron, in that it IS Chromium at the core, but it is in it's component pieces. One gets to pick and choose at a lower level what portions or the entire thing ya want. And being wxWidgets, it runs fine on the desktop OSes. But wxWidgets is unpopular, so be ready for assholes to tell you what you're doing is wrong.

Lazarus is a very similar technology based on Pascal. The language is a bit unusual but you could use it to design a cross-platform frontend that would connect to a separate "server" process running your app code.

This would have been one of the things Mozilla should have been involved, have their Rust/Servo team focus on node/electron alternatives too, this way they could have gain the minds of developers but they would need to somehow be able to accept donations for this projects and not for their weird activities not related to dev.

Mozilla was shipping Electron-style runtimes before Electron even existed—when computers with 128MB of RAM were still being used. These apps worked. The powers that be, in their infinite wisdom, decided to kill it (because obviously nobody wanted anything like that! the important thing is to do a phone!) That was going on ~10 years ago.

The worst part is that the people who fucked that up refuse to acknowledge they were wrong. No amount of evidence is enough to penetrate their big dumb egos.

Similarly(?) Firefox OS was killed before KaiOS become a big thing.

My question is why Electron isn't a shared OS level thing.

It seems like Chrome OS really had the right idea. Can't we have some cross platform app format that's just a ZIP file full of HTML, with some APIs that go beyond normal web features?

Windows 10 apps can be written in javascript, have access to all system APIs and can be rendered in system webview based on chromium, but developers are still too lazy to learn it and use it

They're not too lazy to learn it. They want something that doesn't only work on Windows 10.

Now we just need Linux and Android to do the same, because that's amazing.

Ionic/capacitor/cordova apps are all using the same shared webview instance, electron problem is a sad idiosyncrasie. In fact Ionic apps are smaller than native/flutter apps.

I saw a project on here a while ago that used Godot to make a desktop app. Godot is a “game” engine, but the app posted to HN was a business application. I thought it was interesting to use a game engine to make a business app, it actually looked quite good. I wish I still had the link.

A quick search gives me Godello: https://github.com/alfredbaudisch/Godello

You know WebGL may replace HTML for user interfaces one day especially if coupled with a VR headset. But you would still need Chromium for a unified cross platform experience. It's not hard to imagine bloody minded developers running a business app on Godot, inside a WebGL canvas on Chromium all packaged in an electron framework :)

I am no Godot expert. But from the documentation it seems like you can compile and cross compile for other platforms without the need for electron. The exception being for Mac/iOS, which requires Xcode to compile, so if you wanted to compile for all platforms you would need Mac.

This is related, and has a couple examples down the bottom https://medium.com/swlh/what-makes-godot-engine-great-for-ad...

A "game" app like that sounds horrible for accessibility. How can this be appropriate to a business environment where any users might require special accommodation at some point.

Sorry, I'm not very educated in this regard but how would it being developed in a game dev environment make it any less customisable for accessibility than an app developed in anything else?

I know this might sound weird, but it's very hard to play videogames if you are blind (I suspect there might be some "audiogames")

On Windows and Mac I make application shortcuts directly in Chrome. These use the same amount of resources as an ordinary tab, but appear just like a desktop application. I have dock/taskbar icons for Gmail, calendar, YouTube music, ect.

I don't use Linux, but given that Edge also supports this, I suspect that you can do this with Chromium.

I'm not on my computer, but the steps are to hit the hamburger menu, select create shortcut, and then select the checkbox. The words vary, but it's usually something like "run in separate window" or "run as application."

I do this for a lot of stuff (probably a dozen different apps, on Windows, Linux, macOS, and Android), but there are apps that wouldn't be able to rely on this. VSCode, for example, wouldn't have good enough system access to work.

However, the are some apps that could do this, but have hidden some of their features in the Election version. E.g. it's frustrating that Slack can't have multiple groups in a single browser tab.

The added benifit and drawback here is that you keep the app in the browser sandbox. For me that is what I want 95% of the time anyways. But for apps that really benifit from accessing native resources with no permission requests it is a downside.

As a compromise are there any major downsides to instead deploying your app that hosts its own lite http server using a multi-platform library in Go or Python, which then uses the pre-existing web browser to render the UI?

Developers often work on high-specced laptops and it's hard for us to even remember how using 4GB of RAM feels like. My first laptop I used for professional work had 16GB of RAM and that was a 1000€ laptop 9 years ago. That laptop still works and Discord is usable on it.

On the other hand I did see a computer with 512MB of RAM in use at a high school in my country in 2018, so I understand that in some places people can't afford to upgrade their hardware.

But if RAM is the only issue and most 15 years old hardware can be upgraded to 8GB or 16GB of RAM for 80€, I believe that most developers simply see problems on 4GB RAM systems as a non-issue.

You can use Lazarus IDE/Free Pascal to build small efficient executables on most platforms. A small GUI built without debug information clocks in at less than 3 megabytes on Windows.

To get to the non Mac/Linux/Windows end users, Free Pascal is working on a WebAssembly back end, which should allow you to run in a browser. Here's their RoadMap/Status page - https://wiki.freepascal.org/WebAssembly/Roadmap

I wonder if there would be some way of having a system wide electrond that hosts the rendering engine, that electron apps could check for the existence of and use, instead of having an instance for every app. Like a multi tenant electron. I’m aware that this is basically a browser, but it would be specialised and offer the same level of integration as normal electron unlike the tab-in-a-window that Chrome apps were.

If you want to write Linux apps, Flutter is a compelling alternative - it's not JavaScript but apps start fast and don't use much memory, but you'll still have a fast, React-like dev experience. Writing Flutter apps on 4GB of RAM isn't gonna work though, as the IDE / Dart analyzer uses a *ton* of memory. Would recommend using CodeSpaces or something similar if you go that route.

Anecdote: I have written flutter apps in 4GB of RAM, with both Vim+Dart LSP and IntelliJ (somewhat tuned for low memory, but it was fine for me).

honestly you can use Java or Kotlin. Java/Kotlin targets macOS, Windows, and Linux just like Electron. Even though you’re substituting V8 for the JRE, JRE is much faster and smaller and should not eat up your RAM.

The main downside is that you don’t get to write your UI in HTML. IME, most Java applications look really ugly, but they run very fast and work well.

Do we run the same java apps?

Every time i encounter a java app the ui is way less responsive than any electron app.

Of course, this might be due to the ui framework, still point stands.

I'm working on an alternative. It's a slightly different take, but provides similar functionality of Node.js plus front end code in a packaged binary. Instead of using a weird custom fork of chrome and downloading that for every different binary we just use the system Chrome browser (or install it once for all apps). Eventually we can probably expand to use other Chrome browsers or even other web driver supported browsers which Firefox seems to be building that support out. I just like the idea of using something that's already on the system.

Take a look at the wonderful GraderJS, heh :)

https://github.com/crisdosyago/graderjs

A true Electron-killer will be one that allows migrating from an Electron codebase with 0 code changes, and offer low usage of resources by e.g. using WebKit on Mac.

In the meantime, no one will bother explore other options, because it just works, even if it's a resource hog.

I am working on app that I wrote initialy in electron, but now have moved away from it.I have perspectives on both good and bad sides of electron

The good parts

Low barrier to entry - if you know javascript you are good to good. No need to learn C++ or Java for building a desktop app.

Truly cross platform - any platforms that chromium supports, electron supports

A very active ecosystem - The community around electron is amazing. I am a big fan of electron.build, things like code signing / auto updates etc are provided out of the box

The not so good parts

IPC hell

Electron has a main process and renderer process and they communicate via events. I found myself swimming in the event soup very often.

Easy to make mistakes

This is more for a note for me or any beginner, but it is easy to write compute heavy code in the renderer and make the ui unresponsive or sluggish. There are many other things like this where it is easy to do things the wrong way.

Security

Electron still has a capable browser which can open any webpage. Mix that with native access and you have a remote code execution vulnerability on your hands.

Bloated binaries

Even the simplest of the electron binaries are large, thats just the nature of electron.

Shameless plug

The app that I am working on is https://loadjitsu.com, I rewrote it using golang, couldnt be happier.

> but now have moved away from it

What did you move to? You mention Go, but which GUI framework? Fyne, Gio UI, bindings for GTK or Qt?

> Low barrier to entry - if you know javascript you are good to good. No need to learn C++ or Java for building a desktop app.

What language would you write the actual app logic in?

Rendering engine and toolkits in C++ but application logic in Python/Ruby/JS with layouts and styling in their own file format. Which describes QT and the Web.

> Electron has a main process and renderer process and they communicate via events. I found myself swimming in the event soup very often.

Ironically, this might also be what you need to write a fast non web based client to your app. By keeping the UI renderer is in a separate process, it could be written in any language or technology at all and the "main" app would be none the wiser.

I wish any Electron app would also be available as browser/web app, so I could just run it in a browser tab (and save some resources/memory?). This is possible for Spotify and Slack but not for Signal.

Can you point Edge at the Signal webpage address? Seems like it should work.

We use Object Pascal (via Lazarus) and compile the code for each target platform. The apps concerned are (only?) dev utilities, but they're fast and have a small footprint.

how much is discord using? on windows it seems to use very little (27MB of RAM).

I just started building with NeutralinoJS, and have previously built with NW.js.

Both don’t really solve the browser engine thing, but at least Neutralino is much smaller in terms of executable size.

I like the idea you can use any language you want for the backend/system level stuff, though for me that just means more typescript :)

I haven't gotten around to trying Tauri, but I've meant to. Perhaps you'll find it interesting?

https://tauri.studio/

If memory serves, it reuses the OS default web view and any "backend" or system things are done in Rust.

This saves on the download size of an app, but doesn't significantly reduce the resource usage or non-nativeness of the resulting app. Another pro is that as noted 'system things' are done in rust, but I'm not sure that's a big bonus since your frontend likely has significant bits of js _anyway_. You've effectively increased the language count in your app.

Wikipedia says the first web browser was created in 1990. And it says electron is 8 years old.

So it took 24 years to get a cross platform rendering engine that was feature rich enough for great desktop apps. Even if we take these learnings, how long till we get a new framework good enough?

Gecko-/XULRunner-based applications (like Firefox) predate Electron by many, many years.

How old is Tcl/Tk?

Electron is the lazy way as there is no barrier to entry. But if I wanted to run a web app then I’ll use a browser. I avoid all electron apps except Teams and Edge. When we have a text editor requiring electron then we’ve truly lost our way.

Why isn’t discord.com a PWA already? What are they waiting for?

There are some tradeoffs on the browser version:

- No "currently playing" detection.

- No global hotkeys.

- Reduced noice canceling and other audio cleanup.

Maybe a few others that I can't think of off of the top if my head. But for me personally the browser version is way better. I don't want them snooping on what is running on my system, I have a global mute+unmute hotkey (that I trust and works for all apps) and I already have better processsing on my mic at the system level.

It’s already a PWA app.

I checked in Chrome on macOS, and discord.com does not have a web app manifest nor a service worker.

Have you tried using it on a phone? It’s a horrible experience compared to the app.

But this thread is discussing desktop software..?

Yes, if discord.com works great in a desktop browser, then there should be no reason why it couldn’t be an installable PWA.

> Is "just stick Chromium into all your apps" seriously the best we can do as an industry?

Is there a layout engine that performs faster and more flexible?

Literally every other layout engine in existence is faster and more flexible, even the ones that use native webviews.

And what does "flexible" mean? With Electron you're limited by what HTML/CSS/JS allows you to do, that limitation doesn't exist in native. Do you really think hacking a document display model to simulate a GUI allows greater flexibility than everything else out there?

You mean Gecko and Webkit? Okay

You may be interested in Tauri: https://tauri.studio/

Why don't you open them in browser tabs, let notifications come through your phone when they're closed?

As native tools get easier to use I believe they are the way to go

the funny thing is that all of the apps that run in Electron use much fewer resources when run in the browser itself. so thats what I do.

i don't think many people outside of us technical folk care about electron apps using tons of resources to do what they need to do. (many folks run chrome, for example).

Electron exist because multi-millon dollar companies and the BEST paying people on earth not care about users, at all.

Only what is convenient and fast to do.

---

Alternatives exist, since long time ago. But developers are LAZY. A LOT.

That is why the worst tech that exploit laziness and reward instant gratification (php, js, node, mongo, electron...) survive and get poured millions on effort fighting them, instead of invest is what is better.

Ironically, this kind of tech WASTE money and time like is not tomorrow, but that is for later, and the major effects are not on the laptops of the developers that made it...

Because of sheep effects and state of things: Big&Powerful want all to be web, to be hosted on their datacenters, with the maximum lock-in possible, so they push desktops toward classic mainframe dumb terminals.

The outcome of such push is:

- we do not have anything really cross platform, at least in look&feel terms, there are classic, old, and nearly ignored by most (T)Tk but not much more. Windows have it's own GUI, OSX it's own as well, Qt have derailed long time ago toward a bloated monster with an uncertain future, GTk have derailed since GTk3, and both still do not have a real "native look&feel" on all platforms;

- developers fear having invested a big amount of time and resources on something and then being forced to reinvest time and effort just because at a certain point in time a dependency they used vanish or substantially changing imposing a almost total rewrite of the UI.

WebUI then seems to be the "safest" way to go, at least they can "float" between various platforms as needed and people know them and like their colored style... However chosen a classic local server for a localhost webapp is longer than just grabbing something already made and then...

IMVHO the real alternative is say STOP. Witch means for now ok-ish to develop locally served WebUIs or classic Tk/fltk/OpenGL (depending on the kind of GUI) but certainly not in the Electron/node sauce, only the UI and as much detached as possible from the core logic for the narrow target. For the broad target push back toward a real desktop model. Push networked applications that are not web thing, like pushing again emails with a local MUA, not a webmail, a local maildir not on a remote IMAP, locally indexed to have GMail like search (notmuch/mu for instance), file sharing apps like SyncThing/Retroshare, Jami for audio/video communications etc.

Reply on news.ycombinator.com