Hacker News Reader

Comment by jitl | Hacker News Reader

The animated transitions don’t work very well with iOS’s built-in “swipe from left edge” back gesture. The animation appears to double-play, since the Safari back gesture implements the reveal animation in native code, then once it sends the back event to the browser, the library plays its own animation.

See video here: https://jitl.notion.site/Back-gesture-iOS-3c44da9f8d13491d86...

View on HN

This is my test for any “app-like” transition library in terms of attention to detail. It’s very difficult to get right. I wish we were able to tap into native OS transitions but alas.

The reality is you can't do this kind of transition when running in Safari browser because the browser gestures get in the way. It really has nothing to do with the web being able to do this or not and everything about browser chrome getting in the way.

However, it's much, much better when running in a native web app container like Capacitor.

There is also no alternative, thanks to apple restricting all appstore browsers to the safari webkit engine.

No, the browser itself that wraps the WebKit web view is the culprit here. WebKit has nothing to do with it. Other browsers on iOS can and do implement gestures like this differently

You can set transition options to '' in iOS. https://hezedu.github.io/history-navigation-vue/api.html#tra...

Yup -- it's annoying that Safari does this, but that's Apple for you. Ensuring that webapps have a worse experience than native ones is presumably considered a feature.

Safari is perfectly fine, thank you. When I swipe back, I want to go back to the previous website, where I came from. I don't care about your website's bespoke little internal navigation system.

While I completely agree with you for normal websites, web apps are an entirely different beast. I think it's quite reasonable that applications have some extra logic to deal with navigation, because they're built for complex interaction, not for displaying information.

I think it's quite reasonable to want to respond to a back gesture to cancel a modal that asks if you're sure about deleting <some resource>. You could render everything server side to get website-like navigation, but for these things JS is probably one of the better mechanisms to make user interaction more pleasing.

This stuff should absolutely be kept away from news sites, blogs and other web resources because they're awful enough already with their constant popups about signing up for newsletters, accepting notifications and pitiful pleas to use their app. For your average PWA, though, this is definitely a bad thing.

> web apps are an entirely different beast.

They are not. They are websites running inside a browser. So, they must respect the browser. If they pretend to be standalone and not care about the browser, it's their own fault, and not the browser's.

And yes. The browser cannot distinguish between your shitty "web app" and a regular site.

>This stuff should absolutely be kept away from news sites, blogs and other web resources because they're awful enough already with their constant popups about signing up for newsletters, accepting notifications and pitiful pleas to use their app

I’m sure these sites would respect your wishes and not use this for nefarious purposes!

You see, features like this would make the Web worse for 99.99% of users by enabling shitty websites’ abuses, while making it just a tiny bit better for those who insist on the subpar experience of running general purpose applications in their browsers.

So yeah, that’s gonna be a no from me.

The History API [1] already allows browsers to change the back button behavior. Safari seems to ignore it when the swipe is large enough to trigger the back animation though, but it is most definitely a thing on desktop.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/History

yep I love accidentally visiting Business Insider and having to click back about 30 times through clickbait to leave the godawful place

This is something I’ve been thinking about lately. What real benefits are there to keeping entire web services as a single page apps? We could run the same reacty things as multi page apps if loading time is kept low, which should be easier since we don’t need to load the entire set of features.

There aren't really many benefits to single-page apps, outside niche use cases like "offline first" websites. People make single-page apps either because they're misinformed (see every single reference to Javascript enabling "flicker-free" navigation; modern browsers do not flicker when changing pages), or because they're trying to pave over performance problems caused by their single-page app framework.

In Webview(not the browser), you cannot open in a new window.At this time, single-page applications should be good.

The largest benefit is initializing and requesting things once. For example, Twitter is a single page app and is built the same way you would build a native app. The code needed to render it is downloaded once, and only small API requests are made to fetch content as needed. Sure, it could be built as a regular website (as it once was), but it runs even better now since it doesn't have to re-render and re-initialize everything on each "page". It uses the History API so the back/forward buttons still work as expected.

For me twitter the website runs very slow and does not feel snappy at all, e.g. you have to wait for tweets to load again after back button, and replies to load after each transition. Perhaps it is easier on the servers but very, very few services run on twitter scale.

Wouldn’t a traditional website be even worse then? Instead of loading some JSON from the API it has to load the entire page, parse all of the CSS and JS again (the “time to first paint” or “time to interactive” benchmarks are all about that) A SPA only has to do that once. A lot of frameworks bundle various parts of the website actually, so the “shell” of the Twitter feed is loaded initially and the content is dynamically added to it when you navigate through tweets (just as the native app would), but then loading the shell of lesser used areas like your account settings would be deferred until needed. (So you aren’t really downloading a huge JS bundle on first load)

Also I think the reason it has to load the tweets again is to not serve stale content. They could have the browser cache it using the same cache control mechanism as a page load if they wanted.

What should it do instead when you pull from the left side of the screen?

Their behavior is fine, but the problem is that there's no way to detect it.

If it was possible to check if the user had used the swipe gesture, then it would be possible to use that to control whether or not to display the custom animation, preventing a double-animation scenario.

You can detect if the interaction started from the side of the screen. From there, you can do something different when the history is manipulated.

That wouldn't work, since Safari completely intercepts the touch event if it's a back gesture. Pressing the back button in the browser is indistinguishable in code from the back swipe gesture.

Reply on news.ycombinator.com