[mrcwinn]

PWAs will never be as good as native, definitionally. There is always API drift. There is always runtime cost. Nothing inside a system can ever have parity with its parent container. If it could, it would be the system itself.

People's experience with hardware and physical objects matters. If you accept that, you should always want to be closer to the metal at the cost of convenience or portability.

[palata]

I don't understand why you got downvoted for this. Cross-platform is never as good as native, but in some situations it is cheaper. And there is a need for "cheaper but not as good" (we don't all drive a Porsche, do we?).

[matwood]

There are constant complaints about electron apps being bad and people wanting native apps, except in the case of PWAs. I can't keep all the complaining straight lol

[addicted]

Electron apps are getting much better.

VS Code is considered the best app in its class by a distant margin and it’s an electron app.

The first round of Electron apps were created by people who were simply trying to get some cross platform native version of their apps out.

It’s only been recently that companies are now creating electron apps as first class products and now those apps are doing very well.

[troupo]

> VS Code is considered the best app in its class by a distant margin and it’s an electron app.

Yes, and by now they have spent spent hundreds of millions of dollars and hundreds of man-years of dev time on it. And it's still the only poster child for "good Electron app"

[fiddlerwoaroof]

The popularity of VSCode is mystifying to me: IntelliJ is a much nicer application and VSCode always ends up lagging randomly for me.

[jemmyw]

They both lag. They're both resource hogs. IntelliJ has a better out of the box experience. VSCode has a much much more diverse and interesting plugin ecosystem. I run both. VSCode is interesting in that, depending on the project and/or the plugins required for that project, it can be much kinder or much worse on my battery life. IntelliJ is more predictably bad.

All being equal I'd choose VSCode at this point. When I want to do something like run tests the test plugins for pretty much everything I've looked at are way better. IntelliJ has some powerful configuration capabilities that somehow always manage to be constrained in a sucky way. Support answers are like "oh you want to do THAT. No, you can't do that, read this doc" where the VSCode way would tend to not be as configurable but support the thing you actually wanted to do.

Plus VSCode plugins are majority free. It's not that I mind playing for plugins per se, but my experience with Intellij plugins has been poor, so I don't want to go through the hassle of paying to find out it's rubbish.

[wkat4242]

IntelliJ is very expensive and VS Code is free. That's a big driver for popularity.

[fiddlerwoaroof]

JetBrains isn’t “very expensive”: for one thing, there’s a free and open source community edition; for another, the IntelliJ license is about the same as a Netflix subscription and, rather than being a pure cost, it’s a tool that supports one’s valuable skills.

[willsmith72]

i've found the opposite, once the codebase is large enough jetbrains ides get slower and slower. i've been on teams which had to split their monorepo because it was so bad

[palata]

Same here, I love the JetBrains IDEs.

[robertoandred]

Except VS Code is missing tons of native functionality that makes it still feel out of place.

[addicted]

Strong disagree.

Sure, theoretically, any PWA could possibly be developed as a better native app.

But in the real world people develop apps. If the iOS app developer and designer market declines, then even if theoretically a native app would be better, the best developers and designers will have little to no experience with native and so the best apps will likely be PWAs where the best developers and designers are.

Native only always win if you’re looking at the capability of the platform as the only constraint. In reality, the developer/designer market, money available to develop apps, money and resources available to maintain apps, etc are all additional constraints for real apps, and native apps have significant disadvantages in those other constraints.

[palata]

> If the iOS app developer and designer market declines

That's a pretty huge "if". If the web developer market declines, then native will be better, too.

> In reality, the developer/designer market, money available to develop apps, money and resources available to maintain apps, etc are all additional constraints for real apps, and native apps have significant disadvantages in those other constraints.

In my experience, the reality is much more nuanced than that. There are plenty of mobile devs, and many will tell you that they are not slower writing two apps (iOS/Android) than writing one cross-platform one. I don't know a single mobile dev who likes a cross-platform framework better than the native experience, too.

No really, I think cross-platform seems cheaper if you are a manager (and don't really have experience with any of those frameworks) or if you are a web dev (and don't really have experience with mobile frameworks).

[osrec]

