I've used them before for doing stupid reflection hacks (literally just used them today to build a debug UI where I can make sliders out of objects), but it's not code I would really want to ship in production.
bind creates a new function that is bound to a specified receiver.
class Thing {
method1 = () => {}
method2 = () => {
something.addEventListener('click', this.method1);
}
}... but yes - a 'Modern' approach means calling out risks, or more abruptly - that which may even be considered 'anti pattern' inherent in a language as it evolves over time, with hindsight.
Perhaps the most preeminent example would be pointers in C++ - which we generally know to use with 'smart pointers'.
If C++ 'were designed today' - among other things, it'd be likely that 'smart pointers' would be 'default' and they'd be more deeply and seamlessly integrated, and 'direct memory reference' would be seen as a 'thing to do only if necessary' and a bit of a 'corner case'. Necessary, and common enough, surely as in that level of programming we are going to 'go there', however, it's something we wouldn't see as normal practice, rather something we do but with some other idioms, APIs and conventions around it ... possibly with demarcations of 'unsafe' a bit like Rust.
I think it's important, because these are precisely the things that young developers may become entangled in. It should be more like: "By the way this is how this works, but you may want to think twice about using it, here are some cases where it might be 'ok', here are some cases where it's not".
But I don't want to take away from good authorship either, we depend a lot on people stepping up to the plate and doing this work. As an aside, it seems almost perverse that 'Big Corps' just don't do this themselves. I mean, if AWS uses JS extensively, it'd seem reasonable (even from a selfish perspective) for them to 'just do' a comprehensive, JS set of docs.
It's weird that the world depends on 'a few nice dudes/dudettes' to maintain something like 'caniuse.com' and the plethora of other such important works.
Smart pointers are nice and all that but I have yet figured out how to mix them with code which doesn’t use them which is like 99.9% of all library code.
Not to mention that interfacing with C code (like python extensions) are basically impossible unless the calling code is responsible for the object lifetimes. I don’t know how language de jour deals with this C interop but have read it is a pain point almost universally.
Even some of the newer languages I see posted here have manual memory management as the default.
That's what the "more deeply and seamlessly integrated" would be mostly about.
I tends to avoid smart pointers. There are too many variants, supported in different c++ version. Can't reasonably track which one is supported in which compiler
Smart pointers are unified since C++11 standard with support in all modern compilers for various platform. Invest some time to get familiar with them and you will not regret.
They are a messy bandaid.
The notion of using them in lieu of 'nothing' is rational - but the application is a mess.
We need a clean version of C++ that's not some gigantic new thing.
Now, not using 1% of a language seems common. There are plenty of parts of C, C++, C#, Java, Python, etc that I rarely run into.
On the other hand, for testing, mocking, polyfilling, etc call/bind/apply are invaluable.
For writing libraries to do those things call/bind/apply are useful, but most developers aren't doing that very often.
As a oldschool Amiga/PCDOS/ASM/C developer who moved on to the web ten years later... it always feels awkward to me to do things like arr = [...arr, ...arr2] because I'm always wondering just how effectively that is handled by the Javascript compiler.
But as a fellow former low-level, my humble advice is: stop worrying and write clear code. Clear code eventually will run fast and stay clear. Nuanced code eventually will run as fast but stay nuanced.
To be fair, C++ is the epitome of a language you only adopt after consciously picking a very specific subset of features, or explicitly marking features as verboten. Template metaprogramming and exceptions are perhaps two of the most popular features that are routinely banished from C++ projects.
fn = (a -> b) -> a
list.map(to(v => v * 2))
Ramda’s currying [0] gives you the _ param to play with the order. But I’ve come to the conclusion that currying in JS is rarely worth the effort. [1]
0 - https://github.com/ramda/ramda/blob/v0.28.0/source/__.js
Also, the new React beta docs at https://beta.reactjs.org teach function components rather than classes, and thus there's no use of `.bind()` at all.
That said, I did use it a TON in the jQuery days (event handlers).
Personally, I like to extract larger arrow functions and I am a fan of traditional function declarations in some situations over `const x = () => {}` style function assignment (I feel the latter unnecessarily clutters up code above the logic of the specific component, service or module since it must be declared prior to being used.) Those preferences do lead to needing an understanding of bind, call and apply. Or maybe understanding bind, call and apply lead to me feeling comfortable using those patterns?
Edit to add a bit of history: I started doing this when writing a fair amount of jQuery with a lot of event handlers. And while anonymous or arrow functions worked, the code was soo much cleaner when you put the handler functions below the regular logic. If someone wants to see what a handler function does, it's easy to go down and look, but otherwise, a good name is all that is important. These days, I follow similar patterns, extracting code that doesn't need to be inline into a function that can be referenced as needed, but doesn't need to be inline in the code all of the time.
I don't think is a specific thing of JS. The same happen with almost any language, product features...
With frameworks, it's easy to avoid them and unless you write lots of vanilla or you roll your own framework, they just don't come up, and therefore I expect my colleagues (and me) to just mess things up when we try to use them.
I saw .call just a few hours ago because until recently it was the safe way to call hasOwnProperty[1].
1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty#using_hasownproperty_as_a_property_name