Disclaimer: I am an application developer, and one of the maintainers of the Drogon C++ web framework.
C++ & apps don’t fit well together technologically these days.
Android? Go Kotlin.
iPhone? Go Swift.
Cross platform? Meh, kind of dislike middleware as they always lag behind the vendor. This was the case three decades ago as it is today.
Usually you are far better off by defining a REST API as your border between platforms, then just use whatever easy (de)serialization techniques the language will give you.
Personally I have a cross-platform C++ stack built on top of Drogon that I can use on multiple platforms, then it’s usually a native UI layer (Kotlin + Compose on Android, Swift + SwiftUI on Apple platforms) on top of the cross-platform layer. This way business layer code can be shared across every platform while only the UI needs to be adapted to its host OS.
Just to give you an example: Some Samsung SSDs have slightly strange TRIM behavior that basically seems to get unnoticed during normal workloads.
But when you build a Hackintosh with a recent version of macOS this exact TRIM behavior results in boot times of several minutes (compared to a dozen of seconds or so on a SSD with a better TRIM implementation).
I’m not saying Samsung will ever fix their TRIM implementation, but in theory this would be fixable by a firmware update.
And don’t get me even started on the crap that TRIM is, why we shouldn’t need it in the first place, and how convoluted its development was.
If it’s about side money, it usually also implies a smaller, side project, not necessarily, but eventually for smaller businesses to whom technological choices don’t matter.
You just define the outcome together with your client, and use C++ if it’s a technological fit.
From my limited understanding not the distance is the problem, but the constant focus at a point in the same distance. That’s the reason why they recommend to look at distant objects every 15 minutes or so. Starring at a tree for ten hours straight would have a similar effect, but woods are so complex that your eyes are constantly refocusing.
Tab cycling can be a productivity killer, especially when you need to cycle between more than 4–5 applications (which can happen quite often, but OP wrote “alt-tab (or otherwise)”.
What works excellent (at least for me, not necessary for you) is to set shortcuts to your most used applications (be it the function key row, or some hjkl combinations). With such a setup you can just press a key / combination from muscle memory, instead of opening the tab switcher overlay, parsing it, deciding how often you need to press tab, and then actually switching to the other application window. Keeping shortcuts to applications feels like you would only have to do the last step.
It’s really fascinating how humanity can twist almost everything around and start seeing it from a bad perspective.
Maybe the author is a very engaged developer who already knows a huge part of the “boring software that supports the world”? Maybe he is so engaged that he wants to follow new developments in his professional area to get even better? Maybe he hopes that he will discover new and interesting algorithms that can help him improve his skills?
I think there is a point that simple algorithms are a better user interface, because of their predictability (although they show their flaws, like he specifically mentions with JS). Just try to remember how much discussion there was about Twitter’s feed and their move away from a classic timeline. They still haven’t abandoned the latter one.
But who knows in the end? Maybe your comment was just an attempt of satire a la The Onion? Personally I try not to prematurely judge and stay positive. To each his own I guess.
I see it exactly as the opposite. Github is a boring and effective tool for professionals, and the author has twisted it around to be a bad thing since it’s not “fun”.
A common convention with system administrators is to have the canonical name at www.* and redirect www-less requests to the former. If you argue that a browser implementation should fix uncommon configurations, I would argue that administrators should fix their configurations in the first place.
You don’t have this issue at all for domains that don’t have a www subdomain.
Furthermore it would be extremely confusing to have different content for www.example.com & example.com.
Yeah, I don't like the current trend to redirect www to root. You can easily doing simple dns-based load balancing by having multiple ip addresses on the www subdomain. You can't do that on root domain, you'll have to use a dedicated load balancer even if all you want is just simple load balancing among a small set of servers. It only benefit cloud vendors and hurt hobbyist/small website operators if this trend continues to the point that visitors expect all websites to be served from root insetad of www.
If we could ever be bothered to implement SRV records for http then load balancing and failover could be significantly more straightforward and robust, without worrying about root vs. www at all.
Multiple A records is fine on root domain, but root can't use CNAME, which is used by some people to implement their dns load balancing (I use cname so I forgot that you can still do it using A records). By using root domain instead of www, your options for load balancing is diminished.
Edit: another common use case is hosting your static website on S3 or github pages. Typically it's done by adding a cname entry to s3 or github.io (been a while so hopefully I remember it right). You can't do this on root, unless you're using another server as reverse proxy (e.g. cloudflare's cname flattening service). Again, it's benefits cloud vendors (cloudflare got more potential customers by offering this service for free) but ultimately hurt people that want to host their small websites.
C++ & apps don’t fit well together technologically these days.
Android? Go Kotlin.
iPhone? Go Swift.
Cross platform? Meh, kind of dislike middleware as they always lag behind the vendor. This was the case three decades ago as it is today.
Usually you are far better off by defining a REST API as your border between platforms, then just use whatever easy (de)serialization techniques the language will give you.
Personally I have a cross-platform C++ stack built on top of Drogon that I can use on multiple platforms, then it’s usually a native UI layer (Kotlin + Compose on Android, Swift + SwiftUI on Apple platforms) on top of the cross-platform layer. This way business layer code can be shared across every platform while only the UI needs to be adapted to its host OS.
Drogon website: https://drogon.org