As an engineer and self-hosting and self-coding enthusiast, I would agree with a lot of the points. I have spent most of my life in IT advocating for decentralization and democratization.
However, as someone who has had enough experience in the real world to notice how different time and skill constraints lead to different requirements for outsourcing, I think that it sounds elitist. Even an LLM is not sufficient for people who don't even know the difference between backend and frontend or what an API is, and therefore don't stand a chance to craft a proper prompt, let alone properly test the code that the LLM produces.
For context, I could also tell Mr. "Having a fucking website" that they're a hypocrite because they run a blog on Wordpress and have a social media account on mastodon.social. Those who really believe in decentralization run their own stuff, or code their own blogging platform like I did. They don't just brag of how morally superior they are just because they deleted their Facebook and Instagram accounts.
Of course I would sound elitist. And that's exactly how their stance sounds to the average bakery shop owner.
You know that you are dealing with a fascist scumbag the moment you hear "terrorist", "antifa" and "law and order" in the same phrase. Flock is a disgrace for the industry, and this fascist sociopath is a disgrace for mankind.
My advice is to build such solutions around open products like Signal, XMPP or Matrix if possible. Or even Telegram.
On top of providing a better developer experience compared to Meta's ultra-locked and limited APIs, they aren't subject to the whims of a giant faceless company that can kill your product for no apparent reason with no chances of appeal.
Especially if you're doing these projects for folks in the developing world. Let's not lock them in proprietary American spyware like the whole West has already done :) from a user's perspective, if things are done properly, it'll just be a matter of installing another app.
And btw using a Matrix server with a WhatsApp bridge could also be a temporary solution to bypass the ban. But I haven't tested it with business accounts.
As the developer of a GPS tracking app that relies a lot on OpenStreetMap, I've faced many of these problems myself. A couple of learned lessons/insights:
- I avoid relying on any generic location name/description provided by these APIs. Always prefer structured data whenever possible, and build the locality name from those components (bonus points if you let the user specify a custom format).
- Identifying those components itself is tricky. As the author mentioned, there are countries that have states, others that have regions, other that have counties, or districts, or any combination of those. And there are cities that have suburbs, neighbourhoods, municipalities, or any combination. Oh, and let's not even get started with address names - house numbers? extensions? localization variants - e.g. even the same API may sometimes return "Marrakesh" and sometimes "Marrakech"? and how about places like India where nearby amenities are commonly used instead of house numbers? I'm not aware of any public APIs out there that provide these "expected" taxonomies, preferably from lat/long input, but I'd love to be proven wrong. In the absence of that, I would suggest that is better to avoid double-guessing - unless your software is only intended to run in a specific country, or in a limited number of countries and you can afford to hardcode those rules. It's probably a good option to provide a sensible default, and then let the user override it. Oh, and good catch about abbreviations - I'd say to avoid them unless the user explicitly enables them, if you want to avoid the "does everybody know that IL is Illinois?" problem. Just use "Illinois" instead, at least by default.
- Localization of addresses is a tricky problem only on the surface. My proposed approach is that, again, the user is king. Provide English by default (unless you want to launch your software in a specific country), and let the user override the localization. I feel like the Nominatim's API approach is probably the cleanest: honor the `Accept-Language` HTTP header if available, and if not available, fallback to English. And then just expose that a setting to the user.
- Bounding boxes/polygons can help a lot with solving the proximity/perimeter issue. But they aren't always present/sufficiently accurate in OSM data. And their proper usage usually requires the client's code to run some non-trivial lat/long geometry processing code, even to answer trivial questions such as "is this point inside of this enclosed amenity?" Oh, and let's not even get started with the "what's the exact lat/long of this address?" problem. Is it the entrance of the park? The middle of it? I remember that when I worked with the Bing in the API in the past they provided more granular information at the level of rooftop location, entrance location etc.
- Providing localization information for public benches isn't what I'd call an orthodox use-case for geo software, so I'm not entirely sure of how to solve the "why doesn't everything have an address?" problem :)
The irony of watching this 2017 TED video in 2025, and find out that my NoScript extension reports half a dozen of JS trackers and ads providers on this page - including Google, doubleclick.net, sail-personalize and sail-track.
Oh, and if you navigate to this page without NoScript, AdBlocker or a PiHole DNS you'll probably be presented with a cookie consent banner, a bunch of ads on the page and before watching the video, and your data being shared with at least half a dozen partners (a number that can increase dramatically if you visit the page of any news outlet instead of ted.com).
So yeah, I guess that the message of this video aged like fine wine.
There are cases like media apps, camera apps, videogames, terminal emulators, clipboard managers etc. that won't become Web apps any time soon.
Either because they need to operate closer to the OS, or for performance expectation reasons.
But I've just had a quick scroll through the apps on my phone, and I can confidently say that 90% of them are basically HTTP clients that interact with an HTTP server.
And even those that do more could probably be wrapped into a WebAssembly artifact with comparable performance in a near future.
The reason why they are not PWAs, and why engineers are often expected to do triple work (iOS, Android, Web), and why there aren't more products released as PWAs, keeps eluding me.
Sure, you have to tell folks how the "Install/Add to home screen" process works from a mobile browser, but is it that really that much more friction compared to an App Store paradigm to justify the abuse of native apps that either reinvent the wheel multiple times, or are just unglorified Web browsers running an Electron app just to show you the discounts at the supermarket near your house?
All the features you mentioned can also be achieved by a well developed PWA. Of course, minus the widgets or some deeper system integration (like controlling phone calls etc.)
It doesn't sound like anything that a PWA (paired with some a sync mechanism like Websockets) can't solve. And with WebAssembly the convergence is even more compelling.
It depends on how much Firefox enshittifies. If it's just about removing some telemetry configuration from upstream, then a couple of downstream patches will still do the job. If, say, Firefox decides to fully embrace the spyware business model and drop support for Manifest V2 in order to kill adblockers, then LibreWolf will probably have to maintain their own fat piece of logic built on top of Firefox. Keeping it as a soft fork would then be a lot of work (you'd basically have a patchset of tens of thousands LoC to keep porting through different versions of Firefox). And making it a hard fork would be even more work (it basically means that the LibreWolf folks are on their own and they have to maintain their own independent browser).
The thing is that, in a platform based on link sharing, it should be known which domains point to URL shorteners.
Even if you automate their handling, the algorithm should know that, if it bumps into a say signal.me, bit.ly or goo.gl URL, it should first do a GET and then apply the algorithm to whatever is provided in the Location header.
Not doing this for a widely used URL shortener like signal.me is just a show of technical incompetence.
I did my Github -> self-hosted Gitlab -> Gitea -> Forgejo journey over the years, and I haven't looked back.
Forgejo is great and it's probably going to become even greater once federation is done (having distributed forks and PRs across multiple instances solves the fragmentation problem of self-hosted solutions).
And I lost my trust in Gitea once it spun off a for-profit branch backed by VC money (which was exactly the reason why it was forked into Forgejo).
The only thing I lost from Gitlab is the out-of-the-box CI/CD platform. But I could migrate my pipelines to Drone CI and trigger them via webhooks. Just keep in mind that, depending on the complexity of your Gitlab pipelines, this may not always be an option. Anyway, for me hosting a Gitlab server that hogged up 5GB of RAM to serve a couple of small projects was a big no-no. Forgejo takes 500MB of RAM at peak.
I wish this was the case, I doubt it'll be the case. Suppose for example that the foundation agrees that Manifest V3 is a bad idea (and, objectively, it is an awful idea). I can't imagine a world where the contributors from Google (which currently still make up the vast majority of the commits to the Chromium codebase) go back on their steps and re-implement support for V2, which would basically go against the profitability strategy of their own employer.
Same for intentionally crippling Google websites on non-Chromium browsers: given how deliberate such acts of crippling are, I have reasons to believe that it's part of Google's "works with Chrome" strategy, and I'd doubt that Google employees can do much against it.
The only way to fix the governance of Chromium is to effectively chop all the threads that connect it to Google. As long as Chromium developers who are employed at Google won't do anything that goes against the strategy of their employer, you can't have fair governance.
However, as someone who has had enough experience in the real world to notice how different time and skill constraints lead to different requirements for outsourcing, I think that it sounds elitist. Even an LLM is not sufficient for people who don't even know the difference between backend and frontend or what an API is, and therefore don't stand a chance to craft a proper prompt, let alone properly test the code that the LLM produces.
For context, I could also tell Mr. "Having a fucking website" that they're a hypocrite because they run a blog on Wordpress and have a social media account on mastodon.social. Those who really believe in decentralization run their own stuff, or code their own blogging platform like I did. They don't just brag of how morally superior they are just because they deleted their Facebook and Instagram accounts.
Of course I would sound elitist. And that's exactly how their stance sounds to the average bakery shop owner.