The web stack (html/css/js/http) is one of the most impressive feats of invention by humanity. We have this one stack and toolkit that run on everything from a desktop computer down to a cheap (as little as 100$) mobile phone. It's free with no payments for access or deployment, and at the bottom end basic enough that a child can pick it up. But capable of building incredible professional experiences (see Figma or onShape, seriously they are incredible).
As a sole developer I can build something with a single code base for mobile (both web and installable), and desktop (again both web and installable). The breadth of tooling available is incredible.
The OP is about PWAbuilder, there are alternatives. I like the combination of Capacitor (from the Ionic Framework team) and Native Script. It lets you extent your installable version of the app with additional native capability, all while staying mostly in a JS environment.
The complaints about PWA being poor are, in my view, two fold. One, the support for them on iOS has be atrocious until recently, but also there are a lot of poorly written webapps. That is actually a testament to the accessibility of the platform. Look past that and you see what it is truly capable of.
We need to stop this silly gate keeping, it's frankly ridiculous.
Edit: since I started writing the negative posts have them voted down the page. Looking more positive now.
Edit 2: While I have your attention, if you care about PWAs and consumer choice of web engines on mobile, go support the OWA (Open Web Advocacy - https://open-web-advocacy.org/donate/). They are there to represent us and push for move choice and support. They are turning up and presenting the evidence needed to ensure the large players open up their platforms.
I think the negativity is well deserved because if it doesn't need device integration it doesn't need to be an app.
The device integration criterion includes achieving a full performance(be it for the UI immersiveness or processing speed).
PWA don't tick any of these, they are just an output of the dream to have universal codebase. This is a dream I share but it doesn't need to be an app in the App Store.
The only reason people make apps that don't need to be apps is to get another marketing channel through App Store distribution and another user reach channel through notifications.
> The only reason people make apps that don't need to be apps is to get another marketing channel through App Store distribution and another user reach channel through notifications.
I wrote a longer response but decided to scrap it. The behaviors and expectations are different than you might expect from a pure engineering POV. Its not just sales and marketing. For better or worse, people want to interact with companies' apps on their phone via installing something "trusted" through their appropriate app store. Not responsive mobile web, not even PWAs (which are difficult for people who are not tech savvy).
At my most recent exited startup, we had a web app which was mobile responsive. People asked for a mobile app. We gave them a mobile app that was simply a webview that loaded the web app. Customers loved it. We got almost no inbound from it at all for various reasons, but existing user satisfaction, engagement, etc went through the roof. They could finally "use our app on mobile" even though they always could, and we consistently pointed them to the mobile web experience to do so. This is a market full of people who are average to below average levels of tech savviness.
Notifications alone are a legitimate use case that isn't always spammy growth hacking BS. It would be great if the notification story was better with PWA, but it just isn't on Apple and even on Android the well has been poisoned enough that no one is turning on browser notifications even if they legitimately want to be updated.
We're considering building an app pretty much solely due to notifications, because our only option currently is e-mail and deliverability while good can never be perfect.
AFAIK the web push notifications are already implemented with iOS 16.4
They just have to convince the user to add their PWA to the phone home screen. I guess the issue is that users hate being instructed to "install" "apps" which don't need installation to function.
This is the best part of PWA. Each user can do what they want.
You just want to use it on the web? Just so that. You get the full experience because there is no resource split between the web site and native apps.
You want to find the app in your favourite app store? It's there. Just install it.
You like the web version but want to add a shortcut to your app list? You can do that and there is enough metadata available to provide nice icons and titles.
But owners of these properties do not want users to have that choice, they want users in a mobile app where they can collect more telemetry and spam notifications to get engagement. There’s a reason Reddit aggressively pushes you away from their mobile site.
With Reddit specifically, I think they at least have one legitimate reason in addition to the normal nefarious ones. Their new web interface is incredibly slow, especially as you continue browsing over time. On phones, that's likely to cause more serious performance issues than it does on desktop devices.
> You get the full experience because there is no resource split between the web site and native apps.
It won't be a "full experience". It's amazing to me that people are talking about GUI apps and keep pretending that GUI-wise the web is anywhere on the same level as anything native. I wonder why the https://open-ui.org effort exists if that is the case (because it isn't, of course).
> Half the apps you use on mobile are augmented webviews.
And those almost invariably suck. A few try and invest in smooth-enough experience because customer retention affects their bottom line (e.g. Foodora is a suprisingly nice app), but those are not enough to say "You get the full experience".
There's no question that these are beneficial to devs, but as a dev, I object to the notion that benfiting devs at the expense of users is a goof thing.
Expense of users? How so? If a PWA is not a fair transparent experience, then I would definitely opt for a more native app, but otherwise I don't think they'll care so long as your website is usable on mobile.
HN loves React Native and Flutter but Ionic and Capacitor are really great.
I bootstrapped a Ionic project the other day and had something running right after without knowing anything about it some hours before, compiling as a pwa and native apps using their respective toolchain.
It felt like I was replacing Bootstrap components with Ionic's and was able to transfer all my Vue knowledge.
Also the docs are great nowadays, way less Angular centric than before.
Actually... ReactNative is pretty novel idea TBH but developer experience (DX) is not as smooth IMHO and that's what you use such frameworks in the first place.
Flutter's overall DX experience is so incredible that it is in its own league. But the ecosystem is still pretty limited, there are performance issues as well.
Web (HTML, CSS, JS) has been so optimised over the past two decades and it has such a HUGE ecosystem and libraries that it becomes almost unavoidable choice if coupled with Capacitor et.el.
Imagine d3.js or some of the amazing visualisation libraries. Hard to get the same deal on ReactNative or Flutter with same breadth and robustness.
Regarding Flutters performance issues, they are switching engine from Skia to something called Impeller.
You can already switch to it by adding this flag, "--enable-impeller".
It's waaay smoother and worth giving a shot, their demo on YT is highly suggested.
I was also pleasantly surprised by Ionic. I found it easy to use, quick to set up and performing well. Perfect I think for small to medium sized web-apps!
PWABuilder is glorious. As a 1-man shop I certainly don't have time to develop 3+ versions of my app, but clients keep demanding mobile apps even though it's literally the same thing. The webapp runs great on a phone. Please... just bookmark it to your homescreen, it's fine.
OK, perhaps we need to step back from discussing their capabilities and flaws in a technical sense, but we seriously do need to discuss the capabilities of the average user and how allowing PWAs to bypass the app store review process is likely to be harmful to them.
If any random webpage can get them to install something which has access to things like notification apis, location etc, we're in for a world (more) privacy invasions, scams and just people whose phones become unusable, beeping, message-laden messes.
Yes, there are problems with the app store model, but lets not pretend just bypassing it without a further thought about the impact is a great plan.
(And yes, I am aware this article is about a tool for including PWAs in app stores. This is great, if you want to do that, go for it!)
> we seriously do need to discuss the capabilities of the average user and how allowing PWAs to bypass the app store review process is likely to be harmful to them
We have at least two kinds of users. One is the non-technical user you are talking about. The other is a braver, more independent, and maybe even technically literate user who at least reads the prompts before granting requested permissions. One group of users wants the comfort of knowing that a big tech company is keeping them safe by keeping a close eye on the place where they get their apps from. The other group of users wants to enjoy the new project Fugu apis available on Chromium-based browsers.
Why is the first group of users attended to, and the second one ignored? Why not allow two app stores — one, installed by default and guarded and taxed by Apple, and the other for the projects that want to take a different route — and let the user choose?
> The other group of users wants to enjoy the new project Fugu apis available on Chromium-based browsers.
But it's not users, it's developers.
Specifically below we have people saying that as a developer they don't want to have to jump through hoops, nor pay the tax. And as a developer I can empathise.
But as a tech savvy user I don't actually have anything that makes me desire PWAs. There's no driver there for me, I don't care about the new project fugu apis available on Chromium-based browsers, I can probably get a native app that does the thing I want, it's developers that care about that stuff. Stuff they could already do if they weren't trying to bypass the app store infrastructure.
So even among tech savvy users, the number of users who care about installing from outside of the app store ecosystem is not 100%.
> Why is the first group of users attended to, and the second one ignored?
Group 1 is a lot larger, they are the mainstream audience and the tech-savvy-but-doesn't-care-specifically-for-PWAs audience. Not only are they the people that the device vendors want to target, they are the people that the nefarious would-be PWA writers want to target too.
> and let the user choose?
"Press this button, this button and this button to get the free shiny! Don't worry about those silly warnings, they just don't want you having any fun!"
"Hi, is this Apple? My phone is an unusable pile of shite and somehow all my money is gone"
> But as a tech savvy user I don't actually have anything that makes me desire PWAs.
Storage space? The knowledge that the app you installed runs inside a browser sandbox, with certain safety guarantees (I've never quite learnt what they are; but apparently they exist).
Personally, I would be much happier installing PWAs than native apps. I know PWAs are effectively just websites. I know what to expect from websites. I know I can remove them cleanly if I want to. I have no idea what to expect from native apps.
> "Press this button, this button and this button to get the free shiny! Don't worry about those silly warnings, they just don't want you having any fun!" – "Hi, is this Apple? My phone is an unusable pile of shite and somehow all my money is gone"
Is this a problem on Android or on Windows? Do people besiege Google (or Samsung, or Microsoft) complaining that their devices have become unusable and that their money has evaporated because they have installed something on their device? Is this, ultimately, Apple's problem (you can still install things on a Mac bypassing the app store)?
> Storage space? The knowledge that the app you installed runs inside a browser sandbox, with certain safety guarantees (I've never quite learnt what they are; but apparently they exist).
> Personally, I would be much happier installing PWAs than native apps. I know PWAs are effectively just websites. I know what to expect from websites. I know I can remove them cleanly if I want to. I have no idea what to expect from native apps.
I mean… yes? It is an issue on windows, though it’s not necessarily MS they phone when someone’s got them to install something evil on there. And yes, it’s an issue on PCs that people end up overloaded with alerts and crap.
People do indeed buy tablets because they’re easier and safer, particularly for older, less savvy relatives or kids.
Undermining that is likely to hurt the market.
As for the other - I know what to expect from a native app, mobile platforms particularly have similar guarantees and expectations, and I know someone else has had eyes on it. Those guarantees you’re talking about aren’t necessarily very meaningful in the face of social engineering - a PWA may not be able to take over your device but they could still be great avenues for phishing attacks etc.
I totally understand why developers love PWAs. As a user, though, I very much dislike them and won't use them. Neither of us are wrong, we're both choosing the most appropriate tools for our use cases.
> The web stack (html/css/js/http) is one of the most impressive feats of invention by humanity.
Yes and no.
The "no" part comes from people trying to twist a system designed for displaying static text into an application platform. And as an application platform it sucks. It's one of the most inefficient, slow, resource hungry app platforms that humanity has ever devised.
As a free somewhat open cross-platform means for information exchange, it really is unparalled.
>It's one of the most inefficient, slow, resource hungry app platforms that humanity has ever devised.
Is it? JavaScript interpreters are crazy fast, almost comparable to compiled languages. The layout engines are powerful and efficient. They support extremely-optimized networking protocols and media formats.
It's not (currently) a great platform for high-poly 3D rendering and such, but who knows what the future holds with wasm and WebGPU.
Browsers do use a lot of memory, but so did Java, Flash, Shockwave, Silverlight, etc.
It is. None of what you write is either fast or efficient. Especially not the layout engine that does a re-layout and a re-paint as soon as you look at it sideways
I always say when people talk about efficiency: There's a reason you can't animate height: auto or a list item efficiently without hacks. As is the reason why opacity changes are outright banned on lower-end devices like TVs.
A large part of the issue is the modern Javascript ecosystem too. The browser isn't the most efficient way to build apps, sure, but using a virtual DOM adds a whole extra layer of performance issues.
The "no" part comes from people trying to twist a system designed for displaying static text into an application platform.
The original web memo by Tim Berners-Lee defined "a document" as text only content that could be displayed on a 240x80 character display. Images were defined as an optional extra few people would be able to access. I'm going to guess you want a web that does a bit more than that.
In which case.. Tim Berners-Lee's memo suggests "Live Links". His proposal was that the web should have "documents" that are generated per request aka serverside rendering. He went further and suggested "If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide." To me that sounds a lot like a clientside app. At the time (1989) I imagine he meant that a link in a page would execute a local app, but it turns out we just found a different (better?) approach.
It does provide a cross-platform application development stack with easy to use networking and deployment capabilities while being sandboxed and requiring little to no admin on the user terminal.
There was no real equivalent to this before. In corporate environments, this was often the Java stack that was used and it was often a really painful experience.
PWAs are the same for Mobile, the current experience of developing mobile apps using the native SDKs is really subpar and it is expensive.
PWAs will become the default for mobile apps because, in most cases, there's no reason to go through the pain and cost of creating native mobile apps.
> PWAs will become the default for mobile apps because, in most cases, there's no reason to go through the pain and cost of creating native mobile apps.
Unless you need, you know, actual performance, fast animations or even things like proper controls which the web has none of.
It _sucks_ compared to some other non existent platform. The adoption both by users and developers seems to indicate it is the best thing we have produced for this so far.
> It _sucks_ compared to some other non existent platform.
Those platforms exist: desktop and mobile. People are so enamoured with the web and/or have no experience outside the web, and so don't know how insanely more performant almost literally everything outside the web is.
Sorry, but no. You‘re wrong. „Desktop“ isn‘t a platform, it‘s a loose term for native applications running directly on your OS. „Desktop“ is extremely fragmented: Windows, MacOS, Linux. The latter is fragmented as well.
I will gladly take every disadvantage of the web to deliver my products to every platform. The alternative is not shipping to MacOS and Linux systems.
With that attitude you get Microsoft officially advertising their new Teams version that takes 9 seconds to show less than 1kb of text (3 seconds just to show the splashscreen).
Yes, we are running what essentially amounts to supercomputers. Why is it then that Slack still requires 20% CPU to show an animated emoji? Or that Matrix spikes to 60% CPU when scrolling through a largely empty channel? Or...
Figma is anything but incredible. I have one Figma file that I always open. Every day or every couple of days. Every single time it loads up ~100 MB of God-knows-what and takes ~20 s before showing anything useful to me. Not to mention the added loading time if you don't have Chrome open.
So no, it is not "incredible". It is the slowest app I use. Doesn't put much confidence into me regarding the entire PWA system.
Figma is incredible for what they managed to achieve: "Pulling this off was really hard; we’ve basically ended up building a browser inside a browser." [1]
But yeah. I wish people stopped waving Figma and VSCode around as shining examples of web tech. They are two outlier built at incredible expense and effort.
> The point is the web is capable of these things, sometime with a large team sometime with a tiny one.
The thing is... when you say "the web is capable", keep in mind that it's always one or two of the following:
- it's an insane effort to get something working (VS Code, Figma)
- it's not using web tech, not really, but desktop tech that is usually 5-10 years behind the actual desktop tech (WebGL in Figma and Photopea, Canvas in Google Docs)
And even there it's still multiple unresolved issues like font rendering, accessibility and a plethora of others.
Edit: Speaking of Photopea: I'm always in awe of people who can not only build a complex app, but also build an entire library of controls and a design system, too. Because the web's controls are is just so, so, so poor.
Photopea is a great project and it's nice that we can build things like that, especially with tools that are familiar across a wide variety of use cases (as opposed to having to know OpenJFX, WPF/WinUI and who knows what else).
But compared to native software, there will always be a certain overhead to contend with, which may or may not be an issue: for many, it will be easy to just hand wave away the idea of needing to support netbooks with something like 4 GB of RAM, or many older machines, due to personally having better hardware.
First, I checked the memory usage of both programs without the image open:
Photopea 304 MB
GIMP 110 MB
Then, I opened the image, without doing anything else just yet:
Photopea 1004 MB
GIMP 396 MB
Afterwards, I did a bit of drawing with the brushes for a few seconds, later undoing my changes:
Photopea 1340 MB
GIMP 474 MB
While my current computer is fairly good and I saw no slowdowns, it's fairly easy to imagine that the memory usage alone would present a bit of a problem on my netbook, I couldn't open 3 images like that without running out of memory. Whether this matters for most folks is debatable because the popular stance is to just buy more RAM (on the devices where it's possible to upgrade it, all others becoming e-waste), but there's definitely an argument to be made about the nice efficiency of native software as well.
Otherwise we'll end up in a point where it won't be possible to reasonably open 10 IDE instances at once, or run all of your Electron based software in parallel (e.g. some editors, Postman for API testing, Discord/Slack for chatting, Figma for mockups, Lens for Kubernetes or whatever else people are using, possibly even Terminals built on web tech eventually).
> compared to native software, there will always be a certain overhead
And if the native software is a bloated monstrosity? Naggy, cloud-syncing, process-spamming, privacy-invading, background-lurking garbage? Don't give native apps a pass for being native.
I ditched all google software from my PC after it acted like malware, re-installing itself after I removed it several times. And doing bizarre things like scanning my drive with a "software reporting tool" which thrashed the hell out of my drive. That's the only reason I found it because my hard drive was mechanical and wouldn't stop grinding.
> And if the native software is a bloated monstrosity? Naggy, cloud-syncing, process-spamming, privacy-invading, background-lurking garbage? Don't give native apps a pass for being native.
Then those pieces of software probably should be excluded from your candidates for what to run on your machine.
For example, GIMP, LibreOffice, VLC, Blender, Audacity, Kdenlive, XnView MP, OBS, PeaZip, Thunderbird and others have very little in the way of the issues you've mentioned.
That's not to say that they'll always be the most capable options out there, but for most folks they'll be entirely sufficient.
> I couldn't open 3 images like that without running out of memory.
This isn't a great comparison because you're counting the fixed overhead of the browser as well. If you have three tabs open with other images, it won't take 3x the memory.
Personally, I virtually always have a Chrome instance running on my desktop, so the overhead is incurred either way.
In Electron there is fixed overhead for running Chromium for each program, but it's a stripped-down instance without all the bells-and-whistles of a browser, so it's not as high as it would be for a full browser.
> This isn't a great comparison because you're counting the fixed overhead of the browser as well. If you have three tabs open with other images, it won't take 3x the memory.
This is a good point, my bad. Most people would open multiple images in the same piece of software (though it seemed like more memory was used in comparison to GIMP anyways). A more realistic take on my part would be running X different pieces of Electron based software, which would use Y% more memory than native alternatives.
That's not to say that there can't be good and comparatively efficient software like that out there, Visual Studio Code is a good example of something that actually performs pretty well! But that's mostly because of the huge amount of engineering that MS put into it, most other similar approaches like Brackets or Atom were plagued by sluggishness.
I don't, just failed to mention it along with WebGL/WebGPU, Canvas 2d, and the "origin privet file system" api. These are all providing an escape hatch to a lower level when the higher level abstractions are not performant enough.
There will always be developers who don't understand that their time is their most valueable resource. They'll just waste hours on reinventing the wheel for every app they create just to save a KB of precious RAM.
While this is nice, to me the whole promise of PWA is that developers can escape confusing App Store rules, long approval process, and the absurd 30% commissions.
So no, thank you. I don’t want back into the App Store.
The other purpose is discoverability. I doubt many people know that to install a PWA, you press the "share" button (lol) and then "add to home screen." But yes I have a few personal projects I've deliberately not put on any app stores.
Even very few tech people know this, let alone the general consumer. There is also not much incentive for apple or google to market this functionality further.
> the whole promise of PWA is that developers can escape confusing App Store rules, long approval process
As a consumer, and perhaps more importantly as someone who is frequently unofficial tech support for other consumers, this is why I don't want PWA support or PWAs in generally getting any foothold on devices.
The number of notifications, icons, noises, ads, disturbances and general bullshit that an average user already has to put up with on a device is absurd. Can they be careful about what they install? In theory. Can they configure and down-regulate all these notifications? In theory. But they don't, and they won't.
Having something that appears to be able to bypass app store review is a developer wet dream but a user nightmare. Because they'll go to a website and press the buttons it tells them to, and now instead of it just being spammy bullshit that did pass the app store filter, it might be absolutely anything.
You might have honest intentions, but thousands won't, and users demonstrably can't handle it.
In my opinion PWAs don't need to be in app stores, but they need a MUCH better UX in all modern browsers - For example, I have installed the Spotify PWA in my Linux machine. I get a nice Spotify icon in my favourites toolbar and a great native-like user experience when I open it. I consider it completely separate app to (for example) Chrome browser which I have open at the same time. But if I weren't involved with web technologies day-to-day, I wouldn't have a clue that it was possible because my browser gives almost zero hints.
Actually they are just regular websites and I guess most developers who created them never consider their website PWA. Many of those "PWA" websites were built before PWA term was invented.
They work very well in my opinion. Minimal UI and they are always up to date. I do not have to download or login to any app store to use them.
For average user finding this "Install this site as an app" button is a real UX issue.
While this says "repackaged website", it's much less about the technology used to develop the app and more about the actual content of the app - it's just as easy to make a native app that violates this clause.
It shouldn't be too much of a problem, seeing as most music players, stock apps, and calculators could just as well be simple HTML pages.
I think this rule is supposed to guard against things like packaging amazon.com into an app wrapper rather than developing a mobile-first offline-capable web app. Actual PWAs should be fine.
If you use tools like this you run a high risk of having your app banned.
Google Play strongly enforce their policy about how an app cannot be something that duplicates the functionality of a website.
Example:
Years ago I wrote a simple html/js app, and published it to the Google Play store using Cordova. It was a completely self contained app and did not access the internet (although it required internet permissions to use the webview). After publishing the app, I reused much of that code and release the app as a simple website.
Google Play deleted my app because purely because the app had a similar version on a website - even the styles were slightly different between them! The reviewer ignored of my explanations and refused to reinstate my app, even after I deleted the web-version of the app.
This was a 5 star app with only positive reviews!
If I got my app deleted because it smelt like it might be a webview wrapper of a PWA, using a service that is a PWA wrapper sounds like the most risky thing ever!
That's all well and good, but my app got deleted because they told me an app cannot be a webview of a website.
When I raised an appeal, and proved to them how it was a self contained app, they told me an app cannot be a webview of a website.
When I deleted the website they told me that my app was just a webview of (which it wasn't), and then reappealed, they told me an app cannot be a webview of a website, and deleted my app.
So, the lesson here is: Submitting an app that renders using a webview is a gamble and that Google reviewers don't actually review your app.
The biggest issue to be addressed is monetization IMO. Without monetization there won't be much adoption and without much adoption there won't be much support.
First of all, there is no good guidance about the topic besides some clips about the Digital Goods API and it only works for recent Chrome. How do deal with users that use a different browser or an older version? Is it ok to check if the API is available and if not use Stripe? No info about that... It can be pulled off, but UX will definitely be bad or worse.
Then, there is the problem with complex backend logic and accounting, I have to deal with two scenarios, did the person use Play Billing or Stripe to purchase? What if he used Play Billing and then wants to manage their subscription in the browser or other way around? It would be amazing if either Play Billing could also handle purchases on the web, or if Stripe could detect TWAs and automatically send 15-30% to Google for doing nothing.
Also, what about testing? How can I test my Digital Goods integration if it is only available within an Android app and not in my PWA? Am I supposed to publish an app that points to my dev server?
If Google was really serious about PWAs and Trusted Web Activities I think they should allow developers to use 3rd party payment systems (in TWAs only) until all of the issues are resolved and have solutions, instead of being like "ya we don't know either, you figure it out, but you can't use Stripe". As TWAs are only a miniscule fraction of TWAs in the PlayStore it won't even make a hint of a dent into Google's revenue, but it would allow developers to seriously pursue a PWA solution over a native one and therefore allow Google to see if it is viable and worth putting serious resources into.
Oh really? That's so annoying! I had the issue in the past, it's related to the the mail server from Gandi I suppose. There are no emails sent from this email besides the email confirm, welcome emails, and manual replies to customer requests. Could you mark it as "not spam", that would be very kind.
disclaimer 'iOS does not support PWAs natively and packaging PWAs for iOS is Experimental. We can not guarantee that your app will be accepted into Apple’s App Store.' - i also doubt the PWA push notifications on iOS would work on a webview.
otherwise, very cool however the app store market monopoly is a joke. So are most of the user ratings on such stores. The beauty of PWA's is that there is no appstore or an over looking body - the internet is free!
1. They didn't. Because ask three people, and they will give you five answers on what exactly PWA support means (every time it's a different set of random APIs)
2. There's Android that holds 70% of world's market share and none of the imagined "killing" that Apple does. Unsurprisingly, there's still not a single mind-bending paradigm-shifting PWA that would show the world just how great PWAs is and just how exactly "Apple is killing PWAs"
Maybe unpopular opinion but PWAs generally just suck compared to their native counterparts. There's always something perceptibly 'wrong' that makes them an inferior user experience, even if only marginally so. I worked on PWAs for a while and users complained endlessly even if they can't articulate exactly why.
Technologists are enticed by the cost and development time savings of PWAs over native, but users resent the diminished user experience that almost always comes with it and repay you with poor ratings/reviews.
Something perceptibly 'wrong': probably the buttons and stuff being different from the native versions. Users can't tell the difference between a React Native app vs pure native one, though.
> But Apple and Google don’t exactly have a huge incentive to do that.
Google is literally the main company behind PWA push. Android doesn't have any of the perceived or real limitations that iOS has. Well, where are these non-sucky PWAs?
I am not the biggest fan of VS Code but it has a lot of fans.
That aside, focusing on the main topic, and now I am answering more seriously.
You claimed PWA that do not suck are a fantasy. My point is it is not such a crazy thought. It is very possible. Now that Apple wants to appear less monopolistic (probably because of Epic court case) they are finally giving more permissions to PWAs.
On top of that the founder of the company expressed this same vision.
Both things, together, make me think that it is not such a fantasy.
I do not have a killer PWA app to share with you, unfortunately, unless you want to check my amazing PWA ios calculator clone https://getcalculator.app/ :) The ipad does not have a calculator.
You claimed it was a fantasy. I disagree. I think you will only accept it is not a fantasy if I show you an amazing PWA. I am happy to accept it is not a fantasy if it is possible (Epic app store court case makes it possible IMO).
To me, a fantasy is something impossible, not only something that does not exist.
We will have to agree to disagree.
PWAs and apps are practically the same. You have some code. It turns into bytecode. It runs on a machine (bare metal or virtual machine).
The only difference is the APIs it has access to.
The reason why PWAs suck is that it has access to some pretty basic APIs.
Who controls the APIs? Apple and Google.
They’re the only people that can make a PWA nice. However, you constantly hear about efforts to make PWAs nice from people other than Apple and Google but these people aren’t in control of anything and honestly don’t matter.
Now Google may have been behind PWAs but from what I see, it’s been mostly to make web apps work better in browsers — apps like Gmail. But they’re not that invested in replacing apps with PWAs because if they were, you’d see them dogfooding their own apps as PWAs. However, they’re not.
So really, neither Apple or Google are invested in replacing apps with PWAs and until the dominant platforms want to, it will never happen.
“This time we can make an app based on web technologies for real!”
- it failed when Palm tried it
- it failed when Microsoft tried it
- it failed when RIM tried it
- the “sweet solution” that Steve Jobs called web apps when the iPhone was introduced was called a “shit sandwich” by potential developers who wanted native apps.
On another note, in the history of computing, all cross platform GUI apps have always sucked.
> “This time we can make an app based on web technologies for real!”
> - it failed when Microsoft tried it
VS Code is one of the most successful open source cross platform GUI apps of all time. Who would have thought that good ol' HTML would finally fulfill the promise of "build once, run everywhere".
VS Code is a great success of Electron-based apps but also has massive memory usage and performance bloat that comes with this style of app, see https://news.ycombinator.com/item?id=19144039
Sublime Text is implemented natively (C++) and uses a fraction of the resources to accomplish similar functionality. I know we live in a period of plentiful system resources where RAM usage no longer practically matters, but using 1.5GB RAM for a few files open seems insane, even more so that this is now normalized.
> Sublime Text is implemented natively (C++) and uses a fraction of the resources to accomplish similar functionality.
If VS Code is slower than sublime with the same level of functionality, why does it currently totally dominate the market? Is it because devs just love Microsoft?
VS Code has a quasi-IDE implemented for a bunch of popular languages including a debugger [1]. Sublime is a straight text editor, with limited debugging capability. Sheer usefulness beats performance, so VS Code won the editor war.
Sublime Text is an independent product from a small developer; VS Code is actively pushed and marketed by Microsoft, one of the biggest, best-known companies in the world.
That may or may not be the primary reason for the difference, but I don't think it can be ignored.
> If VS Code is slower than sublime with the same level of functionality, why does it currently totally dominate the market? Is it because devs just love Microsoft?
Because it only has the same level of functionality when you conveniently ignore how easier it is to write plugins
Sublime Text and VS Code are pretty different, despite looking superficially simmilar. VS Code gets much further along the path to being a full IDE (albeit not completely), where Sublime is more of a pure text editor.
At what cost? VS Code is a trillion dollar company throwing thousands of man-years at the problem and still running into issues like "we can't make the terminal fast enough because of web tech": https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
It is free! Free as in free beer. So all those trillions are going to very good use, considering it is the most used editor. And its open source too!! What a web tech success story this one...
> and still running into issues like "we can't make the terminal fast enough
Imagine that! A cross-platform code editor with its own configurable integrated terminal that hooks into the apps extension system. But someone wrote a blog post in 2017 explaining some performance improvements, so bring out the pitch-forks and burn it all down!
Yes. Not all discourse has to be literal. It's called a a metaphor. And your "trillion dollar company throwing thousands of man-years" is called a hyperbole. You are talking about the most successful cross platform code editor of all time, so if you want to be taken seriously, use level-headed arguments rather than emotional exaggerations.
> but at this point it's clear you're not interested in discussion beyond low-level trolling.
> Adieu
I wouldn't consider a discussion where someone cites a 6 year old blog post about performance improvements as proof of "throwing thousands of man years" as a serious, or worthwhile discussion. You can go. Don't let the door hit you on the way out.
None of those companies are known for UX. Palm and RIM were so behind in the field to begin with — they needed to catch up before they even thought about reinventing web apps.
As another example, if Google were to say tomorrow that they would release a high performance database, I’d believe it. If they were to say they are going to release an original social media platform, I would laugh.
I remember you from the other thread about Safari where you were claiming there are no problems whatsoever, so I'm not surprised you're pushing the same agenda here. Regardless what people reply to that question at least agree that when support is missing Safari will be the common denominator. For me, it's not even about APIs. My game gets like 1 FPS on Safari iOS and I'm not using any non-standard features.
> where you were claiming there are no problems whatsoever
Of course I was claiming no such thing
> Regardless what people reply to that question at least agree that when support is missing Safari will be the common denominator
No, you cannot disregard what people reply. Because the common denominator is just whining as people are complaining about random things. And when Safari adds another random API that random people randomly whine about, they immediately switch to whining about some other random API that apparently PWAs can't live without.
So what exactly are you asking for here? A list of PWA api's that must be used all the time in every single PWA app? What's the benefit of that? Which application development API has such an asinine requirement in the first place?
> Because of this you will always have people scream "Apple is killing PWAs" because they don't support a yet another random API.
I like the "yet another random API" phrase. It creates the impression that PWA APIs are being generated fast and furious, and apple is trying very hard to keep up with all these "random" new APIs.
Yet, the reality is that apple has for a long time deliberately crippled PWAs on their platform by not supporting just 4, crucial, old and fundamental APIs. I will list these for you:
- Background Sync
- Web Push
- Before Install Prompt and Installation Banner
- Background audio for PWAs
They do not have to implement any "yet another random API". Just those four. Everything else is a bonus, considering this is Apple's Safari (the new IE) we are talking about.
Imagine going 2000 years back with a book and showing it to some caveman. To you they are words, with meaning and purpose. To him, they're just random gibberish scrawled on some leafy stuff. He might even nibble on one of the pages and declare "it doesn't even taste good, what can be its use?"
Imagine having a discourse in good faith. Imagine not resorting to false analogies. Imagine not resorting to low-effort trolling the moment you run out of arguments. Imagine...
Anyway. I bid you adieu in a sibling thread, I'll do the same here.
haha. Seriously though, do you honestly believe that is what you are doing here? You think you are acting in good faith?
> Anyway. I bid you adieu in a sibling thread, I'll do the same here.
> Adieu.
You cannot even keep track of all your "adieus". Are you saying goodbye to a thread, or to an individual? Or is it all just random. lol
FYI: I do not respond to individuals. I respond to comments. Usually asinine comments because they trigger me. So the best way to say goodbye to me, is to think before you post.
Apple took a very long time to implement HTML5 standards in safari. I think it was 1-2years ago when i found a bug in their indexDb.get call.
been deploying native apps cross compiled from c# with PWA interfaces to app stores for years, so they are possible, u just got to work within the guidelines.
> Apple took a very long time to implement HTML5 standards in safari.
Make sure you don't confuse HTML5 and Chrome-only non-standards.
The former is implemented by Safari to a much larger degree than people would have you believe. The latter they have no intention of implementing even if people pretend they are standards.
If you use standard web push, you shouldn't even need to update your apps. All you need to do is convince your users to install the app to their home screen.
If it's the same thing I did with Android/Play store, it wraps the PWA into an app for submission to the store and deployment to the device, but that's all.
PWABuilder solves nothing. Technology is never the problem, it is the utterly incomprehensible bureaucracy of Google, Meta but especially Apple and Microsoft.
One is supposed to become a Microsoft partner (1000 pages of incoherent BS) or buy Apple hardware. That is the real problem.
Regular reminder that "web apps" are just apps written for the very opinionated and limited stack. In this stack instead of proper UI framework developers left with typesetting engine (HTML), weird set of global styling variables (CSS) and half-baked scripting language with no philosophy (JS). All this lavishly peppered with tons of layers of abstractions and hacks on top to make it more or less usable for modern UIs. Complexity of these layers is borderline insane, and more and more hacks are being added every year. On top of this, as a result of wild nature of non-existent distribution process on web, the app runs in a limited sandbox. That's also a reason why not just usability, but security and performance of web apps are so much worse than native apps.
We are in the process of converting our native apps (+10m daily users) to javascript apps. We did some extensive testing last year and our conclusion is that the current hardware (also 3 year old devices) are powerful enough to run these apps.
User experience is identical in the way we build them. Full client side rendering it means.
We find the eco system of mainly Android extremely bloated and complex. Developing in one code base with just minor platform specific differences is so much better. Things like styling the UI: Css is just king compared to both Android and iOS native solutions. Of course certain things remain native. Push notifications, auth logins, ads and some other minor things. I cant wait to see our apps filly webbased.
Out of curiosity, in which way didn't Flutter fulfill your need? I've been doing Flutter dev since a couple of months back and it's been a sweet ride so far.
There is of course some hiccups but with no major obstacle.
- Rendering to web is (for all practical purposes) entirely broken.
- DNS is broken (because Google wants to have its own version of the internet).
- TLS is broken (for the same reason as above).
- Layout is limited (far too much, in comparison to web).
- Keyboard interaction is (practically) barebones.
- State management is (practically) one-style only.
TBH, that last point applies to nearly all of Flutter. You get a strong feeling that the only way to do anything is the Google-blessed method and nothing else. If you need anything done differently, just don't.
> Rendering to web is (for all practical purposes) entirely broken.
Can you expand on how exactly it "entirely broken"? I use it two years in production apps, and it's been amazing. The look and feel is pixel-to-pixel perfect to the native apps and slightly different from the "native browser", but it doesn't matter to users.
> DNS is broken, TLS is broken
))) right. IP is broken too )
> Layout is limited (far too much, in comparison to web).
Flutter not just designed to give you full control over layouts and its constraints in an efficient way (so widgets don't get rerendered or sizes don't get recalculated redundantly), it has custom painters and shaders and let you create completely custom layouts, including high-fps games. How is this more limited then DOM and "<a href target="_blank">" legacy?
> Keyboard interaction is (practically) barebones.
What's missing?
> State management is (practically) one-style only.
At this point I have a strong suspicion that you're trolling. State management in Flutter is a notoriously overpopulated field, with a whole zoo of officially endorsed approaches (for different cases and/or app sizes). Actually, if you would mention this as a main argument (no one-style state management) – I would agree with your point.
I doubt there is much difference between javs dalvik runtime on Android and a browser javascript runtime. For some tasks the browser runtime is maybe even more optimized.
It wasn't a complain (: Three generations of developers have never experienced anything beyond web stack, so challenging the premise that typesetting engine from 80s isn't even a right foundation for UI app development is a sure way to get negative reactions at scale.
This might just be completely revolutionary for my company. We sell a white-label (their logo and name) application to companies that their customers can use. This made PWA's ideal since we can have both a website and an app that would be created from a single codebase.
The problem is that the companies insist on publishing it to app stores, despite the fact that it is a hell for us to maintain as well as being completely indifferent from the users perspective once it's installed.
Having this as an option almost completely solves the maintainability issues of "packaging" and re-releasing the site every time we want to deliver an update.
Ok, but what happens if your web app has a free and pro plan with a subscription funnel on it? There should be a way to remove the subscription option from the generated package, make an "App Stores" version of the app. App Stores will not accept the webapp version without getting a cut from any payments.
So it seems that PWA means progressive web application [1] and if my very cursory scan is correct it obviously has nothing to do with progressive loading.
> Progressive web apps employ the progressive enhancement web development strategy.
It isn’t like progressive loading of images (low res first, then high res). Instead the concept focuses on content first and then progressively adding functionality/behavior on top of the content. Dedicated web apps make the progressive loading of behavior a bit fuzzier, especially when the entire point of the site is the behavior. But these PWAs are not necessarily single page apps, so that content can be indexable.
Sure, put PWAs in some online "app" store, but personally, if I am going to an App Store (be it iOS or Android), I want actual real platform apps, not cross-platform web apps.
The web stack (html/css/js/http) is one of the most impressive feats of invention by humanity. We have this one stack and toolkit that run on everything from a desktop computer down to a cheap (as little as 100$) mobile phone. It's free with no payments for access or deployment, and at the bottom end basic enough that a child can pick it up. But capable of building incredible professional experiences (see Figma or onShape, seriously they are incredible).
As a sole developer I can build something with a single code base for mobile (both web and installable), and desktop (again both web and installable). The breadth of tooling available is incredible.
The OP is about PWAbuilder, there are alternatives. I like the combination of Capacitor (from the Ionic Framework team) and Native Script. It lets you extent your installable version of the app with additional native capability, all while staying mostly in a JS environment.
The complaints about PWA being poor are, in my view, two fold. One, the support for them on iOS has be atrocious until recently, but also there are a lot of poorly written webapps. That is actually a testament to the accessibility of the platform. Look past that and you see what it is truly capable of.
We need to stop this silly gate keeping, it's frankly ridiculous.
Edit: since I started writing the negative posts have them voted down the page. Looking more positive now.
Edit 2: While I have your attention, if you care about PWAs and consumer choice of web engines on mobile, go support the OWA (Open Web Advocacy - https://open-web-advocacy.org/donate/). They are there to represent us and push for move choice and support. They are turning up and presenting the evidence needed to ensure the large players open up their platforms.