can someone talk me out of monkey patching most of javascripts types for my side project? or at least warn me about pitfalls that matter even if im not importing any libraries?

The main problem has to do with compatibility with other libraries that use the same prototype methods. Otherwise, I think you’re good to go. Also check out Sugar.js https://sugarjs.com/

the page about their philosophy with regard to extensions and how they go about it is actually exactly the kind of in-depth discussion i was looking for—thank you!

Oh, I do the same thing. I just check for existing properties with the same name before patching. I'm not writing a library, so who gives a shit!

Just don't the like that customer support software I was using. They decided to monkey patch arrays in an update and completely destroyed my production app. Quite the nightmare to debug 😭

@Garth Goldwater you have come to the wrong place to be talked off this ledge. "Here, have a parachute or, better yet, this pair of wings."

everyone in this thread should be ashamed of what they’ve enabled

lol, I like it!

me too—my crimes will only get worse from here. a chicken in every pot. a render for every datatype. an edit for every object. chaos reigns!

You can do whatever you want of course. As for me though, why I don't monkey patch 1. don't find out later a function was added with the same name and now in order to use it I have to refactor all my code 2. don't want to mis-lead others into thinking this is a standard function. This comes up a lot since I write tutorials and in particular one of the first/original tutorials on one of the topics I write about monkey patched things in and confused learners for many years. For at least 8 years people would ask on S.O. why their code wasn't working only to have to be told what they thought was part of the official API was monkey patched by their tutorial. Fortunately those tutorials are no longer online but the legacy lingers since the examples have been copied forever 3. because while I might not care about other people's code or never worry my code might become a library I'll get use to this pattern and then find it frustrating when there's a case I can't use it. Prefer just not to go down this path in the fist place. 4. and finally, because I don't get the benefit at all. Why is

someArray.render(msg)

better than

renderArray(someArray, msg)

so zero pluses (for me), multiple negatives = I choose not to do it.

For point 4, you then need a way to get renderArray into every scope where you want to use it. If you're trying to minimize namespace pollution, that's extra friction — and it's arguable the friction, as minor as it is, is worse than the downsides of patching. (Not even touching the OO vs FP -ness of this suggestion, haha)

i’m looking at this as me being spoiled more than me being sensible—i could reframe the original question as, “if i design this system to work exclusively with my aesthetic sensibilities of what i’d like js/html/css to work like, how expensive will it get and what currencies will i be paying with”. i’m not like super concerned with questions about relative merit—for the renderArray example, i’d like to not have to repeat type information, and ivan’s point about namespaces also lines up with my preferences—i don’t want the cognitive load of remembering what i’ve imported where (similarly, i don’t want the cognitive load of remembering to assign new identifiers by calling a function and passing an array in every time i want to do something with it). i don’t think i’d recommend other people do this. it’s more of an “i’m thinking about making my own bottle rockets in my backyard, launching them at my face, and using a trash can lid to block them like i’m a dungeons and dragons character. what should i be worried about in terms of, eg, eye protection”

Gregg's personal reason #3 carries a lot of resonance with me. I have that thought too. But I inevitably end up standing on the other side of that line in the sand. I'm almost always in the "designing languages / frameworks" mentality, and I like to play with different kinds of syntax or call signatures or conventions just to learn more about the pain and pleasure of any given variation from the norm. It's nice to be able to do that a little bit while still benefitting from all the infrastructure of JS and in the context of an actual product/serious project, rather than (say) having to write my own language and then figure out how to have an ecosystem around it and then find some sort of toy example project to build in it. This is the sort of "play" I was referring to in that other thread.