PWA Store
progressiveapp.store
progressiveapp.store
I can understand PWA wants to be more than just a web page and have their own UX. I have more experience in Backend software development and right now leading a small web/mobile/devops team, and always stress to not override browser controls unless absolutely necessary. Somewhat similar thing happens with scrolling. I feel most of the JS overridden scrolling is not needed.
In pwa we have w & a
For the app part, ux generally does not allow you to right click or pinch & zoom.
For the web part, it does.
The best compromise is media queries and have some ux for mobile and another for desktop.
From a business point of view, im not sure final user will value that investment
On iOS you even get a preview window with the links' content when using Safari.
But I assume few people do this, so your last point applies.
I think this happens a lot nowadays because we create and style div elements from scratch while also hooking onto more fundamental events and preventing any browser behavior.
I will also sneak in a pass when I finish something that unexpectedly takes less points to finish.
General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.
- links are for navigation
- buttons are for action
Simple rule is "should this view have a url". Should the user be able to navigate directly to this page? Should it exist in the history? Should the user be able to share a URL to that page to someone else? Most times the answer to all of these is.
In your javascript application, it is trivial to do single page app view navigations (without triggering a full browser request) by listening to link clicks and acting on it just as you would if it were a button click. All frameworks and routing libraries will handle this for you out of the box. If you roll your own, its not that difficult to add this functionality.
Are tabs a view? Should they be buttons or links? What if the tabs are in the sidebar in some widget?
What about collapsible items? HN uses JavaScript to store your collapsible preferences to your account. Not shareable but consistent on page refresh. Is that good? I don't know.
The fact is, in PWA world, what's a links and what's a button is blurred, and there's nothing wrong with admitting it.
It is an action, but it navigates you to the booking page. That page should have a url and should be able to be shared. But wanting to "book now" is an action and most sites have them as a button.
Oops. You can't nest table row <tr>s within anchors <a>, so you have a few options:
1. Each column has a link, and the link extends to the width of the containing cell.
Pros: It's easy to implement. It doesn't break browser behaviors.
Cons: There's unintended holes in the click targets. It's ugly as sin in code. It is quite confusing for screen reader users. It may be hard to get this right if your cells contain more layout than pure text. All in all, it's not an elegant solution.
2. Instead of making it a link, override the behavior of clicking on a row by registering a click event handler.
Pros: It does what you want. It's easy to generalize. It's a little bit of a kludge but certainly less hacky than 1.
Cons: It requires extra work to make it work well with screen readers. It requires extra work to make it work well with ctrl clicking and other behaviors - in fact, many webapps that apply this approach actually emulate the browser behavior, which, imo, is horrifying. Right clicking no longer gives contextual options for links, since there is no real link.
3. Restructure the DOM to not use a <table>. Perhaps use `display: table` with plain divs.
Pros: Now you can use a proper anchor tag link. It's also fairly easy to generalize. It shouldn't require too much work to get working well with screen readers.
Cons: Although it's less of a kludge in the end, it has one annoying flaw: just to get this behavior, you have to completely restructure your document. Which leaves you with choices: Should all tables be structured using other HTML elements instead of <table>?
Ultimately, some applications end up with trouble where anchor links are pretty hard for one reason or another. I don't think PWA or JS developers generally strive to break things or needlessly reimplement them; everything from client-side routing to custom link event handling has a reason to exist, and usually the intent is to make things work as well as possible.
That having been said, I've noticed a great deal of issues even with mature frameworks. For example, if you go to a really heavy PWA that has proper anchor links for fallback, try ctrl+clicking the anchor links and see what happens. You might find that it navigates in the current tab and spawns a new window!
(Note: I'm not suggesting this example is perfect; you could probably argue about whether the tabulated data should ever have clickable rows, or something like that. Still, it is a real thing that I've come across a few times now, and there's some pretty similar siblings to this problem.)
edit: Oh, and on a historical note... some of you who also were early adopters on XHTML will remember that in XHTML, you could actually put an href attribute on more elements, allowing you to get the behavior on list items, spans, etc. Sadly, it was never widely implemented.
When we're presenting data, one of our columns is nearly always a 'primary identifier' of some kind - a name, an id, etc. We make this column a hyper-link and then we also add a click handler to the row. This means it's still fully accessible to screen readers and tab navigators, but users who expect a more 'app'y experience are happy too.
The click handler has to be a little smart to ensure it's not receiving the mouse-up of a selection event, but it's not bad.
I starting making exactly this back in 2018 but didn't get people interested back then so I dropped it and let the domain expire, see the original (seems broken though):
https://web.archive.org/web/20180901171627/http://web-app.st...
It was my first time using a skeleton in CSS and using a Google Form as the way to submit a new app (with the spreadsheet as the database). I believe it was also my first PWA but I'm not 100% sure about that. While I learned a lot, some times I regret not having followed through, will keep an eye on https://progressiveapp.store/ to see how it goes.
Appreciate it!
I can't think of a way that native apps are more convenient? With automatic updates it's even less convenient to have the updates go through the app store.
I totally agree with you, I developed a PWA and 'native app' which is mostly an webview of the same content. I often use the PWA version but it seems most (if not all) of my users are using the app version even when the app stores approve updates in a notifiable slower rate.
My native app do used some native plugin, but those functions are not often used by the users. So I feel they just blindly ask for apps.
Maybe they think native app loads faster than PWA? People don't want to wait for a SPA first-time loading but they won't blame the download and install time of native apps.
Don’t you mean to say the opposite? Most proponents of PWA’s I see are devs claiming that writing native apps is too hard, but most users prefer native apps because of better integration and performance/efficiency.
Think about a random nontechnical Facebook user - How would they get their feet wet? Likely by opening the pwa of Facebook, realizing it’s pretty solid, and trying new ones after that. (I’m not saying Facebook is a good example, just the audience you might think about).
I’d definitely be into helping out with marketing strategy, lmk if you need advice or an extra hand.
Right, because the core technology PWA is based on, the web, hasn't been tainted with ads.
Many sites people have put on the web based on their business decisions are, sure.
But that doesn't mean the core technology has been fundamentally tainted, any business not operating on a model of generating revenue from passive views generally doesn't display ads on their sites/in their products.
* https://www.superhighway98.com/seo * http://jacek.zlydach.pl/blog/2019-07-31-ads-as-cancer.html
* https://www.youtube.com/watch?v=DnPmg0R1M04 * https://voxeu.org/article/advertising-major-source-human-dis... * https://www.forbrukerradet.no/side/new-study-the-advertising... * https://danielmiessler.com/blog/google-amp-not-good-thing/
* https://www.theregister.co.uk/2017/05/19/open_source_insider...
The worlds largest advertising company is well known for abusing its position to push technological features and standards that benefit it-even if nobody else does-suppress and hinder competitors and aggressively and continuously trying to erode the open web. Next up, Facebook is notorious for similarly attempting to subvert and erode the open web, whilst simultaneously invading your privacy and using you as psychological lab-rats.
Search is quite useless. It seems to only display list of matching names. So I can't even search for "game". It does not filter.
I think the UX is supposed to encourage experimentation, but I always find it daunting whenever I try to find an app for something. There is this bunch of huge icons, not enteirly clear names or just straight up deceiving ones and a rating. To get to even a slight neutral description what the thing is one has to tap in, many times also dive deep in description just to have an idea what the thing is trying to be. I guess with web platform it may be easier than normal apps, also I feel I must trust an app much more to install it, but this gives me the same vibes. A channel of spewed icons and mostly unhelpful names.
Sorry if it sounds harsh, I just can't stand how useless Play Store is at finding things.
Also, you've made a very common mistake of setting `outline: none` to your focus states! Very bad for people who navigate using a keyboard.
Good job on launching, by the way.
Appreciate it!!
Many accessibility systems work by emulating keyboard movements.
Also, it's dead-easy to customise - there are a bunch of facilities for doing so, from global to component level, with CSS-in-JS or CSS class overrides. You can make it unrecognizable without that much work.
Just gonna leave us hangin'?
User abuse is rampant on the Web. For example, those APIs you mention are used to fingerprint machines. If you're genuinely concerned with abuse of privacy, you'd do yourself a huge favor by researching the history and current mechanisms for such abuse by websites and, by extension, PWAs.
Both on desktop and mobile I use an array of browser extensions to limit online tracking and fingerprinting. On Android I use Webapps Sandboxed Browser [1] to log in to webapps without leaking the logged in status to other websites.
I feel that with the web I get a fighting chance, while native apps are designed for tracking you.
That's relative to the size of the thing you're installing, no? Wouldn't it then be comparable to software of the same size being installed on the host system?
>no/much less space taken on local storage.
Isn't this, too, relative to the size of the application or the data it is persisting?
What’s the likelihood that people are going to put their credit card information into some unknown website compared to using Apple/Google for payments?
Every “advantage” you mentioned is better for the developer not the user. That’s why PWA’s will never take off.
Outside of HN's bubble, people do that all the time. Or at worst they will use PayPal or an equivalent to make payments.
If people were so willing to make payments on random websites, merchants wouldn’t be falling all over themselves to use Amazon’s marketplace and sell their self published books through Kindle.
Not to mention that micropayments on the web has been the holy grail that no one has found in over two decades.
Apple was the first to make $0.99 payments over the internet feasible with iTunes back in 2005. There is much more friction to buying something on the web than just clicking on buy from Amazon/Apple/Google.
People fall all over themselves to use Amazon's marketplace because
- it has a lower barrier to entry to setting up and managing a store themselves - it has a built-in audience they can access without trying to hustle their proprietary domain name into the public consciousness (SEO is hard)
What on earth gives you the idea that it has anything to do with people's willingness or lack thereof to make payments on random websites?
> There is much more friction to buying something on the web than just clicking on buy from Amazon/Apple/Google.
Again, low-friction payment platforms that aren't "use Apple/Google's in-app payment SDKs" are readily available in 2020. PayPal is one such, Flutterwave is another (in sub-Saharan Africa), etc. In fact, I use those far more in a month than I've ever used Apple or Google Pay.
So the same advantages that using the App Store had over going to random websites and installing J2Me apps back in the day....
Again, low-friction payment platforms that aren't "use Apple/Google's in-app payment SDKs" are readily available in 2020. PayPal is one such, Flutterwave is another (in sub-Saharan Africa), etc. In fact, I use those far more in a month than I've ever used Apple or Google Pay.
You realize Apple has had more users payment information on file than any other company since the iTunes heyday than maybe Amazon?
Stripe integrates with Google Pay, so not as janky as you might imagine...
Native, cross-platform frameworks exist.
>no app store approvals/revenue share required[...]
Software was distributed long before those walled gardens came into existence. It is as possible as ever to install native software on your machine without having to go through a "store."
>openable via a link[...]
I don't follow. Do you mean a hyperlink from within a browser? I suppose, if one really wanted, it wouldn't take much effort to create such a thing for launching their native applications, but why would that be an advantage: "links" to open applications have existed as icons and various other actions for as long as graphical UIs have been in existence.
>works to the webs' strengths
What does this mean? What advantages do PWAs have, garnered from the Web, that native applications are unable to tap in to?
- Crossplatform (in use and development)
- No store/developer fees to pay
- CSS and HTML are capable of things native can only dream of like real reusable responsive UIs across many types of devices.
https://medium.com/missive-app/our-dirty-little-secret-cross...
- Until SwiftUI web front end was way more advanced in terms of reactive programming of UIs
Software was distributed long before those walled gardens popped up. Native applications need no store.
>- Crossplatform (in use and development)
Cross-platform frameworks exist for native applications.
>- No store/developer fees to pay
Same goes for native applications
>- CSS and HTML are capable of things native can only dream of like real reusable responsive UIs across many types of devices.
>https://medium.com/missive-app/our-dirty-little-secret-cross....
This is just an incredibly odd statement. First of all, if such layouts are rendering on your machine then of course native applications are also capable of such a feat. Web browsers capabilities are limited to the resources being made available on the host machine. The same goes for any software running on the machine.
And second: Qt.
>- Until SwiftUI web front end was way more advanced in terms of reactive programming of UIs
I don't understand what you mean here.
On iOS they do. On Android 99% of users won't use a different store.
> Cross-platform frameworks exist for native applications.
Nothing really good though. Best ones are RN and Flutter which do not get you there 100%.
A PWA will consume less memory and will be smaller than a RN or Flutter app.
> Same goes for native applications
Not on iOS.
> if such layouts are rendering on your machine then of course native applications are also capable of such a feat
Theoretically, yes.
> And second: Qt.
Remind me again how much a QT license costs?
> I don't understand what you mean here.
For the last 10 or so years UI development for the web has gone from archaic jQuery imperative DOM manipulation to a new paradigm with data binding and reactive data.
UI data binding in the native world exists but is extremely complicated and tedious. AFAIK the only thing that is similar to what we have now in web dev is SwiftUI.
There's an about button at the top that will take you to the about/landing page. I was debating on linking to that instead, but it's not a PWA, just a simple static site.
I managed to convince myself that I'm not using twitter website correctly because it happens to me all the time - after digging into some comment/thread I want to return to 'main' thread and it returns to the beginning, after that I often give up and just close tab, this is incredibly frustrating and infuriating!
I'm pretty sure that's somehow my fault because it would be insane that one of most frequently used service in the world and company which employs most skilled 10x workforce is unwilling or incapable to deal with problem like this.
They have absolutely no incentive in making your usage of Twitter more efficient as it would 1) decrease the "engagement" metrics and 2) give you less opportunities to look at ads if you just see the content you want directly.
Social networks need to strike a fine balance between extracting the maximum value out of the user (profit) while giving them the least possible value (expense). They believe the current system achieves this balance, which I sadly have to agree with because the average user's bullshit tolerance is orders of magnitude higher than ours and they will put up with a lot of shit without leaving the platform.
> which employs most skilled 10x workforce
There are still scammers replying to high-profile accounts with obvious spam such as fake cryptocurrency giveaways, something which can be filtered out with simple regular expressions. I would like to add a very big "[citation needed]" to Twitter having significant skill in house, whether it's engineering or management. Whatever skill they had when they initially built & scaled the platform seems to be long gone.
The topics of judgement you mentioned are all entirely subjective, but they run near identically for me.
Does it browse twitter? Yes. Is it good? Well, maybe if all you ever uses are PWAs, this is considered "good."
Ever tried to get users in emerging markets on old Android devices to discover, download and update your native app? It's a world of pain.
PWA's aren't the perfect solution here - on those same old devices, theres a good chance your user is running a 5+ year old browser engine, with a lot of bugs that are hard to even test against, considering how many combinations of screen size, phone, and browser software version there are.
There is a Join link at https://pixelfed.org/ by the way.
The most popular english open one seems to be: https://pixfed.com right now
I mean, PWAs by definition run inside a VM that has to provide a very heavy runtime, don't they?
This isn't a (comparatively) minimal like the JVM -- this is usually a Chromium instance, with the full V8 engine, Canvas and DOM support, and sandboxing.
It's not reasonable to say that something with this much baggage should be able to run as quickly as a native application, which can often afford to have a much more minimal sandbox, no bytecode layer, a smaller memory footprint, and more deliberate and performant integration with underlying system APIs.
That average includes the developed world. The average Android phone is even worse in the developing world.
But yes there are classes of applications for which underlying implementation technology does not matter much while browser based access from anywhere is more important.
https://github.com/cdr/code-server
This is amazing. I mean it isn't a stretch considering the main VSCode app is Electron based, but having a hosted development environment like this has always been a dream...
* I don't make a distinction between 'manifest files and offline support' ('PWAs') and other web apps. I suspect most people don't either.
A lot of people don't consider the economics of UI animation.
Smooth animation only makes sense in powerful devices. For the past 10 years we've seen an increase in UI animations which required users to buy newer and more powerful devices to achieve smoother and more complex animations.
Look at any phone/tablet review and you will see the reviewer try to open the app drawer or something similar to showcase performance. "Look how fluid it moves!"
Perfectly fine devices are constantly being replaced and thrown away because they can't keep up with more and more demanding UI animations.
Another aspect is energy consumption, battery production, etc, which I don't think is negligible when considering billions of devices being used for hours every day.
And the sad truth is, very often UI animation is overused.
I turn off all the OS-level animations using my phone's accessibility settings. It is a much better usability experience and "feels" far more performant - I perceive less time spent waiting, anyway.
I wish I could do it in apps too, so that I the time it takes to complete an action wasn't bounded by the duration of the "beautiful animation" someone felt it was helpful to include.
(we're a daily prediction platform with cash prizes - think of us like a hybrid between HQ trivia, a sportsbook, and Jeopardy)
> FREE to install
> HTTPS is required meaning you data is secure
> Takes up less storage on your phone. No need to pay extra money for higher storage
> No in app purchases or ads. Just a clean and simple app experience
> Has an offline mode. Apps can be used in areas where this is no internet connection
All of them are either misleading or completely wrong. The comparison randomly switches from websites to phone apps whenever convenient.
It would be a lot better to provide a more objective description of what PWAs even are.
For example, Twitter’s native iOS app is about 115 MB, while their PWA is a tiny fraction of that, probably not more than a few MB. This unsurprisingly reflects on performance.
I don't see how it is a terrible idea that needs to be killed. Sounds like a technological regression if support were to be removed. It's not like you're not allowed to still build native apps so please make me understand this argument.
And yes, I am advocating for a technical regression. I think the web platform has pushed things unnecessarily too far because it cared more about competing with apps then embracing what the web is good for.
If you want proof this is true, look no further than technologies such as AMP that trade away the general usage of these advanced web technologies for something the end user actually wants: a good user experience.
You could also look at the numerous native apps that have mini apps and games that are developed using web technologies. If the web platform delivered features developers needed, these mini experiences could run in embedded web controllers. Instead they are custom webviews with hooks into the native platform to bridge the gap to what developers actually need.
I have been lately working with lot of clients who want PWA's and I have found https://appsco.pe/ to be one of the nicest PWA gallery.
- Better isolation from my device. I don't worry about them sucking up information I don't want them to have. - I can share links to my friends (if the website has good URLs of course) - I can use it on every device. I don't need to worry if it has an Android App and website, I can just use the website on both. - I can use the same app as my friends no matter what phone they use.
It's trivial to implement but many devs don't pay attention to those things.
It is also partially the web's fault. There isn't an easy way to detect an "in-page" navigation. The best solution I am aware of is:
1. Add global "click" listener. 2. Check that the click target was an `a` tag. 3. Check that the click was a single left click with no modifiers. 4. Check that the `href` points to a page that you can render. 5. Call event.preventDefault() and handle the navigation yourself.
But step 3 isn't even sufficient as people can configure their browsers to open all links in new windows or tabs.
You know many people that do that?
I do that for search results and Reddit but I don't want that behavior for all websites.
There is a "gallery" - a store of games. But most importantly, manifests are available as a JSON feed, which anybody can use. It is at http://www.spreadmygame.com/
This seems to be exclusively optimized on mobile devices, and is not even properly responsive. A progressive web app should be usable both as an app and in a browser. This is not the case here.
Does iOS support offline use of PWAs? (Or perhaps this is an issue with my phone... anyone able to reproduce, or find an App that does work offline?)
Steps: Open App, enable airplane mode, go to iPhone home screen, open the App again, App is unresponsive.
Apps I tried: https://progressiveapp.store/pwa/219 and https://progressiveapp.store/pwa/87
EDIT: Might be a bug: https://github.com/facebook/create-react-app/issues/8889
Orchestration of the resources (CPU, memory, storage) to run API services would also be possible in a distribution manner if we can envision something like Kubernetes to manage workload allocation across compute hardware (smartphones?) and if there's a way for participating nodes to obtain container images and storage volumes (IPFS / Tahoe-LAFS?).
Signing and trust would still be an issue, particularly for container images and storage volumes.
[1] - https://withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-...
I have multiple progressive web application that I’m currently working on and I’m struggling a bit with that point.
Other than that like another user mentioned there's any monetization methods on the web at your disposal (advertising, microtransactions, donations etc) it really comes down to what business model you want to operate on and what seems most natural for users of your product.
As far as a "buy it, you own the copy" model like with traditional media software and games go I don't think there is anything universal to use, most developers would implement their own licensing in their billing/accounts layer and expose a serial key or something that local data gets encrypted with as a rudimentary DRM, so the app can only be used later by having the right serial key (whether from LocalStorage/cache/a fresh login) for that paid user to decrypt and use their local data.
It would be interesting if some service like PWA Store were to offer some kind of universal DRM to developers wanting to sell offline PWAs on a one-off sale format that they can easily wrap their app bundle in
There's one big problem though, if the freemium model doesn't work...
I assume this isn't what it should look like.
Sorry about the bug report here, I couldn't find any contact link.
Appreciate the bug report! will look into it
I don't actually know if it's possible using standard APIs that work on iPhone and Android
At least the demo worked.
You can probably implement facial recognition yourself as well.
[1] https://livebook.manning.com/book/progressive-web-apps/chapt...
The hn app is fast and slick, for example, but it doesn’t have comment collapse which is a major omission.
Then they wouldn't be using React Native in the first place
Pretty neat!
IOS it is still not supported yet but should be soon
Also they actively disabled service workers, the very tech that enables PWAs in the first place
Second issue, what are the chances that I would trust some random website with my credit card information?
Why would I use a native app over a PWA if I had the choice?
Apple will reject your app from the store if you ask for permissions not necessary for it to function. It also gives the user fine grained control and awareness of what the app has access to, for how long, etc.
Some random JS app that can load in whatever it wants after the fact can make no such claim to as much security or privacy.
It's true that Apple does a better job at protecting the privacy of its users. I'm an Android user and privacy is terrible. I self-limit myself to use the least amount of native apps, using webapps and open-source apps as much as possible. For example right now I'm using Hacker News through it's web interface on my phone.
IMO, the entire world has regressed into chaos when it comes to design and UI. Democratic design choices and process is far inferior to dictatorial approach we had going in 90's and into 2000's (See 98.css recently posted: https://news.ycombinator.com/item?id=22940564). Let everyone run loose and we all lose.
Yes, it was painful to develop applications using native UI elements but those apps provide a fantastic, consistent UI experience.
In addition, the entire Javascript ecosystem is rotten with horrible bloat built atop more bloat by many inexperienced software engineers - sorry, I don't meant to insult anyone but this is a factual observation from my own experience of developing on React and Angular. When a website that's serving trivial content is hogging so much CPU, it is time to refactor everything. It is actually time to refactor what we see as a modern browser.
I actually think it’s getting easier. Android and iOS are both offering quick, modern ways of building UIs with there upcoming UI frameworks thats IMO far less work than the web where things have to often be built from scratch or from some third party that will abandon it.
With the advent of web application we ignored it for a while (it is just a window with some strange stuff in it). However, with the mobile platforms (Android, iOS), bootstrap framework and the rise of strict user interface guideline by mega companies (like Google Material Design), the number of UX styles literally exploded. I try to enumerate them, but the web is full of variants.
As a dream, we should consolidate to device factors: Desktop, Mobile, Watch and Interactive. But Apple, Microsoft and Google are not on the same page here ;) If they would, magic could happen.
That you can't easily hack on (as in "customization"; userscripts and the like), aren't based on standards and have no sort of isolation or permission management.
Both ways have their up- and downsides but I think the web is an upgrade. It's not the best possible solution and "native" could be where the web is today but we have it and it's okay.
Also, I think the democratization of programming (whether it be UI frameworks or application development or whatever) is probably the best thing to happen to IT. I think we (as in, society) should make it possible for everyone to do whatever they want and a standards-driven (mostly) easy to understand programming model is a good way of providing that possibility for IT.
This is a common problem but it's certainly not the entire ecosystem.
Check Preact, Svelte, Mithril, Inferno, etc. Those are very lightweight alternatives to React, Angular, etc.
Also with SRR + hydration or SPA with code splitting you can achieve very lightweight apps.
I'm working on a Svelte SSR + hydration app right now and on each page I load about 5kB of JavaScript, some as low as 2kB. See this repo for an example on how to set this up with Rollup and a Node server: https://github.com/PierBover/svelte-ssr-example