I literally started a deep dive into the current state of progressive web app support on iOS this week. WebKit does seem limited on many html apis, but I haven’t seen the bugs this article mentions, yet.
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.
For bugs don't see "open advocacy" site. Because a lot of it a poorly rebranded Chrome propaganda. For example, decrying lack of support for device/hardware APIs which are all Chrome-only non-standards that both Apple and Mozilla will never support.
The site does throw in a few legitimate complaints (like IndexedDB), but otherwise it's poor quality.
Exactly, for both time periods. In 2007, it was probably because Apple wasn't ready for the demand to create apps, see John Gruber's complaints from his notes on the launch [0]. By 2010, the money was too good to invest in webapps.
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.
> I was wondering what you could accomplish now that many of the apis are now reasonably stable.
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.
Competition authorities must force Apple to allow alternative Browser Engines on their platform ASAP and this must include allowing Electron with full access to all Hardware components.
Electron on Desktop and Mobile would be a game-changer - fantastic for Developers and Consumers.
Uhuh, I'm sure both developer who has to learn a whole new platform and a user who suffers without needed application understand your reasons and definitions.
If it was as bad as you describe, then market will decide what to do with them.
> 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.
Isn't that a self-fulfilling prophecy? Clearly no one on iOS is using the real FF now, presumably at least more would if they had the chance. I assume we'd even get some takers for Safari on Android (though I am happy w/ FF + extensions there personally).
Yes, it is larger than iOS (which is why I mentioned Safari on Android as a counterexample), but then Android users can already install Blink or Gecko-based browsers, unlike iOS users?
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).
> I'd be surprised if FF-on-Android was more than 2%, likely it's in the 0.5% to 1% range
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.
> 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.
Well actually enough people have decided that to make Apple the most valuable company in the world? Most people don’t care about the inability to have alternative browser engines.
Easily. Besides being forced to allow sideloading and competing app stores, Apple & Google should be forced to allow competing browser engines and allow for progressive web apps to be installed just like ordinary apps.
Allowing competing browser engines is actually included in EU's DMA, so it should be happening at the same time as sideloading and competing app stores.
Google have an interest of being able to release chrome on iOS as it is the only thing in the way of chrome web domination. And it allow competing browsers on android.
I didn't say webapps are better... I said Android allowed all the things the parent listed with the implication being that it's a pretty open platform.
It's not that they suck. Most users probably can't even tell the difference on modern hardware.
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.
You can definitely tell the difference in battery life when running Electron apps and badly energy optimized browsers (ie Chrome) in Electron apps.
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?
And yet I bet you often use "native apps" that are really just repackaged web views put into the app store. Without even knowing it.
> 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.
"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."
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.
Web apps could, potentially, de-monopolize mobile devices. But what's the point? These devices are generally considered disposable. Most consumers (approximately all of them, in fact, aside from a few hard-core OSS and hardware hacker types) don't see any negative impact from these "monopolies".
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.
They’ve always been considered disposable by the overwhelming majority of consumers. The self-repair and OSS segment of the market is essentially irrelevant and always has been.
For a lot of (most?) apps not requiring native capabilities, I suspect it is. The web has come a long way since the days of FB ditching HTML5 in favor of creating React Native.
Here are some recent comparison videos, using the exact same app example.
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...
You can't have decent animations on the web without a powerful device, period.
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?
For whatever it's worth: on my Android I use Brave to run Facebook, Twitter, and Nextdoor, the same way as in the old days, before smartphones even existed: by typing in the URL. No apps needed for those.
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.
Every once in awhile I try to switch out my native apps for web apps where possible, and the problem is that the web apps are always very noticeably worse. Maybe there's a fix for that, but if so it's a different problem than "monopoly power".
Reduced feature set -> this only demonstrates a lack of investment, because it is not fundamental to the technology.
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.
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.
Given how bad the mobile web is and how little consideration for mobile performance web developers have, this is a pipe dream.
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.
Fortunately there are modern alternatives to React, such as Solid, or Qwik (nearly no JS bundle up front). You can even ‘qwikify’ React components to use them with Qwik, and choose to only execute them on the server/edge, meaning the user doesn’t have to download React at all. But the developer can still tap into the React ecosystem. The future is looking brighter than ever for web apps on mobile.
(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.)
I agree the way most implement frontend dev is a mess, but I strongly disagree that this is where the performance hit comes from.
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.
it will be really cool to write more capable web apps using browser engine libraries(webview), so you have true cross platform apps(from desktop to android and ios), it's the only way to achieve that.
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.
Eh, for once I don’t think I agree with Doctorow. Replacing native apps with web apps is just swapping an oligopoly of mobile platforms based on proprietary APIs for an oligopoly of browser engines based on a Red Queen’s race of keeping up with ever-evolving standards and de-facto standards that are already too prohibitively massive to allow for an independent implementation to emerge. I’m not seeing that as much of an improvement, especially given how Mozilla have been behaving lately.
This is not really true. Chrome's extensions to the Web platform comprising its Page Lifecycle APIs are coherent, well-reasoned, and valuable/inoffensive, yet other browsers have not implemented them (yet; but the proposed APIs are old enough now that if what you're saying were true it'd already be a done deal).
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.
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
> You "counterpoint" isn't even a counterpoint, but just reinforces the original comment.
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.
> 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
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.
> "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.
> Economists call this the monopsony problem (or, since we're talking about two companies, a duopsony or oligopsony problem). That's an unwieldy and esoteric term, so Rebecca Giblin and I coined a much better one, and wrote a book about it: Chokepoint Capitalism:
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.
> Apple has systematically underinvested in Webkit, so that major bugs remain unaddressed for years and years. Some of these bugs are functional – Webkit just doesn't act the way its documentation says it does – but others represent serious security vulnerabilities.
105 comments
[ 3.0 ms ] story [ 193 ms ] threadBack 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.
0: https://daringfireball.net/2007/06/wwdc_2007_keynote
1: https://developer.mozilla.org/en-US/docs/Web/API
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.
https://twitter.com/openwebadvocacy/status/15413180556363694...
Indeed! We would all have to walk around with an external battery pack!
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.
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.
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.
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.
https://backlinko.com/browser-market-share
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.
And you know that how? Or are you retired Microsoft manager? “Most people don’t care about anything but IE?”
Just maybe web apps suck and it’s not mean old Apple holding PWAs back?
https://developer.mozilla.org/en-US/docs/Web/API/Geolocation...
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."
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.
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?
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):
https://tamagui.dev/docs/intro/compiler
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?
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.
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.
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.
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")
https://www.11ty.dev/
Source is here: https://github.com/OpenWebAdvocacy/website
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.
(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.)
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.
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.
Another way just now to have that is Dart with or without Flutter.
There are many other viable ways for creating a cross-platform app:
https://dev.to/this-is-learning/the-different-strategies-to-...
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.
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.
Citation needed.