That thread seems to be based on the assumption that "smoosh" was a serious proposal.
-
-
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 @rektide and
craig martin Retweeted z̢͠a̡ļg͡o͏ b̷e̛҉çk̕͞ơ͢nş̛͞
Are we calling this wrong now? Could we (developers) have a contract governing how the language will evolve, rather than hoping our (private node or small website) code usage is incidentally used in some profiled package and, so only then, finally Safe.https://twitter.com/bterlson/status/973218284081315840 …
craig martin added,
2 replies 1 retweet 0 likes -
Replying to @thecraigmichael @jaffathecake and
The MooTools team was warned *at the time* that built-in monkeypatching was a baaaaaaad idea. There was no surprise here, only the passage of time.
1 reply 0 retweets 4 likes -
Replying to @slightlylate @thecraigmichael and
Agreed. The expectation MooTools had from their for-in loop was incorrect. It was buggy code. Given that, and the mess we're in now, I don't think there's any doubt that MooTools did the wrong thing with that piece of code.
0 replies 0 retweets 1 like -
This Tweet is unavailable.
We didn't in Dojo. Nor did Closure. Nor did Glow. Etc. Etc.
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.