Wikipedia officially requires articles to summarize their sources from a neutral point of view. However, Wikipedia did become overtly political with the PROTECT IP blackout of January 18, 2012, in protest of a proposed law seen to threaten Wikipedia's existence.

The first time you add a website to your home screen, it installs the website's service worker. You have to use the Internet for that, just as you have to use the Internet to download an application from Apple's App Store.

And I'm curious about what the blockers for even a partial PWA implementation have been during each of these 12 years.

All I've been asking is what features of Grab combined with missing features of PWA likely led to their continuing to choose native apps.

I don't see where I "assume[d] to know better than Grab".

No; it's absolutely a terrible idea. It may be great for the businesses; but, it's absolutely fucking terrible for the consumer.

This is absolutely fucking insanity. Imagine having to carry 6 different cards and wondering which one a particular store is going to take.

Even apart from costs associated with proprietary software, the other reason to avoid vendor lock-in is to avoid self-propagating backdoors in the compiler. Ken Thompson described how to make such a backdoor with C in his 1983 "Reflections on Trusting Trust" speech. David A. Wheeler described "diverse double-compiling", a defense against compiler backdoors that relies on the existence of independent implementations of a language. Stable Rust doesn't have that because it's such a moving target, with widely used programs relying on language and library features less than half a year old.

See also "Reflections on Rusting Trust" by Manish Goregaokar

They knew this and decided to maintain Perl 5 alongside Raku (formerly known as Perl 6) for what is looking to be noticeably longer than the 11-year transition from Python 2 to Python 3.

The most prolific poster on my Mastodon feed is a retrocomputing enthusiast who uses a decades-old (pre-Intel) Macintosh PowerBook G4 as their daily driver.

GCC has tended to support more historic instruction sets than LLVM. If a device's instruction set is supported by GCC and not by LLVM, it can run programs written in C, C++, Fortran, and other languages supported by GCC. It can also run programs in an interpreted language whose interpreter is implemented in a language supported by GCC, such as Python and PHP last I checked. It cannot build programs written in languages supported only by LLVM and not by GCC, such as latest stable Rust. What keeps gccrs (the Rust front end of GCC) from entering production is that the Rust language is still a rapidly moving target, with popular programs routinely requiring features added to the language or the standard library less than six months ago.

The service worker API is explicitly designed to avoid downasaurs in "offline-first" use cases. It acts as a proxy to serve the shell document, style sheet, scripts, and stale data, even without an Internet connection. That's why I asked what obstacles there are other than a downasaur.

I have not presented my ideas to Grab because I am not a user of Grab. I would imagine that most readers of Slashdot are likewise not users of Grab.

I was expecting someone who has used the product to help others in this discussion understand why Grab probably chose and continues to choose to develop iOS apps instead of PWAs. The answers might have taken the form:

A. PWAs weren't capable enough 12 years ago for X, Y, and Z reasons, are now, and the engineering resources to port the native app to a web app would exceed the cost of acquiring and maintaining Macs capable of running the latest macOS
B. PWAs still aren't capable for X, Y, and Z reasons

And the right decision would be for phone operating system publishers to provide functionality in the included web browser to let a website act as a progressive web application. Safari for iOS has a history of lagging behind other platforms' browsers in PWA features.[1] This is particularly evident with respect to what the browser allows websites to do in the background. For example, Apple implemented Push API seven years after Mozilla did, and it requires the user to add the website to the home screen to enable PWA features.[2] Do you want Nintendo Music to pause when you switch to another application? Or if you've chosen to let Nintendo's website notify you when something becomes available, do you want to miss the notification if Safari suddenly decides that your domain's notifications shall be silent (without vibration, without sound, and at the bottom of the list)?

[1] "Progress Delayed Is Progress Denied" by Alex Russell
[2] "Push API" on Can I use...

With two exceptions I can think of. Correct me if I'm wrong, but as I understand it:

1. For lightweight web hosting, a low-end VPS from a company like DigitalOcean is likely to be less expensive than upgrading a home office from home-class home Internet to business-class home Internet to unblock inbound ports 80 and 443.
2. SMTP is still an old boys' club, with major mailbox providers (such as Gmail and Outlook) blocking connections on port 25 from on-premise IP addresses as likely sources of spam.

The alternative is developing a progressive web application (PWA) that runs in Safari instead of a native iOS application.

SAS has been dead for 15y; it started with R and then Python absolutely destroyed it. No one teaches SAS in universities any longer, why would they? It's terribly expensive and absolutely fucking dead.

We migrated away from SAS back in 2017 and never looked back. The only verticals still using it are heavily regulated and running long-standing legacy code that they're slowly migrating to Python.

I remember absolutely dying when they tried to renegotiate our contract UP back in 2015. I flat out told them they were dead and we were moving away from them and they told me, "good luck managing your data without us!"

Two companies and 10 years later, we're doing just fine and they are not.

We MUST be able to inspect and age verify every AI slop porn image to protect the fictional children!

-

1. There are a lot of empty seats; a lot.

2. The demo wasn't live, likely due to the huge failure of an event that the Meta one was.

3. They noted that you do all of this 'hands-free', likely an intentional knock at Meta's offering.

4. The examples were...odd. Who the fuck is going to be using this to shop for a fucking rug? Come on; give some real-life examples that are IMPORTANT. None of these were.

5. The entire presentation's style, across multiple different presenters, was...exhausting...halting...jarring...and...really undergraduate level. It was almost as if they were being fed what to say in their earpieces, not from memory and not in a fluid and practiced way.

---

Personally? I love the idea of AR glasses that work well. I want to have live subtitles for humans talking to me as I'm hard of hearing and hearing aids do not work well for me, particularly in public spaces.

I want it to give me important information, respond to my environment in ways that are useful (telling me where I am really isn't that; I know where the fuck I am--tell me what I should be doing or where I should be going next, perhaps?)

I know these are early adopter level devices, but they're just fucking ugly due to their bulk.

I strongly prefer this option to Meta's simply because I don't have to do stupid fucking mime-style hand gestures, but I want this technology to be useful, now, not in 5 years. We're going to see this largely flop just like so many other AR/VR toys out there unless they make this something more than a gimmicky piece of shit.