Native-like Navigation of Web apps | Hacker News Reader

Native-like Navigation of Web apps

hezedu.github.io

114 pointshezedu72 comments

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

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

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.

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

This modifies a lot of platform-specific behaviour as described by their respective specifications. It also hijacks system-level user customisations, possibly also accessibility-related ones.

Whilst it looks like a solid technical implementation, in its current form at least, makes for a very frustrating user experience.

Edit: Which means to say it's very much salvageable! :)

A bit different, but I really appreciate when web apps use the HTML5 history API to implement back buttons, e.g. Twitter. It makes the history queue that appears when long-clicking the back button so much more useful.

Too bad that other sites use the same API to forbid you from going back where you came from, by filling the back stack with hundreds of bogus entries.

I remember some browser blocking that at some point, but I still occasionally see it. I can’t believe there’s no way to “go back to the previous website” in most browsers. Safari iOS for example just clips the history so you can’t even hold the back button and scroll up if there are dozens of entries.

The title is (slightly) misleading. This is some kind of plugin for Vue.js framework.

Yes, the posted title is actually a subtitle for "History Navigation Vue"

And the title should mention "mobile" somewhere as well

The desktop also supports

"History Navigation" is before "Vue"，Is it still like a plugin? I think it’s a good idea to reduce the font size of "Vue".

I've been doing web dev for 20 years and still have no idea what "native" controls means. Controls on every web/desktop/mobile app I use are different. And aside from the labels being legible and the selected states being visible, they're all pretty much the same to me.

does "native" mean not realized through a javascript engine?

no it means vaguely what the person you've responded to is alluding to - window controls and such that mimic the controls that the user's OS uses. incidentally I agree with the person you've responded to - what's the point if all apps are different anyway (despite uniformity in window controls). but i realize i'm an outlier - 90% of tech users probably don't have the patience to learn new UIs over and over again.

And honestly, why would someone want "native-like" controls in a web app? "Native-like" simply means "close enough to make you think it works the same, but subtly doesn't". That's pretty much the definition of uncanny valley.

When I checked the previews in the Guide section, some of them did not work in the latest Firefox as expected. Also, looks like there's only an implementation for the Back button, but what about Forward?

Native does not seem to 'forward' either.

In browsers good UX means to support both.

Oh this is so timely for me! I'm just building a mobile-first webapp with Vue and have been trying to solve this exact issue. Does it work with Nuxt?

To be used with Nuxt. You need to replace Vue router with history-navigation-vue and I think SSR will not work.

There are some problems with this version. Wait, wait for next version, It will be released this week.

1.4.0 was pulished.It's ready to use.

It's amazing that we're often using interfaces without this feature in 2021.

The only client-side rendered webapp I enjoy using is GitHub’s and that’s because it’s indistinguishable from a regular server-side website (until a page fails to load or takes forever to load, but I’ll give them a pass on that).

I might be wrong or misunderstanding your description, but I don't think Github's webapp is client side rendered. They use rails extensively as far as I know unless things have changed, and add additional enhancements on the client side using plain JS.

Certain things are loaded on the client, but for example when viewing a repo it's server rendered.

Whereas on the home page, the app shell is loaded on the server, but the feed is fetched on the client.

But all navigation is not done on the client.

Content is rendered server-side, but navigation is done client-side. It's not the browser which loads pages, instead it's a script that loads the page content through AJAX, updates the current view with it, and pushes a new state to the history API. I think the exact library they use is Pjax. And yes, it inevitably collides with native navigation in that going backwards sometimes brings up stale page states, forcing you to refresh.

Have to disagree.

State is constantly out of sync and I hate when popup menus have to first fetch their content and show you a spinner instead.

This is the reason why I always hit refresh as soon as the URL bar updates. A full page load of the next destination is often faster than their shitty client-side navigation.

Now that I think of it, I can't think of any website where client-side navigation is actually an improvement.

I'm a web developer and typically use bootstrap or materialcss for my projects. I'm looking for a simple css framework that makes my next webapp look and feel like a mobile app. Any suggestions?

It has little to do with CSS frameworks. Looks are easily imitated. Use whatever you like.

It’s all in the feeling. Use design patterns that work on phones. And by god, make it fast.

Once that’s set and at the core of your app, think about flourishes.

