Remix.run Logo
kelnos 5 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.)

danisth 5 hours ago | parent | next [-]

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.

shiflett 5 hours ago | parent | next [-]

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.

wredcoll 4 hours ago | parent [-]

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.

pessimizer 3 hours ago | parent [-]

It's always the preference of people defending bad decisions to compare them to doing nothing.

What you're seeing is people actually making that case instead of forcing it. They're saying that if the app wouldn't exist without this bad thing, then it is appropriate to compare using the bad thing to doing nothing.

You just seem to be demanding that people not mention other ways to do things, or you'll get angry.

joefourier 3 hours ago | parent [-]

The app not existing would unironically be better in so many instances, though. The web version doesn’t take up 1GB of disk space, install persistent services, send you push notifications by default, and it’s trivial to block ads in comparison.

I’d be very happy if companies didn’t artificially degrade their web version to force installation of an “app” that’s effectively a web browser in disguise.

xp84 2 hours ago | parent [-]

Hard agree. Day by day, I become more exhausted with "apps" as they are currently delivered, with native being slightly better than cross-plaform, but not good.

Apps in 2026 deliver all the disadvantages of a plain ol' website (Requires an always-on WAN to have any function whatsoever, UI that doesn't meld with the OS in any way, no integration with things like Shortcuts...) but add huge real costs: Extra time before I can start using it, the hogging of easily 500-1000MB of disk space on day 1, a growing un-clearable cache, sluggish transitions with useless animations, and the need to be "updated" on a regular basis (whether used or not) wasting my time and bandwidth.

One of the few benefits to me as the user of a 'client application' has always been that a well-made app uses an API to speak to the server which is dramatically lower bandwidth than the modern BloatWeb with AdTech™ stack could ever match, which ought to enable the highest performance. But it seems like they rarely actually deliver that benefit.

1123581321 5 hours ago | parent | prev | next [-]

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.

ToucanLoucan 5 hours ago | parent | prev [-]

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.

0cf8612b2e1e 5 hours ago | parent [-]

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.

cosmic_cheese 4 hours ago | parent | next [-]

The thing that makes Microsoft's case particularly annoying is that they have demonstrated how they can develop half-decent Electron apps with VS Code, but have simply elected not to with anything that's not VS Code.

Like yes, I'd prefer native and MS can certainly afford to take that path, but they can't even be bothered to make sure that most of their Electron apps land on the upper half of the quality spectrum.

skydhash an hour ago | parent [-]

> they can develop half-decent Electron apps with VS Code,

Only if you don't compare it with any native or quasi native editors like Notepad++ or Sublime text. And Emacs has been cross-platform for decades.

xp84 2 hours ago | parent | prev | next [-]

Yikes. What apps have they been doing this with?

ToucanLoucan 5 hours ago | parent | prev [-]

What's extra egregious there is I do understand the logic because developing for Windows is such a fucking nightmare, that they're also responsible for.

xp84 2 hours ago | parent [-]

I assure you, developing for competing platforms is also a fucking nightmare... that's something Microsoft has no monopoly on!

hylaride 5 hours ago | parent | prev | next [-]

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.

JeremyNT 5 hours ago | parent | prev | next [-]

> 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.

sfn42 5 hours ago | parent | prev | next [-]

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.

Shitty-kitty 4 hours ago | parent | next [-]

A shitty developer can create a far worst experience on react then on native.

owebmaster 2 hours ago | parent [-]

Yes but only because they can actually ship the react app

bushbaba 5 hours ago | parent | prev | next [-]

Most enterprises are comprised of a high proportion of shit developers. So you need to work with what you got

kentm 3 hours ago | parent | prev [-]

> 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.

sfn42 an hour ago | parent [-]

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.

echelon 5 hours ago | parent | prev | next [-]

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.

raincole 5 hours ago | parent | next [-]

Yet, neither ChatGPT desktop app nor Claude Code CLI is native. Mind you these are made by companies with practically infinite tokens.

echelon 32 minutes ago | parent [-]

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.

gman83 5 hours ago | parent | prev | next [-]

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.

WindyTree 5 hours ago | parent | prev | next [-]

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.

alternatex 5 hours ago | parent | prev | next [-]

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.

zelphirkalt 4 hours ago | parent [-]

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.

suriyaG 5 hours ago | parent | prev [-]

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.

nemomarx 4 hours ago | parent | next [-]

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.

suriyaG 4 hours ago | parent | next [-]

I'm sure these things are in the plans from upper management.

we'll know when the next layoffs hit.

chasd00 3 hours ago | parent | prev [-]

they probably are but have some patience.

Keep in mind, claudecode and the other coding agents were pretty bad until around Jan of this year (2026). So it's only been about 9 months since devs have had decent coding agents and even less time has elapsed since somewhat wide adoption.

collingreen 5 hours ago | parent | prev [-]

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.

kevin_thibedeau 5 hours ago | parent | prev | next [-]

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.

jkubicek 5 hours ago | parent [-]

A React Native app would have all the same access to your personal data that a native app would

kevin_thibedeau 4 hours ago | parent [-]

That isn't a web app.

jwlake 4 hours ago | parent | prev [-]

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.

kentm 3 hours ago | parent | next [-]

> 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.

robertoandred 2 hours ago | parent | prev [-]

I think they also got sick of supporting those open source libraries.