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.

Now that support for author replies and reactions has been added, you can also reply or like posts and articles through simple text files:

``` # This is a like

[//]: (like-of: https://mastodon.social/@user/1234 ```

Comments URL: https://news.ycombinator.com/item?id=47322604

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46974251

Points: 4

# Comments: 0

If you hate Windows just use Linux, BSD or whatever.

I'm sick of all the "Windows 11 sucks" folks that yet keep using Windows.

Just boot your laptop from a Linux ISO and you've got the best way to bypass Windows 11.

Boycott Microsoft and everything it touches.

Comments URL: https://news.ycombinator.com/item?id=45055828

Points: 5

# Comments: 0

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.

- 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 :)

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?

Otherwise the alternatives would be pretty much a nobrainer for me:

Microsoft Office 365 -> Nextcloud Bitwarden -> self-hosted Bitwarden/Vaultwarden GitHub -> Sourcehut/Codeberg/Gitea/Forgejo Google search -> Searxng Reddit -> Lemmy Hackernews -> Lobsters Twitter/LinkedIn -> Mastodon / any Fediverse software

Minio + Celery + 4-5 services just for the main app + Keycloak?

I'm sorry, but this isn't something that "anyone can run".

This is something that requires a beefy server and someone who can manage microservice architectures with 10+ services.

I'm not sure why all of those services are requirements for the app.

I don't know why you need an S3 provider and a federated identity manager to run something that looks like Notion.

I don't know why you need to split the app into 5 microservices.

And I honestly don't think that all of this overhead is needed.

I'll give Docs another look if it decides to trim some of this bloatware.

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.

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.

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.