CRUD mobile apps can be made pretty fast when not doing an SPA bigger than Quake just for displaying text.
SSR, pure CSS3, caching, server workers, mobile first, can go a long way.
Naturally there are other kind of apps where native wins hands down, e.g. WebGL vs GL ES 3.2/Vulkan/Metal/DX.
Have you ever done native Android, including using the NDK?
It is full of arcane knowledge, scattered about commit comments, medium, G+ and Twitter posts from Android team instead of being on developer.android.com, APIs introduced in one IO are deprecated/replaced by the next IO, OEMs (cough Samsung) that change AOSP behaviours,...
So should we now measure who wins in arcane knowledge counts?
The Web lacks even the most primitive of UI primitives that desktop and mobile UI kits have had for decades. Virtual lists is the prime example.
You can't even reliably animate an element independently of other elements without breaking your entire page.
You can't pick an arbitrary group of components and place them in a different location of the page without them breaking in subtle and not-so-subtle ways unless you are extremely careful with your flat global namespace that is CSS. WebComponents solve some of that, extremely poorly.
And the list of things that are taken for granted in the desktop/mobile world is near-infinite. All of them have to be re-created from scratch, poorly, on the web.
Ah, like breaking Android UIs when dealing with fragment management or misplaced constraints on ConstraintLayout, usually only solvable after one finds the golden post on medium?
Furthermore, ConstraintLayout is a brand-new layout manager. Totally agree that there's bugs in it but nothing that could be called arcane knowledge. Do you have any examples for the actually arcane layout managers? Relative, Layout, etc?
Yeah, sure. Try animating an element without breaking layout. Trying animating an element that gets destroyed (oh, it's impossible, there are no events for when element gets removed). Try smooth animation while changing layout. And so on and so on.
Yeah, sure. If you constrain your entire animation to just the one box of a single SVG/Canvas/WebGL, then you can pretend that everything is fine. In reality when you try to animate anything, you're really constrained to animations that don't force re-flow. So, about 3 of them. And you have to be really careful (transposing an element's position will leave gaps).
Meanwhile both desktop and mobile have hundreds of animations big and small that are either impossible or extremely hard to do in a consistent manner on the web.
Single-core performance is largely topping out. The gains are incremental at best.
Mobile SoCs have gone incredibly multi-core incredibly quickly (6-8 cores are common!). Meanwhile the web is incredibly bad at handling that. JavaScript code still has to fight with the GC for CPU time on the single thread they both occupy. WebWorkers are incredibly heavy & limited.
WebAssembly might have threads eventually (it's on their roadmap), but then how long until that happens and will the typical webapp ever even migrate to webasm?
Meanwhile CSS & DOM performance continues to be poor, so webapps are left in this awkward state of needing to re-write part of the browser.
Hardware isn't fixing any of this. It's been almost a decade of hardware not fixing this at this point.
The DOM is not slow, that is brain washing from React developpers to justify your VDOM.
Most Reactive app performance issue nowadays comes from library bloat loading, network saturation or data dependencies.
The main problem with the DOM is not the performance but the API. The DOM API is not appropriate anymore for a reactive usage with transactional reflows. And this triggers a lot of quirks damaging performance.
I'm comparing against native apps, not React VDOM vs. DOM. Direct fiddling of widget properties is common & perfectly fast in native apps, even when done naively. The same is not true of the DOM, especially with all its synchronous layout & style resolution foot-guns.
Performance. But we're beginning to approach performance parity - not by the web becoming an faster, mind you, but by apps becoming slower. It used to be only cheap/poor-quality apps that felt like glorified web pages, but now even many high-profile apps are just parts of a web stack embedded into an app.