[HN Gopher] What PWA Can Do Today
___________________________________________________________________
What PWA Can Do Today
Author : thunderbong
Score : 320 points
Date : 2024-01-08 13:44 UTC (9 hours ago)
(HTM) web link (whatpwacando.today)
(TXT) w3m dump (whatpwacando.today)
| PaulHoule wrote:
| Spam you with spam spamifications. Clutter your mobile device
| device with more twisty little icons that all look look the same.
| Attempt to store content with an unreliable storage service.
|
| Move on folks, nothing more to see here. PWAs are just another
| Google side project, talking about them in 2024 is like still
| being hung up on a chat app Google killed years ago or being that
| guy who did his whole house up in Material Design.
| exo-pla-net wrote:
| Whatever their merits, PWAs are _not_ a Google side project.
| The idea was first proposed by Steve Jobs and Microsoft is
| excited about it, too [1]. In other words, all the big players
| are in on it.
|
| It's a good idea and frankly superior to the current
| Store+PhoneApp approach to making stateful apps that can run on
| mobile devices. Contributing helps. Being sour, not so much.
|
| [1] https://learn.microsoft.com/en-us/microsoft-
| edge/progressive...
| JimDabell wrote:
| Some of the functionality listed on this site is not part of
| the web platform, but rather Blink-only APIs Google
| implemented unilaterally that have been explicitly rejected
| by Mozilla and Apple.
| postalrat wrote:
| Apple wants to keep in control with the app store. PWAs
| threaten that control. So much so apple doesn't allow other
| browsers.
| JimDabell wrote:
| That argument would work if it were only Apple rejecting
| them. Mozilla rejects them on the same grounds.
| postalrat wrote:
| Mozilla rejects stuff like webusb while apple is blocking
| add to home screen, push notifications, etc. Stuff that
| is needed to replace many app store apps.
|
| Firefox supports both add to home screen and push
| notifications.
| tgv wrote:
| While Google wants as much access to your phone as it can
| get. Why would that be?
| zamadatix wrote:
| What access does Google gain here?
| postalrat wrote:
| If its that simple then why is Apple blocking the most
| useful features like push notifications and add to home
| screen? Those aren't particularly useful for tracking.
| postalrat wrote:
| What's with the FUD. What else besides PWAs promise to free
| everyone from app store rent and anticompetitive policies?
|
| PWAs would also open the doors to new mobile OSs beyond Google
| or apple control.
| PaulHoule wrote:
| I think web apps are great. The average brand has no business
| making a mobile app when an web application would do.
|
| It's the "progressive" part I have a problem with. Web apps
| revolutionized our idea of what an application can do;
| everything in PWA makes web applications worse, not better.
|
| Just to take a simple example, when I want to visit Hacker
| news I just type n in the address bar of my iPad and click on
| the auto-suggest result and I am there.
|
| If I had an app for it, it would compete with all the other
| apps that have a burnt umber orange icon or that have an "H",
| an "N" or a "Y" as their own logo. (McDonald's might be the
| _only_ brand that can pull that off) If I had an app for that
| I 'd also be installing lots of other apps and have 4 or 5
| pages of them to scroll through. If anything, brands should
| be asking for ways to make installed apps as easy to find as
| uninstalled web pages are.
|
| (Note all the things I complained about originally except the
| lack of a reliable storage facility, are problems with apps.
| What makes it a 'side project' is that PWA advocates keep
| denying that "it just doesn't work" and then act incredulous
| that nobody wants to waste time with them.)
|
| If anything, most app authors should just quit drinking the
| Kool-Aid and just make plain ordinary web applications
| without any of the PWA power-downs. It's like playing a Mario
| game and finding some mushroom that makes you smaller without
| any benefit (like being able to go in some hole.)
| janci wrote:
| What are you even talking about? PWAs are an option on top
| of an ordinary web app. I guess all PWAs can be opened in
| the browser without "installing" them. Also "competing with
| all other apps" is the fault of OS built-in search. Nothing
| to do with PWA
| palata wrote:
| > What else besides PWAs promise to free everyone from app
| store rent and anticompetitive policies?
|
| I don't know... laws?
|
| > PWAs would also open the doors to new mobile OSs beyond
| Google or apple control.
|
| Or force everyone into ChromeOS once and for all.
| kristiandupont wrote:
| >laws?
|
| Maybe. I am not impressed so far, though.
|
| >Or force everyone into ChromeOS once and for all.
|
| I don't see that happening on iOS.
| palata wrote:
| Still you count on the law to force iOS to accept PWAs,
| right? Isn't that a bit hypocritical?
| kristiandupont wrote:
| First of all, no, even if I did, that would only be
| hypocritical if I was rooting for the law _not_ to apply
| to the app store. But I am not expecting either.
| palata wrote:
| So you don't count on the law to free you from the Apple
| Store (because that is the only major platform with a
| lock-in), but you hope that somehow magically PWAs will
| be distributed on iOS?
|
| How does that work?
| cranberryturkey wrote:
| firefox killed of pwas
| ricardobeat wrote:
| How? Did it even reach significant mobile share at any point?
| doodlesdev wrote:
| Also, Firefox on Android still supports PWAs, it was only
| removed on the desktop.
| riordan wrote:
| It's good to hear that PWAs are still on Firefox Android,
| even though they're out of Desktop.
|
| From my [fairly-out-of-the-loop-for-the-past-few-years]
| vantage point, Mozilla's been a lot less invested in the
| PWA ecosystem since they abandoned their Firefox Phone /
| Boot2Gecko initiative, which was intended to create a
| middle tier between the expensive smartphones of the early
| 2010's and ubiquitous and cheap feature phones (flip
| phones, classic Nokia candy bars), and expand access to the
| web across the world with it.
|
| All the apps were PWAs, which made it simple to build out.
| Eventually Mozilla stopped the project, but KaiOS became a
| commercial implementation and it still runs on a fair
| number of feature phones to this day.
|
| But without that pressure for PWA support in Firefox as a
| critical mobile feature, it was largely serving as an
| expensive bookmark launcher in the Firefox code base so
| that folks could alt-tab to the small number of sites that
| supported it on their desktops. Not a noble end for
| Mozilla's support for what should have been / could have
| been an incredible leverage point for the web ecosystem and
| open development.
| mnau wrote:
| How so? FF has minimal market share, most of it on desktops.
| starfox64_ wrote:
| It's kinda sad that the website doesn't prominently display which
| features have "universal" support across iOS and Android. The
| whole point of PWAs is to provide cross platforms apps so if a
| feature isn't available on all/most platforms, I don't think it's
| fair to say that it's really usable at all in your PWA.
| worksonmine wrote:
| Knowing what will come and be available is also a valid use
| case. If you want to know about support every feature has links
| to MDN and caniuse, just check there. The web isn't as simple
| as comparing iOS/Android. For example Firefox on desktop isn't
| Firefox on Android and Firefox on iOS is just Safari. The web
| is a complex ecosystem.
| throwawaymaths wrote:
| Depends. What if your PWA is an in-house app for operators in
| your company? They all have an issued device with MDM, one or a
| few skus, all apple (or all Google).
|
| I think most in-house devs would rather not deal with the app
| store or the vagaries of getting the MDM side loading pathway
| working
| pjmlp wrote:
| PWAs are the next step in mobile Web, for most forms over data
| apps, it isn't really needed.
|
| When I came back to Web/Distributed Systems after my stint
| dealing with Windows desktop, all the applications I have been
| involved only had Web frontends, including for mobile devices,
| not Web views, the actual browser.
|
| They managed perfectly fine.
| hotgeart wrote:
| > PWAs are the next step in mobile Web
|
| For subscription app may be, but all ads revenue websites
| will reject it.
| pjmlp wrote:
| There are many types of applications out there besides ads.
| HWR_14 wrote:
| Wouldn't that be the opposite? Subscriptions through the
| App stores, ads as PWA?
| worik wrote:
| > but all ads revenue websites will reject it.
|
| I reject them
|
| I cannot tolerate apps with ads
| rchaud wrote:
| "ad-driven websites" and PWAs aren't targeting the same
| user. Even if they were, there's nothing stopping a PWA
| developer from adding a Google Ads script to the markup.
| ajross wrote:
| Doesn't https://caniuse.com already fill this need? This
| article is just evangelism, if you want technical sources the
| community has had you covered for a long time.
| MBCook wrote:
| Sure you can look things up but it would be nice to look at
| this evangelism site and tell at a glance that Bluetooth
| isn't supported everywhere the way playing a sound is.
| ajross wrote:
| To clarify what you're actually trying to say: Access to
| the low level Bluetooth device API is not as pervasively
| supported as audio output is. Quite clearly you can play
| audio to a bluetooth device in a PWA everywhere.
|
| And that kind of ambiguity is why you need to be using a
| rigorous source like caniuse and not just looking at
| summary statements for this kind of information.
| MBCook wrote:
| Right. Audio over BT just counts as audio, the BT
| permission means something mote like connect to and use
| arbitrary BT devices.
|
| I didn't actually mean to compare BT vs BT audio in my
| original post, I just picked an example every browser
| will let you do. I hadn't considered the crossover until
| I saw your reply.
| onion2k wrote:
| _The whole point of PWAs is to provide cross platforms apps so
| if a feature isn 't available on all/most platforms, I don't
| think it's fair to say that it's really usable at all in your
| PWA._
|
| You should be delivering the best possible experience for the
| user based on what their device can do, not the lowest common
| denominator of some arbitrary set of features. Progressive
| enhancement, API detection, and polyfilling are all common
| strategies that can be used to mitigate almost all device
| differences.
| hn_throwaway_99 wrote:
| > Progressive enhancement, API detection, and polyfilling are
| all common strategies that can be used to mitigate almost all
| device differences.
|
| Keyword being "almost", and that in some cases if the
| platform doesn't support your feature, you're shit outta
| luck.
|
| _By far_ the thing that prevented PWAs from bigger uptake
| earlier was Apple dragging their feet on push notifications
| support on iOS. There was simply no workaround or polyfill
| for that at all, and the biggest use case for PWAs was
| supporting push. Apple finally released web push notification
| support last year on iOS _but_ the app needs to have already
| been installed on the home screen (I think that part is
| good), and last I checked the "install to home screen" on
| iOS Safari was still a horrible user experience (the actions
| is hidden under the "share" menu, which makes no sense to
| me).
| CharlesW wrote:
| > By far _the thing that prevented PWAs from bigger uptake
| earlier was Apple dragging their feet on push notifications
| support on iOS._
|
| Is there any evidence that this moved the PWA needle at
| all, he said hopefully? I would've predicted no effect on
| PWA adoption.
|
| > _...last I checked the "install to home screen" on iOS
| Safari was still a horrible user experience (the actions is
| hidden under the "share" menu, which makes no sense to
| me)._
|
| For better or worse, it's how iOS users are trained to "do
| something" with the current web page. Keeping in mind that
| "PWA" is jargon that average users won't be familiar with,
| what would be easier than (1) tap Share, tap (2) Add to
| Home Screen?
| ChadNauseam wrote:
| Android allows the site to prompt the user to add it to
| their home screen, which it can do at a time when it
| makes sense. e.g. the user orders something, then the
| "add to home screen" pop-up appears and the user can
| accept with one tap, which they're likely to want to do
| because they anticipate wanting to check their order
| status.
| NoZebra120vClip wrote:
| This doesn't work for me. (Android 11, Motorola phone.)
|
| If I add a PWA or shortcut to my Home Screen, it will
| quite quickly disappear silently. Especially if I use
| Chrome to do it. The Support community is at a loss to
| explain this and they're starting to send me nonsensical
| instructions, showing they are desperate to get rid of my
| embarrassing question.
| jon-wood wrote:
| Sadly this is caught up in the usual conflict of
| interests. As someone building a PWA I would love a quick
| and easy method to pop up an install dialogue for the
| user. Unfortunately as a user of Safari on iOS the last
| thing I want is for every single website I interact with
| to be popping install dialogues, and you just know that's
| going to be as prolific as the current bombardment of
| requests to subscribe to mailing lists, and on desktop
| enable push notifications the moment a web page is
| opened.
| usrusr wrote:
| The "natural" UI place for that kind of begging would not
| be a pop-up, but the head end of the URL bar, where the
| domain certificate validity is shown. Usually that's also
| the place where the UI for revoking permissions that are
| already granted is launched. Assuming the best I suspect
| that this is already the future plan of browser makers:
| on both browsers I usr (android chrome and FF on the
| desktop) hair the begging pop-up point there already,
| perhaps this is not only done as a hint to the place
| where the permission can be revoked, but also as training
| wheels for a less annoying future where the pop-up is
| replaced with some simple notification state in that
| place?
| hn_throwaway_99 wrote:
| As an Android user I don't feel bombarded by install
| requests, so I don't really know what you're talking
| about.
| steve1977 wrote:
| As an iOS user, I would certainly not want websites
| prompting me for things like that. But I probably also
| would not want a webshop as an app. That's a good use for
| a plain website.
| usrusr wrote:
| Companies that already have two copies of their app
| front-end team will certainly not jump at the first hunch
| that they might perhaps be substituted by a third line.
| It's a slow process. But five years from the watershed
| moment of Apple ending their web push boycott (announced
| 22, executed 23), I expect a noticeable trend. For now,
| it's probably just orgs that would start from zero with
| an app questioning the need for a pair of native apps who
| might pick PWA over faux-native (electron/tauri wrapping
| a web UI). And perhaps some who already did faux-native,
| keep their app-store presence but also offer a third
| variant of the same running unwrapped in regular
| browsers.
| hn_throwaway_99 wrote:
| > what would be easier than (1) tap Share, tap (2) Add to
| Home Screen?
|
| In what universe does "adding to home screen" have
| anything to do with sharing? It's completely nonsensical.
|
| As others have noted, it would be trivially simple for
| browser makers to explicitly have something in the
| address bar or a pop-up that allows users to install.
| JumpCrisscross wrote:
| > _By far the thing that prevented PWAs from bigger uptake
| earlier was Apple dragging their feet on push
| notifications_
|
| For me, it was developers trying to push Android design
| language via PWAs. In others, it was what should have been
| a website being packaged as a PWA, which is just clunky.
| That combination made PWAs feel cheap compared to native
| apps or sites.
| alternatex wrote:
| PWAs are cheap compared to native apps. That's the whole
| point.
| amadeuspagel wrote:
| What website uses the Android design language? Every
| website wants to look different, to stand out. A design
| language can only exist if it's enforced by an app store.
|
| What does a website packaged as a PWA mean? A PWA is a
| website.
| Longhanks wrote:
| > You should be delivering the best possible experience for
| the user based on what their device can do, not the lowest
| common denominator of some arbitrary set of features.
|
| So the exact opposite of PWAs.
| alternatex wrote:
| Technically that's what Progressive means in Progressive
| Web Apps. That the developer enables features for customers
| based on the browser API support on their device,
| inadvertently ending up with software that works
| differently on every person's device. You might not like
| it, but that's what peak Chromebook performance looks like.
| rchaud wrote:
| If you open the site on a target device, it'll tell you whether
| the feature works on that browser or not.
| moffkalast wrote:
| > "universal" support
|
| Apple laughs at your universal support.
| alternatex wrote:
| Apple spent a huge amount of time and money getting Safari in
| line with PWA standards in the past few years. Your comment
| would make sense 3 years ago when it was completely unclear
| whether Apple will flinch.
| mdhb wrote:
| It just happened to coincide with the moment the EU started
| looking quite seriously at what they were doing.
|
| They have tried to hobble the web as a platform for fairly
| obvious reasons for as long as they could.
|
| They don't deserve any credit for whatever progress they
| made, it was done unwillingly at gunpoint.
| moffkalast wrote:
| "You mean to tell me there's this thing called the world
| wide web, where anyone can just host anything and all
| people need to access it is a few words typed into a
| program that runs on anything? They don't need to buy our
| proprietary iDevices?! They don't even need to pay us a
| yearly ransom to put their stuff onto our store?! But
| what if it's something we don't approve of? This is
| preposterous and I want it dead."
|
| - Tim Apple, probably
|
| I wonder what kind of preachy "we are so brave" excuse it
| will be this time now that they're finally forced to
| allow app sideloading by the EU and Japan.
| phartenfeller wrote:
| I'm wondering why there isn't a calendar API available. I wanted
| to create a simple PWA to track upcoming events for my favorite
| sports. It would be convenient to sync these events with my
| phone's calendar. Currently, downloading .ical files isn't a
| sufficient solution because it requires accepting prompts for
| each event and doesn't allow for modifications (as I am aware).
| wombarly wrote:
| Most calendars have the option for you to subscribe to an ical
| by pasting in the web address. Which they will then keep in
| sync.
| lawgimenez wrote:
| I track sport events with Fantastical's interesting calendars.
| graphe wrote:
| You're looking for SOGo. https://en.m.wikipedia.org/wiki/SOGo
| augustohp wrote:
| I might be missing something here but thet "Calendar API"
| exists for a long time: CalDav.
|
| You can have .ical for a whole Calendar, not only an (offline)
| event. The calendar can be synced with new events, through
| CalDav, when they are added to the calendar you shared. You
| would still have to accept the prompt once but that is it.
| jallasprit wrote:
| Couldnt add it to homescreen on ios firefox because the option in
| the share menu wasn't there
| JimDabell wrote:
| This should have big warnings on it. Some of these are not web
| standards; they are features implemented unilaterally by Google
| in Blink that have been explicitly rejected by both Mozilla and
| Apple on privacy and security grounds.
|
| Take Web Bluetooth, for example:
|
| Mozilla:
|
| > This model is unsustainable and presents a significant risk to
| users and their devices.
|
| -- https://mozilla.github.io/standards-positions/#web-bluetooth
|
| Apple:
|
| > Here are some examples of features we have decided to not yet
| implement due to fingerprinting, security, and other concerns,
| and where we do not yet see a path to resolving those concerns
|
| -- https://webkit.org/tracking-prevention/
|
| This is Microsoft's Embrace, Extend, and Extinguish bullshit
| applied to the web platform by Google. Google keeps implementing
| these things despite all other major rendering engines rejecting
| them, convinces people that they are part of the web, resulting
| in sites like this, then people start asking why Firefox and
| Safari are "missing functionality". These are not part of the web
| platform, they are Google APIs that have been explicitly
| rejected.
| sberder wrote:
| Thanks for putting it in context, the Bluetooth API has been a
| big source of frustration in my exploration of PWAs. So many
| simple setup apps wouldn't need to be native. A cross platform
| Bluetooth API for the web would provide really easy PoC with
| MCUs.
| stephenr wrote:
| And a massive exploit capability for malware.
| scarface_74 wrote:
| Yes I really want random websites to have access to Bluetooth
| janci wrote:
| No, they do not get access unless you allow it and
| explicitly selet a bluetooth device the page is allowed to
| connect to. The bluetooth dialog is handled entirely by the
| browser.
| jauntywundrkind wrote:
| They're not random websites though. They're apps that you
| have installed. And given permissions to.
|
| The gatekeeping/FUD/wringing-of-pewrls over this seems
| absurd, cruel, and most of all arbitrary to me.
| Insubstantial naysaying.
| palata wrote:
| > So many simple setup apps wouldn't need to be native.
|
| If they are simple, why not making them native?
| jampekka wrote:
| Because in native even simple is complicated?
| palata wrote:
| Are you not saying that because you know webtech and not
| native? I find native easier, webtech with new frameworks
| and bundlers and fashion every two days is much more
| annoying to me.
| jampekka wrote:
| Probably not. I've coded more for webtech, but have done
| native for Android (and Linux and Windows. And J2ME and
| Symbian FFS). Luckily very little iOS and MacOS apart
| from some reverse engineering.
|
| You don't need frameworks or bundlers for simple cases.
| For many you need just one .html file.
|
| For e.g. Android you need quite a bunch of files and
| directory structures to do even get a Hello world [1].
| You need to compile and bundle and package. And install.
| And god knows what if you want the application
| distributed. And then you have to fight with the
| inconsistent and very boilerplatey Android APIs. And
| figure out which API was deprecated yesterday and what's
| today's one that will be deprecated tomorrow.
|
| From what I gather, iOS native is even worse. E.g. have
| to buy a Mac and use MacOS. And Xcode. And faff with
| signing keys.
|
| [1] https://github.com/IanDarwin/AndroidTemplate
| palata wrote:
| In my experience, Android-Studio creates the app for me.
| There are many files indeed, but that's nicely solved by
| the IDE. Then Kotlin is great, and I really like Jetpack
| Compose.
|
| You can distribute your APK manually, but if you want it
| on the Play Store you have to jump through loops indeed.
| Though I don't think it's worse than running a webserver.
|
| > And figure out which API was deprecated yesterday and
| what's today's one that will be deprecated tomorrow.
|
| That's a bit exaggerated. I have been developing for
| Android for 10 years, and deprecations take years. There
| are deprecations, but I find that they are made in a
| controlled fashion.
|
| > E.g. have to buy a Mac and use MacOS. And Xcode.
|
| Yes, I am not a big fan of that. But many people are,
| so...
| coupdejarnac wrote:
| Provisioning IoT devices has to be done through native apps
| if Web Bluetooth isn't viable. It's a total PITA.
|
| Web BT permissions can be disabled if not needed. I reject
| Mozilla's and Apple's reasoning.
| jwells89 wrote:
| Another API that Google implemented that Mozilla and Apple made
| similar objections to is WebUSB.
| janci wrote:
| Very useful for flashing microcontrollers and devices without
| need of native apps. No installation, no drivers, works cross
| platform.
| jwells89 wrote:
| No doubt, but Google probably could've worked with Mozilla
| and Apple to figure out an approach that addressed their
| concerns instead of disregarding them and implementing it
| as-is.
| janci wrote:
| Maybe I remember it wrong, but I think Mozilla said it is
| unacceptable in any form and they will not even consider
| it. I don't like the google way either, but Mozilla is
| stubborn here and Apple fights for control over app
| market.
| nolist_policy wrote:
| So sad, if FirefoxOS still where a thing they wouldn't
| bat an eye.
| amadeuspagel wrote:
| Extinguish? The web is "existinguished" by websites being able
| to use bluetooth, after asking for permission?
| lolinder wrote:
| The "extinguish" is what happens after a substantial portion
| of the web is only accessible through Chrome. At some point
| it no longer makes sense to use a different web browser, and
| when we reach that point the open web is gone.
| robertlagrant wrote:
| Isn't the idea of PWAs that you aren't doing it through
| Chrome, or not knowingly. You're just running an app, and
| Chrome (or Blink) is a library that the app can use?
| palata wrote:
| > or not knowingly
|
| That's a big difference. What if I sold you a Linux
| computer that was actually running Windows with a UI that
| looks like Linux?
| robertlagrant wrote:
| It feels like too complex an example that would need to
| be constrained in various ways to make it apply. Simpler
| example: if you've used an Electron app e.g. VSCode,
| you've used Chrome under the hood.
| palata wrote:
| Yeah, I refuse to use VScode because it's ElectronJS. I
| have colleagues who now find it super cool to use it from
| GitHub, I don't understand.
|
| I use the JetBrains IDEs, made for the JVM.
| amadeuspagel wrote:
| If bluetooth is so essential that a substantial portion of
| the web will rely on it, then maybe other browsers should
| support it.
| lolinder wrote:
| You're still focused on the Bluetooth, but that's just
| one tiny part of a larger pattern of Google ignoring the
| rest of the vendors and doing what they want. The death
| of the web, if it occurs, will be death by a thousand
| cuts.
| amadeuspagel wrote:
| Bluetooth is the example that you chose, and that I used
| to make a general point, which also applies to any other
| API.
| lolinder wrote:
| I'm not OP
| Andrex wrote:
| I used to have this view until I wanted to build a PWA that
| communicated with a cash register drawer and found only Chrome
| supports WebSerial (although others are positive on it).
|
| It may be possible on WebUSB but WebSerial is the perfect match
| for what I need.
| fidotron wrote:
| On a purely technical level the main thing stopping PWA adoption
| is the JS front end universe being addicted to front end
| frameworks which destroy the UX of websites and PWAs, but there
| is a key value add with app stores which PWAs will never have:
| trust, and much as the Apple haters will hate it it is much
| stronger on the iOS App Store because of the very things they
| hate about it.
|
| Chrome, for all of Google's sins, is a modern miracle of software
| engineering. Safari is nothing like as far off as people make out
| either.
| jwells89 wrote:
| The front end framework mess is just a symptom of the actual
| problem, which is that the building blocks provided by browsers
| are too crude/limited to allow for consistent quality, and so
| Rube Goldberg machine frameworks arise to try to paper it all
| over.
|
| I think browsers _can_ be a good platform but for that to
| happen they need to be a bit more batteries-included, with
| built in APIs for UI and other essentials that rival those of
| desktop platforms so crazy frameworks are rendered unnecessary.
| fidotron wrote:
| Honestly, I believe you have this backwards; the problem with
| browsers is they are too flexible and complicated. If you
| delivered a consistent MVC framework in the style of the
| classic NeXT APIs the major complaint would be the imposed
| look and feel, which from the point-of-view of a user is a
| feature, but for whatever reason people are drawn like moths
| to a flame towards that which is at the edge of reasonably
| possible and so devs and designers will forever be pushing at
| the limits until this state of chaos recurs.
| jwells89 wrote:
| It depends on what part of browsers are being spoken about.
| They're plenty flexible and capable for the case of
| traditional pages and server-side apps, but it's a totally
| different story for interactive widgets and especially full
| blown SPA's.
|
| For example, browsers don't furnish a tableview/datagrid or
| even a basic single column recycler view, meaning one has
| to find a third party library to do those things that's
| still maintained, fits into your stack, and has holes in
| functionality that are tolerable for the use case in
| question, or if none meet those criteria write it
| themselves. The result is a million reimplementations of
| the same thing nearly all of which have major shortcomings
| (some of which are present only because they aren't
| implemented as a native browser control).
|
| I totally get that styling is a pivotal part of web apps
| but I think that can be maintained without requiring devs
| to build castles from grains of sand instead of giving them
| more appropriate building materials to use.
| DaiPlusPlus wrote:
| > For example, browsers don't furnish a
| tableview/datagrid or even a basic single column recycler
| view
|
| <table> and <ol>? Or am I missing something?
| jwells89 wrote:
| Goes back to static vs. dynamic/interactive. That's fine
| for static content but falls apart when you need a table
| view that can be edited, sorted, reordered, can have
| columns resized/rearranged, and can contain thousands of
| rows (necessitating recycling of table row DOM elements
| to maintain performance and efficiency).
|
| This sort of view has been table stakes for desktop UI
| frameworks for decades and is a common need.
| fidotron wrote:
| The big question is how the table gets populated with the
| data and enables things like column based sorting all
| executed on the client side. (With the associated
| interactions with scrolling).
|
| The point of recycling views is as row UI elements scroll
| off the top they are reused for those appearing at the
| bottom (or vice versa) which reduces system resources for
| these things a lot. This way the data table can contain
| 20 million rows but if the user can only see 100 the UI
| only pays the cost for 100.
|
| This is standard practice in native app dev and I think
| is a good example for the case they are making. I would
| argue such a thing would be needed in the hypothetical
| NeXT type API of course.
| bob1029 wrote:
| > On a purely technical level the main thing stopping PWA
| adoption is the JS front end universe being addicted to front
| end frameworks which destroy the UX of websites and PWAs
|
| I would hesitate to conflate PWA adoption with JS framework
| popularity olympics. On a purely technical level, the only
| thing stopping you from using a PWA is you.
|
| Perhaps you should reconsider your product and business model
| if it doesn't work without App Store presence. The App Store
| cannot sell your product for you. At some point you will need
| to interact with your actual customers if you want to succeed.
|
| Having an app "in the store" does not equate to trust for me.
| fidotron wrote:
| > Having an app "in the store" does not equate to trust for
| me.
|
| It's not about you, but the users. iOS users do trust Apple
| as a proxy in the App Store and consequently spend much more
| there than even Android users do in the Play Store (on a per
| user basis).
|
| The great anomaly to this used to be Amazon where Kindle Fire
| users used to have even higher ARPUs than iOS, but I've been
| out of the loop too long to know if this is still the case.
|
| Not too long ago I decided to push the limits to see what web
| apps can do now and did https://luduxia.com/reversi/ - there
| are no UI libs here, the whole thing bundles in under a
| second with esbuild, and it runs perfectly on iOS Safari.
| hutzlibu wrote:
| "On a purely technical level the main thing stopping PWA
| adoption"
|
| I rather think, the main thing stopping PWA are that browsers
| still can not decide how to treat them. In some ways you can
| just do anything unrestricted and in other areas your PWA gets
| treated and limited like a random untrusted website, with no
| way to get needed rights. At least that was my experience last
| time I messed with it.
|
| It is of course a problem to do it right, as prompts for
| confirmation just gets clicked away, but there should be a way
| to get real user consent for a proper app, that people trust.
|
| But Apple for example wants to keep their app store under their
| control, so they surely won't provide an easy way to bypass the
| normal app store by giving developers a way to ship full apps
| just through the browser.
| MBCook wrote:
| Go to any webpage/PWA, hit the share button, hit "add to home
| screen".
|
| That's it. It's not complicated or restricted in any way.
| hutzlibu wrote:
| Hm, last time I checked and tried this, there were still
| limitations, but it has been a while and maybe something
| improved.
| rchaud wrote:
| it has changed, at least on MacOS Sonoma. I can "add a
| website to dock" and it launches in fullscreen if the
| manifest.json is set up correctly.
| bodantogat wrote:
| Its not intuitive for the average user. "Share" does not
| usually imply "Install" , and the add to home screen option
| for me is way down in the menu.
| MBCook wrote:
| You're not wrong. But at this point Apple has buried
| EVERYTHING inside the share sheet.
|
| Adding bookmarks, finding on the page, printing,
| triggering extension actions/scripts... it's a junk
| drawer.
|
| It's not hard to explain to users at least. It certainly
| could've been much worse. Not high praise but it is what
| it is.
| bodantogat wrote:
| Not on the list of Apple's priorities I guess. If you
| have an app, you can include a meta tag on your web page
| and Safari will show users an Get from app-store banner
| at the top of the page. (https://developer.apple.com/docu
| mentation/webkit/promoting_a...) Would it be nice if they
| did that for PWAs.
| mdhb wrote:
| Absolutely nobody expects to find installation options
| under layers of indirection in a share menu.
|
| It's an intentional choice by Apple that's hostile to users
| but very aligned with their strategy to lock users into
| their own proprietary platform as much as possible.
| MBCook wrote:
| What do you think the process should be? There are only
| five buttons on screen, should one of them be permanently
| dedicated to adding a webpage/PWA to your home screen?
|
| For the record they are the back, forward, share,
| history/bookmarks, and tabs buttons.
|
| As I explained in another reply, I don't think Apple is
| being malicious here. I think they just shove everything
| that's not a very common use in there.
| bodantogat wrote:
| On IOS, I can't install a PWA/add to home screen with a simple
| click. I think thats the bigger obstacle.
| aquova wrote:
| Can't you? You just hit Share->Add to Home Screen, granted
| that's two clicks, but it seems pretty straight-forward.
| bodantogat wrote:
| Not really. Not for non-tech savvy users. Try it on an
| iPhone. First you'll have to find the share button on the
| browser bar, then scroll down and find the option 'Add to
| home screen'. I don't think its very obvious.
|
| Most users don't know about it, and need a how-to guide -
| similar to what the posted link does.
| asystole wrote:
| The "share" button is massively overloaded on iOS and has
| been for ages. It does a bunch of stuff that isn't really
| related to sharing in any reasonable sense of the word.
| It's really IMO one of the worst UI elements in what
| overall is a pretty nice and consistent system
| amadeuspagel wrote:
| I like this website. I tap on the share button. That lets
| me do a bunch of things I can do with websites I like,
| like sharing them or bookmarking them or pinning them to
| the homescreen.
| kccqzy wrote:
| You can't install an app from the App Store with a single
| click.
| bodantogat wrote:
| Perhaps I should have chosen my words more carefully. The
| obstacle is that its not intuitive that you can
| install/save this PWA to my home screen via the Share
| Button. Someone is going to have to tell you the first
| time. If you open the original link on an iPhone, and click
| the "Install to Home Screen" button, it'll show you a popup
| with screenshots and instructions. The user will have to be
| somewhat determined to install the PWA.
|
| As opposed to an obvious button that says click me to
| install/download. (The usual Get it on the Appstore
| buttons), or Smart Banners[1]. The banner/button makes it
| crystal clear that I can click it to install the app. (Yes,
| you are correct you may need additional clicks to actually
| install, but by that time, you are in a familiar workflow).
|
| 1. https://developer.apple.com/documentation/webkit/promoti
| ng_a...
| SigmundA wrote:
| The only thing holding me back from using PWA's right now is
| tabbed mode [1].
|
| Browser tabs are so useful and having them open in new windows or
| in the system browser is a bad experience.
|
| Not sure why this is taking so long, there have been prototypes
| for years. Not like its even a security question just bringing
| over a UI that already exists in the browser.
|
| https://developer.chrome.com/docs/capabilities/tabbed-applic...
| jauntywundrkind wrote:
| Tabbed isnt enough for me. I don't want an app. I want a
| website. I want my user-agent! My user agent is what I know,
| affords me URLs & extensions and a powerful UI with lots of
| options.
|
| The PWA thing seems sick to me. Henry Ford listens to market
| research and rebuilds his car as a mechanized horse. For me,
| the UX is strictly worse in every way. (And I already knew how
| to put links to webpages on my home screens).
|
| There does seem to be a _browser_ display mode, but it 's up to
| the app maker to decide for the user what mode the app will be
| in. Why?!
|
| > _Progressive Web Apps can run in various display modes
| determined by the display property in the web app manifest.
| Examples are_ fullscreen, standalone, minimal-ui, and browser.
|
| It makes me so sad how much _lesser_ a person a user of a PWA
| is. The utter lack of user agent, being cast to whatever is
| provided by the maker, is a horrifying loss. All to ape what
| felt to me like the descending losing old-guard technologies.
| jauntywundrkind wrote:
| I assume I'm being down voted by pro-native people for
| calling their preferred tech descending losing old-guard
| technologies.
|
| Does anyone actually have any comments or reactions to what I
| was actually arguing about?
|
| PWAs being such brutal downgrade over what the web browser
| offers seems glaringly obvious to me; I'm shocked there's not
| more outcry. If people actually feel otherwise, please leave
| some arguments out in support of blowing away the user agent.
|
| This feels like it always has been the nexus of power where
| the web gets consistent enriching capabilities and
| affordances. It's what has made the web powerful & better,
| rather than every user being cast naked &bat the mercies into
| whatever app a company decides to cook up.
|
| There's a submission right now on _The Eight Golden Rules of
| Interface Design_ & the browser alone satisfies 6 or 7 of
| these, by my judgement, whereas native & PWA apps require the
| app to carefully construct it's own paradigm that can fully
| meet these user needs. The user agent is a helpful baseline,
| and it seems mad that PWAs throw it away to me.
| https://news.ycombinator.com/item?id=38916663
| https://www.cs.umd.edu/~ben/goldenrules.html
|
| If people think PWAs offer anything or make any sense versus
| the web browser, I'd love to hear why. Tabbed design was sooo
| late relatively to emerge in PWA space, and it feels like
| just one of a million affordances that are going to be half
| baked recreations of what we already had in the browser. How
| is being an app in an OS better than being a tab in a much
| more powerful & competent & featureful user-agent?
| SPBS wrote:
| Call me back when PWAs can be registered as share targets on iOS
| (i.e. it appears as an app on the share sheet when you click
| "share" on a web page). I really want the ability to bookmark
| sites I browse on my phone and save it to a self-hosted web
| application.
| taknil wrote:
| this is foreseen to come eventually, the APIs are there
| https://web.dev/articles/web-share?hl=en
| wojciechpolak wrote:
| Web Share Target API (manifest: share_target) - it allows a
| website to specify itself as a share target. Of course, it's
| not yet supported on iOS.
| JimDabell wrote:
| This is not a web standard. Google wrote the specification
| and only Google have implemented it. It's an unofficial
| draft:
|
| > Editors:
|
| > Matt Giuca (Google Inc.)
|
| > Eric Willigers (Google Inc.)
|
| > Status of This Document
|
| > This specification was published by the Web Incubator
| Community Group. It is not a W3C Standard nor is it on the
| W3C Standards Track
|
| -- https://w3c.github.io/web-share-target/level-2/
|
| Firefox doesn't implement it either:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1476515
|
| Apple raised a concern about spoofing which seems to have
| gone unaddressed by the spec authors in over a year:
| https://github.com/w3c/web-share-target/issues/109
|
| This may yet turn into a web standard given more work, but
| please don't hold up a Google spec. implemented only by
| Google as if it were a part of the web platform that Apple
| are late in implementing.
| bensecure wrote:
| The only relevant browsers on mobile are google's and
| apple's, and (modern) web standards are created by enough
| popular browsers implementing them. Literally all it would
| take for this to be a reliable web standard would be apple
| choosing to implement it.
| spiffytech wrote:
| Web Share Target API isn't a good experience on Android either.
|
| Partly because it only works if the user visits your site with
| Chrome for Android (even Chromium browsers don't work).
|
| And partly because receiving a share unrecoverably takes over
| whatever the user is doing. If the user opens something from
| your PWA (an external link, another app) and then shares back
| into your PWA, whatever they were looking at gets killed and
| your PWA navigates to the share target.
|
| I'm building a web app built around sharing and I'm going to
| have to wrap it in an Android app solely to get around this.
| zx_q12 wrote:
| If you just want something for yourself, you can set that up
| with a Shortcut and the "Get contents of url" action. You can
| then configure the shortcut to be available in the Share page
| so you could then easily share links/whatever to your self
| hosted app
| smokeydoe wrote:
| iOS PWA notifications are a pain in the ass to set up without
| using something like firebase, but they are so nice to have
| finally.
| kevincox wrote:
| Why are they a pain? Do they have extra requirements over the
| standard Web Push API?
| dannymoerkerke wrote:
| They don't
| esskay wrote:
| Slightly misleading domain when a large number of those arent
| actually supported in major browsers, certainly not at enough
| consistency.
| bob1029 wrote:
| We push PWAs to iPads & Surface Go devices via Microsoft InTune
| for some of our clients today.
|
| This path started out very nightmarish (circa 2020) but it's
| going much smoother today. One of our customers actually came
| back to us with a slightly improved process based upon the one we
| gave them. They switched from iPad to Surface Go and used some
| extra endpoint management to make the PWA experience into a sort
| of kiosk mode.
|
| The #1 constraint for us is the quality of the environment-facing
| camera and the level of access we have to its capabilities via
| the browser. iOS/Safari started out extremely weak on this but is
| quite good today. I can get a solid 2k environment scan at 30fps
| from the rear facing iPad camera in Safari today. Things like 2D
| barcode scan and document capture are 100% feasible now. These
| items used to make us extremely nervous on product demos but we
| don't worry anymore.
|
| We almost capitulated and went back to native iOS apps because of
| the camera issues, but the pain of maintaining a native build
| chain when you are otherwise a 100% Microsoft shop (with barely 3
| developers) was pushing back hard too. We were signing enterprise
| IPAs for all of our clients for half a decade before we switched
| to web/PWA. I will _never_ go back to native apps. I 'll find a
| different career path and hobbies if the web goes away.
|
| I don't have a clean answer for B2C other than... I use HN and
| Twitter in Safari and I don't even process that it's not a native
| app. Neither of these web properties had to spend a single second
| worrying about a native app to acquire my business.
| thekingshorses wrote:
| > 2D barcode
|
| Which JS library do you use?
|
| I couldn't find a single library that can reliably scan PDF417
| barcodes.
| martinald wrote:
| I assume the built in one that OP has?
| https://developer.mozilla.org/en-
| US/docs/Web/API/Barcode_Det...
| sevenf0ur wrote:
| Safari doesn't support that API whatsoever so a third party
| JS library is really your only option. The landscape of
| open source barcode detection libraries is bleak at the
| moment.
| martinald wrote:
| That's a shame. Works really well on Android.
| asveikau wrote:
| Can't you take a C library and compile to JS?
| cicko wrote:
| Wasm should also work, no?
| JimDabell wrote:
| This is another Google-authored specification, implemented
| only by Google, which is not currently a web standard. It's
| not just Safari that doesn't support it; Firefox doesn't
| either. It's a Blink-only API.
|
| > Editors:
|
| > Miguel Casas-Sanchez (Google LLC)
|
| > Reilly Grant (Google LLC)
|
| > Status of this document
|
| > This specification was published by the Web Platform
| Incubator Community Group. It is not a W3C Standard nor is
| it on the W3C Standards Track.
|
| -- https://wicg.github.io/shape-detection-api/
| bob1029 wrote:
| https://github.com/zxing-js/library
|
| Media constraints are the #1 reason it won't scan in my
| experience. You need at least ~1000px horizontal to reliably
| decode PDF417. If the resolution is 720p or lower, you aren't
| capturing enough information for a decode.
| k__ wrote:
| I tried zxing too.
|
| Scanning 2D barcodes only works reliable on smartphones
| with good camera and with good lighting.
|
| I needed it for a ticket scanner used on an old phone at
| night entries for concerts.
|
| Went and bought a hardware scanner (for 30EUR or something)
| that connects itself as a "Bluetooth keyboard". Works like
| a charm.
| bob1029 wrote:
| > Scanning 2D barcodes only works reliable on smartphones
|
| We wont even fully certify iPhones for use with this
| solution because we have seen consistent failure to
| autofocus on the barcode for "some weird reason". iPads
| work like magic though. I have to go out of my way to not
| get a quick scan on recent generation iPad camera.
|
| We went down the hardware scanning path w/ keyboard
| emulation in the browser, but its kind of clunky when you
| are considering the overall solution stack in a B2B
| setting.
| ubercore wrote:
| We've also not had the best luck with keyboard emulation
| scanners, but unless you want to add a native wrapper,
| there aren't a ton of good options.
| dvsk wrote:
| If you're open to using a commercial solution then there is a
| WebSDK offered by Scandit -
| https://www.scandit.com/products/web-sdk/ - full disclosure,
| I manage their website, however I thought this maybe of
| interest.
| jr19mi wrote:
| Full disclosure: I work for Scanbot SDK, but we do offer
| PDF417 scanning for JS. It's a commercial solution that comes
| with a not-insignificant price tag, but it might be what
| you're looking for. You can check out the demo and
| documentation here: https://scanbot.io/trial/demo-
| web/barcode-demo/ , https://docs.scanbot.io/barcode-scanner-
| sdk/web/introduction...
| oaiey wrote:
| As a Microsoft shop: Any experience with Blazor and PWA? I find
| Blazor very awesome for developing an App using WebAssembly.
| When using it as a PWA and caching the .NET runtime locally
| etc, the combination of productivity and ease of deployment
| could be theoretically really awesome.
| asabla wrote:
| Built an application using strictly Blazor wasm for my last
| assignment (so .Net 7).
|
| It wasn't a easy ride (especially when it comes to LSP
| support for razor pages). But the overall experience was
| pretty decent.
|
| Almost half of our users preferred to use the application as
| a PWA (using windows 10 and edge) instead of an ordinary tab
| in your browser.
|
| Somethings to consider tho: Upgrades to service workers and
| what not can be a bit challenging depending on your
| situation.
|
| Keep in mind that a lot of firewalls and antivituses may
| block all those binary downloads (since it's just dll files).
| There are ways around it ofc, but still expect files to be
| blocked.
|
| Authorization changed between .net 7 and 8. So make sure you
| understand what these changes are (if you use packages from
| Microsoft)
| bob1029 wrote:
| Yes. Tons with server-side Blazor apps. We currently use
| Blazor for our internal admin UIs, but at this point I'd
| never put it in something customer facing (even in B2B
| setting).
|
| We haven't played with the client-side WASM stuff, but the
| conclusion is that server-side blazor is not a fantastic
| technology if you want something that "just works".
| Websockets in particular are kind of nasty when you have a
| client device ecosystem where screens and apps are frequently
| changing activity state. Stateless forms are much easier to
| reason about. iOS/Safari is very aggressive with closing down
| unused resources. Stateless forms can survive for days on
| those user agents. Our blazor apps would require refreshes
| after a few minutes of inactivity.
|
| Vanilla web forms & SSR is what we run with today. Our
| "framework" is to use string verbatim & interpolation
| operators in C# to compose our responses. Looks something
| like PHP and has zero dependencies.
| asveikau wrote:
| A GitHub repo with just a bug tracker and no source code is kind
| of lame. If they really want to promote PWA they should have full
| source on there.
| wackget wrote:
| They don't want to promote PWAs. They want to promote their own
| business.
| fudged71 wrote:
| I see there are a few features not available on my phone (iPhone
| 15 Pro Max). If possible it would be great if the feature icons
| could turn grey if they aren't supported on the current device
| exabrial wrote:
| My estimate is there are 5,000-10,000 really poor PWA/SPA/etc for
| every actual good PWA/SPA.
|
| Going to a website and it loads some massive chunk of
| overengineered javascript when all I need to do is display one
| piece of text is infuriating.
| palata wrote:
| I think we have to get used to it, it's the new engineering
| way. "I see potential profit with blockchain, let's rush and do
| whatever quick project I can imagine with blockchain". "I see
| potential with AI, let's rush and do the same with AI".
|
| It's not important to make a good product anymore: you need to
| be the first or the luckiest. Good products don't win because
| they are drowned in all the crap. And AI will soon make it
| infinitely easier to generate more crap.
| steve1977 wrote:
| Please don't call this engineering.
| sccxy wrote:
| Gatekeeping is strong here.
|
| Most apps do not need to be made by 10x developers who code in
| assembly.
| steve1977 wrote:
| Some things should be kept at gates.
| exabrial wrote:
| Then just serve a text file, literally 99% of PWA/SPAs could
| be static sites
| hanselot wrote:
| Will wait for the next version of the website:
| whatpwacandosafely.never
| self_awareness wrote:
| > A PWA is much smaller than a native app. Your users no longer
| need to install tens of megabytes of code.
|
| I don't think we have the same definition what a "native app"
| means.
| nprateem wrote:
| A big limitation is that pwabuilder doesn't support push
| notifications on ios
| 2024user wrote:
| I dislike that when you install a PWA it is browser specific. For
| example, if I use Chrome, the installed app will only open in
| Chrome. Use Firefox on Android and it overlays a Firefox icon on
| the installed app icon.
| palata wrote:
| PWAs to me sound like "we want everyone to use the same OS (in
| this case something like ChromeOS), because that's more
| productive for us".
|
| I get that Google pushes for PWAs because that's how they conquer
| the OS world. But why do individuals push for that? Because they
| don't know anything other than webtech and don't want to learn?
| Have a look at Kotlin and Swift guys, it's kinda cool!
| marvinblum wrote:
| > But why do individuals push for that?
|
| Because we don't have the resources to build a native app for
| every OS out there.
| palata wrote:
| Are you using Windows? I am happy that the people who
| contributed Linux/BSD/Android/iOS did not have your
| mentality, otherwise I would be forced to use Windows
| everywhere.
| marvinblum wrote:
| I'm on Fedora. Of course, there has to be a native UI, but
| I'm running a two-person company for example. How on earth
| are we supposed to manage three or more platforms (browser,
| Android, iOS)?
|
| We're not lazy but limited by our mortality.
|
| > Because they don't know anything other than webtech and
| don't want to learn?
| palata wrote:
| > How on earth are we supposed to manage three or more
| platforms (browser, Android, iOS)?
|
| Are you sure you need three or more platforms? In my
| experience, when I ask small companies what they need,
| they say "everything". If I listen to them, they even
| need to run on a Gameboy. Then most startups fail, so
| apparently the problem was not the number of platforms.
|
| It feels like many times, selecting the platforms may be
| fine.
| sccxy wrote:
| Yeah, only privileged white people can build apps.
|
| Web is free and people can build and release web apps they
| want.
| palata wrote:
| > only privileged white people can build apps.
|
| Android is free, isn't it? Most smartphones use Android.
|
| Then writing Desktop apps is free, too.
| andrei_says_ wrote:
| I'm looking to release two web apps as PWAs. This will make the
| experience close to native on iOS and android without going
| through the app stores.
| palata wrote:
| How do you release them? You don't have to go through the
| Play Store to release an Android native app, and I think the
| EU is making it change for iOS.
| davidy123 wrote:
| "Cool" is not a great reason. Only having to develop something
| once that serves all users is great, though. Personally, I
| cannot stand apps, I only use them when absolutely required,
| using a PWA gets you all the security of the browser
| (relatively speaking, but it's a lot more secure than a from
| scratch black box, and look at goon moves like Facebook
| embedding a browser that retains third party site interactions)
| and as a developer and user I can use my own extensions and
| general browser features.
| palata wrote:
| > Only having to develop something once that serves all users
| is great, though.
|
| Cross-platform usually sucks in some way. If the app is not
| worse, the development is: "write once, debug everywhere".
|
| Web is solving that by forcing everybody to use the same
| (Google-controlled) renderer, so that there is no need for
| cross-platform anymore: just use the Google thing. I don't
| want that.
| davidy123 wrote:
| Debug everywhere or google controlled, those things seem
| diametrically opposed. Aside from the murky area of
| cookies, chrome isn't straying much from web standards.
|
| There's really not much reason to not use a browser, the
| compatibility issues are pretty much a thing of the past on
| any browser, unless you're doing something esoteric.
| Installing a special app should be unusual.
| palata wrote:
| > Debug everywhere or google controlled, those things
| seem diametrically opposed.
|
| That's what I said.
|
| > the compatibility issues are pretty much a thing of the
| past on any browser
|
| Because there is only one meaningful browser left:
| Chromium. It is not a solution to cross-platform, it is
| just pushing for a monopoly. Just like a few years ago
| you could have been advocating for supporting exclusively
| Internet Explorer: that solves the compatibility issues
| too.
|
| Now PWAs are not trying to kill other browsers (it's done
| already), but other platforms. That's just the next step.
| bad_user wrote:
| The biggest reason, as I see it, is that the web is a free
| market, whereas on Android's and iOS's app stores you're
| beholden to Google's and Apple's taxes, restrictions and whims.
|
| The second reason is the resources available. Going web first
| means your app is instantly available everywhere, even if not
| perfect.
|
| We can learn Android and iOS development for sure, but how
| about both? And have you ever seen shops with the same
| developers targeting both iOS and Android with their native
| stacks? I haven't. Besides the web, you're limited in available
| options for reusing existing code and knowledge, such as React
| Native, and using cross-platform toolkits may be more risky
| than targeting the open web.
| palata wrote:
| > is that the web is a free market
|
| Controlled by Google with Chromium, right?
|
| > The second reason is the resources available.
|
| I guess that's the excuse, yes. But in my experience the
| native way is not necessarily more expensive. It's just
| faster to make a prototype in web, I suppose. And most apps
| end up being prototypes thrown into production nowadays.
|
| So yeah: it's cheaper, not better, but that's enough to win.
| mvkel wrote:
| As soon as I tapped into this site, the browser's back button got
| hijacked and half of the features don't work.
|
| This is why (imo) PWAs should not try to replicate native app
| functionality, but instead recognize the web for what it is and
| play to its strengths.
| heax wrote:
| That it can break my back button is also what i took away from
| this before closing the tab and reopeing hackernews.
| doublerabbit wrote:
| > As soon as I tapped into this site, the browser's back button
| got hijacked and half of the features don't work.
|
| Sounds like common SPA application features to me.
| RomanPushkin wrote:
| Is there such a thing as _live_ geolocation?
| sccxy wrote:
| Geolocation API has "watchPosition", so it sends updates as
| often OS/browser decides.
|
| Was very unreliable in iOS, but is much better now.
| magnat wrote:
| Doesn't work with JavaScript disabled.
| zamadatix wrote:
| This is an example showcase and PWAs require JavaScript to
| register the service workers for these features (as well as to
| operate them of course).
| comex wrote:
| How typical of PWAs that even a demonstration site, which should
| demonstrate the best that PWAs can be, has a glaring UX bug on
| iOS.
|
| Namely: if you swipe from the sides of the screen to go
| back/forward, you get a duplicate animation. If you swipe back
| from B to A, once the native (interactive) slide animation
| finishes, the page then jumps back to B and then does another
| (noninteractive) slide animation to A.
|
| Fixing this would be as simple as disabling the page's slide
| animation, but whoever made this site didn't notice or didn't
| bother.
|
| Apple does have some blame here. Disabling the page's slide
| animation wouldn't be a perfect solution since it wouldn't
| distinguish slide gestures from other ways to go back/forward
| (which ideally would still show an animation), like using the
| browser's back/forward buttons if accessing the site in a browser
| rather than as an app, or using a keyboard shortcut with an
| external keyboard. I don't think it's possible to easily detect
| which kind of gesture triggered navigation (in order to
| conditionally show the animation).
|
| Another option would be to disable the native slide gesture
| entirely in favor of a fully JS-based one. In the past it wasn't
| even possible to disable it, but that has been fixed for years
| now [1]. However, it's hard to exactly replicate the native
| behavior.
|
| Ideally there would be a more purpose-built interface to detect
| and customize the native swipe gesture.
|
| [1] https://pqina.nl/blog/blocking-navigation-gestures-on-
| ios-13...
| andreyvit wrote:
| Yes! And the visuals are horrific too, just look at that
| tabbar. If anything, it's a showcase of just how hard it's
| gonna be to build a good app this way.
| bbor wrote:
| Is there anything about native apps or conventional
| websites/apps that would improve the visuals?
| dannymoerkerke wrote:
| I'm the creator of this and haven't been able to reliably fix
| this so far but I'll give your suggestion a try.
| debacle wrote:
| Whoever made this, this is incredible, thank you.
| Tepix wrote:
| Several of the features in this demo app are broken (not just not
| implemented on iOS 17). That's how Apple likes it, i guess.
|
| On the other hand i have been using the Eclipse Emulator PWA
| https://eclipseemu.me/ on iOS for a few days and it works
| _really_ well! The only issue i 've had so far is choppy sound
| when emulating SNES.
| mvdtnz wrote:
| I tried two of the features at random (face detection and
| vibration). Face detection told me my device wasn't supported,
| and vibration just straight up didn't work. Then I tried to back
| out of the website and it wouldn't let me.
|
| I'm on Android Firefox.
| account-5 wrote:
| I thought it was just me because I'm using uBlock. But even
| with the site first party scripts and line allowed it didn't
| work.
| majesticmerc wrote:
| Same experience for me on Android Firefox. Couldn't return to
| HN via the back button, and most of the features were either
| "not supported" or just didn't work (e.g. Vibration)
|
| Seems that either the author is only working in Chrome (which
| is probably reasonable for a prototype or whatever) or Firefox
| is lacking many of these features.
| matt-tingen wrote:
| Unfortunately, feature detection indicates that Firefox on
| Android supports vibration, but it doesn't currently work.
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1653318
| mvdtnz wrote:
| Par for the course on Firefox I'm afraid. Every time I give
| it a chance it lets me down.
| TulliusCicero wrote:
| This is what happens for a lot of "this is just as good!" type
| features in any domain.
|
| Many advocates will tell you the thing is just as good, or at
| least more than good enough, and will deliberately avoid
| telling you about the many pitfalls and not-so-edge cases that
| they are very much aware of.
| lordofmoria wrote:
| Things PWAs can't do: 1. On mobile, access full-definition
| camera/video as part of MediaDeviceCapture. There are new
| javascript APIs for this, but they're only partialy supported
| (the name of the new escapes me)
| turtlebits wrote:
| I'm working on a minimal music player for Android that just plays
| from a directory on device. Can I do this with a PWA? I just
| tried the File System Acecss API -> Open directory but it did
| nothing.
| nolist_policy wrote:
| Firefox doesn't support the File System API btw.
| judah wrote:
| I have a music player PWA published on Android[0]. It works
| pretty good, my users are happy (rated 4.5 stars), and I
| haven't encountered any significant issues with it.
|
| For the file system access API, only the origin private file
| system is enabled on Android[1].
|
| IMO, the file system access APIs are still a bit immature.
|
| [0]:
| https://play.google.com/store/apps/details?id=com.messianicr...
|
| [1]: https://caniuse.com/native-filesystem-api
| account-5 wrote:
| I'm still glad I invested time in flutter for a cross platform
| framework.
| rock_artist wrote:
| I really love how PWA goes. But one aspect for some use cases is
| monetizing.
|
| How can you "sell" PWA or have subscription for ad removal?
| judah wrote:
| For in-app purchases of PWAs in app Stores, you can use the
| Digital Goods API[0]. It works for Google Play and Microsoft
| Store.
|
| For non-free apps, one thing I've seen is app Stores launch the
| PWA with some flags indicating it was launched from the Store.
| If these flags are not present, the app is being launched via
| direct URL, in which case the app server can give a not
| authorized response.
|
| [0]: https://developer.chrome.com/docs/android/trusted-web-
| activi...
| mcculley wrote:
| This page was the first time I had heard of the Contact Picker
| API. I tried to select the text to google it and this page has
| somehow disabled select/copy/paste of text. This is an ironic way
| to show that the web is just as capable/incapable as native apps.
| dannymoerkerke wrote:
| I'm perfectly able to select the text.
| mcculley wrote:
| I tried on Safari and Chrome. Maybe I need to install a
| special browser to use that web page. I wonder if they make
| an app.
| dannymoerkerke wrote:
| Just tap and hold, works fine for me on iOS and Android
| mcculley wrote:
| I see that it works fine for me also on mobile. Somehow
| they have managed to neuter the desktop experience. A
| perfect demonstration of PWA today.
| Alifatisk wrote:
| Man, the amount of ux bugs really describes the state of this. Is
| this the best experience we can give users through pwa?
| synergy20 wrote:
| the elephant in the room is the lack of support from Apple, by
| this alone, its apps store should be legally challenged, before
| that happens, it's hard to sell PWA, which is great on a tech
| standpoint.
| Andrex wrote:
| It's rumored Apple may finally allow outside browser engines
| due to pressure from the EU (also behind the USB-C switch).
|
| https://9to5mac.com/2022/12/13/apple-mulls-opening-browser-e...
|
| I very much hope it's true.
| judah wrote:
| It's not a rumor, it's reality:
| https://infrequently.org/2024/01/the-web-is-the-app-store/
|
| > "First, browser engine choice should become a reality on
| iOS in the EU in 2024, thanks to the plain language of the
| DMA. Apple will, of course, attempt to delay the entry of
| competing browsers through as-yet-unknown strategies, but the
| clock is ticking. Once browsers can enable capable web apps
| with easier distribution, the logic of the app store loses a
| bit of its lustre."
| wbharding wrote:
| Sure would be nice if Firefox desktop would join the browsers
| that support PWAs. We build an app that has been PWA-first, but
| it is unfortunate that this generally requires users to have a
| Chrome instance running. Would much rather point people to
| Firefox, and it seems like it would be to their advantage to give
| apps a reason to recommend FF, if they built a smoother PWA
| integration than Chrome.
| ctoth wrote:
| Mozilla's removal of SSB support (single-site browser[0]) which
| is the key missing piece here is completely mystifying.
|
| I reckon that CEO salary has to come from somewhere though.
|
| [0]:
| https://www.reddit.com/r/firefox/comments/uwojh7/why_did_fir...
| taway789aaa6 wrote:
| Agreed. On Firefox, if I navigate to the main page I can scroll
| and look at all the items. If I go to a sub-page, then back to
| the main page, I can no-longer scroll to see all of the
| "supported" features. :/
| tacone wrote:
| I really wish they would do that.
| donmcronald wrote:
| Firefox on Android is worse experience than Chrome too, at
| least for this app. The app is harder to install (no prompt),
| the icon looks worse, and the icon has a Firefox badge on it.
|
| I wonder if that's down to config for the PWA or a Firefox
| shortcoming. Anyone know?
| amadeuspagel wrote:
| > and the icon has a Firefox badge on it
|
| This is something enforced by android. If every app was able
| to pin apps to the homescreen without such a badge, phishing
| would be too easy ... add something that looks like a bank
| app to the homescreen, get people to type in their password
| ...
|
| It's not fair, since that's not true for chrome, but there's
| no obvious solution, other then I guess having some sort of
| "super trustworthy" status for a few other browsers like
| firefox.
| amadeuspagel wrote:
| I don't understand the point of PWAs on desktop.
|
| I find it much easier to open a website from the addressbar
| then to open an "app" using spotlight.
|
| I always have a browser window open anyway.
| FridgeSeal wrote:
| If this site is supposed to be a good demo of what they're
| capable of, it's failing pretty hard for me.
|
| - Takes _ages_ to finish loading
|
| - huge number of features/functionality I don't want a website to
| have over my phone/desktop
|
| - navigation is broken: swiping back causes some double-
| navigation stutter.
|
| - history is broken: attempting to navigate back to HN loads the
| same page again and again with no content change a stack of
| times, before I can finally escape.
| benrutter wrote:
| This blows me away! I did a tiny bit of prototyping a year or so
| ago with an app for react native that required text to speech.
|
| Maybe I'm just a little slow with things but alongside janky
| styling I found it insanely difficult to implement any kind of
| offline native text to speech (I.e. not just sending sound files
| over an api call to anither api).
|
| Seeing that it (and lots of other things) are now implementable
| with PWAs fills me with excitement that "write once, run on
| iOS/android" might be becoming a real option for apps.
| wg0 wrote:
| Just wondering why mobile platform gate keepers, even Google
| would allow PWAs which will erode the value of their platform.
| mdhb wrote:
| Because holding customers hostage is a shit strategy?
|
| That and the fact that there is a large legal aspect to all of
| this largely led by the EU that seeks to prevent that kind of
| anticompetitive behaviour.
| Andrex wrote:
| Google makes more money from the Web platform than the Android
| platform.
| magicseth wrote:
| We built hellowonder.ai as a PWA first, and it was almost
| amazing! But we use voice input, and ios would pop up the
| microphone permission repeatedly after a few minutes, even if it
| had been approved recently. I couldn't figure out how to keep the
| microphone permission!
|
| So frustrating to be soooo close, and then need to build an iOS
| app.
| maxglute wrote:
| Pretty buggy for me. Wonder if better connectivity will lead to
| remote streaming apps and skip this mess altogether.
| deathanatos wrote:
| Is this satire? I'm not sure what about this is supposed to be a
| convincing argument for PWA?
|
| Even the text seems wrong? The prose seems to indicate it is
| installable even outside of mobile ... but I have no idea. I'd've
| expected one of those popup "this site wants..." boxes, but nope?
|
| I also sort of thought PWAs were supposed to be responsive in
| their UI, adjusting to more/less real estate, but this is just
| the same UI at any size?
| hoten wrote:
| Why does the HN crowd love to leave comments of mean criticism as
| if it was certain the creator of the submitted site wasn't going
| to see it? You can levy critique without being rude. Not many are
| doing this, but it doesn't take much. Maybe letting harsher-than-
| necessary criticism wash over you is necessary for putting any
| creation out into the world, but it still feels bad to see.
|
| This is why people outside this community often dislike their
| work being shared here, or at least refuse to read the comments.
| doublerabbit wrote:
| The HN crowd are mainly developers who feel that their opinion
| is strictly correct with no leeway; as per developer culture.
|
| If it's not Apple, Go or Rust; or some ten-story sandwich stack
| of cobbled together libraries, it's deemed trash. Don't you
| dare mention Java.
|
| But what do I know, I'm just a sysadmin after-all. Everything
| is full-cycle cynicism to me; tomorrow we will be bitching
| about SPA's again and praising some new reinvented library.
|
| Bring back ActiveX and JavaApplets.
|
| I'm sure I'll get some "deemed worthy" downvotes for this
| comment; and I think I need more tequila.
| mardifoufs wrote:
| Especially for an article about... PWAs. It's so weird to be
| this worked up about this, like sure maybe they suck but that's
| not the point of the article. It's like getting mad at someone
| for writing a c++ article because it's not a memory safe
| language... like... okay!
| ryan29 wrote:
| A lot of the criticism seems to be about the UI and the site is
| about functionality that's available. It doesn't make sense to
| criticize the implementation details in my opinion.
|
| It's disappointing because this site was one of the rare
| occasions I emailed the link to myself so I can add it to my
| list of things I want to look at. Having a concise demo of PWA
| functionality that exists is very useful.
___________________________________________________________________
(page generated 2024-01-08 23:01 UTC)