Awesome collection! One thing I am always curious about, the right click and open in new tab does not work on the list items. I have seen this on many recent JS heavy web applications. Is this normal for PWAs to not support traditional browser interaction points?
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.
They could absolutely fix the URL thing. At least if they are using a routing library at all they can. Even if they arent they could very well manage routing as well.
You often have the dilemma whether something should be a link, or just a button. Links trigger a navigation to another page/URL, although in an "app" it could just render a new view rather then making a new browser request. A button is usually not a navigation, although it can render a new view and also have a unique URL. So the only difference is that you can right click and open in new tab on links, but not on buttons. And then you have to decide if you should style it like a button element or a:href element, where a:href signals to the user that they can right click and open in new tab, while a button does not. But you can also make an a:href look like a button, which can be considered an anti-pattern. Buttons do look nicer then links though. And buttons can also trigger a navigation, like in a form submit, but it's technically difficult to support submitting and open in new tab at the same time, because browsers have a hard separation between tabs, where one tab can't easily access another tab and vice versa. So while it's technically possible UX is often a matter of budget/laziness and stack/architecture.
There's not really much of a delimma. This is a problem that was solved in "single page apps" 10 years ago.
- links are for navigation
- buttons are for action
Styling and appearance are not a factor - you can make buttons look like links, links look like buttons.
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.
You're just making blanket assumptions about pretty hard UX problems.
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.
There is no dilemma. 99 times out of 100 the user is expecting a link (aka a browser history update) and a way to get back to that screen (an idempotent collection of data on that url).
That's actually a heuristic I often use to decide this dilemma: Would I want to open this in a new tab / copy the link? In terms of styling, I like to start both from zero so that a button "look" can easily be a link (like "learn more").
Yeah it's a trade-off and button links what this person would be experiencing.
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.
Yeah, another way of putting it is a link is great for GET requests while a button is better for POST requests (form submissions, AJAX, etc.) If you use a link for these, you have to think about what the href points to, you can’t just use JavaScript alone when it’s a link. If it’s a button, JS is more acceptable due to the inability to open new tabs, etc.
They would need to set the href attribute that points to the url on the card. After doing that you need to prevent the browser from actually going to that url when clicking on the card to prevent a full page refresh.
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.
When building webapps I like to keep a list of nit picks for ux and usability issues (usually things I find myself that aren't directly related to feature stories) and I fight to schedule as many passes as possible for fixing them. It tends to be difficult because no one besides artists and ux engineers will want to prioritize/pay-for them.
I will also sneak in a pass when I finish something that unexpectedly takes less points to finish.
In my personal experience, the real problem is when there's an impedance mismatch in the web platform. Here's an example. Let's say you have some tabulated data. So, being a good developer, you use a <table>. Done. Then, you want to make the rows clickable.
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.
In our in-house apps we went for the progressive-enhancement, almost-2 option.
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.
Interesting, and congratulations on launching the site! How do you plan on growing and generating demand?
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):
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.
PWA is definitely great for developers and users. But I often see users asking for native apps even when they're using PWA at hand. They say "It's more convenience to have app version".
I'd argue that many people wouldn't know wether they were looking at a PWA or a native application written in a JS container format (like react-native).
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.
They may not distinct visually, but iPhone user without chrome can definitely tell.
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.
I don't think it's necessarily convenience. PWAs are loved by developers but they kind of suck for usrs. Native apps should use less battery, memory, and cpu. On a desktop machine, that might not be a big deal, but it is on mobile.
> Native apps are loved by developers but they kind of suck for usrs.
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.
I remember your site!
I was planning on adding a service worker to my trivia game so I could eventually add it to your site but never got around to it!
Awesome idea! I would reccomend seeding this with the pwa version of very popular apps. If you want to grow this you’ll need to expand beyond people who know or even care what a pwa is. The easiest way is just to convert people from using an app they use now to using the pwa.
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.
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.
I am saying the drive for revenue and the programming model of the web have created an abuse vector for user experience. That's all. We know it's true because platforms that have grown dominant on the web (indexing it, for instance) have to build scores and filters as a layer to protect the user from this. AMP is another example of investing in the protection of users. If it hand't been tainted, the user experience wouldn't need this level of protection from it.
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.
Your icon has those stripes on it that you usually see in previews for stock icons. Are you sure you have permission to use it? (it appears to be from "Shopping Set 4" by 13ree)
I like the idea, but taking UX ideas from Android or iOS app stores leads only to frustration. For now there are only a couple of screens worth of apps, so it's not a problem.
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, what's up with so many websites being built in a way that makes "open in new tab"/middle click impossible?
This problem is exacerbated by the fact that clicking "back", either in the browser or in the webpage, doesn't remember your position in the previous page.
Is this due to whatever javascript UI framework was used?
People with limited mouse dexterity. People who hate mice. If you don't browse with the keyboard you don't see the focus state move anyway, so leave it on for people who need it.
I agree with both of you actually, app is great but I don't don't like Material when I see it usually unless it's skinned well enough to not instantly tell it's Material. Something about that default theme...
I have a hard time seeing how "gross" could describe the look of Material UI. Uninspired or unnatractive maybe, but gross?
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.
I hate to say it but this just demonstrates, all in one place, how far behind PWAs are from native apps. Does anyone have an example of a PWA (hosted here or elsewhere) that rivals the best apps seen in native app stores? I’m talking about beautiful animations, native-feeling navigation, and an overall immersive, cohesive experience?
Weird how I can't join pixelfed.social. I tried looking up how to register and the registration link is supposed to be there on the homepage according to their help center, but all I see is a login form
They might be at capacity and closed new signups for the moment. Being a federated network you can find a different instance, or set up your own if you want.
This being a federated network you should be able to follow and interact with users in other instances. That's what ActivityPub is about. I haven't checked Pixelfed specifically but it's how Mastodon works.
> I’m talking about beautiful animations, native-feeling navigation, and an overall immersive, cohesive experience?
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.
Yes, I think this example highlights a point many aren't picking up on. PWAs have been biggest in emerging markets. I think Ali Baba also used them to great effect.
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.
Old cheap android devices nearly always have no available storage space, which makes it almost impossible to install a native app. Freeing up 1MB of space isn't enough to allow you to install a 1MB app - typically you need to free up 1GB or more before the store will function at all, and there's a good chance on old devices that won't be possible at all, due to the way updates consume space, and old devices have a lot of updates...
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.
Does the native app also constantly fail to load tweets linked from Reddit? And then you click the "retry" button and it fails again? Cause that's my general Twitter website experience...
I don't use any anti tracking or ad blockers. I have the normal Reddit all and Twitter app on my pixel 3a and every time I click on a Twitter link it opens in an in app browser that can't log me in.
I think this is correct. My experience has been that when it's using a tracking url it fails (I Ad block and Tracker block) and I see the tracker url in the address bar, but when I click again, it just goes directly to the real URL; presumably some fallback Twitter put in to deal with people like myself :D
Just tried it, and the difference between Twitter native and Twitter PWA is night and day. The PWA has absolutely 0 polish. No animations, no transitions, nothing. The tab bar at the bottom misses hits if you tap quickly / right after the PWA opens. The pull-to-refresh doesn't use the native scroll physics. The search tab's tab bar horizontal scrolling can interfere / combine with the vertical scrolling, causing really funky interactions.
Does it browse twitter? Yes. Is it good? Well, maybe if all you ever uses are PWAs, this is considered "good."
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...
This is particularly true on iPads. Instagram has clearly decided it's not worth the engineering effort to adapt Instagram (a multi billion dollar asset) for iPad. No matter - add the PWA to your homescreen!
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.
Thank you! I did, but it didn't get much traction, since Show HNs can be a bit of a lottery! After a fairly slow start, we're doing quite well in the UK now (7 figure MRR after 3 years).
Checkout our product, Domestica. It's an offline capable PWA to help you manage tasks, budgeting, cooking, shopping, and more. You can even self host it.
Sorry to hear that, I'd really appreciate your feedback if you're willing to provide it (mikeatcandid.dev).
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.
Twitter is awful (slow, loses scrolling position all the time, breaks common functionality like copying URLs or opening in a new tab) but that's due to bad engineering and user-hostile design and not a flaw of PWAs.
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.
Twitter's criteria for using the Twitter website correctly is to be looking at ads. Seeing useful content in between the ads is a side-effect only necessary to keep you there so you can look at ads.
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.
>Most important thing for me is sandboxing, no abuse of the device's data and sensors. I hate how most native apps invade your privacy.
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.
I'm well aware of browser fingerprinting, I take my privacy seriously and do my best to protect it.
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.
>Biggest thing for me would be instant installs[...]
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?
Single codebase for multiple platforms, no app store approvals/revenue share required, openable via a link, works to the webs' strengths, etc. That sort of stuff. It has its own set of disadvantages too of course.
Hasn’t pretty much every Silicon Valley tech company that tried to use single-condensed Cross platform apps essentially come to the conclusion that they’re not worth it, or better than OS-specific codebases and proper separation of UI and logic?
Native is obviously better and always will be. Making cross platform apps is not worth it only if you can easily afford to go native. This is obviously not true for everyone.
>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?
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.
> 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?
Outside of HN's bubble, people do that all the time. Or at worst they will use PayPal or an equivalent to make payments.
It’s outside of the HN bubble that people are less trusting of random websites.
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.
> 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.
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.
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)
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?
Cross platform support is nice for users as well. I have a number of apps that I can't use on my desktop which is quite annoying. When I use a PWA I know that I can access it from whatever device I am on.
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
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 is no reason PWAs couldn't run as well as native in most cases. The issue is that there are orders of magnitude more developers and money behind native apps, and giant corporations making their access super simple through app stores. If we saw the same amount of resources going into PWAs, they would be as good.
>There is no reason PWAs couldn't run as well as native in most cases
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.
If you do not count the browser itself - a single web app has a very small memory footprint. For comparison you can have hundreds of web apps running at the same time - taking up less memory then one native app!
Then there are Electonr/nw.js apps that all come with their own browser, but PWA's will reuse and share the existing browser.
Which is why I said "most cases". It's a small percentage of apps that require maxing out a device's resources. I even mention elsewhere in this thread that they are not as performant as native. You can make vague statements about VM characteristics but in practice they won't have a real impact on most use cases.
Native application has level of access to OS features and computer peripherals that PWA can only dream of. Same about performance.
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.
No way are they more performant than native apps. Their big advantages are write once run anywhere, no vendor lock in, easier install, and more control, privacy and sandboxing since they are web apps.
I'm assuming they're talking about a standard SPA (or even a conventional full-page-reload web app), or React Native or Electron on the desktop or similar. In the former case, a PWA can use service workers and caching and so on to get better network performance. In the latter case, they can leverage a preexisting Chromium/other browser instance to get most of the advantages of "write once, run everywhere" without bundling a whole browser instance with your app. I can't wait for full PWA support in Firefox, especially on desktop!
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.
The whole idea of debating PWA and native apps is really old. I wish Google would just come out and say "we tried this idea, it wasn't the right one, we're sorry, PWAs are dead." Until this happens this idea will never die. Google is happy to kill good products but won't kill terrible ideas!
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.
Hard to say whether the down votes are because of my attitude or the true belief that PWAs are a viable alternative that should be weighed against native apps.
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 like websites more than apps for a couple of reasons:
- 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.
The motivation can come from privacy-conscious users as well. I use the Uber PWA (m.uber.com) instead of the app because I can control the permissions it has if it runs in the browser. While you can control permissions in the native app as well, they get switched back to their defaults each time an app update is installed.
This site doesn't use links so it is very frustrating to use. I was trying to middle click to open new tabs but it didn't work because they aren't <a> tags.
People underestimate the value in functionality and consistency that native interfaces provide.
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.
I don't know about many but I do something similar. I make all links open in the same tab. Then if I want another tab I can middle click. This way I can decide where links open, not the website owner.
And even more importantly, external content should always be a link instead of a button. If it's a button, you can't see where you are going which is a poor user experience and security issue. Other than that, neat idea.
Is there a simple way to charge for a monthly PWA subscription without coding a backend to handle the various subscription use cases and without providing a complicated UI to subscribers?
My understanding is that Stripe offers UI to sign up for a subscription, but then offers only an API for other subscription actions such as changing from monthly to yearly or cancelling. Someone have a link describing Stripe's comprehensive UI for subscriptions?
I did a similar thing back in 2012 :) but it was only for web games, which run without plugins. Authors of games submit the name of a game, the URL of the game, and the URL of a thumbnail (similar to a PWA manifest).
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/
I tried exactly the same thing and then left frustrated.
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.
It's possible that both the hosting[1] of apps and also inter-app communication[2] would be possible via IPFS.
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.
I don't see why it wouldn't be possible, there are already working websites on IPFS. I think we will see more as IPFS support in browsers increase. Opera launched native integration for IPFS weeks ago, hopefully Firefox and Chrome will follow at some point.
Let’s say I create a progressive web app. What are the options to monetize it? I see that this PWA store specifies that a progressive Web app is free. For the concept to go beyond hobbyists, shouldn’t we sell a different story, like one where indie developers can make a living by creating and selling their applications? Mobile app stores have a lot of issues but you can develop a sustainable business there.
I have multiple progressive web application that I’m currently working on and I’m struggling a bit with that point.
I think most PWAs are essentially front-end clients to a SaaS, so revenue typically comes from user subscriptions.
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
The most common business model is freemium, where you funnel users to become paying users of another product of yours, or users can upgrade to a more advanced paid version. Then there's ads. Asking for a payment upfront for a web app will be though. You might remember demos or shareware? Think like that, you give away a free demo, if the user likes it, they will pay for more.
There's one big problem though, if the freemium model doesn't work...
Hi, I've always loved these PWA stores. I just updated the https://offline-dino-game.firebaseapp.com/ PWA with the ability to save your highscore to localstorage! Took me long enough...
I love PWAs. I'd be really curious to know if anyone could point to some good examples of PWAs doing biometric authentication using facial recognition / fingerprint.
I don't actually know if it's possible using standard APIs that work on iPhone and Android
I have been wondering, since PWA are sandboxed and all, would it be possible to save a "snapshot" of it and be able to run it even if the original website/app went offline?
That is great to read this news online. We can not go anywhere now as COVID-19. So many people are surging dating game, especially apps, such as Tinder, Bumble, Yumi and Meetme.
No one has "won". The vast majority of phone apps are still written using native code and frameworks, and that will be the case for the foreseeable future.
PWA's aren't for developers with the time and resources to build native apps. It's for web developers who want to improve the mobile experience on their sites.
Thats pretty unsurprising seeing as Pale Moon is not on-par with the standards and actively trying to not keep up, but instead seem to focus on keep support with legacy tech Mozilla removed quite a while ago.
Also they actively disabled service workers, the very tech that enables PWAs in the first place
apple is lagging behind on PWA support but PWA's are definitely coming either way. the reason why apple is lagging on support is because it will take a significant hit on their app store revenues as PWA's remove having to go throw third parties such as apple
The funny thing is that Steve Jobs vision was that all apps would be web apps. Apple don't want to sell apps, they want to sell devices. And for people to buy devices there need to be great app's. The reason why they didn't go with web apps is that you wouldn't be able to utilize 100% of the hardware capabilities. But it seems to get harder and harder to do low level stuff on Apple devices, so maybe they will eventually get to something that is close to web apps... But if PWA's works on other devices too, I don't think Apple would want that.
This always gets spread around HN as some kind of conspiracy theory. The webkit team has implemented many of the features required for PWAs and has many more on their roadmap. In fact there is probably enough there already for PWAs to compete with some classes of native apps.
Well if the PWA experience is good enough then some developers aren't going to list their apps in the app store at all so they can bypass Apple's revenue cut. PWAs also have less access in general and so are more secure/sandboxed.
Most of the revenue made from app stores come from pay to win games (which need native performance) or subscriptions that work across platforms. Many major players that use subscription prices have abandoned Apple’s subscription payments.
Second issue, what are the chances that I would trust some random website with my credit card information?
^ exactly and when there are big benefits to developers like that and the technology is focused on more, the maturity of what it will become is what really excites me
All true except reduced resource consumption, I don't believe that's an universal truth. Some native apps drain a lot of battery because they do more than they should, like the Facebook app spying on you on every conceivable way (and probably also in some inconceivable ones).
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.
Whatever JS a page loads it cannot steal all my contacts, browse my filesystem or track my location without me giving permission, so I consider web apps much better than native apps privacy-wise.
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.
This is further regression from UI consistency, with no supervision, now on Desktop. Every javascript developer has their own way of doing UI, often a hodgepodge of framework libraries mashed up to make it work.
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.
> Yes, it was painful to develop applications using native UI elements but those apps provide a fantastic, consistent UI experience.
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.
> Yes, it was painful to develop applications using native UI
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.
I think the issue is the following: In the 90s there was exactly two vendors with reasonable user base and design philosophies (Microsoft and Apple). And even they had a similar behavior.
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.
> In addition, the entire Javascript ecosystem is rotten
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
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.