I think nobody will argue against, that the majority of native apps are faster than web apps. But the key point isn't faster, but how much is fast enough.
In general, 60fps is considered sufficient for smooth rendering and even 5 years ago, mobile hardware was fast enough for 60 fps web page rendering. However, many web pages a built in ways, that the browsers can't achieve that goal.
So yes, it is harder for developers to create a pleasant experience and as a result there are more bad apples in the web app basket.
I disagree. Yes, if you have a static webpage and all you need to do is scroll, then you can easily get 60 fps, notably because the scrolling is handled natively by the browser and basically is just a translation on the GPU. If the web app accepts user input, especially touch with dragging, then the page will not feel native with the current batch of browsers for the reasons I mentioned above.
You don’t have to always use the DOM. You can render in another thread, or even run compute in another thread and use the animation frame system to handle updates.
Having said that, maybe a little less than 10 years ago, we achieved the desired performance with touch-screen dragging of DOM elements. I don’t remember specifics, but we didn’t use any frameworks.
I would want to see an iOS app that renders 1000 items in a list, with each item pushing to the navigation stack when clicked. And then I would want to see the same thing implemented in the browser with similar responsiveness on iOS Safari.
Writing this out made me realize another limitation of the browser: the page unloads when navigating, so going “back” can be a pain / impossible depending on the circumstances.
Actually, the biggest issue here is writing a native iOS app, due to the limitations enforced by Apple. Browsers on iOS are also a big pain, because all iOS browsers use the Safari rendering engine and the users don't even have the choice to use anything else.
However, you wrote that 'the page unloads when navigating' which made me wonder, how much you know about frontend development, because the pattern to prevent browsers from navigating is such a common topic and there are multiple solution patterns, all well understood by professional frontend developers:
- preventDefault
- return false
- use anchors
The 1000 item list is indeed a problem frontend developers have to be aware of. Modern flagship smartphones may have the capability to render such lists, but less powerful devices can't handle the load in a 60fps fashion. So you have to build list views that render only the visible part of the list. In the end, you have to do that anyway, because even for high-end devices there are limits to what they can show, but many web-components are not build with such scenarios in mind. And that is certainly one of the reasons why there are so many web apps with slow performance rendering.
In general, 60fps is considered sufficient for smooth rendering and even 5 years ago, mobile hardware was fast enough for 60 fps web page rendering. However, many web pages a built in ways, that the browsers can't achieve that goal.
So yes, it is harder for developers to create a pleasant experience and as a result there are more bad apples in the web app basket.