1. 22
  1.  

  2. 42

    But it uses lots of memory

    True. That extra abstraction might mean the app uses more memory than a native app. But memory is there to be used. You paid for it. Why don’t you want apps to use it?

    Because I have other apps that also want to use memory, and I really notice it when I have three or more webbrowser-ish apps running at the same time, even though I have a laptop with 16GB, which I thought was a lot.

    1. 12

      The idea that “you have memory why shouldn’t this glorified text chat tool (or whatever it is) use it” is ridiculous.

      It’s the same reason I refuse to use an editor built on electron.

      Yes the java based IDE I use, consumes a metric fuck ton of memory. But it also does a ridiculously good job at understanding my project code across a bunch of languages.

      Using memory when there is some advantage is fine. Using memory “because it’s there” is ducking ridiculous.

    2. 26

      Let’s look at an example: I make software for hair salons. Our main product is based on Electron and runs in many hair salons in The Netherlands. Over 95% of our users have PC’s that run Windows. So, we have a choice: Use Electron to support both macOS and Windows. Or don’t support macOS at all.

      […]

      I’ve never gotten the feedback during the last ten years: “It’s a nice app, but it would be better if it were a native app”. Not once. Users only care that it works, not how it works.

      Sounds like you’re looking for the wrong feedback. If your clientele isn’t technical, they don’t know there’s a difference between electron and native apps. Even if they can tell there’s a difference, they don’t know how to express it. Maybe they would be happier with a native app. Maybe they’d be happier if the app was more responsive, and the app would be more responsive if it used less memory. You can’t take what the customer says as gospel, because they don’t know how to communicate at your level.

      1. 11

        Right, the salon doesn’t care about the stack, but they do care about its effects; if it’s slow, they’ll feel it (even if it’s not enough to make it worth communicating). If it doesn’t take the same shortcuts as the other apps, they’ll complain, etc.

        1. 6

          Honestly a salon app can probably be done entirely with a local web app and a shortcut on the desktop which opens the default browser to the salon app location. I’ve seen lots of apps for kiosks and such distributed this way. Usually written in Java but not always. When I’ve done non-profit work in the past, it’s what I’ve done.

          1. 3

            Why is this better than an Electron app? It’s using potentially more RAM — a full browser and a JVM, rather than just a stripped-down browser — with a more confusing UI (why is there an address bar?). It’s just as “slow” and most likely actually slower, since every interaction needs the entire UI and any data updates serialized to and from strings and sent over a local socket, rather than happening entirely in-process with shared memory. Electron for consumer apps has some known downsides (e.g. RAM, since most users will be running a browser in addition to the app at most times), but for point-of-sale or registration management apps, it’s not like someone’s trying to browse Reddit and stream Netflix on the same machine at the same time. A local webserver with a desktop shortcut to open a browser seems… significantly worse than a single Electron app.

            1. 3

              It’s using potentially more RAM

              This is a kiosk app. There’s nothing running on this box other than the operating system and the application. I struggle to think of a box made in the last 10 years that couldn’t run a single browser tab and a JVM to run a CRUD web app. Some of these boxes are even airgapped. Why prematurely optimize?

              with a more confusing UI (why is there an address bar?)

              Kiosk mode apps usually hide the address bar. Okay that’s not exactly what I said when I said “shortcut on the desktop which opens the default browser to the salon app location” but please use good faith and permit me to say I am capable of hiding the address bar.

              since every interaction needs the entire UI and any data updates serialized to and from strings and sent over a local socket

              And a multiprocessing environment is running background processes and handling devices that I couldn’t care less about in a kiosk environment. Why even go with an Electron or native app here if you could grab a microcontroller and a VGA display and implement the entire thing from scratch in C or Forth or something? The answer is, it’s easy and quick for me to write, it’s easy and quick to deploy, it’s easy for the non-profit to find other people who can work on the app, and it’s cheap for the non-profit to hire somebody to fix the app if they need to. A non-profit isn’t looking for the leanest/meanest application, they just need to have something to quickly run (e.g. fast development) and make a difference to their organization, be easy/cheap to maintain, and easy/cheap to fix. That’s the whole calculus here. I presume @Sophistifunk’s work on airline kiosks probably had very similar requirements.

              1. 6

                Right, but in a thread dumping on Electron for this exact use case — a salon kiosk app is exactly the app the blog post author was talking about — I’m confused why Electron is viewed as bad but a locally-running JVM webserver + custom webview for a browser is viewed as good.

                I agree wholeheartedly that nobody should care about less-than-gigabyte RAM overhead for a kiosk app: nothing else is running on the machine, so it doesn’t matter. And I agree that “it works” and “it has the features I need” and are the most important parts. Just… Why the Electron hate? It has generally similar upsides in terms of easy to maintain + easy to hire for + easy cross platform support, and the downsides are as meaningless as you mention for the local webserver+browser version. It’s also probably easier for the average team to deploy: you don’t need a custom webview, you don’t need multiple build targets, you need to support one fewer language’s tooling, it’s easier to manage since there aren’t hidden-to-the-end-user processes running separately from the application and binding ports, that can crash or hang or get into buggy states that simply closing the app window won’t fix… I’m not saying “don’t do a local webserver + browser/custom webview” — if your company has mostly JVM people already, then it could make sense — I’m just confused why people would think Electron is inferior or poorly suited for kiosk apps by comparison.

                Edit: maybe I misunderstood, and you agree with the blog post author that Electron is fine for this use case?

                1. 1

                  quick to write and deploy is definitely not my experience with webapps! i have found that desktop apps have a far simpler architecture, in general.

                2. 3

                  It’s not better in those metrics you point out. It is that exact mindset that led to electron success and before that, it’s existence.

                  It is a possibility. A web developer can develop a desktop app. They could already before electron as pointed out by GP. Electron just streamlined that way of working. It works, that is enough for many people, but not always. I think the position on the article is silly because it essentially justify everything by “it works”. I’m pretty sure the author doesn’t have that mindset when he buys a car, a computer or a pair of jeans. It is not so difficult to grasp that people want quality products that work well.

                  Two aspects that don’t usually get discussed: 1.UI libraries are usually horrible to work with, poorly documented and the communities are generally full of entitled people that are not too interested in sharing their knowledge. The same doesn’t apply to web technologies, which have been more open and welcoming from day one. 2. People used to value a UI that had the same style as the rest of their os chrome, nowdays they value individually designed aestetics. Pretty much the opposite. Webtech, being a document formatting solution, excels here.

                  Chromium apps dont get enough love, and I think half of the people would use them instead of electron. Slack is one such case.n I cannot understand how people reason about having a desktop app that is literally just showing webpage you can open.

                  1. 1

                    I think the position on the article is silly because it essentially justify everything by “it works”. I’m pretty sure the author doesn’t have that mindset when he buys a car, a computer or a pair of jeans. It is not so difficult to grasp that people want quality products that work well.

                    That is what most people want out of a car, a computer, or a pair of jeans. Almost everyone in my life that drives has opted for a simple Japanese car with high reliability, often slightly used, not because they love their CVT engines (lol) or they find the styling of the Corolla to be beautiful, but because it gets them from point A to point B with minimal fuss and breaks down seldom. In another life I used to do cabinetry. The number of people willing to pay for solid woodwork when they can get a rickety Ikea table is vanishingly few. I, and most other folks with an eye for woodwork, would love to sit on a Morton Chair but most people have never heard of it nor even care about it. They want a chair that’s decently aesthetic that’s comfortable enough. That’s all. This doesn’t excuse slow apps or apps that are unresponsive, but as TFA says, that’s a matter of how you write an app, not an indictment of Electron itself. A slow app is slow and disrespecting of its users regardless of the technology it uses underneath. Much like people wouldn’t sit in a chair that wobbles excessively.

                    It’s not better in those metrics you point out. It is that exact mindset that led to electron success and before that, it’s existence.

                    At one end of a spectrum is a bespoke solution from a bespoke FPGA and a bespoke display. On the other is some plug-and-play Electron monstrosity. Given the requirements you have at hand which point along this spectrum would you pick and why?

                    1. 3

                      From an engineering perspective, the Corolla is the native app in the analogy. Compared to european and american cars, it has less superfluous resources thrown at it. Less unecessairy features, no luxury factor, better fuel economy, great durability. etc. In essence is makes better usage of resources.

                      But I agree with you that from the user perspective, things might be switched around. The fact is that making an electron app is cheaper because there is a much larger pool of [cheap] developers availlable. At that point, even if the user would prefer a native app, the electron app is good enough, or to be fair, often does exactly what the user wants. Resource usage being unimportant in many cases.

                      At one end of a spectrum is a bespoke solution from a bespoke FPGA and a bespoke display. On the other is some plug-and-play Electron monstrosity. Given the requirements you have at hand which point along this spectrum would you pick and why?

                      95-99% of the time an electron app. The 1-5% being left for more critical missions. Or for cases where resources are limited or scarce for whatever reason.

                3. 1

                  Yes, many years ago now I was behind the curtain at “airline you’ve heard of” and all their airport kiosks were a Java web app with a web front-end.

                  1. 3

                    Surprised it wasn’t a 3270/5250 application.

                    1. 1

                      These were public-facing touch screens.

                      1. 1

                        United States based carrier? With a popular bag check system that exhibits many 9s of user facing uptime?

                4. 1

                  You assume working feedback chains between users and owners, and then developers.

                  Most of the time you need to be a coworker to know what people hate.

                5. 6

                  Also: these are computers that do one thing and one thing only. In a more typical desktop example you will have several apps open, including perhaps multiple Electron apps, and I bet the general expectation is also a bit higher than a point of sale system.

                  Anecdotally, I’ve certainly noticed quite a few Electron apps have issues in terms of performance and UX, which I usually noticed before I knew it was Electron. This is a biased sample of course since I never noticed apps using Electron when it worked well, but all of this seems a bit too hand-wavy to me.

                  1. 5

                    There are plenty of apps that are fine delivered via Electron. In every case other than VSCode (which is basically a miracle), they’re things that should just be web-apps in the first place.

                    1. 1

                      Maybe they’d be happier if the app was more responsive, and the app would be more responsive if it used less memory.

                      Though this raises the question, what if the author of the app used Electron and they made sure to optimize it to make it as responsive as possible? VSCode is an example but VSCode actually does a lot. A salon app, like the author of this site is talking about, is probably a lot easier to optimize than something like VSCode.

                      (FWIW I’m not saying the author did or did not make their app responsive/low-latency. I’m just raising the point that there’s a middle ground that can be acceptable.)

                      1. 4

                        VSCode often gets touted as an example, but also realize that there is a huge team at a well funded company that makes this app, and clearly put a lot of work into it! I’d say VSCode is more an exception than anything, and an example of how much work it takes to make an Electron app that performs reasonably.
                        Slack is a counter example of a large team at a well funded company that ships a poorly performing electron app.

                        1. 4

                          If you want an example of a poorly-performing Electron app from the same company that made VSCode, let me point you at MS Teams.

                          1. 1

                            I think there’s a lot more variables here than team size and funding and as such using these as predictive features is misguided. Just like trying to use those two features to determine the success of any software project.

                            1. 2

                              Nah, not sure how you got that take.

                              I’m more saying that even with lots of advantages, Electron apps still end up like crap most of the time. VSCode should be considered an anomaly, or at best an example of what is possible by as an unlikely/amazing result, not a good predictor of what end users most often end up with.

                              1. 4

                                I’m more saying that even with lots of advantages, Electron apps still end up like crap most of the time. VSCode should be considered an anomaly, or at best an example of what is possible by as an unlikely/amazing result, not a good predictor of what end users most often end up with.

                                I mean I disagree but there’s no substance to disagree over. It’s just your word against mine. That’s literally what TFA is about. The author of TFA thinks good and bad apps are independent of Electron and I agree. You don’t. Without anything more to bring to this we’re just voicing our unfounded opinions.

                      2. 41

                        Shorter version of the article: everyone uses a computer made in the last 5 years, and no one uses a device that is constrained in storage or memory by modern standards. And even if they did, my application is the most important thing on their computer, and entitled to fully use all of its resources.

                        Slight addendum: I recently spent a week using a computer with 1 core and 512MB of RAM, as a challenge. I could do absolutely everything I wanted to with the computer — as long as it didn’t involve a modern web browser.

                        1. 16

                          This doesn’t really touch on the economic factors for why Electron is a thing; it’s easy to find JS devs off the street for cheap, not so much for Win32 or Cocoa. Or for that matter, finding them at all. (edit: Or hiring both at the same time. Why bother when you can (seemingly) do the same with one?)

                          1. 3

                            Yeah it would have been a much better article if he touched on the hire-ability aspect. OP is clearly a product guy, it seems like he has no clue there are a lot of good cross-platform frameworks out there these days.

                            1. 2

                              [citation required].

                            2. 2

                              Not sure where you got your data for JS dev pay. That might have been true a decade ago, but the pay gap has shrunk, especially for experienced devs.

                              You’re about one thing: targeting multiple platforms natively isn’t economical, especially nowadays with mobile platforms.

                            3. 14

                              The choice is between an Electron app or no macOS app.

                              Really? Were there no other cross-platform GUI toolkits you could have used?

                              1. 15

                                I wrote and maintain an Electron application. If I weren’t using Electron, if the application would exist at all, it would be Linux-only. There’s a very simple reason why: we use interactive SVGs a lot throughout the application, because we need an image that resembles a keyboard, and SVGs make that easy. GTK can’t do that, QT can’t do that. They can display SVGs, sure, but they don’t support interactive SVGs, only via a webview. Since about 90% of the stuff the app does is tied to interacting with that SVG, there’s no point in using a native toolkit, when most of it will be spent in the same WebKit anyway.

                                We could, of course, build our own widgets instead of using SVGs, but that’s way more time investment than we can afford. We - well, I - explored the native options. None of them would’ve allowed me to build the app as it is today. Electron did.

                                Sometimes there are good reasons for using Electron.

                                1. 1

                                  not svgs, but the tk vector canvas is surprisingly capable and nice to use.

                                2. 12

                                  Honestly, I have a dim view of cross-platform toolkits having used them and developed on them. UX-wise, they’re about as bad mouthfeel-wise as Electron. I had to do quite a bit of work to get Qt to have not awful mouthfeel on Mac OS. I find most of the advocates of cross-platform UI toolkits tend to be on Linux, which was historically a pretty low bar UX-wise and clamouring for any application. You’d get better performance, but it’s not a strong argument from the UX side.

                                  1. 6

                                    Honestly, in my experience they’re worse than Electron apps. At least standard text input shortcuts work in Electron! The “cross-platform” toolkits tend to look non-native, just like an Electron app (although often more dated), and have very… weird shortcut support, e.g. macOS Emacs-style keyboard input.

                                  2. 7

                                    What would you recommend? I don’t mean this adversarially, it’s just that every time I’ve looked for a good cross-platform GUI toolkit, I’ve come back disappointed. I hate working with Qt because Qt bindings vary in quality across languages and I’d rather not use Qt’s stdlib over the C++ stdlib when writing C++ because I have much more experience with the C++ stdlib. Gtk similarly has some pretty poor bindings in certain languages. Tk is probably the toolkit I’ve enjoyed using the most, but it’s rapidly losing mindshare from what I can tell.

                                    1. 2

                                      I agree with you that the state of cross-platform GUI toolkits is bad. I love GTK on Linux, and as far as I can tell, its language bindings are consistently good, even when they’re third-party. But GTK support on Windows is second-class, and on MacOS has historically been terrible (but is maybe getting better?).

                                      When I was looking at a toolkit to use for a cross-platform graphical Common Lisp app, the best I could find was Tk, despite its limitations.

                                    2. 4

                                      I think so? There are options you can use, but there are no really good options. https://blog.royalsloth.eu/posts/sad-state-of-cross-platform-gui-frameworks/ is a nice survey.

                                      1. 2

                                        They missed some third-party XAML implementations like https://avaloniaui.net/ It’s going to be closer to javafx, but with a great RAD environment (visual studio)

                                        I hope MAUI will get a community Linux back-end. That would make it a good alternative too.

                                      2. 4

                                        i mean you have to buy into the react paradigm but react native can compile to windows and mac in addition to ios and android

                                        https://microsoft.github.io/react-native-windows/

                                        1. 2

                                          I guess people really haven’t tried how fast you can get stuff running with QT. Yeah it’s not completely native (and it can also be used the electron way since some version), but that’s not something you get with electron either. To be fair, you have to use c++ (with QT additions) or python for it..

                                          1. 2

                                            I inherited a Qt project once. It was awful. I’ve never used Electron, but I know enough about it to pick it over Qt in most circumstances.

                                            Not sure there are many other options if you’re targeting desktop. Proton looks promising. Microsoft’s React Native for Windows and Mac does as well. Both are similar concepts with ostensibly less overhead than Electron. Anyone here try those?

                                          2. 9

                                            Electron is the Flash of the 2020s. It runs everywhere but it runs like a pig everywhere. I will note that it was inevitable that someone would shove Node and the renderer from Chrome into one box to build a cross architecture application platform.

                                            I take notice of these Apps when the fans come on and usually when I check, I see three things: my RAM usage is way high, my CPU temperature is above 80C, and my expected battery life is half of normal if I’m running on battery.

                                            Having said that, this article and the comments here made me think about the situation. I’ll take it on faith that there are good Electron Apps and bad Electron Apps. I would never notice that a good Electron App was using Electron and there are plenty of times when I kill Chrome because someone’s poorly written JS is trying to consume all of the CPU cycles on my machine.

                                            If I developed on Electron, I might be enticed to purchase a used, low end machine for testing.

                                            1. 9

                                              And at the same time, I don’t care at all. And neither should you.

                                              This feels like an article that I’ve been itching to write.

                                              I agree with this sentiment, ultimately. Good Electron apps are good, and bad Electron apps are bad. There isn’t anything inherent about the tech that precludes an app from using appropriate amounts of resources. And in the context of macOS specifically, it’s very possible to make Electron apps feel “native” on the platform.¹

                                              I’m a bit sensitive to this argument having spent a lot of time at work discussing it, recently. It’s very possible to build a good app with Electron and it’s frustrating that the industry/macOS community dunks on it without question. It all feels quite disingenuous. Nobody seems to question a “native” app using 300MB of memory. From the example in the article, nobody batted an eye when Apple announced the idea of universal binaries and doubled the download size for some apps. Nobody cares when Notes or Music or other stock apps are just webviews. A “native” app can do all those things and macOS users don’t care, but any of these things in the context of Electron and they’re disqualifications.

                                              1. 2

                                                From the example in the article, nobody batted an eye when Apple announced the idea of universal binaries and doubled the download size for some apps.

                                                Universal binaries solve a real problem for users.

                                                Electron solves a real problem for developers.

                                              2. 8

                                                Suggested the rant tag because the first sentence includes the phrase “shitty takes”

                                                1. 6

                                                  The author misses one specific case where Electron apps most definitely aren’t fine: porting to an OS other than Linux, Windows, or macOS.

                                                  The Electron codebase is replete with cases where OS type, not capabilities, are detected. So when you want to add a new OS - oh, say, FreeBSD - it’s not a matter of just detecting or declaring the capabilities your OS offers. Instead it’s a bazillion-line patch changing most - but not all! - tests to check for Linux or FreeBSD.

                                                  To put it mildly, I do not love the autoconf tools. But those folks had it right decades ago, allowing one to write portable code by testing for features rather than OS type. Electron gets this dead wrong.

                                                  1. 3

                                                    According to this site, Windows, MacOS and Linux account for 96.68% of all desktops. Having a tech that targets this many platform is probably better than any other technology in the history of computers…

                                                    1. 3

                                                      Sure, I don’t deny that. Electron has almost unparalleled reach … except when compared with Web apps themselves of course. But that’s a separate discussion ;)

                                                      Electron, though, has achieved that ubiquity in a way that greatly hinders its spread to the remaining 3.32% of machines. There was no good reason to take their approach to platform detection - AFACIT, it didn’t offer one single solitary benefit over a more correct approach that would have vastly simplified porting, which is still an ongoing issue despite a bounty.

                                                      As Paul Graham put it (talking about why to use gensym in Lisp):

                                                      Why write programs with small bugs when you could write programs with no bugs?

                                                      Unlike some of the other complaints about Electron, this one isn’t intrinsic to the choice of Web technologies. It’s just a bad design decision that could (admittedly with a lot of faff) be reversed.

                                                      1. 1

                                                        Thanks for clarifying!

                                                  2. 5

                                                    This article is bad and you should feel bad.

                                                    No seriously, there’s nothing wrong per se with Electron. It’s that too many people have used it to solve the wrong problem, so too many people are already wary. And then another completely shitty Electron app drops and everyone feels confirmation. There is no general “Electron bad, Electron good”.

                                                    My pet peeve example is: If it’s a useful tool I actively use, like an IDE or whatever, something I spend meaningful time, it can have all the RAM and CPU it wants, as it provides a benefit.

                                                    If it’s an audio player or an app that lives in the tray that I have minimized 99% of the time.. WHY O WHY would you write that in Electron and use up all my ram when I never open it. I have a dozen of those running, they should be conservative in their usage.

                                                    1. 4

                                                      Compute always wins. Imagine anything that was hard in the past and how hardware eventually overcame it. We don’t even notice that thing anymore.

                                                      I understand the efficiency argument but the horse has kind of left the barn. Bets against webtech aren’t good bets to me. Something like Tauri, Photino or Neutralinojs will do the efficiency angle or we’ll have 512GB DDR5 sticks on desktop around ~2022. Yes, it’s a shame it’s a waste and there are other platforms than desktop but they’ll follow suit eventually.

                                                      API and feature-wise, I can’t imagine something like QT having feature parity or adoption force. I appreciate and love the QT apps I use, they are lightweight and fast. I appreciate QT and efficiency. I just have stopped betting against webtech. The OP’s 2nd point of web tabs use memory too is slightly weak but I like the idea. You can close tabs and kind of manage it. You can’t do this in Slack for example.

                                                      I understand the debate and I’m happy to listen, I’m just trying to write down where my head is at about this. I hope you consider compute always wins even if it annoyingly generalized.

                                                      1. 6

                                                        This view is stuck in the 90s. CPU speeds and memory sizes have plateaued since the mid 2000s.

                                                        1. 3

                                                          Here’s a graph from 2014 to 2021 across two architectures. https://twitter.com/iancutress/status/1334549180967227393 One arch (arm) is absolutely not plateaued (if you mean flat), the other is still having 10-20% IPC jumps per gen. Cores have been increasing, performance for parallel work is massively upward trend.

                                                          Since 2000s dollar per GB of RAM is going down. I mentioned DDR5 stick density. We’ll see about price. Memory size is increasing, has been. https://jcmit.net/memoryprice.htm

                                                          Surely computers have not been ~the same speed since the early 2000s? Can I read something you are thinking of?

                                                          1. 3

                                                            Surely computers have not been ~the same speed since the early 2000s? Can I read something you are thinking of?

                                                            Computers in the early 2000s were nearly doubling in speed annually. You’re talking about low double digits. That’s an order of magnitude slower growth.

                                                            Going from 1993 to 2003, my CPU went from 33 mhz to 2.4 ghz, a factor of about 1000. Probably more when counting IPC increase. My ram went from 12 megs to 1 gig of ram, a factor of 100.

                                                            Between 2011 and 2021, we’ve seen nothing like that, especially counting single core performance. We’ve probably roughly doubled single core CPU performance, and quadrupled memory sizes. I’d say that this is a plateau.

                                                            (And, sure, core counts have gone up – but that requires programmers to spend time optimizing – and effective optimizations mean ensuring that you’re not getting false sharing, slowing things down due to cache line ping pong and lock contention, etc. It’s not a free lunch.)

                                                            1. 1

                                                              Also, while performance capability has gone up, so have performance requirements - if you compared Windows XP to Windows 10, you’ll find a whole lot of stuff had to be removed from kernelspace and slowed down as a result, AIUI. It’s not enough to just run XP on a Ryzen chip, these days.

                                                      2. 3

                                                        Why Electron apps are fine

                                                        Fine for the author. It’s OK for each of us to have our own standards, and there’s no reason you should lower your standards just because many users don’t care about what you care about.

                                                        1. 3

                                                          I’ve never gotten the feedback during the last ten years: “It’s a nice app, but it would be better if it were a native app”. Not once.

                                                          Thats my hunch as well. The only time I hear about this complaint is on HN

                                                          1. 3

                                                            No. They’re not. Do you want ants? Because that’s how you get ants.

                                                            1. 2

                                                              It is a finely-crafted constructive comment. It menaces with spikes of snarkiness.

                                                            2. 2

                                                              All I want is a cross-platform high-performance accelerated 2d scenegraph, basically at feature parity with Flash, with a C API so you can bind to it from C++ / Rust / Zig / JSKit.

                                                              1. [Comment removed by author]

                                                                1. 2

                                                                  Him saying “the choice is between an Electron app or no macOS app” makes me laugh because he clearly has no clue what’s even out there.

                                                                  So what is out there then? Because I’m not aware of what is. I talked about some of what I’ve looked at in https://lobste.rs/s/knejqd/why_electron_apps_are_fine#c_gzeqnn

                                                                  BUT. If you’re actually writing the thing yourself there are much better ways of writing a cross-platform application.

                                                                  How often do you write an app yourself in a vacuum and continue supporting it in perpetuity? Most apps are written in teams and teams change over time. I don’t necessarily mean big tech shops with hypergrowth, I mean even if you are the app maintainer of a small local store, you’ll eventually want to leave and then the store will have to hire someone else to replace you. Then that person will have to learn the language you chose and the FFI bindings you invoked along with just … writing the business logic for the local store.