10 ms·

Web apps could de-monopolize mobile devices

72 points by redbar0n 4y ago

boxed 4y ago
> 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. Citation needed.
pfarrell 4y ago
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.
- mtomweb 4y ago
  For bugs see: https://open-web-advocacy.org/walled-gardens-report/#ios-safari-is-buggy https://open-web-advocacy.org/walled-gardens-report/#ios-saf... And https://open-web-advocacy.org/walled-gardens-report/#evidence-of-long-term-neglect-and-developer-discontent 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 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.
  - dmitriid 4y ago
    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.
- duxup 4y ago
  I think it is worth noting that web apps in 2007 weren’t up to the task…
  - mtomweb 4y ago
    True. Or even 2010
    - pfarrell 4y ago
      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. 0: https://daringfireball.net/2007/06/wwdc_2007_keynote https://daringfireball.net/2007/06/wwdc_2007_keynote 1: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API
      - dmitriid 4y ago
        > 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/ 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.
    - d12bb 4y ago
mtomweb 4y ago
If anyone would like to help fight for the future of Web Apps and the Web on mobile please join the effort at https://open-web-advocacy.org https://open-web-advocacy.org
chrisco255 4y ago
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.
- agust 4y ago
  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.
- ko27 4y ago
  Google does allow competing browser engines
- elashri 4y ago
  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.
- Mikeb85 4y ago
  I mean, Google Android already allows all these things...
  - scarface74 4y ago
    And yet no company releases an iOS app and a web app and tell Android users to just use the web. Instead they also release an Android app. Just maybe web apps suck and it’s not mean old Apple holding PWAs back?
    - postalrat 4y ago
      Why would a company push their pwa when the app doesn't have any ad blocking but the pwa does?
      - scarface74 4y ago
garyclarke27 4y ago
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.
- alwayslikethis 4y ago
  With only 8 disclosed 0-days this year in Chromium, this wouldn't bode well with security on already less than perfect Android.
  - mtomweb 4y ago
    Please read: https://open-web-advocacy.org/walled-gardens-report/#security https://open-web-advocacy.org/walled-gardens-report/#securit... https://twitter.com/openwebadvocacy/status/1541318055636369409 https://twitter.com/openwebadvocacy/status/15413180556363694...
- JustSomeNobody 4y ago
  > Electron on Desktop and Mobile would be a game-changer... Indeed! We would all have to walk around with an external battery pack!
  - wiseowise 4y ago
    Haha! "Electron bad" joke, how original!
    - bryanrasmussen 4y ago
      hmm, maybe the lack of originality in the joke indicates a degree of accuracy in its observation.
      - wiseowise 4y ago
        Everybody knows that Electron is inefficient. You what is even less efficient? No app at all.
sidlls 4y ago
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.
- wiseowise 4y ago
  > These devices are generally considered disposable. And you never wondered how it came to this in the first place?
  - sidlls 4y ago
    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.
    - wiseowise 4y ago
      https://news.ycombinator.com/item?id=33984870 https://news.ycombinator.com/item?id=33984870
fsniper 4y ago
Isn't this the whole circle? Returning to the time where iPhone would not have a native API and web apps were the way?
- redbar0n 4y ago
  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. React Native (w/ Animated API): https://www.youtube.com/watch?v=yV-2HRzNX9o&t=13s 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 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-comparison 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 https://tamagui.dev/docs/intro/compiler
  - deleted 4y ago
    [deleted]
  - throw_m239339 4y ago
    > 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 https://ionic.io/blog/ionic-vs-react-native-performance-comp... 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...
    - redbar0n 4y ago
      That's interesting, and very ironic, since PWA's are supposed to be the lightweight option.. 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?
AlbertCory 4y ago
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.
ushtaritk421 4y ago
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".
- redbar0n 4y ago
  noticeably worse in what ways?
  - pvillano 4y ago
    Slower, reduced feature set, often buggy.
    - BackBlast 4y ago
      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.
  - BackBlast 4y ago
    For a real list of objections... 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.
