Osmose
In short, the W3C adopted it because they thought it was a good idea, while browsers and screen readers both refused to adopt it for various reasons like ambiguity with existing web content or concerns about screen readers having to implement and maintain their own independent outline algorithm implementations. 8 years and an entire standards organization after the thread above, the WHATWG finally dropped it.
https://www.psychologytoday.com/us/blog/close-and-personal/2...
It's pretty standard among browsers. The risk should be about equal to someone spoofing the domains that the browser downloads software updates from, and you can turn it off via prefs if you really don't want it.
Meta really does not need to be subsidized when they have so many resources at hand—if LLMs are really hard to train without that much data, then perhaps that's a flaw with the approach instead of something the world has to accommodate.
A specific use case where Bun beat the pants out of Node for me was making a standalone executable. Node has a very VERY in-development API for this that requires a lot of work and doesn't support much, and all the other options (pkg, NEXE, ncc, nodejs-static) are out-of-date, unmaintained, support a single OS, etc.
`bun build --compile` worked out-of-the-box for me, with the caveat of not supporting native node libraries at the time—this 1.1 release fixes that issue.
It is not unfair that, in order to have voice acting, you must have someone perform voice acting. You don't have the natural right to professional-level voice acting for free, nor do you need it to create beautiful things.
The tech is simply something that may be possible, and it has tradeoffs, and claiming that it's an accessibility problem does not grant you permission to ignore the tradeoffs.
Yes, we should avoid using it because it will upend the lives of a significant amount of artists for the primary benefit of "some indie games will have more voice acting and big game companies will be able to save money on voice actors". That's not worth it, how could you think it is?
Crucially, I do not think predictions that all these issues will improve is a good enough justification to keep innovating before they have improved. Harm caused now is not undone just because we fixed the flaws later.
In that sense: I think feeling weird about the hype train is completely normal, but for different reasons. I do not want any complicity in legitimizing LLMs.
Besides ethical concerns, I also think the myriad applications of LLMs are mostly misguided market waste. In that sense, profiting off the hype could be seen as you simply slurping up some of that waste for yourself, and while I don't like that function of the system, I think the system is the issue rather than you trying to exist within it. If you don't share my ethical concerns or aren't objecting to the market's function of trying all ideas and assuming the good ones profit, then you're probably not really doing anything scummy by your own standards.
...I don't follow? You're suggesting businesses have a right to attention?
> But Yuzu wasn't acting in good faith. The team saw abuse firsthand and embraced it.
As mentioned elsewhere in the thread, they had rules against ROM distribution and some of the links shared as evidence that they didn't have been by unrelated people.
But to your larger point: Nintendo being mad about people sharing Switch ROMs or Yuzu funding their work shouldn't have any bearing on the actual legal question of whether Yuzu violates the DMCA anti-circumvention clause. Dolphin argued after legal consultation that inclusion of these keys qualifies under exceptions for interoperability; Yuzu doesn't include the keys at all. It doesn't appear to have been a question tested in the courts yet.
That point _does_ matter if you're making a moral argument about whether Yuzu crossed a line, but given that emulation has been commonplace for almost the entirety of Nintendo's video game business and it has done very little to stop them from staying on top of the game industry, but has enabled millions to experience and be inspired by games they would've otherwise never have been able to play, I'm not terribly convinced that $23k a month in donations is wrong for people putting in serious engineering work into a project that enables that.
There's a power imbalance—enforcement exists to help balance the scales so that an efficient negotiation between workers and the company can happen.
This is not at all universally true? A union can be dysfunctional just like any other collaboration between people—that's hardly a reason to not even try.
Specifically, I joined the Glitch union along with my coworkers in 2020, and we were pretty united on what we wanted to negotiate for. The union more than paid for the effort we put in to forming it and our dues when it won severance and health coverage for those hit by layoffs later.
> What is the difference between being fired and being told we don't have any work for you? Labors often do lose their job - they may still be in the union and thus early in line if there is another job, but they don't have control of when jobs come up.
What does this have to do with a union improving the power balance in negotiations between employees and a company? If you're suggesting that even with a union companies can find ways to get rid of you, well, that's one of the very things unions can fight against with the help of the labor board being threatened in the article above.
But a more direct criticism of the legal aspect would be: getting a job is voluntary from a legal perspective, how does that make joining the associated union a compelled action? The union is part of the job.
Besides, union security agreements already _are_ heavily regulated in the US.
When negotiations break down, the union makes it clear and potentially strikes or takes other steps to pressure the company. When individual employee negotiations break down, you get churn and underperformance and dissatisfaction. People will often see burnout or mismanagement and assume it's an individual issue vs a breakdown in the contract between workers and the company.
To paraphrase a common argument about why we don't need unions, if you don't like the union, why not just find another job?
But in a comment thread of people saying the virtual DOM is not faster than equivalent manual DOM mutations you can understand why "The virtual DOM was faster than the DOM" got understood differently since it lacked that clarification.
I guess you could say that not being specific was misleading but we'd have to agree to disagree on that. I _did_ work on the web a decade ago and my recollection is that it wasn't ever unclear that React's performance claims were that it was fast for a framework and not faster than equivalent manual DOM mutations.
Prior to React, performant apps that weren't using frameworks that regenerated the entire DOM tree would simply manually mutate the DOM nodes based on what it was doing. If your app was loading a new comment, it would find the list of comment nodes and append a new one to it, same as a virtual DOM would.
The problem is that this could be error-prone in large apps—are you even sure that the comment list is still on the page? If it's not, do you need to add it to the page or is this a completely new view and you're reacting to a network request that finished after the user navigated away from the page? That's the kind of finnicky manual work that React helped simplify, but the performance was the same as an app manually mutating the DOM plus the extra virtual DOM comparisons.
I'm sure React fans who misunderstood the virtual DOM (which was explicitly advertised because it was the most popular part of React[1] vs the other parts that people were more critical of) may have said this, but I never saw the project itself advertising itself as faster than vanilla JS, only that it could be faster than competing frameworks, _especially_ ones that rebuilt the DOM unnecessarily.
> I dunno, I used Redux for a few years
Redux is a different library than React. State management across an app is a problem even for non-React applications, it's not like React _uniquely requires_ work to address state management.
I don't see why your dissatisfaction with Redux has anything to do with React making a very specific and buggy part of building web apps easier to manage in return for a performance cost and following its API.
[1]: See mention near the end of https://medium.com/@dan_abramov/youre-missing-the-point-of-r...