Imagine an e-commerce site that lets you review your order history and product pages offline (even if a bit outdated). That kind of experience feels genuinely useful—much more so than the "you're offline, here’s a cute dog (I love the pictures though)" fallback most sites provide.
Over the weekend, I experimented with service workers for the first time (assisted by Vibe coding). My initial impression was honestly a bit magical—“this website works offline, unlike most mobile apps these days that are just WebView-wrapped SPAs and crash offline.” [1]
That said, debugging was rough. Vibe coding output had subtle issues I found hard to untangle as a newcomer, cache saved v/s cache matching was being done incorrectly in the code, which LLM wasn't able to point out (cors/non-cors requests had issue).And Chrome’s DevTools made debugging manageable, but Firefox’s service worker support felt clunky in comparison (personal take).
Curious if others feel the same—are PWAs underused because of DX hurdles, lack of awareness, or just industry momentum around SPAs?
Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess.
In other words, offline isn't PWAs killer feature. Besides, native apps can do it too.
PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.
Another Hacker News client would be a good example of a good PWA that you might install to your phone. It could have niceties like "save for later" or special styles applied to your favorite commenters. Offline support would be useful too, of course but not the main reason to develop a PWA.
Uncensored, paid content is another significant use case.
So... Taxes?
I'm intrigued as to the framing of your post. You seem to be positing that it's entirely expected and understandable that wealthy individuals in well functioning systems should commit fraud to the detriment of the system that brought them their wealth. That seems counterintuitive to me, at least.
If we're talking about wealth not income, then no, not really. We don't usually think of asset seizure as "taxes". In other words, one "taxes" flows (like capital gains and wages) and "siezes" stocks (like bank deposits and equity).
"You seem to be positing that it's entirely expected and understandable"
I wasn't making value judgement, but yes, if you look at it with the assumption these wealthy individuals are cold, calculating, self-interested actors, then it's "expected and understandable" to me.
"That seems counterintuitive to me, at least."
I think you're using "intuitive" as a shorthand for "the way things ought to work in a righteous world", where I find incentives and disincentives to be a more intuitive way of understanding the world.
"wealthy individuals in well functioning systems should commit fraud to the detriment of the system that brought them their wealth"
To be fair, it's not necessarily fraudulent to have offshore accounts or to conceal your identity (it can certainly be depending on the circumstances). Technically I have an "offshore" account, I just happen to be living outside the US and a US citizen. I also use mechanisms to conceal my identity when registering domain names, for example. Is it the same thing, no, but these people might not technically be doing anything illegal.
It isn't necessarily true that those systems "brought them their wealth" either. Plenty of them likely inherited wealth that was accumulated long before the current systems were put in place (granted, it could very well have been accumulated illegitimately 300 years ago).
(Again, I'm not saying any of this is how the world should work, I'm trying to look at the world dispassionately and describe how things seem to be)
At the level of wealth we're discussing, these individuals probably have to think about "diversifying" among nation-states. Instead of worrying about whether to short the tech sector, they're worried about a country being invaded and the new puppet regime deciding to nationalize the hydroelectric dam they financed. Or they may be worrying about whether their country of residence will pass a law that the biggest national telcom must sell the government a majority stake (i.e., their share) at a government-mandated price denominated in an inflating currency... with expert bureaucratic efficiency.
So... no, not really taxes.
"This suggests a counterintuitive result: use of offshore finance is driven not only by negative political conditions such as corruption and lack of civil justice, but by positive conditions, such as regulatory enforcement and civil justice."
But it's not counterintuitive at all. Those people aren't concerned about getting mugged and they're definitely not concerned about how long it takes to get a construction permit in a corrupt country. They're concerned about state-sponsored expropriation.Given so many of the comments here about tracking the offshore accounts down and confiscating the contents, it's no surprise.
Irrespective of whether their practices are immoral, unethical, unfair, or unjust, they're definitely not counterintuitive.
It's genuinely hard for me to understand how the authors could believe otherwise.
My conclusion is exactly the opposite. In-house developers can be expected (read: cajoled) to do things the "right" way, like follow links at runtime. You can run tests against your client and server. Internally, flexible REST makes independent evolution of the front end and back end easy.
Externally, you must cater to somebody who hard-coded a URL into their curl command that runs on cron and whose code can't tolerate the slightest deviation from exactly what existed when the script was written. In that case, an RPC-like call is great and easy to document. Increment from `/v1/` to `/v2/`, writer a BC layer between them and move on.
Links update when you log in or out, indicating the state of your session. Vote up/down links appear or disappear based on one's profile. This is HATEOAS.
Link relations can be used to alter how the client (browser) interprets the link—a rel="stylesheet" causes very different behavior from rel="canonical".
JavaScript provides even provides "code on-demand" as it's called in Fielding's paper.
From that perspective, REST is incredible. REST is extremely flexible, scalable, evolvable, etc. It is the pattern that powers the web.
Now, it's an entirely different story when it come to what many people call REST APIs, which are often nothing like HN. They cannot be consumed by a generic client. They are not interlinked. They don't ship code on-demand.
Is "REST" to blame? No. Few people have time or reason to build a client as powerful as the browser to consume their SaaS product's API.
But even building a truly generic client isn't the hardest thing about building RESTful APIs—the hardest thing is that the web depends entirely on having a human-in-the-loop and your standard API integration's purpose is to eliminate having a human in the loop.
For example, a human reads the link text saying "Log in" or "Reset password" and interprets that text to understand the state of the system (they do not have an authenticated session). And a human can reinterpret a redesigned webpage with links in a new location, but trivial clients can't reinterpret a refactored JSON object (or XML for that matter).
The folly is in thinking that there's some design pattern out there that's better than REST without understanding that the actual problem to be solved by that elusive, perfect paradigm is how you'll be able to refactor your API when your API's clients will likely be bodged-together JS programs whose authors dug through JSON for the URL they needed and then hard-coded it in a curl command instead of conscientiously and meticulously reading documentation and semantically looking up the URL at runtime, follows redirects, and handles failures gracefully.
Deleted Comment
Your post was implicitly invoking Occam's razor and so the premise of the question was about deciding which explanation to believe. I rejected that premise because it wasn't necessary to decide between the two explanations—they weren't mutually exclusive.
The only proof I had was that I've seen enough of these events resolve themselves very similarly to the way this one was resolved—which is why I was recommending a "wait and see" approach.
Call it wisdom or "lived experience".