- agust 4y ago
  Apple's monopoly combined with its underinvestment in WebKit is definitely the main reason why web apps are subpar compared to native at the moment.
mikeweiss 4y ago
Off topic but does anyone know what static site generator was used for https://open-web-advocacy.org https://open-web-advocacy.org ?
- mtomweb 4y ago
  We use 11ty. https://www.11ty.dev/ https://www.11ty.dev/ Source is here: https://github.com/OpenWebAdvocacy/website https://github.com/OpenWebAdvocacy/website
  - mikeweiss 4y ago
    Thanks!
- mikeweiss 4y ago
  Yeesh, down voted for this. Man
throw_m239339 4y ago
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.
- redbar0n 4y ago
  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.)
- sublinear 4y ago
  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.
synergy20 4y ago
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.
- account-5 4y ago
  > ... so you have true cross platform apps(from desktop to android and ios), it's the only way to achieve that. Another way just now to have that is Dart with or without Flutter.
  - synergy20 4y ago
    that's yet another new language, there are only so many one can master to use it with good productivity.
    - account-5 4y ago
      That's a fair point, but is it much different from learning a new webdev framework?
      - synergy20 4y ago
        not really,with wrappers like what tauri,wails etc use,i can just use html and js
- redbar0n 4y ago
  > ... so you have true cross platform apps(from desktop to android and ios), it's the only way to achieve that. There are many other viable ways for creating a cross-platform app: https://dev.to/this-is-learning/the-different-strategies-to-building-a-cross-platform-app-3p56 https://dev.to/this-is-learning/the-different-strategies-to-...
pwdisswordfish9 4y ago
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.
- redbar0n 4y ago
  at least there is a well established process of standardization on the web.. (however slow it is).
  - pwdisswordfish9 4y ago
    0. Get a feature into Chromium 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!
    - pwdisswordfish0 4y ago
      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).
      - dmitriid 4y ago
        > This is not really true. 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.
avmich 4y ago
> 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.

72 points by redbar0n 4y ago

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

pfarrell 4y ago

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.

mtomweb 4y ago
For bugs see: https://open-web-advocacy.org/walled-gardens-report/#ios-safari-is-buggy https://open-web-advocacy.org/walled-gardens-report/#ios-saf... And https://open-web-advocacy.org/walled-gardens-report/#evidence-of-long-term-neglect-and-developer-discontent 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 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.
- dmitriid 4y ago
  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.
duxup 4y ago
I think it is worth noting that web apps in 2007 weren’t up to the task…
- mtomweb 4y ago
  True. Or even 2010
  - pfarrell 4y ago
    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. 0: https://daringfireball.net/2007/06/wwdc_2007_keynote https://daringfireball.net/2007/06/wwdc_2007_keynote 1: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API
    - dmitriid 4y ago
      > 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/ 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.
  - d12bb 4y ago

mtomweb 4y ago

If anyone would like to help fight for the future of Web Apps and the Web on mobile please join the effort at https://open-web-advocacy.org https://open-web-advocacy.org

chrisco255 4y ago

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.

agust 4y ago
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.
ko27 4y ago
Google does allow competing browser engines
elashri 4y ago
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.
Mikeb85 4y ago
I mean, Google Android already allows all these things...
- scarface74 4y ago
  And yet no company releases an iOS app and a web app and tell Android users to just use the web. Instead they also release an Android app. Just maybe web apps suck and it’s not mean old Apple holding PWAs back?
  - postalrat 4y ago
    Why would a company push their pwa when the app doesn't have any ad blocking but the pwa does?
    - scarface74 4y ago

garyclarke27 4y ago

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.

