[HN Gopher] Native-like Navigation of Web apps
___________________________________________________________________
Native-like Navigation of Web apps
Author : hezedu
Score : 100 points
Date : 2021-11-21 15:15 UTC (7 hours ago)
(HTM) web link (hezedu.github.io)
(TXT) w3m dump (hezedu.github.io)
| _def wrote:
| It's amazing that we're often using interfaces without this
| feature in 2021.
| [deleted]
| jitl wrote:
| 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...
| afavour wrote:
| 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.
| yesimahuman wrote:
| 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.
| the_gipsy wrote:
| There is also no alternative, thanks to apple restricting
| all appstore browsers to the safari webkit engine.
| yesimahuman wrote:
| 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
| warning26 wrote:
| 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.
| [deleted]
| aaaaaaaaaaab wrote:
| 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.
| jeroenhd wrote:
| 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.
| aaaaaaaaaaab wrote:
| >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.
| cyral wrote:
| 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
| dmitriid wrote:
| > 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.
| lewantmontreal wrote:
| 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.
| csande17 wrote:
| 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.
| cyral wrote:
| 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.
| lewantmontreal wrote:
| 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.
| hackmiester wrote:
| What should it do instead when you pull from the left side of
| the screen?
| warning26 wrote:
| 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.
| mikewhy wrote:
| 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.
| The_rationalist wrote:
| The problem is already solved by Ionic
| ComputerGuru wrote:
| 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).
| Jcampuzano2 wrote:
| 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.
| noisem4ker wrote:
| 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.
| gherkinnn wrote:
| 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.
| austincheney wrote:
| I have always found the SPA abuse of the term _router_ deeply
| frustrating. Routers are devices that connect separated networks.
| The SPA use of the term merely performs a fetch for content and
| then shows /hides some content on the screen in concert with the
| page address. Not even remotely close to functionality or
| challenges associated with an actual router.
|
| Is this abuse of terminology because front-end developers have no
| idea how this stuff actually works or is that they don't care and
| want to sound smart?
|
| Actual routers: https://en.wikipedia.org/wiki/Router_(computing)
| riantogo wrote:
| 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?
| dariosalvi78 wrote:
| check https://onsen.io/
| gherkinnn wrote:
| 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.
| dariosalvi78 wrote:
| also: https://framework7.io/
| ivan_gammel wrote:
| 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?
| The_rationalist wrote:
| The "normal router" issue is BIG and make browsing github
| issues/PRs on mobile an awful experience.
| tootie wrote:
| 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.
| jjtheblunt wrote:
| does "native" mean not realized through a javascript engine?
| tubby12345 wrote:
| 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.
| m4r35n357 wrote:
| OMG how much more hideousness are we going to throw at this non-
| problem?
| kylecordes wrote:
| 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.
| dariosalvi78 wrote:
| 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.
| VWWHFSfQ wrote:
| 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.
| afavour wrote:
| 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.
| marcellus23 wrote:
| > 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.
| afavour wrote:
| 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.
| marcellus23 wrote:
| 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.
| dmitriid wrote:
| > 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
| spiffytech wrote:
| > 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.
| marcellus23 wrote:
| 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.
| martini333 wrote:
| No, you cannot.
| slater wrote:
| Yes, you can.
| supernintendo wrote:
| What's the accessibility story for these kind of mobile UIs?
| pcr910303 wrote:
| 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.
| aaaaaaaaaaab wrote:
| 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.
| rudian wrote:
| 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.
| felixthehat wrote:
| 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?
| krono wrote:
| 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! :)
| [deleted]
| yesimahuman wrote:
| 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
| gondo wrote:
| The title is (slightly) misleading. This is some kind of plugin
| for Vue.js framework.
| elwell wrote:
| And the title should mention "mobile" somewhere as well
| karmakaze wrote:
| Yes, the posted title is actually a subtitle for "History
| Navigation Vue"
| butz wrote:
| 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?
| chrisdsaldivar wrote:
| 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...
| yesimahuman wrote:
| 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
___________________________________________________________________
(page generated 2021-11-21 23:00 UTC)