You won’t achieve the level of Airbnb’s native app, but a little will take you very far.

check https://onsen.io/

also: https://framework7.io/

If you're interested in bringing native navigation patterns to web apps, take a look at Ionic Framework which has had this for a long time (and recently added Vue support). Demo of some of these patterns (screen needs to be wide enough to display the phone): https://ionicframework.com/docs

Ionic used to do this. But in angular they stopped supporting this type stacked page transitions. Do they do this with vue or react?

Ionic still supports stacked page transitions in Angular! Where did you hear that?

When building native-like web apps I noticed that they lack tactile feedback, e.g. tap sound or vibration after pressing button. Is it actually possible to implement with web apps at all?

You can play sound with the audio API since the user is interacting with the page. However, the vibration API is only implemented in Chrome and Firefox on mobile. Safari removed it from WebKit.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_A...

https://developer.mozilla.org/en-US/docs/Web/API/Vibration_A...

Not when running solely on the web in a browser unfortunately. A tool like Capacitor has haptic feedback support if you deploy your app natively, however: https://capacitorjs.com/docs/apis/haptics

Thank you all for your feedback. Currently, there are differences between different devices, I will continue to improve as soon as possible.

What’s the accessibility story for these kind of mobile UIs?

I am often impressed by how native some web-rendered mobile apps can feel.

But as of a few years ago, as I understand the top N most popular, best-selling, highest revenue, etc. apps for both iOS and Android were mostly native apps, build with the primary native tooling/language/etc per-platform. Presumably this is because that last little bit of being native pays off in a highly competitive environment. I wonder if that is still true.

It's definitely still true. I can spot a mobile app built with web tech pretty much instantly. It just feels very slightly crappy. I don't think there's any kind of library or framework that will ever fix that. Native is pretty much the only way to go if you really want the app to look/feel good.

No, you cannot.

Yes, you can.

I’m less sure about that. You can spot a mobile app built with crappy web tech, because it is very slightly crappy. An app using web tech well would be indistinguishable from a native one.

Case in point: years ago the Instagram activity feed was rendered in a webview. The only way I ever found out was because they clearly did a faulty deploy that was missing CSS: it rendered in Times New Roman with blue links, etc. But up until that point I didn’t have a clue and I do this stuff for a living.

On iOS at least there are a ton of WKWebView APIs that aid native integration, you can even do force touch context menus and the like. It’s just that by and large people don’t.

> years ago the Instagram activity feed was rendered in a webview

Isn’t the instagram activity feed just a big scrolling page of images and text? It doesn’t exactly have a lot of interactivity or animations and transitions, so maybe not the best example for what can be done with web APIs. Lots of native apps use web views for individual screens that display mostly static content, but that’s not really what’s being discussed.

Maybe we disagree about what’s being discussed: “mobile app made with web tech” definitely falls into that category for me. I bring it up because it isn’t hypothetical for me, I’ve received pushback against using webviews in these situations because “web stuff always looks awful” and I know that to not be the case.

In any case the vast majority of native apps aren’t much more that scrolling lists themselves! Sometimes I think we overcomplicate our image of what native apps usually are. The OS-provided transitions between views are one of few big differentiators, IMO.

But then that’s just a native app that uses web views for some pieces. Every app does that. Native transitions between views are exactly what the posted link is discussing. For static content, of course there’s really not a difference. It’s the interactions that matter.

> maybe not the best example for what can be done with web APIs.

Well, the page sucks. If they can't make such a simple thing right, perhaps wait before making something else?

BTW almost all such pages on the web suck (Twitter comes to mind) and are worse than native versions

> You can spot a mobile app built with crappy web tech, because it is very slightly crappy. An app using web tech well would be indistinguishable from a native one.

I've seen many people remark that they can reliably spot a web-based mobile app, and this response is exactly what goes through my mind. My core rebuttal is that we generally don't get feedback about our guesses - we don't get corrected if we guess wrong about what powers an app. So maybe we'll correctly guess the most obvious cases, but that gives us false confidence about our overall accuracy.

Do you have any example of a mobile app known to be built with web tech which is indistinguishable from a native app? Presumably there should be at least one out there.

a simple web app with a good CSS framework can be hardly distinguishable from a native one. There will always be some UI quirks, for example how the back button in Android is handled, but probably few users will notice them.

Reply on news.ycombinator.com