I'm absolutely in favor of the rule, but this is simply not true. Mandating everyone to implement changes in how their software works will incur huge costs, no matter what the change is, even if there were zero benefit or savings for anyone.
I’d argue that it costs more to implement and maintain dark patterns in the software than to do happy paths. It also costs customers time and money to jump through hoops to end service you don’t want and need.
In MAGA terms - if your business cannot survive in free market competition without scam schemes - it’s “unamerican” and shouldn’t be a business.
>I’d argue that it costs more to implement and maintain dark patterns in the software than to do happy paths.
I would agree with this argument. After all, you have to staff the customer service phone lines now to cancel service. It follows that presumably customer service's capacity to retain customers/revenue is profitable after factoring in costs for their wages and overhead. Dark patterns may cost money vs light patterns, but they also may have more net profit.
They absolutely do not need 23 hours of lawyers + programmers + designers + etc to comply with the law.
There are numerous states with an existing "click to cancel" regulation. If you're compliant with those states then that implementation was federally compliant as well.
The only huge cost is a drop in revenue not an increase in cost.
This has nothing to do with forgotten subscriptions or dark practices.
Nearly any mandated changes to nearly any company's software no matter what business they are in will incur costs. The FTC is required to take extra care when regulating in the case when those costs will be high.
mandating changes for power generation to stop polluting as much, for car manufacturers to make safer cars, for chemical plants to stop dumping toxic waste in water supplies all also cost a lot, but we make them do it anyway
Fact is, people in the past had far more worries and were fighting for survival much harder than the average person in rich countries today - and still had far more children.
Absolutely, yes. There's lots of factors, and any answer that just says "Because this one reason obviously", without giving arguments and statistics showing why it's that and not something else, is worthless.
It's pretty clearly not simply household income vs. cost of living, though, the data just doesn't support it.
Early 2000s PHP was a DSL for very simple web apps. So it's no surprise it excels at that.
People soon found out that it was not very good at complex web apps, though.
These days, there's almost no demand for very simple web apps, partially because common use cases are covered by SaaS providers, and those with a need and the money for custom web apps have seen all the fancy stuff that's possible and want it.
So it's no surprise that today's languages and frameworks are more concerned with making complex web apps manageable, and don't optimize much (or at all) for the "very simple" case.
> These days, there's almost no demand for very simple web apps, partially because common use cases are covered by SaaS providers, and those with a need and the money for custom web apps have seen all the fancy stuff that's possible and want it.
I dunno about that.
In 2000, one needed a cluster of backends to handle, say, a webapp built for 5000 concurrent requests.
In 2025, a single monolith running on a single VM, using a single DB on another instance can vertically scale to handle 100k concurrent users. Put a load balancer in front of 10 instances of that monolith and use RO DB followers for RO queries, and you can easily handle 10x that load.
> So it's no surprise that today's languages and frameworks are more concerned with making complex web apps manageable, and don't optimize much (or at all) for the "very simple" case.
Maybe the goal is to make complex web apps manageable, but in practice what I see are even very simply webapps being mad with those frameworks.
I disagree. I would say most of the migration from PHP was due to the appeal of one language for frontend and backend, and fashion/hype. PHP is still very usable for server-side rendering and APIs. You say "very simple" as if you can't have complex systems with PHP.
I see the current state of web development as a spiral of complexity with a lot of performance pitfalls. Over-engineering seems to be the default.
Client certificates are a thing and can in principle be used for authentication on websites. Not 100% sure that was possible 20 years ago, but Istrongly suspect that it was.
The problem is the UX around handling the certificates. Password are nearly impossible to beat in terms of "works everywhere without requiring any support infrastructure".
Passkeys absolutely make sense from a security (and in theory also UX) POV. Handling logins for dozens of services is either very insecure (reuse), has even worse vendor lock in (federated ID), or has pretty bad UX (password manager).
In practice, unfortunately the UX gains are not realized because interoperability is unsolved, because vendors have little motivation to solve it and eliminate the lock in.
That hypothetical one person would not just need to produce the code, but also understand how it fulfills the requirements. Otherwise they are unable to fix problems or make changes.
If the amount of code grows without bounds and is an incoherent mess, team sizes may not, in fact, actually get smaller.
Agreed. I don't think anyone can produce useful code without understanding what it should do.
One useful dimension to consider team organization is the "lone genius" to "infinite monkeys on typewriters" axis. Agile as usually practised, microservices, and other recent techniques seem to me to be addressing the "monkey on typewriters" end of the spectrum. Smalltalk and Common Lisp were built around the idea of putting amazing tools in the hands of a single or small group of devs. There are still things that address this group (e.g. it's part of Rails philosophy) but it is less prominent.
Because they don't use libxml2 and don't actually have any need for a fix. They only want to build a reputation as pentrsters by finding vulnerabilities in high profile projects
reply