5 ms·

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

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.

jsheard 5y ago
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.
- danielvaughn 5y ago
  Also aren't service workers technically multi-threading? That's been a thing for a while in the browser now.
  - jsheard 5y ago
    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.
- halpert 5y ago
  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.
nicoburns 5y ago
> 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.
- kitsunesoba 5y ago
  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.
  - themerone 5y ago
    So, basically everything.
    - kitsunesoba 5y ago
      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.
- halpert 5y ago
  Really? Even something simple like Wordle feels janky with the way Safari’s chrome overlaps the keyboard.
  - acdha 5y ago
    Do you have some kind of extensions or something like text zooming enabled? On a clean install it doesn't overlap at all.
    - 5y ago
eyelidlessness 5y ago
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).
- halpert 5y ago
  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.
  - amelius 5y ago
    Soon, other browsers can simply run themselves inside WASM which then runs inside a WkWebView :)
  - jacobolus 5y ago
    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.
- Uehreka 5y ago
  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”.
arendtio 5y ago
> 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.
- halpert 5y ago
  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.
  - arendtio 5y ago
    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.
    - halpert 5y ago
      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.

jsheard 5y ago

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.

danielvaughn 5y ago
Also aren't service workers technically multi-threading? That's been a thing for a while in the browser now.
- jsheard 5y ago
  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.
halpert 5y ago
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.

nicoburns 5y ago

> 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.

kitsunesoba 5y ago
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.
- themerone 5y ago
  So, basically everything.
  - kitsunesoba 5y ago
    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.
halpert 5y ago
Really? Even something simple like Wordle feels janky with the way Safari’s chrome overlaps the keyboard.
- acdha 5y ago
  Do you have some kind of extensions or something like text zooming enabled? On a clean install it doesn't overlap at all.
  - 5y ago

eyelidlessness 5y ago

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).

halpert 5y ago
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.
- amelius 5y ago
  Soon, other browsers can simply run themselves inside WASM which then runs inside a WkWebView :)
- jacobolus 5y ago
  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.
Uehreka 5y ago
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”.

arendtio 5y ago

> 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.

halpert 5y ago
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.
- arendtio 5y ago
  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.
  - halpert 5y ago
    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.