This whole thing is handled so disgustingly by strong-arming pretentious ass "leaders" who browbeat & disabuse any arugmentation in such over the top ways. This disgusting FAQ just carries that on. So unwilling to accept the very premise that there are tradeoffs.
-
-
Replying to @rektide @thecraigmichael and
rektide de la fay Retweeted Reginald Braithwaite
From a calmer man than me, in a solid thread, touching to how silly & absolute-ist the "leadership" is on this one,https://mobile.twitter.com/raganwald/status/974691199020945408 …
rektide de la fay added,
1 reply 0 retweets 0 likes -
Replying to @rektide @thecraigmichael and
That thread seems to be based on the assumption that "smoosh" was a serious proposal.
1 reply 0 retweets 3 likes -
Replying to @jaffathecake @rektide and
I should know better than to weigh in here, but a few things: - browsers have a responsibility towards their users and competitive pressure to render as much content as possible - browser teams fund most JS engine development - change sometimes involves breaking *some* things
1 reply 0 retweets 4 likes -
Replying to @slightlylate @jaffathecake and
But being a responsible steward means understandng the scale and scope of impact of proposed changes -- if only as a proxy to the likely costs you're externalizing. Hence guidance like this: https://www.chromium.org/blink/removing-features …
2 replies 0 retweets 9 likes -
Replying to @slightlylate @jaffathecake and
In most situations I deeply appreciate the "dont break the web" sensibility, & these guidelines are great. But the way it is being used today feels like it is being used to trample those who feel MooTools 1.2 broke JS the language with it's slipshod monkeypatching of core JS.
1 reply 0 retweets 0 likes -
Replying to @rektide @slightlylate and
The unwillingness of "dont break the web" advocates to acknowledge or recognize these pleas- that this is a very different case than usual- feels so wounding & aggravating. * MooTools 1.2 broke JS * Anyone monkeying /w the primitives of JS objects accepts a higher responsibility
1 reply 0 retweets 0 likes -
Replying to @rektide @slightlylate and
From the article: In retrospect MooTools did the wrong thing — but breaking the web doesn’t punish them, it punishes users. These users do not know what a moo tool is. Alternatively, we can find another solution, and users can continue to use the web. The choice is easy to make.
2 replies 0 retweets 5 likes -
Replying to @jaffathecake @slightlylate and
There has to be a practical limit somewhere to how badly users can break JavaScript before we decide we don't need to support their irresponsible monkeypatching of core JS. Unlimited permission to monkeypatch as you please is not a viable long term strategy.
1 reply 0 retweets 0 likes -
Replying to @rektide @jaffathecake and
I haven't heard any of the "defenders" give recognition that there does have to be some limit, somewhere, to how far JS will go to support those who monkeypatch core JS. While this situation may be an "easy call," their broad stance is unrealistic.
1 reply 0 retweets 0 likes
I was one of the people warning the MooTools team Back In The Day (TM) that their builtin prototype monkeypatching was a bad idea...but there's literally no joy in "I told you so". Being "right" still leaves you with the problem to solve...so we're solving it.
-
-
Replying to @slightlylate @rektide and
This is about hurting sites, devs, and users who didn't cause the problem vs. just *picking a different word* for a new method. Nothing wrong with starting from "don't break the web" and relaxing the mantra if the damage isn't too bad.
1 reply 0 retweets 2 likes - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.