Yeah, the janky foundation made me and my boss wish we chose Java for the back-end multiple times. I like async / await (or coroutines in Kotlin-land), it’s easier to wrap my head around than Promises / Futures and I thought I would miss Reactive Programming, but not that much.

Yet, people willingly choose to use one of the most horrific ecosystems out there.

So far I have heard the following explanations for going full-stack JS

• Ability to re-use business logic in back-end and front-end

• Reduced context switching (though with frameworks that’s less true)

• You don’t have to recruit developers proficient in your back-end language in addition to Javascript

Personally, having worked on a full-stack Typescript project for the past year, I kinda miss the maturity of Java’s ecosystem: there is usually one mature and well-maintained library that does its job really well ; while in Javascript-land there are multiple libraries for a single job, each with varying quality and maturity, and most of them are no longer maintained.

This is anecdotal experience, but last time I left Wireguard on for an entire day and it accounted for 5% of battery usage that day.

I believe you swapped DoT (TLS, port 853) and DoH (HTTPS) in your message. I have yet to be in a network that restricts port 853, but if I could I would rather use DoH on Android.

Not directly, but if the developers would call some global variable set by a third-party library that’s blocked by an ad-blocker (say GTM) without checking if said variable is set first, that probably could trigger that error.