Hacker News Reader

Comment by halpert | Hacker News Reader

The web always feels terrible compared to a native app, especially on a phone. Some of the difference is due to Safari being a bad browser (probably intentional), but a bigger part is that the threading model makes it really difficult to have a responsive UI. Not to mention the browser’s gestures often clash with the application’s gestures.

View on HN

> The web always feels terrible compared to a native app

'always' is certainly not true. Yes, with modern frameworks it is very easy to build websites which are slow. But it is also possible to build websites with butter smooth animations and instant responses.

I hope that in the future we will get frameworks that make it easier to create lightweight web apps, so that we will see more high performance apps.

I made a another comment further down, but basically web apps can’t run as fast as native apps for a variety of reasons.

One reason is the thread model. There are two main threads that need to be synchronized (browser main thread and JS main thread) which will always be slower than a single main thread.

Another reason is that layout and measurement of elements in HTML is really complicated. Native apps heavily encourage deferred measurement which lets the app measure and lay itself out once per render pass. In JavaScript, layouts may need to happen immediately based on what properties of the dom you’re reading and setting.

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.

So what would be needed to prove you wrong?

How about a 240fps video of a 60Hz display, with 2 implementations

1. Qt

2. Web

Both times a finger dragging a slider from point A to point B?

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.

I generally find Safari’s performance better than other browsers. Also, every mainstream JS runtime is multithreaded. There are limitations on what can be shared between threads, but you can optimize a lot despite those limitations (including using WASM on the web, and native extensions/FFI on Node/Deno).

On iOS, the perf of Safari is definitely better than every other browser, because every other browser is mandated to use WkWebView by Apple. They aren’t allowed to implement their own engine. Of course Apple isn’t subject to the same restriction.

Soon, other browsers can simply run themselves inside WASM which then runs inside a WkWebView :)

On a Mac, Safari Javascript generally outperforms Chrome and Firefox (other browsing tasks are also generally better performing), but there are some workloads where Safari turns out slower, especially when the developer has put a lot of work into Chrome-specific optimization.

Safari also generally uses a lot less memory and CPU for the same websites. Chrome in particular burns through my battery very quickly, and is basically completely incapable of keeping up with my browser use style (it just crashes when I try to open a few hundred tabs). Presumably nobody with authority at Google is a heavy laptop web-user or prioritizes client-side resource use: Google’s websites are also among the biggest browser resource hogs, even when sitting idle in a background tab.

Safari often takes a couple years longer than other browsers to implement cutting-edge features. This seems to me like a perfectly reasonable design decision; some web developers love complaining about it though, and some sites that were only developed against the most recent versions of Chrome don’t work correctly in Safari.

In my experience, if the thing I’m working on runs in Safari, it’s buttery smooth. And if it doesn’t run, it completely shits the bed. Stuff like “we don’t support that way of doing shadows in SVG, so rather than simply not implement that property, we’ve turned your entire SVG element black”.

Every mainstream JS runtime has some sort of background garbage collection and parsing/compilation, but for any execution that has to interact with JavaScript heap or stack state you’re still in single threaded territory. SharedArrayBuffer can help if you’re willing to give up on JavaScript objects entirely, and for WebAssembly this is less of a burden, but that’s not going to help you perform rendering on most web apps concurrently. JSCore goes a little bit further and can run javascript in the same runtime instance on multiple threads with some significant limitations, but this isn’t exposed to developers on Safari.

It really depends on your use case and on how you design for threads. Quite a lot of data types can be sent by postMessage, and a decent amount of them are transferable. If your use case doesn’t require passing around functions (and if you can’t find a way to work around that), many workloads which would benefit from multithreading in another language will likely similarly benefit from JS threads (Web Workers, Node’s Worker Threads, etc). The biggest determining factor at that point is whether the overhead of instantiating them, and of message passing, is worth it. (And the latter is often a lot less than people realize; in my experience it’s almost universally faster than crossing a WASM/FFI-type of boundary.)

On what engine have you seen postmessage be faster than a WASM/JS boundary? It’s at least an order of magnitude slower on Chrome/V8, even when a call needs to pass significant strings into WASM (microseconds vs hundreds of ns). It’s also worth noting that postmessage is itself an FFI boundary that requires a JS to C++ transition on every engine I’m aware of.

I’ve seen in on Node 16 (also V8) trying both purpose-built and custom bindings to libraries built in Rust, C, C++ and Go. All of the purpose built libraries acknowledge there’s an overhead to cross the native/WASM boundary. In my experience, measuring extensively, postMessage with native runtime objects outperforms any other ser/de solution that works with JS values.

WASM threads are available in all modern browsers now, including Safari. It's very early days in terms of ecosystem but we're steadily getting there.

Also aren't service workers technically multi-threading? That's been a thing for a while in the browser now.

Technically yeah, but the threads could only communicate through message passing which isn't ideal for performance. The more recent major improvement is for workers to be able to share a single memory space similar to how threading works in native applications.

The issue isn’t so much having additional threads, it’s needing two main threads. The browser has one main thread for accepting user input and then dispatches the relevant user events to the JS main thread.

The browser can either dispatch the events asynchronously, leading to the events being handled in a noticeably delayed way, or the browser can block its main thread until the JS dispatch finishes, leading to fewer UI events being handled. Either way is an inferior experience.

> Some of the difference is due to Safari being a bad browser (probably intentional), but a bigger part is that only having one thread makes it really difficult to have a responsive UI

Interestingly Safari is actually generally better than other browsers for running a responsive smooth UI. Not sure how much of that is the Safari engine and how much of it is better CPU on iPhones. But even on a first generation iPad or an iPhone 4 it was possible to get 60fps rendering fairly easily. The same could not be said for even higher end android phones of the time.

Anecdotally, the only time I’ve had issues with unresponsiveness for pages in Safari is with sites that were written with Chrome specifically in mind.

So, basically everything.

The impact is minimal to nonexistent on a light-to-moderate-JS “site” and only really shows up in heavy “apps”, like YouTube or GDocs.

Really? Even something simple like Wordle feels janky with the way Safari’s chrome overlaps the keyboard.

Do you have some kind of extensions or something like text zooming enabled? On a clean install it doesn't overlap at all.

Hmm the layout is working for me now, but the tile animation is broken. They flicker instead of smoothly flipping over.

Any chance you have reduced motion enabled? They flip for me but are obviously on a short timer.

Reply on news.ycombinator.com