alwayslikethis 4y ago
With only 8 disclosed 0-days this year in Chromium, this wouldn't bode well with security on already less than perfect Android.
- mtomweb 4y ago
  Please read: https://open-web-advocacy.org/walled-gardens-report/#security https://open-web-advocacy.org/walled-gardens-report/#securit... https://twitter.com/openwebadvocacy/status/1541318055636369409 https://twitter.com/openwebadvocacy/status/15413180556363694...
JustSomeNobody 4y ago
> Electron on Desktop and Mobile would be a game-changer... Indeed! We would all have to walk around with an external battery pack!
- wiseowise 4y ago
  Haha! "Electron bad" joke, how original!
  - bryanrasmussen 4y ago
    hmm, maybe the lack of originality in the joke indicates a degree of accuracy in its observation.
    - wiseowise 4y ago
      Everybody knows that Electron is inefficient. You what is even less efficient? No app at all.

sidlls 4y ago

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.

wiseowise 4y ago
> These devices are generally considered disposable. And you never wondered how it came to this in the first place?
- sidlls 4y ago
  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.
  - wiseowise 4y ago
    https://news.ycombinator.com/item?id=33984870 https://news.ycombinator.com/item?id=33984870

fsniper 4y ago

Isn't this the whole circle? Returning to the time where iPhone would not have a native API and web apps were the way?

redbar0n 4y ago
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. React Native (w/ Animated API): https://www.youtube.com/watch?v=yV-2HRzNX9o&t=13s 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 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-comparison 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 https://tamagui.dev/docs/intro/compiler
- deleted 4y ago
  [deleted]
- throw_m239339 4y ago
  > 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 https://ionic.io/blog/ionic-vs-react-native-performance-comp... 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...
  - redbar0n 4y ago
    That's interesting, and very ironic, since PWA's are supposed to be the lightweight option.. 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?

AlbertCory 4y ago

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.

ushtaritk421 4y ago

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

redbar0n 4y ago
noticeably worse in what ways?
- pvillano 4y ago
  Slower, reduced feature set, often buggy.
  - BackBlast 4y ago
    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.
- BackBlast 4y ago
  For a real list of objections... 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.
agust 4y ago
Apple's monopoly combined with its underinvestment in WebKit is definitely the main reason why web apps are subpar compared to native at the moment.

mikeweiss 4y ago

Off topic but does anyone know what static site generator was used for https://open-web-advocacy.org https://open-web-advocacy.org ?

mtomweb 4y ago
We use 11ty. https://www.11ty.dev/ https://www.11ty.dev/ Source is here: https://github.com/OpenWebAdvocacy/website https://github.com/OpenWebAdvocacy/website
- mikeweiss 4y ago
  Thanks!
mikeweiss 4y ago
Yeesh, down voted for this. Man

throw_m239339 4y ago

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.

redbar0n 4y ago
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.)
sublinear 4y ago
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.

synergy20 4y ago

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.

account-5 4y ago
> ... so you have true cross platform apps(from desktop to android and ios), it's the only way to achieve that. Another way just now to have that is Dart with or without Flutter.
- synergy20 4y ago
  that's yet another new language, there are only so many one can master to use it with good productivity.
  - account-5 4y ago
    That's a fair point, but is it much different from learning a new webdev framework?
    - synergy20 4y ago
      not really,with wrappers like what tauri,wails etc use,i can just use html and js
redbar0n 4y ago
> ... so you have true cross platform apps(from desktop to android and ios), it's the only way to achieve that. There are many other viable ways for creating a cross-platform app: https://dev.to/this-is-learning/the-different-strategies-to-building-a-cross-platform-app-3p56 https://dev.to/this-is-learning/the-different-strategies-to-...

pwdisswordfish9 4y ago

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.

redbar0n 4y ago
at least there is a well established process of standardization on the web.. (however slow it is).
- pwdisswordfish9 4y ago
  0. Get a feature into Chromium 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!
  - pwdisswordfish0 4y ago
    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).
    - dmitriid 4y ago
      > This is not really true. 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.

avmich 4y ago

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