6 ms·
> What's missing until regular websites have parity with mobile apps in functionality? Performance. But we're beginning to approach performance parity - not by
by _hl_ 7y ago
> What's missing until regular websites have parity with mobile apps in functionality?
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.
- weberc2 7y agoAbsolutely this. Native apps are just so much smoother, and I say this as someone who really wants the web to win, and who used web apps almost exclusively because my 16GB iPhone 6 had very little space for apps. Also, the quality of native apps was much higher (e.g., Twitter feed doesn’t abruptly jump all over on mobile) although this could just be due to more budget allocation into native apps for whatever reason.
- gargs 7y agoNot just smoother, native apps done right are interactive at the visual element level.
- weberc2 7y agoCan you elaborate on this? I’m not following.
- sciprojguy 7y agoNative iOS developer here (10 years). Knowing how to leverage UIKit and CoreAnimation properly can give a very smooth UX. SwiftUI has significantly upped the ante on iOS13 and future versions; it's reactive without the middleware layers, and it lets you get your app done (with live view previews) and not have to drag in a pant-load of external frameworks.
- pjmlp 7y agoIt depends pretty much on what the app is all about. 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.
- yummybear 7y agoIt certainly possible, but there is a lot of arcane knowledge that goes in to the techniques listed. Native apps, generally, has better performance “built in”.
- pjmlp 7y agoArcane knowledge? That is pretty basic stuff for anyone doing Web since the HTML 3 days. 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,...
- dmitriid 7y agoYes. Web is full of arcane knowledge. Take virtual lists for example: https://news.ycombinator.com/item?id=22186827 https://news.ycombinator.com/item?id=22186827
- pjmlp 7y agoUnfortunately I can also provide several items of arcane knowledge for Android and iOS. So should we now measure who wins in arcane knowledge counts?
- dmitriid 7y agoYes. We could. The web would lose hands down. 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.
- axbytg 7y agoAgreed. Map performance especially on native is night and day -- 60fps smooth scrolling even with React Native, vs choppy shitiness on the web.
- onion2k 7y agoYou make a fair point but it's one about the current state of apps rather than the future of apps. In the future phones will be more powerful and apps will do mostly the same stuff. In theory that should mean the apps will be faster.
- kllrnohj 7y ago> In the future phones will be more powerful 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.
- Brakenshire 7y agoWeb apps need a parallel layout engine, and such a thing exists with Mozilla’s Servo, but they’re for some reason Mozilla using it for WebVR rather than building a functional browser.
- adev_ 7y ago> Meanwhile CSS & DOM performance continues to be poor 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.
- kllrnohj 7y ago> The DOM is not slow, that is brain washing from React developpers to justify your VDOM. 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.