The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.

Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.

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.

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.

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

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.

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

> For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced

this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.

Strong opinions considered harmful

That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium?

Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with?

Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.

Sure, cross-platform frameworks were great. I do think LLMs are changing the game, however. If you have a robust set of tests, it's much easier to maintain native versions of an app, compared to the past.

Apart from the hassle that OSes put in the way of PWAs (intentionally, but that's another topic), a local Node app simply has a different kind of system access compared to a web app.

Most apps won't need these capabilities to function, but they are there, for all purposes good and bad:

- background activities with fewer restrictions

- less restricted file system and sensor access etc

- ...

sure, many app use this for nefarious things.

But real use cases don't need to be sophisticated rendering algorithms or what not.

I think good streaming apps also use these capabilities, for example, for performance.

Is everyone wrong, or is there more to it than you can see from where you stand?

I don't want to spend much time on this comment so I risk not making a sufficient point, but something I notice is that you're appraising the situation from a purely technical point of view. The technical component is just one piece of what makes a whole product. I think Apple is probably a good example: they regularly make decisions that bother the hell out of tech-centered minds.

There’s risk to doing anything. There’s risk to doing nothing. A bit off topic but my perception is that organizations bias towards doing something more often than they should.