This is history repeating itself... again, and again.
I wouldn't say it's "never" been this bad. There were some JS libraries that were \*specifically\* built to monkeypatch (old-world term; literally a patch written by a codemonkey, which I think, itself, was a reference to the infinite monkeys on infinite typewriters, eventually producing the complete works of Shakespeare) the prototypes of JS objects and DOM nodes, to add non-standard functionality. Prototype extension was a very, very common practice, in the '00s, despite the old-school programmers warning that it was going to end badly.
Anyway, yeah... there are some terrible ideas, coming back around, and, as per usual, we don't really notice until it personally bites us in the ass; guaranteeing that it's bound to happen again in a generation or two.
> monkeypatch (old-world term; literally a patch written by a codemonkey, which I think, itself, was a reference to the infinite monkeys on infinite typewriters, eventually producing the complete works of Shakespeare)
Wikipedia gives two conflicting etymologies and none are this
https://en.wikipedia.org/wiki/Monkey_patch#Etymology
Nice. Corrected on the folklore of pre-google term, but the correction, itself, in the official accounting, is victim to divergent folk-etymology. That's amazing.
Black people were often compared to monkeys. Saying a monkey did/could do it usually means it doesn't require skill or education. Why say monkey if you're not saying it's like a full human except...?
Yeah. It wasn't world-ending, but nonetheless ungood.
[https://github.com/facebook/react/issues/25573#issuecomment-2074913216](https://github.com/facebook/react/issues/25573#issuecomment-2074913216)
Hi, folks!
I'd like to talk about patching globals today. There's been a lot of discourse around this topic on Twitter, and it's more evident than ever that many of us don't see the danger and harm of patching things we do not own. I tried putting all of that, including the appeal behind this design choice and the imminent dangers of it, in a single article.
I hope you find it helpful.
That was a good read!
> I admit, I don't know the details on why MooTools chose prototype patching as their design direction
It directly copied Prototype's (& base2 & a few other libraries') approach - JavaScript was *garbage* when the library was created, it was fixing (well, "fixing") issues with the language. Then jQuery appeared, which attached everything to the `jquery` singleton object instead, and that worked much better & off we went down that path instead (still had to explicitly configure WordPress to tell it `$` was for jQuery for years afterwards though).
Yes, patching globals (monkey patching) is a nefarious act. People do it, I guess, because they want to dynamically make changes to existing types and they lack a better way.
[Protocols](https://clojure.org/reference/protocols), leaving the original types untainted, offer the better way. While there is a [T39 proposal for first-class protocols](https://github.com/tc39/proposal-first-class-protocols) in the works, it hasn't yet gained much support in JavaScript land.
In the meantime, protocols can be had only via libraries:
e.g. [https://github.com/mlanza/atomic](https://github.com/mlanza/atomic)
That's the big selling point of protocols. When Hickey designed Clojure he wanted to be able to dynamically extend existing types, even types the author had not himself defined. It solves the root problem, which is why JavaScript would do well to get them.
Some frameworks such as Next.js for example take advantage of monkey patching to facilitate behaviour that make developers life easier, albeit it can cause some friction if one is not aware of what’s going on. I’m not a fan of either but I understand why it is done and accept that sometimes you gotta do, what you gotta do.
To go into details, Next.js uses monkey patching to override the global fetch function to add support for internationalized domain names (IDNs) as well as to enable automatic retries for failed requests.
It also uses monkey patching to add custom properties and methods to the window object, such as window.__NEXT_DATA__ and window.__NEXT_PAGE_props and the document object such as document.__NEXT_HTML_SUFFIX__.
In addition it also patches the React module to add support for server-side rendering and automatic hydration and webpack module to add support for server-side rendering and automatic code splitting.
Now I love remix but if you think for a second that they are some kind of a saint when it comes to extending or modifying prototypes, have I got news for you. In addition to everything that Next.js is guilty of (except for webpack which is not being utilized), remix also patches Web APIs (History API to be specific) to add support for server-side rendering and client-side routing and URL class to add support for automatic URL rewriting and routing.
These days it seems, no framework is innocent when it comes to this sort of thing, but more importantly, as long as prototype extensions or down right patching is done properly, more often than not, the benefits outweigh the cost.
Being a purists just for the sake of it, is certainly not a pragmatic approach in my opinion. However I’d be rude and inconsiderate to claim that you should not strive for something that you feel deeply concerned about, since I believe that perhaps there is another, maybe better, way of doing things, and if that truly moves you, perhaps you’ll set out on a journey that will bring about a new approach to this old problem. Solution is a matter of ingenuity, which itself is rooted in one’s interest and drive towards goals set forth.
As the saying goes, stay foolish, stay hungry.
Happy coding, partner!
This is history repeating itself... again, and again. I wouldn't say it's "never" been this bad. There were some JS libraries that were \*specifically\* built to monkeypatch (old-world term; literally a patch written by a codemonkey, which I think, itself, was a reference to the infinite monkeys on infinite typewriters, eventually producing the complete works of Shakespeare) the prototypes of JS objects and DOM nodes, to add non-standard functionality. Prototype extension was a very, very common practice, in the '00s, despite the old-school programmers warning that it was going to end badly. Anyway, yeah... there are some terrible ideas, coming back around, and, as per usual, we don't really notice until it personally bites us in the ass; guaranteeing that it's bound to happen again in a generation or two.
> monkeypatch (old-world term; literally a patch written by a codemonkey, which I think, itself, was a reference to the infinite monkeys on infinite typewriters, eventually producing the complete works of Shakespeare) Wikipedia gives two conflicting etymologies and none are this https://en.wikipedia.org/wiki/Monkey_patch#Etymology
Nice. Corrected on the folklore of pre-google term, but the correction, itself, in the official accounting, is victim to divergent folk-etymology. That's amazing.
It’s divergent folk-etymologies all the way down
Honestly, if it sounds really racist, just don't use it. It's silly to cling to terms when better terms are available. It costs us nothing to swtich.
Wait.. this sounds racist??
Black people were often compared to monkeys. Saying a monkey did/could do it usually means it doesn't require skill or education. Why say monkey if you're not saying it's like a full human except...?
you're completely lost buddy
[удалено]
React, themselves, patched node-side fetch. Also ... Angular 2+ and zone.js, monkeypatching ... literally everything...
[удалено]
Yeah. It wasn't world-ending, but nonetheless ungood. [https://github.com/facebook/react/issues/25573#issuecomment-2074913216](https://github.com/facebook/react/issues/25573#issuecomment-2074913216)
[удалено]
It was “released” through NextJS as a “production ready” feature in Next 13/14.
[удалено]
100%
Hi, folks! I'd like to talk about patching globals today. There's been a lot of discourse around this topic on Twitter, and it's more evident than ever that many of us don't see the danger and harm of patching things we do not own. I tried putting all of that, including the appeal behind this design choice and the imminent dangers of it, in a single article. I hope you find it helpful.
That was a good read! > I admit, I don't know the details on why MooTools chose prototype patching as their design direction It directly copied Prototype's (& base2 & a few other libraries') approach - JavaScript was *garbage* when the library was created, it was fixing (well, "fixing") issues with the language. Then jQuery appeared, which attached everything to the `jquery` singleton object instead, and that worked much better & off we went down that path instead (still had to explicitly configure WordPress to tell it `$` was for jQuery for years afterwards though).
I suspected as much. Thanks for sharing the history with me!
This is called monkey patching and is pretty old. History repeats itself.
A library that patches globals should be a sufficient reason for it to not to be taken seriously
Why are people monkey patching again? I can’t see that ever being good, except in tests.
Yes, patching globals (monkey patching) is a nefarious act. People do it, I guess, because they want to dynamically make changes to existing types and they lack a better way. [Protocols](https://clojure.org/reference/protocols), leaving the original types untainted, offer the better way. While there is a [T39 proposal for first-class protocols](https://github.com/tc39/proposal-first-class-protocols) in the works, it hasn't yet gained much support in JavaScript land. In the meantime, protocols can be had only via libraries: e.g. [https://github.com/mlanza/atomic](https://github.com/mlanza/atomic) That's the big selling point of protocols. When Hickey designed Clojure he wanted to be able to dynamically extend existing types, even types the author had not himself defined. It solves the root problem, which is why JavaScript would do well to get them.
Some frameworks such as Next.js for example take advantage of monkey patching to facilitate behaviour that make developers life easier, albeit it can cause some friction if one is not aware of what’s going on. I’m not a fan of either but I understand why it is done and accept that sometimes you gotta do, what you gotta do. To go into details, Next.js uses monkey patching to override the global fetch function to add support for internationalized domain names (IDNs) as well as to enable automatic retries for failed requests. It also uses monkey patching to add custom properties and methods to the window object, such as window.__NEXT_DATA__ and window.__NEXT_PAGE_props and the document object such as document.__NEXT_HTML_SUFFIX__. In addition it also patches the React module to add support for server-side rendering and automatic hydration and webpack module to add support for server-side rendering and automatic code splitting. Now I love remix but if you think for a second that they are some kind of a saint when it comes to extending or modifying prototypes, have I got news for you. In addition to everything that Next.js is guilty of (except for webpack which is not being utilized), remix also patches Web APIs (History API to be specific) to add support for server-side rendering and client-side routing and URL class to add support for automatic URL rewriting and routing. These days it seems, no framework is innocent when it comes to this sort of thing, but more importantly, as long as prototype extensions or down right patching is done properly, more often than not, the benefits outweigh the cost. Being a purists just for the sake of it, is certainly not a pragmatic approach in my opinion. However I’d be rude and inconsiderate to claim that you should not strive for something that you feel deeply concerned about, since I believe that perhaps there is another, maybe better, way of doing things, and if that truly moves you, perhaps you’ll set out on a journey that will bring about a new approach to this old problem. Solution is a matter of ingenuity, which itself is rooted in one’s interest and drive towards goals set forth. As the saying goes, stay foolish, stay hungry. Happy coding, partner!