Comment by kelnos
20 hours ago
> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools.
I don't think that's necessarily true. Nuance is a thing.
These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all.
(To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)
I think you contradicted yourself. If a tool provides better value for the time spent for a company, I don’t understand how you can call it objectively bad.
You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
I think they were speaking as a user. These tools create inferior products. (Still not technically objective, but true nonetheless.)
That doesn't mean companies should necessarily avoid them. As a user, I always want the best possible user experience, but a company can't prioritize that above all else, and I know that.
I am so tired of existing react/electron applications being compared against imaginary, hypothetical "native" applications.
Like, it's fine to criticize something, "this component doesn't follow the OS's UI guidelines" or "this scrollbar disappears when the mouse isn't over it which is a bad UX" or whatever, but this generic "oh this is bad but if it was rewritten it would be perfect" is annoying.
4 replies →
I'm not the OP, but my understanding (and I agree) is that it can seem like a better value when a subset of factors are considered (ones that IT can measure, biases in IT against Apple etc.) and it leads the company into making a choice that is worse for them overall.
It's objectively bad because of how hot my phone is.
It's subjectively bad because it's an embarrassment. Like you're seriously going to tell me something like Discord, worth 15 BILLION, cannot afford native apps? Spare me.
What really grinds my gears is Microsoft replacing native apps with Electron. Trillion dollar company who is so cash strapped they have no choice but to punt to the easy development path.
8 replies →
Nuance is always a thing. Native apps are faster and better most of the time. Electron and React Native wouldn't annoy me so much if they were used with small apps where it's not worth over-optimizing.
However, it's now the default for Multiplatform apps that are used constantly, including IDEs, chat apps, etc. They gobble up memory and cpu cycles and are constantly getting updates due to the shitshow that is the javascript dependancy ecosystem.
React Native apps make more revenue than Flutter and Native apps according to Revenue Cat report published on June 3rd, 2026.
https://www.revenuecat.com/blog/engineering/why-react-native...
Thanks, but from the same article:
"First key learning: execution matters far more than stack choice"
which directly translates to: make a great app and nobody cares about the tech and this includes whether or not to use Liquid Glass.
I would rather have the opposite? I don't want 10 people making small apps that use Electron. I would rather that be used for bigger apps where the overhead is negligible.
> These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
They can be "bad" in some dimensions (as you mentioned) while being "good" in others (dev productivity).
These frameworks didn't become popular for no reason. They have value. The parts that are "good" can easily outweigh the parts that are "objectively bad" when they enable a smaller team to get things out the door they would have had trouble shipping otherwise.
I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers.
For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.
I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.
After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.
A shitty developer can create a far worst experience on react then on native.
Most developers cannot make any experience on Native.
Yes but only because they can actually ship the react app
Most enterprises are comprised of a high proportion of shit developers. So you need to work with what you got
> React can render at more than 60fps if necessary, and if the code isn't shit.
Sorry, that doesn't really come across as a ringing endorsement. React apps are typically not doing anything complex so rendering at less than 60fps should only happen if you're doing very computationally intensive things or writing bottom-quartile quality code.
Yeah, obviously your average React app has no need to render anywhere near that frequently. The ones I've worked on will generally only render as a response to user action, server event or polling.
I'm just saying they can render that fast. So if your app takes a second (or several) to render it's obviously not because react is slow, it's because the code is ass.
In most cases if a React app takes a long time to render a page it isn't really rendering that's taking time, it's a slow network call or multiple. So the app being slow has nothing to do with React at all, it's the backend code that's slow or it's the frontend code doing multiple consecutive requests or something like that.
All I'm saying is react is not the reason it's slow.
None of this matters anymore.
We have LLMs.
It's easy to build native everything now without much resource expenditure.
Android will be Kotlin. iOS will be Swift. Desktop and server will be Rust. Web will be TypeScript / React for now, but maybe one day WASM.
LLMs are the target now.
Yet, neither ChatGPT desktop app nor Claude Code CLI is native. Mind you these are made by companies with practically infinite tokens.
These apps predated LLMs "getting good".
Both have an enormous number of paying customers and you don't just disrupt that for a language change.
2 replies →
FYI I've been building an app, Android first, and discovered the magic of Kotlin Multiplatform. The LLM modularized everything so that it's substantively the same code base, but with Swift only where it's needed. Still working through it, but it seems like a great and underrated platform to build on.
You're not emitting the code yourself anymore. The platform ease of use for humans no longer matters as much (if at all).
Preference for a native feel, solid software, bugfree code, compile/develop velocity, LLM friendliness.
We're in a brand new world.
I'm building an app that targets Android, iOS, Windows, Mac, Linux. There's no way I'm going to be maintaining 5 different codebases, even with LLMs.
This is one of those “oh gosh” posts at first glance, then you actually think about it, and it’s 100% correct. Python, Node exist to save the precious commodity of developer time. Once that’s no longer precious, best value comes from purified custom Rust, no attack surface from huge libraries, optimized performance for the specific task on all possible hardware.
Windows desktop native is WinUI 3 and Windows App SDK, for better or for worse. No amount of Rust and tokens will recreate everything you get out of the box with that stack. Native needs to feel native.
The last time Windows UI felt native was maybe Windows XP. Maaayyybe 7, if we are generous. It also has to do with sluggish or no feedback by UI widgets, due to the trend of flat everywhere.
not sure why you're getting downvoted. but if you're building even very popular applications, it is quite easy to see how LLMs are very well suited for this type of consistency job.
- they follow instructions quite well.
- are tireless at doing mechanical ports between languages and frameworks.
- Can understand a new ecosystem quite well.
Then why aren't people doing that? Microsoft has as much access to cheap tokens as any software company around, right, so you'd think they would be leading the way.
2 replies →
I didn't downvote but I'd expect downvotes for a completely unnuanced thought terminating cliche that ignores everything in the thread. AI fanaticism doesn't help but lots of people don't get downvoted for that alone.
A well built native app can still serve as a vector for harvesting personal data in ways you cannot control. A web app is inherently superior because of its security envelope.
A React Native app would have all the same access to your personal data that a native app would
That isn't a web app.
A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.
In stories like this its much more likely that they just got sick of refactoring a big ugly code base so got buy in to throw it all away and starting over and the justification is native. Wait like 5 years and there will be a new react-native corss platform app because the native apps have too much cruft. Assuming we still have human in the loop then.
> A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.
Sure, but thats not an interesting observation unless there is something about react-native that makes those apps consistently higher quality than native apps.
On the other hand, like-for-like C/C++/Rust performs better than javascript in terms of CPU and memory use, so the null hypothesis is that re-implementing would , in fact, improve things. There's little reason to think a priori that the end result would somehow be worse.
I think they also got sick of supporting those open source libraries.