if people use this will it make browser navigation even more fundamentally broken than it already is?
Edit: it seems to work OK but there are still several of the examples that pretty much immediately break my browser back button. I wish we would stop doing that.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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?
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
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?
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.
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.
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.
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.
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.
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
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.
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.
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?
Edit: it seems to work OK but there are still several of the examples that pretty much immediately break my browser back button. I wish we would stop doing that.
reply