Flatpak is often used as a solution for creating OS-agnostic distribution packages for applications, by bundling dependencies. This is an example of a solution that provides a standalone binary, obviating the need for the extra complexity of Flatpak.
> Sandboxing, permissions management, separation from system (needed on 'immutable' and image-based distributions), unified package format (don't need to create deb, rpm, etc. for a simple GUI app), and many other Flatpak's features can benefit the devs and the users alike.
These all point out the problems with Flatpak.
Runtime sandboxing is unrelated to packaging and distribution, and having Flatpak do both of these things amounts to poor separation of concerns: how do I use a Flatpak package when I don't want sandboxing, and how do I sandbox a non-Flatpak app? The combinatorics of the use cases involved require multiple simultaneous solutions to both package management and sandboxing, which undermines Flatpak's aspiration to be a universal solution.
The attempt to unify the package format, apart from being a prime example of XKCD 927, also highlights the complexity of package management as a concept. If you're going to bundle dependencies anyway, why bother with building a packaging solution to include dynamically linked libraries? Why not release static builds that minimize the need for packaging in the first place?
The idea of Flatpak being easier on developers masks the attempt to shift packaging responsibility to app devs in the first place -- the traditional approach is that developers just work on their app, and the distro maintainers are the ones who package and distribute it. So this approach is actually extra work for devs.
> That has not much to do with what you use to write UI.
It's less about the UI and more about the self-contained nature of the executables generated by the engine.
I also don't think Godot is inherently more performant for any random UI than Electron is. It happens that most Godot apps are performant because they're made by the type of people who want to use videogame engines and thus care about performance. Electron can definitely have great performance when the developers care about performance (VSCode).
I say all this as someone who's worked on game engines before.
I don't believe that either choice is ideal, but if Godot were ubiquitous instead of Electron, applications would probably at least be less laggy and more memory-efficient.
If those results are even remotely representative of real-world scenarios then VS Code can't come close to intelliJ performance.
[0] https://pavelfatin.com/typing-with-pleasure/#windows
[1] https://github.com/microsoft/vscode/issues/161622#issuecomme...
Only those who have used systems yielding low input latency (e.g. Commodore 64, BeOS or the Amiga) can tell that something is very wrong.
Whether sanity and productivity are correlated, I won't go into.
When you've experienced low latency, high latency is very noticeable, and drains mental health.
Edit: Tip 2: the screenplay looks nothing like a screenplay
> Tip 2: the screenplay looks nothing like a screenplay
Is it because the lack of middle alignment? I was thinking about that. At the end of the day it's all plaintext/markdown underneath, so I need to come up with the right syntax for that.
How does it compare to Obsidian? I didn't see it in any of the comparison graphs.
- Obsidian is using the resource-hag framework Electron. So it uses much more resources. Plume is built using Qt C++ and QML, and it's actually faster than comparable native apps.
- Obsidian editor is not a block editor (i.e., like Notion), so you can't put advanced blocks like a Kanban (tasks board) within the same page.
- Since it's not a block editor, you can't drag & drop different components.
Unlike Notion (which is also a web app wrapped with Electron), Plume is:
- Fast (Qt C++ vs Electron)
- Easier to use (opinionated design vs. Notion's complex databases)
- Portable (Underlying data is plaintext* vs. proprietary database)
*Currently all the notes' plaintext is stored in a database, but soon we'll change that to support arbitrary folder.
Haven't had this problem with other text editors.
(In my particular case I've a passively cooled laptop from like 2021; The limited compute resource available to applications in that device really made me appreciate the well built applications)
Of course you can always go less powerful but at one point you just can't use all more complex editors. It's not an electron issue.
It's imperceptible to some. Not to me. Drives me up the wall, but the vscode integrations are too good.
VSCode works because they chose Electron for the advantages that web tech has when it comes to building a plugin ecosystem. They were then willing to put in the effort to make performance decent.
Which amounts to a strong argument in favor of using a tech stack that has superior default performance, and therefore requires less dev effort for optimization.
Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.
Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.
Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be.
Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS.
Some other people have written detailed answers:
https://news.ycombinator.com/item?id=38953558
https://news.ycombinator.com/item?id=38954455
https://news.ycombinator.com/item?id=38954087
EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.
Accessibility is often language in game technology. That should be better.
To be honest my first reaction was negative to this idea. But if your comments and links have done anything it’s convince me that maybe this isn’t a bad idea after all!
They handle specific subsets of text rendering across a wide range of languages. There's a ton of interactions with the OS-level text interactions that are both difficult to fully enumerate and even more difficult to re-implement non-natively. Font programming can get really, really complex—some of it might be perceived as unnecessary—ligatures, proper kerning, certainly sub pixel rendering, glyph variants, arguably emoji—but others will really suck, like poor interactions with highlighting and cursor movement; replicating native keybindings; replicating differences in how e.g. linux and Macs kill, yank, copy, cut, paste, etc; replicating differences in how "paragraphs" are split into "lines" (logical or visual?) across platforms.... this isn't even touching the complexity of processing input (do you really want to implement wubi chinese? Do you know how to properly handle unicode normalization the same way the local editor does so that typing the same keystrokes causes the same behavior? how about differences between punctuation glyphs between scripts? Are you even handling hyphenation correctly? Does it reflow as expected when the layout constraints change?) and simply processing unicode in a consistent and well-behaved manner.
(and of course this isn't even touching attributed text or rich text editing or combining fonts on a single line....)
> Accessibility is often language in game technology
I'm no expert, but accessibility concerns must be wildly different in a game than in a data-heavy or prose-heavy app. I can't imagine implementing a screen reader without relying heavily on the OS....
People radically overstate how hard this is. Yes there’s a lot of cases. But God bless UTF-8 which provides a very clear path.
There are countless hobby text editors and libraries that handle literally all of this.
> I can't imagine implementing a screen reader without relying heavily on the OS....
Of course. You “just” need to use the documented OS APIs. It’s not trivial. But like it’s not that hard to use the APIs that lots of programs and libraries already use.
The thing is, there really aren't. Certainly not that I would characterize as a "hobby" text editor.
It's a very clear middle finger for CJK users if text rendering issues were dismissed because "we do UTF-8." Thanks to the Unicode Consortium, letters from CJK languages have shared code points in Unicode. This makes it very easy to have, for example, Chinese style fonts sprinkled over Japanese text. This kind of mixed styles are aesthetically inconsistent, unpleasant, and hard to read.
https://en.wikipedia.org/wiki/Han_unification
i18n is very much not about slapping on UTF-8 support and calling it a day.
Every major game engine has robust support for internationalization. It’s a strict requirement for professional video games.
And I never said video games can't handle text. I said it currently can't do it at the same level as the OS or browser, with all the features.
Implementing is of course possible. But unlike something like React Native, or Electron, if you want to keep the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch. The ceiling here is something like Flutter, which cost Google millions of dollars.
It even remains to be seen if performance will be even comparable to Electron if someone implement all the missing features.
> "Accessibility is often language in game technology. That should be better."
There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.
The actual metric is “can they handle text at a sufficient level”. I’m inclined to say yes.
> Due to the rendering model of game engines, you won't be able to leverage 40+ years of OS development and 30+ years of browser development. You gotta restart from scratch.
Oh baby don’t threaten me with a good time.
Web browsers are kinda terrible at UX. Native mobile apps are sooo much better than web.
> There are exactly zero game engines or game engine libraries currently that provide the automatic accessibility at the level of something like Electron. This is something else that must be rebuilt from scratch.
It’s weird that you say “nothing to level of electron and therefore must start from scratch”. As if there aren’t already libraries and utilities to build off of. At the end of the day electron “just” uses the documented Windows API! It’s not a trivial project. But it’s hardly insurmountable.
Let me try to explain a different way:
- You are saying that native is better. Sure. UX is better, look and feel is better, rendering, accessibility (in most cases), consistency, configurability.
- Electron leverages native for a lot of functionality, so it is able to provide good quality. With light styling and semantic tags, it will use a lot of native functionality and will look exactly like the OS.
- Game engines can't use native to the extent that Electron does, because the rendering model is fundamentally different (as explained in one of the links), so it must use libraries that don't exactly have the look/feel/quality of native and must simulate it. It doesn't get as far from native than that.
> It’s weird that you say “nothing to level of electron and therefore must start from scratch”.
But this is true. There is currently nothing close to Electron accessibility in the game world. I'm not talking about base-level accessibility. Check the kind of accessibility provided by browser engines and operating systems, and you'll see it is a lot of work already cut out for developers.
Are there libraries? Of course there are, I never disputed that. I actually managed to sneak a few commits and opened a few issues in AccessKit, which is a Rust accessibility library that can be integrated with game engines. But it's still early days compared to what Electron can do.
Browser accessibility is actually really great, and it's virtually automatic for developers. I would say that only Apple has as good/simple accessibility as browsers. Check these posts to see the opinion of a Microsoft alumnus that specializes in accessibility: https://news.ycombinator.com/item?id=27338151 https://news.ycombinator.com/item?id=24188387
But I don’t find any of the other arguments compelling.
Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).
Maybe Scaleform or other flash based UI frameworks solved this problem elegantly for games, but it died ahead of my time.
The issues come from stuff like autocompletion tricks etc leading to weird lagginess. People get a first version of a thing working, and then it just kind of exists in that state forever.
Exactly what most devs reaching out to Electron don't want to do, only cozy JavaScript.
This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms.
I don't think Godot would be a great alternative to developing a conventional desktop app, relying on the OS-provided runtime environment, but if you're already deviating away from that, it might still be much better than Flatpak or Electron.
> Electron can definitely have great performance when the developers care about performance (VSCode).
But most Electron applications do not have great performance because they're not being developed this way. Using Godot would provide an easy-to-learn frontend environment (with a scripting language that might even be simpler than using web-derived JS) while still providing the performance of a game engine under the hood. So non-Microsoft developers who would otherwise use Electron might still stand a chance of releasing decent software.
Flatpak and Electron don't sabotage any of these things. Flatpak usage is entirely orthogonal, and Electron actually has best-in-class accessibility, i18n, text rendering, keyboard navigation, RTL support, hi-DPI support, etc.; its widgets feel by default as-or-more-native than anything Qt or GTK produce.
Without massive engineering work, handcrafting your GUI in Godot is going to suck for anyone using a screen reader, anyone who reads Arabic, anyone who can't use a mouse, etc.
Godot UI components are keyboard accessible by default and do support Arabic. I haven't tested them with a screen reader so I have no data there.
The Godot editor itself is made in Godot, and it doesn't feel particularly snappy when compared to vscode, so I agree with the general premise that it wouldn't be a huge step forward. That said, it is more accessible out of the box than you might expect.
Flatpak does, you need to give access to xdg-config/fontconfig to each flatpak or globally for it to respect your fontconfig settings. I've hit this, and it's one of the reasons why I don't use nor want to use flatpak.
VSCode with no extensions is very fast and light. VSCode with 30 extensions you've accumulated? Not so much.
I think that's why you see such conflicting experiences - people have different extensions.
Actually I think Rust analyser had a "smart enter" feature that worked in a similar way and was similarly slow.
Basically if an extension overrides typing then it's going to be slow.
I absolutely love vscode and think all of the people complaining about it being sluggish are ridiculous, but the cpp extensions really are genuinely annoying.
Could you explain this to someone who doesn't program and knows nothing about how os internals?
My naive question is wouldn't the OS/DE/WM still take care of the above for an application?
This is the same difference between an system like Flutter and native App toolkits (I'm going to talk about Flutter because I know more about it). It has massive advantages on portability - Flutter rendering is very predictable on different phones because the only thing that can vary is screen size. The subtle variations between OS versions and phone manufacturer UI skins don't screw things up.
There are downsides: You need to implement all the common stuff that you'd normally get for free. This includes native look and feel - Flutter has to have all the Android and Apple widgets. It also includes text rendering accessibility, etc. etc.
With a game engine the OS is basially handing you a blank canvas and telling you to draw what you want. With a GUI toolkit like GTK or Qt, the "OS" is handing you a bunch of pre-made parts and you get to arrange them on the page how you like.
If you're writing a game, the former is obviously better. If you're writing a standard application, the latter is usually better. By "better" I mean higher quality output, and less work to construct.
- Copy/paste
- Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.)
- User's preferred text size and font as selected in System Preferences
- Spellcheck
- Nice features for non-latin text (e.g. built in pinyin keyboard)
- Crisp text rendering
- Dictation support
- Screen reader support
- Autofill
- Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated)
- And hundreds more features I'm forgetting...
This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.
It probably depends on the app?
Electron will obviously excel at things that resemble an oldschool web page, but one would think Godot would excel at more dynamic OS UIs? If something is already sluggish or GPU heavy in Electron, I would think its right up Godot's alley.
Accessibility of course is a seperate and huge concern.
HTML was never intended for dynamic interfaces. Whenever you diverge beyond what it does best which is hypertext, things become more and more hacky and awkward. If you wanted to design an os UI in electron, you would use a framework called react, and you would use a language called JavaScript that compiles down into typescript and you'd need a whole build ecosystem and connect everything together, then you might find HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg... In both cases you miss the text rendering from HTML. If you stick with HTML then you'd be using css to move shit around and create windows which is also incredibly awkward.
People use electron because it's easy. The reason why it's easy is because of familiarity not because of actual superiority.
Web UI is one of the most hacked together technology stacks ever. Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target. It's not unique in this regard but it doesn't change the reality. Godot has the benefit of a very specific design implementation for a target that is highly dynamic and likely will never change. Plus it's new so you don't have armies of developers trying to "abstract" shit on it over years and years of horizontal progress.
HTML is replaceable by WebGL which is replaceable by SVG?
> JavaScript that compiles down into typescript
JS compiles down to TS?
I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL
Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/
Here's one that mocks macOS - https://macos-web.app/
It's called a typo.
>I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL
I think you're smart enough to recognize it's a typo. The primary issue with your comment is hiliteing issues as if it weren't typos but actual lapses in experience. It's like saying someone misspelled a word and claiming they therefore have no experience with the English language. If someone did that, the intent is 100% malice, not a misunderstanding. Don't be malicious. Don't debate and use malice to prove a point. What you should do is Make a point and change your stance based off of evidence.
Also I never said it can't be done. I said it's awkward. It certainly can be done.
WebGL is low level. Same with WebGPU, it means you have to use shaders. Godot has a library for UI. Which makes it less awkward. I'm saying it's JUST as awkward to build these things with webGL then with other web front end technologies.
>Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ >Here's one that mocks macOS - https://macos-web.app/
What do these examples prove? That it can be done? Did I say it can't be done? Again I didn't. It's obvious these examples exist, everyones seen them. Heck you can probably do the whole thing with CSS and no JS. The gist of my comment is that it's awkward to do, not that it can't be done. You can construct a house out of toothpicks and glue. I'm sure it CAN be done. But bricks are the less awkward tool.
So as someone aligned closer to your team (preferring other toolkits to Electron) I don't think the other user who replied to your comment previously was being malicious in interpretation.
I'm sorry but that comment alone makes me think malice. It's too obvious. To each their own.
It's not like I'm attributing ill intent now that you've clarified what you meant (I mentioned having the same anti-Electron inclination as you to demonstrate that) but I probably can't change your mind if you think two people's misinterpretation of the same comment came from malice.
It's more likely someone utilizes such errors as ammunition. Such an action is quite common. It's obvious to me that this is the more likely scenario here from the other replyer.
Another common thing is to team up with people who have similar intentions. When such a situation happens they synchronize their biases. Two coworkers with the same intent will synchronize their biases in a meeting in order to push their intent... Happens all the time.
You like the front end, my guess of what's going on with you is a team up of sorts. Malice is too strong of a word for what you're doing. You're doing a team up and you're adjusting some obvious biases to favor your intent and create alignment with your team mate. This is all done subconsciously too. But that's just my guess on what you're doing.
These are all obvious human behaviors that are quite common but people don't think about it until it's explicitly pointed out.
But in the end. Who cares. We both are now clear about what's going on. No point in debating this further.
Bullshit. React is almost 11 years old, the only other two really popular competitors are 10 and 13 and use the same paradigm.
Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".
Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.
React has been changing a lot. And before react it changed even more. There's all kinds of change in the front end world and you know it. Not even close to bullshit.
>Everything else in this area is very experimental and tentative, as it should be, but it is mostly celebrated by people who, surprise, complain that "the web is too complex".
Webgl and svg are experimental? I don't think so. Using CSS + HTML + Javascript to build an Windows like application is more experimental.
>Even "new hotness" like Tailwind is based off quite old Atomic CSS ideas that started in the late 2000s and early 2010s at Yahoo.
I never talked about whether something is based off of old technology. I'm just saying all the state of the art is always changing constantly as people build new things. Whether those new things are recycling old ideas is besides the point. The main problem is that each "new" thing is placed as this big ugly layer above something that was designed to be a high level interface anyways.
And "before react it changed even more" is a terrible argument. We had a handful second-tier frameworks who never gained enough traction compared to React/Vue/Angular even in their first months. None of those temporary frameworks achieved more than a very small fraction of jQuery popularity in their heyday. jQuery was king since almost launch, and was never really threatened, until React came along.
By "in this area" I obviously mean frameworks. And good call: WebGL is gonna be 13 years old this year and SVG will be astonishing 25 years.
And no, the "state of the art" is not really changing, unless you're going for non-market-tested technology. But that's you, that's not the market, that's not what people are hiring for, and that's not even what's getting stars in Github. New experimental projects are not "change".
The "state of the art" is still React/Vue/Angular, perhaps with SASS or CSS, which is from 2006. Even Webpack is 10 years old next February! And only now it is getting serious competition. Typescript is still 100% optional but is 11 years old.
The meme that "Javascript changes too much" was already old and tired in 2015. In 2024 it's absurd.
Heck you can argue for how HTML and JavaScript are 20 years old!! Wow that means front end hasn't changed at all for 20b years! Come on man.
Anyway my overall point wasn't even about what's changed. My point is that these are all awkward apis to use to develop a windows style UI.
Even if you think they are old, these frameworks are bending and adjusting an underlying layer to do something it wasn't designed to do in the first place. Hence the awkwardness.
I will maintain that the pace of change is not the same as you portray. Definitely not when it comes to professional frontend developers working in the industry. Blog-oriented-development or experimental niche frameworks that reach top of HN don't count as "industry" yet.
Your job is to prove why ages of technologies is relevant to your argument. If it's not then the only thing you can do is admit how that part of your argument is fucking baseless. You may be happy to discuss other things with me but until you admit or prove me wrong on this point there is zero further discussion about anything. Just walking up to someone and telling them they're wrong is useless. When you say gross expectation I expect some evidence to back that shit up. If not then you can just leave.
That being said I don't think I'm in the mood discuss anything with you. Let me be clear, any response you make to me after this will be illogical because I won't care for it or respond and it will be a complete waste of your time. We are done.
Your counterpoint was instead that React changed a lot, but I counter argued. You are free to disagree with that, of course, but instead chose to answer with "Come on man!!"...
I understand that it might seem overwhelming to see lots of "new things" here at HN and other sites, but the reality is that those things are pet projects or new incumbents that haven't been adopted at large by the industry, if at all. In reality, movement in frontend has been slower after 2015 than it was in the 10 years before.
And sorry but you can't preemptively call my response illogical. This is not cool.
Godot isn't perfect of course, and there are some things that many other UI creating tools do better, but I think there's a lot of untapped potential here.
[0]: https://alfredbaudisch.com/blog/gamedev/godot-engine/standal...
https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aop...
Godot, as a game engine, bypasses the OS and uses lower-level graphics APIs like OpenGL and Vulkan. But you only need these APIs available regardless of what hardware is under them, and you can use software-based rendering with e.g. Mesa, Lavapipe, or other software renderers. With a 2D desktop application, performance should still be fine.
The children yearn for Swing Toolkit
Unless accessibility becomes a first class concern, game engines are not going to be good choices for desktop applications.
But as another of those bundled-runtime solutions, like Flatpak, it suffers from the same issues, including high complexity and poor cohesiveness with the rest of the system.
The other problem with Godot specifically is that every thing is tied to GDScript/the Godot typing system (yes, even the C# and gdextension APIs) and you need to deal with its inconsistencies. I'm currently implementing something as simple as a schema validator (think JSON schema) and it's nightmareishly tough in comparison to any other language I have implemented this in. And then we are not even talking about the almost universal lack of error handling in a large portion of the built-in functions, or really silly things like that opening a TCP connection apparently requiring active polling. I could go on.
I love Godot, it's super simple to build game-related things with, but holy macaroni do I wish they had thought things through just a little more when they implemented them. I would never want to build a data-heavy desktop app in Godot.
> schema validator > opening a TCP connection
You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8.
But I agree that any game engine is a poor fit for general applications.
Could you give me a link please? The Godot editor itself can't do multi-window and I haven't found a clear explanation on how to do that in the games either.
> You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8.
I use the non-dotnet version of Godot, I'm not happy with the confusing licensing Microsoft has put around .NET [1]. If anything, I'll go the gdextension route, but it hasn't been painful enough yet to do that. For a UI you couldn't ignore the typing system since you'd need to feed the data into it and read from it a lot.
[0] https://github.com/dotnet/runtime/blob/main/LICENSE.TXT
[1] https://github.com/dotnet/runtime/blob/main/PATENTS.TXT (I think there was another document, please post the link if you remember which one)
I think the functionality for multiple windows was added before this release but here's the 4.1 notes that you can open the code editor/other stuff in other windows: https://godotengine.org/article/godot-4-1-is-here/#editor
I just tried it and it seems to work.
Games are full desktop applications, ad often have full-featured GUIs overlaid on top of a 3D-rendered playfield.
Certain game genres, especially strategy games and RPGs, regularly implement full UI toolkits, with floating windows, list and table widgets, combo-boxes, toolbars and menu bars, etc. Some games have a superset of standard desktop widgets in order to account for standard UI functionality along with very game-specific needs.
Look at Paradox's grand strategy games for some examples of this. Some people refer to them as "spreadsheet games" because of the complexity of game data and statistics exposed through application-like UI controls.
Last time I did that was two years (I think) ago and "excellent", even with Godot 4 beta, wasn't what I called it.
This seems much superior to Flatpak and the like as a way to offer fully self-contained distro-agnostic binary packages, and vastly superior to Electron in the performance department. Maybe desktop applications built with game engines are the next big trend.