PWAs can absolutely be as good as native, however they aren't being given a chance due to reasons unrelated to technology. I personally believe it is the protection of Apple's fees that is driving its poor implementation of web technologies (even though their original plan was to only have web apps, with a small number of native apps for very specific things). The money they could extract from the app store made them change their tune re web apps, and they've managed to convince every Apple fan it's for their benefit. Unfortunately, this goes unchallenged by the average Apple user, who lacks the tech knowledge or desire to question Apple.

[palata]

> and they've managed to convince every Apple fan it's for their benefit

To add to your statistics: I am an Android user, and I mostly hate PWAs. I want native apps.

[osrec]

Do you want native apps, or do you want polished apps, regardless of the type?

[mvdtnz]

No, not definitionally. Some kinds of apps simply can't be native in iOS, either because of their content or their function. Whatever gimped version ends up on the app store is worse than what can be found on the web.

[postalrat]

In theory you are right but in practice you are absolutely wrong.

[palata]

Sure, in practice nobody really cares about the user experience, it's all about the money. That's why most software in 2024 is crap.

Still I don't think it's a reason to completely give up on the good ways.

[bowsamic]

> Nothing inside a system can ever have parity with its parent container. If it could, it would be the system itself.

I have no idea what you mean by this, can you give some justification? It sounds kind of nonsensical

> you should always want to be closer to the metal at the cost of convenience or portability.

Right but that isn't really a thing anymore. Even machine code is very abstract compared to the actual physical processes going on inside. Bare metal programming is an illusion for pipelined CPUs with speculative execution

[palata]

> Right but that isn't really a thing anymore.

"Wanting to be closer" does not mean "needing to be at the lowest theoretical level". In this case it just means that native mobile frameworks are one layer of abstraction lower than web frameworks, and it is better (not cheaper, not easier, but better).

[bowsamic]

Native libraries are already an huge abstraction. Anyone can write a GUI framework, even on iPhone. I don’t understand where the line is being drawn here

[palata]

I am not the OP, but my line here is between the APIs provided by Apple and the third-party abstractions. As an iOS developer, the "lowest" you can get is the Apple framework. PWAs are a third-party abstraction on top of that, which come with all the risks/limitations of both third-party dependencies and abstractions.

[bowsamic]

I just don't really agree, almost all modern JS engines compile to machine code, so it's as "low" as writing Swift or Objective-C.

[Klonoar]

The JIT aspect is merely one component of the larger picture. With PWA’s specifically you have the entire browser stack to move around. Native code simply does not have this constraint.

They are (IMO) correct that having less layers between you and the lowest layer is ideal. The browser is an engineering marvel but it’s still a nuisance to work around.

[palata]

I think you're not talking about the same thing. What I am saying is that if you depend only on Apple and their framework, then you have all the improvements as soon as they exist and you don't really have the risk that Apple stops developing iOS (or if they do, then iOS is most likely dead).

If you depend on, say, Qt-for-iOS, then you need Qt to integrate the new features (with more or less success, taking more or less time), and you have a much higher chance that Qt will stop working on iOS some day (or that some important feature never reaches Qt, or that it is super painful to use with iOS).

Removing third party dependencies reduces your risk.

[kmbfjr]

Lets start with a browser based application that struggles with basic IOS capabilities. Not entirely a web app’s fault, but dealing with badges and push notifications will most certainly be a better experience in a native app.

I admit that I am not saddened by this hurdle. The moment that becomes a thing, further enshitification will ensue with every web site trying to drop and icon and start pushing messages.

“Closer to metal”? Not sure you are wrong to ask if there is a line given SwiftUI. That is some very high abstraction.

[bowsamic]

I agree that Apple make it so that unless you use their frameworks then you can't use certain functionalities of the OS, but that has nothing to do with being "lower" or "higher". It's just that Apple has a specific abstraction that you must use in order to access those features. It could just as easily be the other way around and have it so that only web apps can access those features and so-called "native" apps cannot. It just has nothing to do with the level of abstraction.

If you wrote pure machine code without system calls you can't even read a file. You have to call into the kernel, which could even be written in javascript, in order to do that.