Yeah. Perhaps that's why I'm not seeing them on any of the User agent lists, though I assumed it's because they're all new and just haven't been documented yet. (Hoping it's the latter).

I may have to break down and install them in a sacrificial VM, check, and submit my findings.

Unfortunately, a lot of browsers now completely obfuscate themselves and don't put anything unique in the user agent string. They intentionally don't want to be detected at all beyond "I'm a modern browser".

That's literally what the OP said they didn't want to do. Did you read it? 😄

Just install the browsers and test them on your website. That's the best way to be sure it works.

There are some standards, used to ensure content is readable, and comprehensible by tools like screen readers. https://www.w3.org/WAI/standards-guidelines/wcag/

It's just that most websites don't respect them, as implementation can be a challenge.

Offtopic, but I'm digging that site's aesthetic! No bullshit, no weird popping around when ads load in, no wonkyness on mobile, it just works and has a cool concept! I'm currently reading through their advent calendar thing and it's super interesting!

Huge, huge fan of this API. Can't wait until we don't need a polyfill anymore. The built-in commands concept is cool and hopefully will expand in time, but the custom commands functionality is a real game-changer! Anything which makes wiring up various web components into a real UI more declarative and web-native is most welcome.

I wonder if anyone has built a system that automatically load balances between multiple CDN providers and which can automatically temporarily drop a provider that is having issues. That would mitigate the issue of depending on one provider which can go down at any time.

I never though about it, but that makes a lot of sens.

It's mainly an issue with old drivers and not the latest software.

You can try turn it on in each browser's settings to see if it works. But it's not a major issue if it doesn't.

If you don't understand the relationship between technical debt and enshittification, how the business desire for quick and easy (and marketing friendly, user-as-product)solutions now helps drive intentional degredation, deprication, and abandonment of features later, I don't know what to tell you. This shit has literally happened in Open-Source products.

Enshittification, as a brand-new word, is en vogue, and its "definition", misused as a quick-and-easy way to dismiss @SanctimoniousApe's entirely correct and appropriate linking of it to OP, is itself an example of Platform Degredation.

Enshittification is often consumer-driven. That is to say, "giving the users what they want", only so long as its what the majority will go along with, and leaves-out "edge-cases" that were originally a major feature.

Tired of supporting a feature that doesn't drive profit or has become hard to support or update after years of neglect?

(your original devs, the ones who understand how anything marketting doesn't care about works have probably moved to other positions by this point as well)

Poll the users, ask them if they care about it. The fact the platforms have the data to pick and choose users who don't use said feature is conveniently left-out

It has a dictionary definition, I don't know what to tell you.

Before the enshittification you know today, there was Flash, everywhere, whether the page needed it or not. Tech debt, scope-creep, and feature removal, are drivers of enshittification, not-at-all outside of its definition or unrelated to it, particularly where they drive forced-obselecence and unnecessary up-grade cycles, aka consumerism.

It doesn't have to be intentional to be enshittification. Laziness and group-think will suffice.

This quote really sums up the situation:

This is a technical and business challenge, but also an ethical crisis. Anyone who cares to look can see the tragic consequences for those who most need the help technology can offer. Meanwhile, the lies, half-truths, and excuses made by frontend's influencer class are in defence of these approaches are, if anything, getting worse.

Through no action of their own, frontend developers have been blessed with more compute and bandwidth every year. Instead of converting that bounty into delightful experiences and positive business results, the dominant culture of frontend has leant into self-aggrandising narratives that venerate failure as success. The result is a web that increasingly punishes the poor for their bad luck while paying developers huge salaries to deliver business-undermining results.

The developer community really needs to be building websites that work on all devices and connections, and not just for those who can afford the latest technology and high-speed internet connections.

While I know what you mean, that's not what enshittification means.

IOW, enshittification continues apace.

Still not a single one of them supports it on linux by default

(Also worth mentioning the author's entire modus operandi is to promote Google's Big Tech vision of AI-all-the-things and hence the blog is chock full of one just-so story after another. It's quite safe to ignore completely as pure propaganda.)

Every year…every decade…the dream of low-code/no-code emerges once again in another form. And while well-built tools with good UX can indeed help non-programmers build "simple" databases and webpages, this is not something that scales to projects which require programming expertise.

Also the examples in this article make no sense. It's already trivial to compile plain text in accessible formats like Markdown to beautiful, semantic HTML. You can already build systems which take very simple text descriptions of forms and emit actual forms. Heck, I could take input like:

Contact Me form

name
email (required)
appointment date
message

and turn that into an HTML form with zero LLMs involved. But why even do that? Someone, anyone, could drag'n'drop a form together in a couple minutes. Easy.

LLMs are constantly a (poor) solution in search of a problem. Virtually every just-so story someone can share with me about how an LLM supposedly will solve their problem, I can show examples of how else to do it. We are wasting outrageous amounts of time on technologies unfit for purpose.

It's a joke, not a real point, don't worry.

Yes they could, but most importantly it gives more time for researchers and maintainers to detect attacks and fix them before they reach end-users.

I don't get your point. In most examples cited in the article, the supply chain attacks were found either by security researchers or maintainers realizing they did not intentionally push compromised version, not by everyday developers. The goal of dependency cooldowns is to give researchers and maintainers more time to detect attacks before they reach end-users.

If we all use them, won't attackers switch to waiting an extra week before attempting to activate their attacks? This feels similar to antibiotics resistance in bacteria coming from over use of antibiotics.

No no no, I should be using dependency cooldowns. You all should be finding the vulnerabilities and getting them fixed before they reach me.

Backwards compatibility, it's never been valid to send a body with a GET, and software does enforce that (to varying levels)

It's easier to create a new verb with the wanted semantics, than to change an existing one.