[HN Gopher] Claude is an Electron App because we've lost native
___________________________________________________________________
Claude is an Electron App because we've lost native
Author : todsacerdoti
Score : 94 points
Date : 2026-03-03 17:09 UTC (5 hours ago)
(HTM) web link (tonsky.me)
(TXT) w3m dump (tonsky.me)
| ttd wrote:
| Some random thoughts, since I've had a similar train of thought
| for a while now.
|
| On one hand I also lament the amount of hardware-potential
| wastage that occurs with deep stacks of abstractions. On the
| other hand, I've evolved my perspective into feeling that the
| medium doesn't really matter as much as the result... and most
| software is about achieving a result. I still take personal joy
| in writing what I think is well-crafted code, and I also accept
| that that may become more niche as time goes on.
|
| To me this shift from software-as-craft to software-as-bulk-
| product has some similarities to the "pets vs cattle" mindset
| change when thinking about server / process orchestration and
| provisioning.
|
| Then also on the dismay of JS becoming even more entrenched as
| the lingua franca. There's every possibility that in a software-
| as-bulk-product world, LLM-driven development could land on a
| safer language due to efficiency gains from e.g. static type
| checking. Economically I wonder if an adoption of a different
| lingua franca could manifest by way of increasing LLM development
| speed / throughput.
| usrnm wrote:
| > LLM-driven development could land on a safer language
|
| Why does an LLM need to produce human readable code at all?
| Especially in a language optimized around preventing humans
| from making human mistakes. For now, sure, we're in the
| transitional period, but in the long run? Why?
| zadikian wrote:
| LLMs are better at dealing with human-readable code on their
| own too
| IncreasePosts wrote:
| For one thing, because it would be trained on human readable
| code.
| mandevil wrote:
| I can't even imagine what "next token prediction" would look
| like generating x86 asm. Feels like 300 buffer overflows
| wearing a trench-coat, honestly.
| zadikian wrote:
| It'd just run out of tokens
| jerf wrote:
| From my post at
| https://jerf.org/iri/post/2026/what_value_code_in_ai_era/ ,
| in a footnote:
|
| "It has been lost in AI money-grabbing frenzy but a few years
| ago we were talking a lot about AIs being "legible", that
| they could explain their actions in human-comprehensible
| terms. "Running code we can examine" is the highest grade of
| legibility any AI system has produced to date. We should not
| give that away.
|
| "We will, of course. The Number Must Go Up. We aren't very
| good at this sort of thinking.
|
| "But we shouldn't."
| recursive wrote:
| So humans can verify that the code is behaving in the
| interests of humanity.
| mjr00 wrote:
| Because the traits that make code easy for LLMs to work on
| are the same that make it ideal for humans: predictable
| patterns, clearly named functions and variables, one
| canonical way to accomplish a task, logical separation of
| concerns, clear separation of layers of abstraction, etc.
| Ultimately human readability costs very little.
| davorak wrote:
| > For now, sure, we're in the transitional period, but in the
| long run? Why?
|
| Assuming that after the transitional period it will still be
| humans working with ai tools to build things where humans
| actually add value to the process. Will the human+ai where
| the ai can explain what the ai built in detail and the human
| leverages that to build something better, be more productive
| that the human+ai where the human does not leverage those
| details?
|
| That 'explanation' will be/can act as the human readable code
| or the equivalent. It does not need to be any coding language
| we know today however. The languages we have today are
| already abstractions and generalizations over architectures,
| OSs, etc and that 'explanation' will be different but in the
| same vein.
| ttd wrote:
| Well, IMO there's not much reason for an LLM to be trained to
| produce machine language, nor a functional binary blob
| appearing fully-formed from its head.
|
| If you take your question and look into the future, you might
| consider the existence of an LLM specifically trained to take
| high-level language inputs and produce machine code. Well, we
| already have that technology: we call it a compiler.
| Compilers exist, are (frequently) deterministic, and are
| generally exceedingly good at their job. Leaving this behind
| in favor of a complete English -> binary blob black box
| doesn't make much sense to me, logically or economically.
|
| I also think there is utility in humans being able to read
| the generated output. At the end of the day, we're the
| conscious ones here, we're the ones operating in meatspace,
| and we're driving the goals, outputs, etc. Reading and
| understanding the building blocks of what's driving our lives
| feels like a good thing to me. (I don't have many well-
| articulated thoughts about the concept of singularity, so I
| leave that to others to contemplate.)
| mushufasa wrote:
| Perhaps a hot take, but I'm glad for electron apps because that
| also means they will be well supported on linux, which is almost
| never the target of native development.
| tuetuopay wrote:
| Conversely, an app using native toolkits (at least the Windows
| ones) will have better chances of running fine under Wine. I've
| recently had the (dis)pleasure of trying to run some .Net
| monstruosity with Wine, and oh my got did it not work for
| obscure reasons.
|
| But overall yeah, from a compatibility perspective, nothing
| beats Electron. I'm not sure we'd ever get an official Discord
| client on Linux otherwise.
| lostmsu wrote:
| Now if only Wine would work natively on Android
| drcongo wrote:
| I _really_ hate Electron, but something is so rotten under macOS
| that even some of Apple 's own native apps are appalling. The
| Settings and Passwords apps are so bad as to be almost unusable,
| I'd love to know how and why they're that bad - are they
| catalyst, or just badly made?
| nullbyte wrote:
| They did something to Settings after MacOS Monterey that made
| it very slow. I miss the snappiness of the old app!
| dilap wrote:
| I don't know for a fact, but I'd bet a few digits of cold
| hard cash it's a SwiftUI rewrite that is to blame. (Any1 in
| the know want to chime in?)
|
| And yeah, it's terrible. Apple doesn't make good apps
| anymore.
|
| (This is part of why I think electron does so well -- it's
| not as good as a really good native app [e.g. Sublime Text],
| but it's way better than the sort of default whatever you'll
| get doing native. You get a lot of niceness that's built into
| the web stack.)
| poszlem wrote:
| Well, perhaps it has something to do with the fact that they
| started using webviews for stuff like system UI:
| https://blog.jim-nielsen.com/2022/inspecting-web-views-in-
| ma...
| jen20 wrote:
| While there are missing features (e.g. ability to merge
| records), I have to say that Passwords.app is worlds ahead of
| 1Password since their electron rewrite. System Settings is not
| the best (mostly because the search is broken), but Passwords
| is sufficiently good that I haven't bothered looking what it's
| written using, whereas I can immediately tell with Electron.
| drcongo wrote:
| Hard agree on 1Password. After Slack it's probably the worst
| Electron app on my Mac.
| bloomca wrote:
| System Settings is so slow for the amount of contents it has
| that I have to say it is probably the worst offender per
| content capita
| goda90 wrote:
| Maybe the hardware supply crisis caused by demand for AI data
| centers will lead to a push for more efficient and backwards
| compatible client software.
| RobRivera wrote:
| Ha
|
| Hahaha
|
| Hahahahaha
| pjmlp wrote:
| Nah, some developers are lazy, that is all, lets not dance around
| the bush with that one.
|
| Most of those Electron folks would not manage to even write C
| applications on an Amiga, use Delphi, VB, or whatever.
|
| Educated on node and do not know anything else.
|
| Even doing a TUI seems like a revelation to current generations,
| something quite mudane and quite common on 1980's text based
| computing of Turbo Vision, Clipper and curses.
| reactordev wrote:
| They wrote a React TUI renderer, that's what they did. Shame...
|
| I understand why, but there is such beauty in the simplicity of
| ansi.
| pjmlp wrote:
| The company that supposedly is selling that AI can do
| everything to replace us.
| esafak wrote:
| I see no contradiction. You _could_ get replaced by an
| agent that spews out React TUIs; as if corporate buyers are
| going to care about the difference!
| reactordev wrote:
| That's the hard swallow. End users only care about the UX
| and it working. They don't care how succinct your code
| is. They indirectly care about its performance.
| zadikian wrote:
| At least it seems like a lot more apps are cross-platform than
| before. I wouldn't call the native devs lazy for not making a
| Mac version of their Windows app.
| pjmlp wrote:
| Agreed, yet back in the day we even managed to do that with
| applications being written in Assembly, in some cases.
|
| Uphill both ways, should be easy for a company doing C
| compilers with LLMs.
| codebje wrote:
| Early games frequently took the approach of inventing an
| interpreted machine code in which the bulk of the game
| would be written, with an assembly interpreter that would
| need to be rewritten for each target IA and modified for
| the specific peripheral mixes of each target machine.
|
| The approach runs slower than a game written directly in
| assembly, but the cost to port to different architectures
| is much lower.
|
| Sort of like Electron trades off native performance and
| look-and-feel to make multi-platform apps much more
| achievable.
|
| IMO the OS vendors failed everyone by refusing to even
| attempt to agree on a common API for UI development, paving
| the way for web browsers to become the real OS and,
| ultimately, embedded browsers to be the affordable and
| practical way to be cross platform.
| Iolaum wrote:
| In an age where LLM's start writing applications why would this
| matter?
| pjmlp wrote:
| Yet another reason to have those LLMs create native
| applications, should be easy apparently.
| avbanks wrote:
| I agree, this is clearly an indictment against LLMs. If LLMs
| and agents were capable they'd 100% write it natively but
| they realize the current limitations.
| sehugg wrote:
| Realize, though, that just grabbing a frame buffer is not a
| thing anymore. To render graphics you need GLES support through
| something like ANGLE, vectors and fonts via Skia, Unicode, etc.
| A web browser has those things. Any static binary bundling
| those things is also gonna be pretty large.
|
| And JavaScript is very good at backwards compatibility when you
| remove the churn of frameworks (unfortunately Electron doesn't
| guarantee compatibility quite as far back)
| pjmlp wrote:
| And CPUs are only sand powered by electricity.
|
| I do realise the need for abstractions and they do exist,
| provided there is actually the interest to _learn them_.
| dist-epoch wrote:
| I've programmed in every native Windows GUI starting with MFC.
| Used Delphi too. I've even created MS-DOS TUI apps using Turbo
| Vision.
|
| Compared to the web stack and Electron, native GUI APIs are
| complete shit. Both for the programmer, but also for the user.
|
| Reactive UI (in the sense of React, Vue, ...), the greatest
| innovation in UI programming ever, was made popular by web-
| people.
|
| Unless you write some ultra-high performance app like a
| Browser, a CAD app, a music production app, it doesn't make any
| sense to use native GUIs. Takes longer to program, the result
| is uglier and with less features. And for those ultra high
| performance apps you don't use the native UI toolkit anyway,
| you program your own widgets since the native ones are dog shit
| and slow.
| VorpalWay wrote:
| Don't forget about all the embedded UIs (kiosks, appliances,
| car infotainment, industrial equipment, ...), those computers
| are weaker and it makes a ton of sense to use native toolkits
| there.
|
| They tried to replace our Qt GUI at work in this space with a
| react based one, the new UI ran like utter shit
| comparatively, even after a lot of effort was spent on
| optimisation.
|
| Also, most of the world don't use high end developer laptops.
| Most of the world is the developing world, where phone apps
| on low end Android phones reign supreme.
| __alexs wrote:
| This is such a lazy take.
|
| Electron is very easy to deliver a good quality app for
| everything but absolute power users.
|
| Yes it's horribly slow but it enables rapid experimentation and
| it's easy to deliver the wide range of UI integrations you are
| likely to want in a chat-esq experience.
| dangus wrote:
| It's not even horribly slow. It works fine. It's just a chat
| program. It's the right trade off for the job.
|
| Doing more work for no reason is stupid even if you the have
| money of a small nation.
|
| The inevitable differences between platforms you get with all
| native everything isn't a good user experience, either. Now
| you need to duplicate your documentation and support pages
| and have support staff available to address every platform.
| And what's the payoff? Saving 80MB of RAM? Gaining
| milliseconds of latency that Joe Business will never notice
| as he's hunt and pecking his way through the interface?
|
| I thought we were done with Electron hate articles. It's so
| 2018 to complain about it. It's like talking about
| millennials and their skinny jeans. Yawn.
| hedgehog wrote:
| Let's assume for the moment the developers are doing about the
| best they can for the goals they're given. The slowness is a
| product decision, not an engineering problem. They are swimming
| in cash and could write a check to solve the problem if they
| cared. Evidence is they have other priorities.
| lapcat wrote:
| It's weird for the author to mention Mac window buttons and
| corner radius as reasons to use Electron, because while the main
| content of Electron app windows is HTML, the Electron windows
| themselves and the window chrome are native, with the same
| buttons and corner radius as other apps on the system.
|
| Electron is a native wrapper for web content. The wrapper is
| still native.
|
| > Native APIs are terrible to use, and OS vendors use everything
| in their power to make you not want to develop native apps for
| their platform.
|
| I'm honestly not quite sure what the author means here.
|
| Web APIs are equally "terrible" in my opinion. In any case, you
| have to release an Electron app on Mac the same way you release
| any native app on Mac. The benefit of using web APIs is not that
| they are non-terrible but that you can share the same code as
| your website. And of course you can more easily find web
| developers than native developers. But that has nothing to do
| with whether or not the API is terrible. It's just supply and
| demand.
|
| I'll take AppKit and autolayout any day over CSS, ugh. CSS is the
| worst.
| lxgr wrote:
| > with the same buttons and corner radius as other apps on the
| system
|
| I just checked: No, the corner radius is different. I'm
| personally not very bothered by that, but it's just empirically
| true.
|
| > Electron is a native wrapper for web content. The wrapper is
| still native.
|
| In my view, the problem isn't that it's a wrapper, but rather
| that it's that it's a bad wrapper of a bad runtime (i.e. the
| incredibly bloated JS/web stack).
| lapcat wrote:
| > I just checked: No, the corner radius is different.
|
| It may depend on which SDK version the developer uses.
| zadikian wrote:
| UIKit etc never made sense to me after years, CSS also didn't
| make sense, but right out of the box I understood React. And
| with hooks, it's way less boilerplate than the UIKit ways.
|
| Separate from that, Apple doesn't seem to mind breaking native
| macOS apps, to the point where most devs treat native code like
| a liability on Mac but ok on Windows.
| reconnecting wrote:
| 10 days ago: https://news.ycombinator.com/item?id=47104973
| rapnie wrote:
| Besides going full native, a Tauri [0] app might have been
| another good alternative given they already use Rust. There are
| pros and cons to that choice, of course, and perhaps Tauri was
| considered and not chosen. Tauri plus Extism [1] would have been
| interesting, enabling polyglot plugin development via wasm. For
| Extism see also the list of known implementations [2].
|
| [0] https://tauri.app/
|
| [1] https://extism.org/
|
| [2] https://github.com/extism/extism/discussions/684
| headcanon wrote:
| +1 for Tauri, I've been using it for my recent vibe-coded
| experimental apps. Making rust the "center of gravity" for the
| app lets me use the best of all worlds:
|
| - declarative-ish UI in typescript with react
|
| - rust backend for performance-sensitive operations
|
| - I can run a python sidecar, bundled with the app, that lets
| me use python libraries if I need it
|
| If I can and it makes sense to, I'll pull functionality into
| rust progressively, but this give me a ton of flexibility and
| lets me use the best parts of each language/platform.
|
| Its _fast_ too and doesn 't use a ton of memory like electron
| apps do.
| EduardoBautista wrote:
| Also, Rust's strong and strict type system keeps Claude
| honest. It seems as if the big LLM models have trained on a
| lot of poorly written TypeScript because they tend to use
| type assertions such as `as any` and eslint disable comments.
|
| I had to add strict ESLint and TypeScript rules to keep
| guardrails on the coding agents.
| rapnie wrote:
| I added a list of known Extism implementers to my comment
| above, to take inspiration from should Extism be attractive
| to consider for you.
| oooyay wrote:
| I use something similar to Tauri called Wails:
| https://wails.io/ that's Go-based.
| tvink wrote:
| Looks cool, but the phrase 'build applications with the
| flexibility and power of go' made me chuckle. Least damn
| flexible language in this whole space.
| Joeboy wrote:
| I find it a bit odd how much people talk up the Rust aspect of
| Tauri. For most cases you'll be writing a Typescript frontend
| and relying on boilerplate Rust + plugins for the backend. And
| I'd think most of the target audience would see that as a good
| thing.
| rapnie wrote:
| I am considering a Tauri app, but still wondering about
| architecture design choices, which the docs are sparse about.
| For instance the Web-side may constitute a more full-blown,
| say NextJS, webapp. And include the database persistance, say
| SQLite based, on the web side too, closest to the webapp.
| That goes against the sandboxing (and best-practice likely),
| where all platform-related side effects are dealt with
| Platform-side, implemented in Rust code. I wonder if it is a
| valid choice. There is a trade-off in more ease of use and
| straightforwardness vs. stricter sandboxing.
| jemmyw wrote:
| At least with Tauri it's easy to both make the choice and
| change it later if you want to. I think the docs are sparse
| because it's your decision to make. I've done it both ways
| and there are pros and cons. If you use the sqlite plugin
| and write the actual statements on the JS side then you
| don't need to worry about the JS<->Rust interface and
| sharing types. Easier to just get going. If you write your
| own interface then you probably want to generate TS types
| from Rust. I think a big advantage to the Rust interface
| way is that it makes it easier to have the web side be dual
| purpose with the same code running on the web and in Tauri
| - the only difference being whether it invokes a tauri call
| or an API call.
| francisl wrote:
| I working on a project using tauri with htmx. I know a bit
| uncommon. But the backend part use axum and htmx. No Js/Ts
| UI. It's fast, reliable and it work well. Plus its easy to
| share/reuse the lib with the server/web.
| TimFogarty wrote:
| I have been using Tauri for a macOS app I'm making[1] and it
| has been great. The app is only 11MB and I've had most of the
| APIs I'd need.
|
| However, there are still some rough edges that have been
| annoying to work with. I think for my next project I will
| actually go back to electron. There are two issues that caused
| me pain:
|
| 1. I can't use Playwright to run e2e tests on the tauri app
| itself. That's because the webview doesn't expose the Chrome
| DevTools Protocol, and the tauri-driver [2] does not work on
| MacOS.
|
| 2. Security Scoped Resources aren't fully implemented which
| means if a user gets the app through the app store the app
| won't be able to remember file permissions between runs [3].
| It's not too much of an issue since I probably won't release it
| on the app store, but still annoying.
|
| But I hope Tauri continues to grow and we start seeing apps use
| it more.
|
| [1] https://tidyfox.app/
|
| [2] https://v2.tauri.app/develop/tests/webdriver/
|
| [3] https://github.com/tauri-apps/tauri/issues/3716
| nitwit005 wrote:
| Even if web rendering is the best technology possible, there's
| still plenty you could hypothetically optimize, like replacing
| the Javascript with native code, or cutting out unused features
| to get a smaller download.
|
| Ultimately, Claude having limitations is an issue. They can't
| just point it at the code base and ask it to make it faster.
| written-beyond wrote:
| You've basically described Flutter and Jetpack compose(for
| desktop). The problem really does turn into effort to pay off,
| even if we stayed with JS and the rendering engine, figured out
| a way to compile JS into native code and completely stripping
| all of the unused functionality and doing the same thing with
| the rendering engine. All of that would need to be made, it's
| not like electron apps literally crash you machine. You have
| metrics, hundreds of millions of devices running electron apps
| at a daily basis. Unless you make your own company, I don't
| think anyone can convince their leadership to take such a
| decision.
| nitwit005 wrote:
| I'm not arguing for actually doing this, I'm just suggesting
| Claude's limitations are actually an issue (contrary to what
| the article asserts).
| zitterbewegung wrote:
| X foundational model Apps UIs are electron apps because all of
| them are web first and App second and the easiest way to do this
| is being an Electron app.
| zadikian wrote:
| What's the advantage of their Electron apps vs using the web? I
| get that in theory you can use native-only pieces that a
| browser doesn't support, but in practice a lot of Electron apps
| are literally the website.
| daxfohl wrote:
| I imagine the first step would be for them to make a cross
| platform UI framework that's better than any existing options,
| and then port claude to it.
|
| Making five different apps just to claim "native" doesn't seem
| like a great choice, and obviously for now, delivering new claude
| features takes priority over a native graphics framework, so
| electron makes sense. But that doesn't mean it'll be on electron
| forever.
| ToucanLoucan wrote:
| Respectfully: skill issue. My employer ships software native
| for Windows, Mac, iOS and Android. Different codebases for all
| (though they share a lot of common stuff), all maintained by a
| shockingly small team.
|
| It's absolutely achievable if you give a shit about your
| products and I'm long over hearing the bevy of usual fucking
| excuses from software houses often magnitudes larger than us
| who struggle to even keep their electron shit working
| correctly.
| jen20 wrote:
| Native is shorthand for "integrated into the platform". Lowest-
| common-denominator stuff that Electron gives feels correct
| nowhere (looking at you, Slack). The very best cross-platform
| applications implement their UI using the native platform
| idioms on the native platform technologies, and share the core
| of their logic. The current best example I have is Ghostty
| which feels perfectly at home on either macOS or Linux.
| jxdxbx wrote:
| When I complain about a lack of "native" software I pretty much
| always mean the platform-provided defaults. Not some cross-
| plaform UI toolkit that happens to be "native" code. Most apps
| that I see using QT on Mac or whatever would provably be better
| as Tauri apps.
| HoldOnAMinute wrote:
| >> cross platform UI framework
|
| How about Java Swing? It's already battle tested and deployed
| everywhere you have Java.
| asah wrote:
| great post - let me add that native was forced into some of this
| _by_ the web:
|
| 1. locked up files ==> that's for security, which wasn't an issue
| in the 1990s.
|
| 2. inconsistent look ==> people are embedding browsers inside
| apps for all sorts of reasons, ruining the "native" UI/UX even if
| the OS "look" were stable.
|
| It took a while, but once again open source and the web kinda
| won, though if you like consistency, then I agree it's a pyrrhic
| victory...
| rvz wrote:
| More like a skill issue, than 'losing native'.
| fHr wrote:
| Codex cli rust /thread
| strongpigeon wrote:
| But the Codex app is Electron based...
| baggachipz wrote:
| _Clicks link, goes to blog site_
|
| My eyes! The goggles, they do nothing!
| 1970-01-01 wrote:
| Isn't native just the CLI?
| giancarlostoro wrote:
| I have been using Claude Code ironically enough to build native
| apps via Qt and Rust, the output is impressive. Might give
| writing an IRC client a shot and put it in GitHub.
| andyjohnson0 wrote:
| I felt that this article didn't provide strong justifications for
| some of its assertions.
|
| > Native APIs are terrible to use, and OS vendors use everything
| in their power to make you not want to develop native apps for
| their platform.
|
| Disagree. I'm most familiar with Windows and Android - but native
| apps on those platforms, snd also on Mac, look pretty good when
| using the default tools and libraries. Yes, its possible to use
| (say) material design and other ux-overkill approaches on native,
| but thats a choice just like it us for web apps.
|
| And OS vendors are very much incentivised to make natuve
| development as easy and painless as possible - because lock-in.
|
| > That explains the rise of Electron before LLM times,
|
| Disagree. The "rise of Electron" is due to the economics of
| skill-set convergence on JS, the ubiquity of the JS/HTML/CSS/Node
| stack platform, and many junior developers knowing little or
| nothing else.
|
| As for the rest: minor variations in traffic light positioning
| and corner radii are topical but hardly indicators of decaying
| platorms.
| bdangubic wrote:
| > Disagree. The "rise of Electron" is due to the ubiquity of
| the JS/HTML/CSS/Node stack, and many junior developers knowing
| nothing else.
|
| with all due respect - hard disagree. in what place on Earth to
| Junior Devs make these types of decisions?? Or decision makers
| going "we got these Juniors that know JS so it is what is..."
| nitwit005 wrote:
| I don't believe they were implying they would make the
| decision. It's expensive to have your team learn new skills
| from scratch, and management won't want to pay for that if
| they don't have to.
| bdangubic wrote:
| I have been coding for 30 years now and I have _never_
| encountered a technical decision like choosing technology
| (e.g. Electron) for anything important to the company being
| made with "oh, we must use X because so and so knows X"
|
| Maybe if there was a toss-up between X and Y or something
| like that but to flat-out pick Electron because you have
| people that knows JS is madness
| andyjohnson0 wrote:
| I'm thirty+ years in too, and it happens all the time -
| particularly in smaller operations. Resourcing
| constraints, disinclination to provide training, tight
| deadlines, etc.
| bdangubic wrote:
| so interesting!! and scary :)
| andyjohnson0 wrote:
| This is indeed what I meant. Thanks for stating it with
| more clarity than I was able to.
| bloomca wrote:
| The rise of Electron was purely because you can share the
| codebase for real with the web app (for lots of apps it is
| their main focus) and get cross-platform support for free.
|
| Native apps are not bad to develop when using Swift or C#, they
| are nice to use and their UI frameworks are fine, it's just
| that it requires a separate team. With Electron you need much
| less, simple as that.
|
| > As for the rest: minor variations in traffic light
| positioning and corner radii are topical but hardly indicators
| of decaying platorms.
|
| I think it shows how important the platform itself is to the
| company. The system settings app on macOS is literally slow to
| change the topic (the detail page is updated like ~500ms after
| clicking).
|
| I personally love to develop desktop apps but business-wise
| they rarely make sense these days.
| d0m wrote:
| Apple/Google could easily make web apps native if they wanted
| etothet wrote:
| "The real reason is: native has nothing to offer."
|
| I get it, but this is a bit dramatic.
|
| One of the biggest challenges I've found with using non-native
| tools (and specifically the various frameworks that let you write
| JavaScript that compile to Native code) is that there is much
| less of a guarantee that the 3rd party solution will continue
| support for new OS versions. There's much less of a risk with
| that with 1st party solutions.
|
| Additionally, those 3rd parties are always chasing the 1st part
| vendor for features. Being far behind the regular cadence of
| releases can be quite inconvenient, despite any advantages
| initially gained.
| odiroot wrote:
| I'd still take native KDE/Plasma apps over Electron any day. Just
| the performance and memory usage alone is worth it.
|
| Sublime Text feels so much snappier than VSCode, for another
| example. And I can leave it running for weeks without it leaking
| memory.
| eikenberry wrote:
| This wouldn't be an issue if they allowed 3rd party apps or
| priced their API competitively with their subscriptions. Free
| software normally fixes these types of problems but is prevented
| in this case.
| rapnie wrote:
| With regards to "we've lost native" isn't local-first _the
| opportunity_ to bring it back in a paradigm shift that deals a
| blow to both the browser _and_ cloud vendor hegemonies?
|
| https://lofi.so/
| il-b wrote:
| Somehow, a CAD program, a 3D editor, a video editor, broadcasting
| software, a circuit simulation package, etc are all native
| applications with thousands of features each - yet native
| development has nothing to offer?
| alentred wrote:
| Having said (read) that, I am surprised there is still no
| official Claude Desktop app for Linux. :'(
| dankwizard wrote:
| With today's processors and speeds, there really is no difference
| in performance of these Electron apps vs Native and anyone
| disagreeing just dislikes the JS ecosystem
| amelius wrote:
| How about power, and battery capacity?
| felixgallo wrote:
| also memory footprint, jank, and the pitch-black dependency
| forest.
| bdangubic wrote:
| Cannot agree more. Whenever I am making a decision like picking
| tech at work I always assume everyone who will use it has new
| $5k MBPs.
|
| all the kids in schools with their chromebooks and whatnots? -
| oh well, they can tell their parents to get you an MBP :)
| gib444 wrote:
| Everyone has a 1000Mbps fibre connection too with 3ms
| latency. If not, well, they need to try harder at not being
| poor
| hedgehog wrote:
| Claude is slow on a $5k MBP too.
| weakfish wrote:
| hard disagree, Zed, for example, feels miles better than VS
| Code
| msy wrote:
| The thing people miss is isn't not that there aren't downsides
| (power, memory, disk size, dependency ecosystem size etc etc)
| it's that they're still completely outweighed by the upsides of
| write-once-ship-all for authors.
| __alexs wrote:
| I probably drink more web kool aid than the next guy but this
| is just not true.
|
| Electron apps dealing with more than a small handful of data
| rapidly start to show poor frame timing and input lag.
| elashri wrote:
| I disagree because yes I dislike the whole JS ecosystem and the
| language itself. But also because Electron apps in general are
| resource monsters and while some are better than the others,
| Claude Desktop is definitely not one of them. Hell even their
| website will crash on Firefox very often.
| graypegg wrote:
| Based on "anyone disagreeing just dislikes the JS ecosystem", I
| feel like you might not want to grace me with a response, but I
| disagree /somewhat/.
|
| Electron and web technology generally is certainly more
| performant than it once was, and I think people do malign
| Electron specifically a bit too much. VS Code continues to be
| the anti-example. It's always rather surprising it's just a web
| view, even on lower end hardware. (A several year old raspberry
| pi for example)
|
| (Please note, I said "surprising it's just a web view", not
| "it's more performant than it could be if built differently".)
|
| I think the main difference people tend to experience is a lack
| of care. I would say, for reasons I am NOT sure are causal,
| electron apps do seem to tend towards worse experiences on
| average in my experience. I think on the web, a quick flash of
| unstyled content or that ghost of the element you accidentally
| dragged instead of clicked are seen as just minor issues,
| because they're expectations of the web. If things go REALLY
| wrong, I have a whole rock solid toolbar above the app that
| lets me refresh if I think I'm in some infinite loop, or the
| URL bar I can look at if I'm not sure what page I was just
| redirected to. The back button promises to return me to where I
| was before. The browser is caging-in applications for me, so
| it's fine if they're a bit rowdy.
|
| But using an application that is pretending to NOT be a web
| browser, seeing any web-quirk feels like I'm staring at rusted
| rebar in a cracked concrete bridge. The bridge still works, but
| now I'm aware of the internals of it and maybe that makes me
| feel a little more uneasy about standing on it. There is no
| back button if something goes wrong, and if there is, the app
| itself is rendering it. It's of course possible to hide that
| reality from me, but you need to care about sealing up all the
| cracks that let me see the rowdy internals.
|
| To be fair, maybe that's just me that feels that way. And I do
| rather like the JS ecosystem.
| nfcampos wrote:
| But on the other hand the claude app is garbage...
| https://github.com/anthropics/claude-code/issues/22543 obviously
| native apps can be garbage too, but I must say electron apps have
| a surprisingly high incidence of terrible performance issues,
| unsure if it's a correlation or causation issue
| dtagames wrote:
| This is a good thing. Native was always a place where gatekeeping
| and proprietary crap sprout and thrive.
|
| It can't die soon enough. Doesn't all have to be Electron, but
| web tech for the win and force everything to the browser unless
| you'd like to write it twice.
| HoldOnAMinute wrote:
| Use Claude to create native apps. Done.
|
| It can even create a beautiful Java Swing apps.
| rmonvfer wrote:
| I love Claude but both the desktop and the web apps are
| incredibly janky when compared with their OpenAI counterparts (I
| won't even comment on Gemini's because it's also incredibly
| broken and unreliable).
|
| Start times are atrocious, long conversations literally break
| rendering (and I'm using the desktop app on a MacBook Pro with an
| M3 Pro CPU and 36 GB of RAM so an electron app shouldn't feel so
| janky so frequently, right?).
|
| IMHO they just don't care right now (and I get it from their
| perspective) but I'm pretty sure there's a lot of low hanging
| fruit they could fix to make the experience 5x or even 10x
| smoother. Claude Code (TUI) is also another memory hog and I've
| even had Ghostty literally crash with enough open sessions.
|
| Fortunately Anthropic models are also incredibly so at least I've
| been able to speedrun my own desktop client using Tauri and fix
| many of the issues I encounter every day. I might release it at
| some point.
| titanomachy wrote:
| I've only built some basic CRUD-type apps in SwiftUI, but I
| thought it was pretty nice. The APIs seem well thought-out, I
| needed less code than I would have to do the same thing in React,
| and the default styling looked quite professional.
|
| Of course, the React ecosystem and community is enormous. I bet
| if I was building something complex, I would have gotten
| frustrated building it all from scratch in SwiftUI when I could
| just reach for a React component library.
| cladopa wrote:
| I would say that the real reason is because "it works". As simple
| as that.
|
| The first thing you need when you make something new is making it
| work, it is much better that it works badly than having something
| not working at all.
|
| Take for example the Newcomen engine, with an abysmal efficiency
| of half a percent. You needed 90 times more fuel than an engine
| today, so it could only be used in the mines were the fuel was.
|
| It worked badly, but it worked. Later came efficiency.
|
| The same happened with locomotives. So bad efficiency at first,
| but it changed the world.
|
| The first thing AI people had to do is making it work in all
| OSes. Yeah, it works badly but it works.
|
| We downloaded some Clojure editor made in java to test if we were
| going to deploy it in our company. It gave us some obscure java
| error in different OSes like linux or Mac configurations. We
| discarded it. It did not work.
|
| We have engineers and we can fix those issues but it is not worth
| it. The people that made this software do not understand basic
| things.
|
| We have Claude working in hundreds of computers with different
| OSes. It just works.
| observationist wrote:
| They could have done better. They chose the path of least
| resistance, putting in the least amount of effort, spending the
| least amount of resources into accomplishing a task.
|
| There's nothing "good" about electron. Hell, there are even
| easier ways of getting high performance cross platform software
| out there. Electron was used because it's a default, defacto
| choice that nobody bothered with even researching or testing if
| it was the right choice, or even a good choice.
|
| "It just works". A rabid raccoon mashing its face on a keyboard
| could plausibly produce a shippable electron app. Vibe-bandit
| development. (This is not a selling point.) People claiming to
| be software developers should aim to do better.
| avbanks wrote:
| No it's because LLMs aren't that good yet.
| labrador wrote:
| I'm reposting this I saved from Hacker News user gjsman-1000
| because it's so good and so true.
|
| https://news.ycombinator.com/item?id=36060678
|
| _I really doubt that at this point. Developers have learned that
| everything Microsoft says to do for Windows, since 2012, will be
| garbage within a few years. Guaranteed.
|
| Learned Silverlight for Windows Phone development? Too bad, it's
| UWP now. And the XAML is incompatible.
|
| Learned WinRT for Windows 8/8.1 app development? Too bad, it's
| UWP now. And the XAML is incompatible.
|
| Packaged your App for APPX? Too bad, it's MSIX now.
|
| You learned how to develop UWP apps? Too bad, the User Interface
| layer has been ripped out of UWP, it's now called WinUI 3, and it
| doesn't even run on UWP. Better port your UWP app back to Win32
| now, I guess. Why did you even learn UWP again?
|
| You went and learned WinUI 3 like we recommended? Well, unlike
| WinUI 2, it doesn't have a visual designer, and it doesn't have
| input validation, or a bunch of other WinUI 2 features. So,
| depending on what your app needs, you might have a mix of UWP and
| Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is
| Win32-exclusive and neither has all the features of the other.
| Progress!
|
| You built your Windows 8 app with WinJS? Well, sucks to be you,
| rewrite it in entirety, WinJS was scrapped.
|
| You ported your app from iOS with Project Islandwood? Well,
| again, that sucks. It was brilliant, it made pulling apps over
| from iOS much easier, but it's dead. Rewrite!
|
| You decided to hang it all, develop for good old WPF, but wanted
| to use the Ink Controls from UWP? Great, we developed a scheme
| for that called XAML Islands which made so you could have some of
| the best UWP controls in your old app. Then we released WinUI 3,
| completely broke it, and made it so complicated nobody can figure
| it out. So broken; even the Windows Team doesn't use it and is
| writing the modern Windows components for File Explorer with the
| old version.
|
| But of course, that would require WinUI 2, for UWP, inside Win32
| which is the main feature of the broken WinUI 3; which means that
| the Windows Team has a bastardized version of XAML Islands for
| their own use that nobody else has (literally), to modernize the
| taskbar and File Explorer and built-in apps like Paint, that
| nobody who wants to emulate them can borrow. Their apps don't
| look modern and their users complain? Suckers, go learn WinUI 3,
| even though our own teams couldn't figure it out.
|
| You wanted your app on the Microsoft Store? Well, good news,
| package it together with this obtuse script that requires 30
| command-line arguments, perfect file path formats, and a Windows
| 10 Pro License! Oh, you didn't do that? Do it 5 years later with
| MSIX and a GUI this time! Oh, you didn't do that? Forget the
| packaging, just submit a URL to your file download location.
| Anyone who bothered with the packaging wasted hours for no real
| purpose.
|
| Did I mention Xamarin? A XAML dialect of its own, that supports
| all platforms. But it runs on Mono instead of the authentic .NET,
| so you'd better... work around the quirks. Also it's called MAUI
| now, and runs on .NET now. But that might break a few things so
| hang around for over a year's worth of delays. We'll get it
| running for sure!
|
| Oh, and don't forget about ARM! The first attempt to get everyone
| to support ARM was in 2012 with a Windows version called... No,
| no, no. Go past this. Pass this part. In fact, never play this
| again. (If you want to imagine pain, imagine running Windows and
| Microsoft Office on a ARM CPU that came three generations before
| the Tegra X1 in the Nintendo Switch. Surface RT ended with a
| $900M write-off.)
|
| And so on...
|
| Or, you could just ignore everything, create a Windows Forms (22
| years strong) or WPF app (17 years strong), and continue business
| like usual. Add in DevExpress or Telerik controls and you are
| developing at the speed of light. And if you need a fancier UI,
| use Avalonia, Electron, React, or Flutter._
| cdrnsf wrote:
| On iOS there isn't always a choice to not build something native.
| For example, I can't install Navidrome as a PWA because Apple
| doesn't properly support audio playback for PWAs. I ended up
| writing a client that suited my listening habits.
|
| To read ePubs, however, I was able to write a PWA leveraging
| epub.js because no native APIs were required.
___________________________________________________________________
(page generated 2026-03-03 23:00 UTC)