Web apps could de-monopolize mobile devices
pluralistic.net
pluralistic.net
Just maybe web apps suck and it’s not mean old Apple holding PWAs back?
It's that you can't spy on your user nearly as effectively with a web app compared to what you get with native. You're limited to web APIs, instead of native APIs. Which is why, I believe, there is a full court press on so many sites to get mobile users away from websites and into their apps.
I'm not alone in preferring to just use a website and not clutter my phone with apps for every online site I may interact with. Yet many sites actively press me to switch to the app including crippling the mobile version of the site. Removing features that work fine on desktop as soon as they detect a mobile client.
Even on mobile, there is a huge difference in responsiveness for instance with travel apps than the equivalent websites.
I fly and stay in hotels a lot for both business and personal (digital nomadding flying everywhere across the US staying in hotels).
> You're limited to web APIs, instead of native APIs. Which is why, I believe, there is a full court press on so many sites to get mobile users away from websites and into their apps
So how can you both want web apps to have more native capabilities and want to avoid apps because they have too many native capabilities?
> So how can you both want web apps to have more native capabilities and want to avoid apps because they have too many native capabilities?
You seem to totally miss my point.
A native application can do things like sniff local bluetooth devices, track your GPS location, snoop your clipboard. Something a web app can't, because the web APIs have been much more carefully vetted for privacy.
It's this fine grained user tracking that is behind the push towards using the app store. Companies want to know everything your doing, where you are, etc etc. That's much more difficult through a web API as compared to native APIs. This is why they will intentionally cripple their mobile sites and push to use their apps. They want native API level user tracking.
Depends. Chrome for example doesn't vet these as much as the other browsers do. Someone in a sibling thread linked to this tweet from a Mozilla engineer: https://twitter.com/denschub/status/1582730985778556931
"Just a day after shipping an impl to Firefox Nightly, this is the first discovered case of WebMIDI-fingerprinting... Chrome still allows web developers to enumerate attached MIDI devices without user consent or even a notification, btw."
https://developer.mozilla.org/en-US/docs/Web/API/Geolocation...
In what way?
Epic tried with Fortnite and they came crawling back to Google Play
For who? I as a consumer, win monetarily because I can use good OSS apps and bypass shitty first-party ones.
> Popularity?
Popularity is a spectrum, you know. But judging by your comments, your definition of popularity is “more popular than Play Store”, in which case it would never be like that, since play store comes preinstalled and therefore has advantage.
> Can you name one app that has seen wide spread adoption that uses an alternate App Store?
Tmux, NewPipe.
> Epic tried with Fortnite and they came crawling back to Google Play
“System is so hostile to third parties that you have to buy into monopoly”, what a good reason to lock it down even further.
No one ever said “I would really love to have a battery draining, more CPU intensive slower web app than a native app”
> No one ever said “I would really love to have a battery draining, more CPU intensive slower web app than a native app”
No one ever said "I want to pay 1,5k euro for a phone that has the limitations of a feature phone from 20 years ago". Go on, tell me how blocking me from loading proper browser benefits me because of some performance boogieman that you have in your imagination.
And you know that how? Or are you retired Microsoft manager? “Most people don’t care about anything but IE?”
Which market? There are no browser engines beyond Chrome, a very distant Safari, and a near-irrelevant Firefox
> for a phone that has the limitations of a feature phone from 20 years ago
Tell me you never used a feature phone from 20 years ago without telling me this.
The market is much larger than just iOS.
> I assume we'd even get some takers for Safari on Android
And what do you imagine the share of FF is on Android (vs. what it actually is)?
As for what I imagine, that's a cheerfully unpleasant way to phrase that, I'd be surprised if FF-on-Android was more than 2%, likely it's in the 0.5% to 1% range (but it's still far superior to Chrome or even Brave/Vivaldi/Opera due to its support for extensions, most users don't know what they're missing).
So. Back to my statement of fact:
Which market? There are no browser engines beyond Chrome, a very distant Safari, and a near-irrelevant Firefox.
There's no self-fullfilling prophecy. If FF or any other browser was in any way, shape or form relevant, it would be more than 1-2% on Android and 3% on desktop.
It is relevant to those people. And you’re focusing too much on percentages, we’re talking about 150 MILLIONS people worldwide.
Literally doesn't matter for my original comment
> And you’re focusing too much on percentages
Percentages matter for the health of the browser ecosystem. Which is, and I repeat myself:
- Chrome with overwhelming dominance. Which led to Chrome literally shitting all over the standards processes and doing whatever it feels like
- A very, very, very distant second Safari
- Firefox which rapidly slides into obscurity
That is it. There's nothing else. It's a objective, verifiable monopoly by Chrome.
Electron apps compete with native apps, what does this even have to do with browser engines?
> Tell me you never used a feature phone from 20 years ago without telling me this.
???
What do you think Electron apps are based on?
> ???
You can't in all seriousness day that iPhone of the day is as limited as feature phones of 20 years ago.
It’s irrelevant on what they’re based on. I was replying to Web vs Native comment, not monopoly of one browser engine.
> You can't in all seriousness day that iPhone of the day is as limited as feature phones of 20 years ago.
You’re right, those were more open than iPhones. Just open directory and drop file to install application.
Indeed! We would all have to walk around with an external battery pack!
Back at the release in 2007, web apps were the original way to build for the iPhone until Apple got the App Store working. Apps became king because of the 30% cut.
And
https://open-web-advocacy.org/walled-gardens-report/#evidenc...
Make sure you tap more comments to see the examples.
The number one issue for building native like apps is this https://github.com/web-platform-tests/interop/issues/84
It has been buggy for as long as I can remember and never been fixed.
Not to mention the 10 years of issues with indexeddb or the issues with WebRTC.
The site does throw in a few legitimate complaints (like IndexedDB), but otherwise it's poor quality.
We're like 15 years from the original iPhone launch. I was going through reading about every web API on MDN [1]. I was wondering what you could accomplish now that many of the apis are now reasonably stable. Looks like I'm in for some frustration. Glad to learn about open web advocacy initiative today, mtomweb.
Many of those "stable APIs" are non-standard and exist only in Chrome. Almost every one that is listed as "experimental" on that page are one or more of:
- only exist as a scribble on a napkin. Example "Barcode Detection API" which is literally, and I quote, "not a W3C Standard nor is it on the W3C Standards Track" https://wicg.github.io/shape-detection-api/
- are in the process of gathering requirements or trying to reach consensus
- will not ever be implemented by either Firefox or Safari in the current state of the spec. Example: most of the hardware APIs (Bluetooth, HID, Serial etc., considered harmful and will not implement by both Mozilla and Safari)
However, almost every single one of these are being shipped by Chrome.
Don't be fooled by mtomweb's "web advocacy". It's anything but.
No, pretty sure that's not the main reason they're subpar compared to native.
Hell, so's Java, and that's way better-positioned to not-suck relative to native than webtech is, and it's been in that game far longer.
(Cue in "but they are underpowered devices in poor countries")
PWAs don't integrate well into the native menu system, like say MacOS. This is much more noticeable on desktop. On mobile, it's fine.
The access to the file system is more limited (can be a feature rather than a limitation). Again, this is more noticeable on desktop as mobile apps tend to be heavily sandboxed.
Specialty hardware access like bluetooth, USB doesn't work. Direct access to the network stack or information isn't available, etc etc.
It's much more popular to use a wrapper around an HTML5+JS+CSS stack to overcome these shortcomings. Electron, Capacitor, etc.
Buggy -> same demonstration of a lack of investment, not fundamental to the technology.
Slower -> I only see this "objection" on hackernews. Every user I talk to just wants their stuff to work, speed doesn't even make their list of concerns.
the problem is really on apple's side, if its own webkit keeps ignoring the new advancements in web apis intentionally(PWA, new web apis,etc), at least it should allow a true thrid-party browser engine installed who can do it. a true chrome will be much better at least.
what apple does has to be stopped via lawsuits as microsoft experienced in the early days for its browser and OS exclusive tight integration.
There are many other viable ways for creating a cross-platform app:
https://dev.to/this-is-learning/the-different-strategies-to-...
Another way just now to have that is Dart with or without Flutter.
1. Encourage webshi^H^H^H developers to use it
2. Insist the feature cannot be removed because Don't Break The Web™
3. Get someone to type up something that describes the Chromium implementation into the standard
4. It's standard now!
This is 100% true.
The latest example is WebTransport. Which isn't even on the standards track. Yet Chrome already released it, and calls it "an emergent standard".
And this goes for multiple other Chrome-only non-standards.
Good thing you found an API that you decided was reasonable. Doesn't make it a standard, or that there's a consensus, or that other browsers agree with your assessment. Age of the proposal doesn't factor into it.
> This is 100% true.
It literally is not, unless you think 100% means "less than 100%".
You "counterpoint" isn't even a counterpoint, but just reinforces the original comment.
It literally says in the actual document about Page Lifecycle API: "It is not a W3C Standard nor is it on the W3C Standards Track." https://wicg.github.io/page-lifecycle/spec.html
Literally not a standard shipped in Chrome, literally is something Chrome came up with and implemented on its own, literally only shipped in Chrome without any consensus or input from other browser implementers...
And yet "no, this isn't true, this isn't how Chrome works at all".
Is this true for 100% of things that Chrome is shipping? No. But it's so asymptotically close that the difference doesn't matter. They ship 40 to 70 new web APIs in each version. That is, 40 to 70 new Web APIs every month. Over 500 new APIs a year. How many do you imagine they even pretend to be a standard? https://web-confluence.appspot.com/#!/confluence
This sleight of hand is not going to work.
> Literally not a standard shipped in Chrome, literally is something Chrome came up with and implemented on its own, literally only shipped in Chrome without any consensus or input from other browser implementers
... and literally hasn't gotten "someone to type up something that describes the Chromium implementation into the standard". Your choice to ignore this does not bode well for whether you should be taken seriously on matters of intellectual honesty.
The fact that other browser vendors have not been forced to implement it by now contradicts what you are arguing to be true.
All of the Chrome-proprietary APIs that shipped once upon a time in Chrome but were later removed from Chrome (incl. no remaining signs in subsequent draft standards) also contradicts it.
Does Chrome ship non-standard stuff? Yes. So has Gecko. Webkit, too. Has Mozilla in particular been forced to implement some things for no reason other than it because became unavoidable at some point after it started shipping in Chrome? Yes. Does the standardization process merely consist of Chrome doing whatever it wants and the eventual result is a new standard (with nobody else being able to influence this or contribute anything of their own)? No.
> And yet "no, this isn't true, this isn't how Chrome works at all".
Nice strawman. The moment where you resort to putting words in someone else's mouth is the moment you forfeit. Goodbye.
It's not a sleight of hand. It's a fact.
> and literally hasn't gotten "someone to type up something that describes the Chromium implementation into the standard".
And literally exists as a spec that I even linked. Which gives Chrome and gullible devs the license to say things like "oh look at this beautiful reasonable standard that other browsers have not implemented"
> All of the Chrome-proprietary APIs that shipped once upon a time in Chrome but were later removed from Chrome
Of course they haven't. By default everything that Google ships and is not a standard is Chrome-only.
So let's look at your example, Page Lifecycle API.
- Is it a standard? No.
- Is it even on a standards track? No
- Is it shipped only in Chrome? Yes.
- Has Chrome dropped it? No.
- Does this make it a Chrome-only non-standard? Yes.
- Does Chrome drop this and hundreds of other such APIs? Of course not.
Thankfully, we can check that from two sources:
- Chrome's own Web APIs dashboard. https://web-confluence.appspot.com/#!/confluence If you click "Browser Specific", you will see that Chrome ships over a thousand Chrome-specific APIs, and that number grows rapidly.
And this is, undoubtedly on top of APIs that they pretend are standard. This is where the second source comes in
- MDN Web APIs list https://developer.mozilla.org/en-US/docs/Web/API
This one lists both actual existing APIs and "experimental APIs". Those experimental APIs? Most of them are "not a standard, not on a standard track" but are shipped in Chrome. I checked the letter B on that page. There are 4 experimental APIs. All of them are "not a standard, not on a standard track". All of them are shipped in Chrome.
> The moment where you resort to putting words in someone else's mouth is the moment you forfeit.
Which I of course didn't. I did paraphrase it for dramatic effect, but "this is not really true" and "all chrome-only proprietary APIs were dropped" amount to the same thing.
> Goodbye
Adieu
Of course they haven't what?
> "this is not really true" and "all chrome-only proprietary APIs were dropped"
First of all, that's insane, but secondly, no one is even claiming the latter. It's easy to make up things all day. Say something connected to reality.
Easy. I even gave links to show how modern web "standards" work. To quote myself: "Is this true for 100% of things that Chrome is shipping? No. But it's so asymptotically close that the difference doesn't matter. They ship 40 to 70 new web APIs in each version. That is, 40 to 70 new Web APIs every month. Over 500 new APIs a year. How many do you imagine they even pretend to be a standard?"
All this with response to literally what has been happening for the past several years: Chrome ships its own non-standards (even if it spits out a spec doesn't make it a standard), developers start using them, due to Chrome dominance its now a de facto standard.
To think otherwise is to be completely oblivious to what's happening in web standards.
Edit. As to "then someone writes a standard". This also happens. See Web HID timeline: https://github.com/mozilla/standards-positions/issues/459#is... Same happened to WebRTC, by the way. Stable spec version was finally complete in 2018, 7 years after Chrome spat it out and called it a standard. And so on and so on.
And the answer is, "no, that's not the standardization process", and furthermore, "that comment was hyperbole". If you can't admit this, then you are disconnected from reality.
None of your words or links will make the original comment true.
Citation needed.
Except it's even easier than in the old days, because Brave remembers where you went, holds the credentials, and puts an icon on the start page for them.
Take even any native app in a webview, the performance are abysmal. Not because of the web tech itself, if these apps were written in plain JS/DOM, I'm sure they would run fine, but because developers chose to use complicated technologies with terrible performances on mobile, such as React. React is fine on desktop, React is not fine at all on mobile, unless one has access to $500+ handsets, which already discriminates against a significant audience, but developers won't test performances on low cost handsets at first place.
Profile any web app and you'll find that most of the slowness is the unnecessary and constant fetching of unoptimized assets and very high latency responses to API calls. Caching is rarely done correctly on the client side of a web app and nobody wants to put in the effort to properly lazy load and unload stuff seamlessly because of how tightly coupled it is with the visual layout and design. Network requests are especially unreliable and slow on mobile devices. On the dev's machine and in the testing environment it's not though.
This is really all it is. I'm serious. Why doesn't anyone ever look at the network tab in dev tools and see for themselves? It's disgusting.
(Now we just have to cross our fingers for Apple delivering PWA push notifications for Safari in iOS 16 next year like they’ve announced. Then PWAs on mobile will be all the rage.)
Here are some recent comparison videos, using the exact same app example.
React Native (w/ Animated API): https://www.youtube.com/watch?v=yV-2HRzNX9o&t=13s
Ionic React 5 + Capacitor 3.0 (w/ SwiperJS): https://www.youtube.com/watch?v=2o2hpv9N7Ys
Web apps are apparently able to achieve 60 fps in a Web View these days: https://ionic.io/blog/ionic-vs-react-native-performance-comp...
On the other hand, you have efforts such as Tamagui.dev which can give you close to 100% code sharing between a React web app and a React Native app (making the divide less relevant, for mobile apps at least):
With a high end device. That's the problem. I can get 60FPS in my native app on a $50 Android phone if I use Kotlin/Java and Android SDK... I can't get that in a web view on the same device with a native wrapper using Ionic...
Did you try recently? Ionic has developed quite a bit the last years, it looks like.
Did you try the same with a React Native app too?
The reasons are simple:
- animations that affect layout are extremely heavy because you need to re-layout and re-draw the entire page on every update. That's why you still can't animate things like height: auto etc. They can only be done on the CPU. There's literally no good way around that besides hacks that rely on the next reason
- animations that don't affect layout like transform: translate can be offloaded to the GPU. But then you need a GPU and some of them are still ridiculously expensive. For example, anything related to opacity changes (because you'r likely to still run into layout re-calculations with opacity changes)
Some device manufacturers (like TVs where many apps are just web apps) even have specific requirements and block lists for things your can and cannot do with respect to animations on the device
Why don't you need to 're-layout and re-draw the entire page on every update' on native? Animations that affect layout still affect layout when on native, right?
Is the reason that JS (and/or the browser sandbox) is single-threaded, whereas native is natively multi-threaded by default?
So the point is that cheap mobile devices may not have a GPU, but they may have multiple cores, so they can layout & draw using multiple-threads?
Source is here: https://github.com/OpenWebAdvocacy/website
In Soviet Russia, where economics was interesting, terms like "monopsony" or "oligopoly" were known to (many) schoolkids. I'd still prefer them than this vague novelty.
Aside from that web app technology is of poor quality in almost every important domain: architecture, efficiency, stability and security. "Native" mobile apps have overlapping problems in these domains, too, but web apps are generally going to be strictly worse. No thanks.
And you never wondered how it came to this in the first place?