How JavaScript Works: deep dive into call, apply, and bind(blog.sessionstack.com)
blog.sessionstack.com
How JavaScript Works: deep dive into call, apply, and bind
https://blog.sessionstack.com/how-javascript-works-deep-dive-into-call-apply-and-bind-415f6729c902
126 comments
Call, bind and apply should be discarded and forgotten about, they add too much confusion, there are better ways, and they end up being used as terrible interview questions.
Incidentally, we should also discard `this`, unless directly inside an instance method of a class.
Incidentally, we should also discard `this`, unless directly inside an instance method of a class.
Every language has parts that are harder to understand because they unlock the deep magic.
If you really haven't found a use case for call/apply/bind, or are confused by `this`, it's more likely that your focus has been on thin-client user facing applications for most of your career. These language features are invaluable for tool building, and are foundational to most of the tools you probably leverage to make thin-client user facing apps
NOTE: most developers work in thin-client user facing applications, that's not a dig or anything, it's just where 99% of the work exists
If you really haven't found a use case for call/apply/bind, or are confused by `this`, it's more likely that your focus has been on thin-client user facing applications for most of your career. These language features are invaluable for tool building, and are foundational to most of the tools you probably leverage to make thin-client user facing apps
NOTE: most developers work in thin-client user facing applications, that's not a dig or anything, it's just where 99% of the work exists
I've worked full-stack in javascript for many years, and I've written plenty of libraries and tooling. I've used call/apply/bind/this extensively and I understand them to a fault.
I would still remove them in favor of arrow functions and spreads. Unless you can show me any code which is pivotal to writing some tool which absolutely can not be done using the alternatives.
I would still remove them in favor of arrow functions and spreads. Unless you can show me any code which is pivotal to writing some tool which absolutely can not be done using the alternatives.
arrow functions and spread do not cover all use cases of call/apply/bind
proxies and wrappers are two areas where you need call because you need be able able to pass the correct "this" which arrow functions will fail to do
proxies and wrappers are two areas where you need call because you need be able able to pass the correct "this" which arrow functions will fail to do
Yup in terms of patterns that are easier/harder to understand, I much prefer arrow functions over bind and map/forEach over apply. And explicit function parameters over call though how to replace call is often contextual.
It’s not that I inherently think call/apply/bind are bad (JS programmers should understand them), it’s just that they are old JS-isms and arrow functions/map/forEach/etc. follow pretty consistent conventions across multiple programming languages (readability) and with JS compilers you mostly don’t have to explicitly write JS in the old way any more.
It’s kind of like using malloc/variants in C++, you should be able to understand it, but you mostly shouldn’t need it in new code.
It’s not that I inherently think call/apply/bind are bad (JS programmers should understand them), it’s just that they are old JS-isms and arrow functions/map/forEach/etc. follow pretty consistent conventions across multiple programming languages (readability) and with JS compilers you mostly don’t have to explicitly write JS in the old way any more.
It’s kind of like using malloc/variants in C++, you should be able to understand it, but you mostly shouldn’t need it in new code.
Detecting that a value is an Object as opposed to an Array/Arguments/etc (or more generally, reading the StringTag of a value) still requires a toString.call(value) AFAIK.
This is still used a lot in recursive polymorphic code like virtual dom, AST traversal, deep cloning, etc.
This is still used a lot in recursive polymorphic code like virtual dom, AST traversal, deep cloning, etc.
`Array.prototype.slice.call(arguments)` is a good example. In fact, I'm struggling to think why you would replace anything other than bind with an arrow function
EDIT: My example is bad, you could just `[...arguments]`
EDIT: My example is bad, you could just `[...arguments]`
`Array.prototype.slice.call(arguments)` can be replaced with `Array.from(arguments)` (or as you mentioned `[ ...arguments ]`)
It's a pointless argument. These can't be removed from the language, without breaking a lot of code.
They can't be removed from the language, sure, but we can benefit by shunning the bad parts of the language, and using newer additions that are easier to reason about.
When's the last time you considered using a with(x){} block in JS? Would you still use var instead of let or const?
When's the last time you considered using a with(x){} block in JS? Would you still use var instead of let or const?
Quite a few years since I used `with` the last time. Not going back to that one.
`call/apply/bind` are normal functions though, not some fancy syntax construct, and `this` is important if you want to play with prototypes/Object.create, which is what you want to do if you found class syntax sugar lacking in features/extensibility/overrideability.
`call/apply/bind` are normal functions though, not some fancy syntax construct, and `this` is important if you want to play with prototypes/Object.create, which is what you want to do if you found class syntax sugar lacking in features/extensibility/overrideability.
[deleted]
>I would still remove them in favor of arrow functions and spreads.
Entire Javascript needs to be removed in favor of some other language. It's literally garbage. Callback hells, prototypal inheritance, constant new features ala async/await, Promises and a new framework every 2 years. It's not even a functional langauge just some features of functional language. Endless introduction of new syntactic sugar to cover up the old fuck-ups and weird behavior on every corner.
Entire Javascript needs to be removed in favor of some other language. It's literally garbage. Callback hells, prototypal inheritance, constant new features ala async/await, Promises and a new framework every 2 years. It's not even a functional langauge just some features of functional language. Endless introduction of new syntactic sugar to cover up the old fuck-ups and weird behavior on every corner.
I hear this sentiment pretty often but don't really get it. New features like async/await and Promises are added so that we don't have to do things the old/bad/confusing way any more - isn't that a good thing? Tools like linters and Typescript make it much easier to avoid the various 'old fuck-ups' and 'weird behavior'.
There is something slightly demoralizing about writing JS as if because of the language itself there is cruft, ugly workarounds, and type confusion from day one instead of developing over time. That said I find it effective and doubt it will ever be replaced by a more pure clean language.
You might not want to use magic not because you don't understand it, but because you don't want to rely on the future maintainer understanding it.
If you want to write future-proof software, you have to do it as simple as possible.
If you want to write future-proof software, you have to do it as simple as possible.
Assuming that future programmers will be less intelligent is a dangerous self-fulfilling prophecy.
Then again, I think we're already well on that path with some languages' ecosystems... if you don't want your jobs replaced by idiots, maybe you should not write code for idiots.
Then again, I think we're already well on that path with some languages' ecosystems... if you don't want your jobs replaced by idiots, maybe you should not write code for idiots.
> should be discarded and forgotten about, they add too much confusion
How does it add confusion?
Bind, call and apply are fairly straightforward and not difficult concepts to grasp for any mid to advanced level JS dev and they're useful in many scenarios (although bind is less useful / less needed now that we have arrow functions, but call and apply are definitely not something to be "discarded").
How does it add confusion?
Bind, call and apply are fairly straightforward and not difficult concepts to grasp for any mid to advanced level JS dev and they're useful in many scenarios (although bind is less useful / less needed now that we have arrow functions, but call and apply are definitely not something to be "discarded").
`call` and `apply` can also be replaced with arrow functions and splats.
How would you replace the classic `Array.prototype.map.call($nodeList, myFn)` with arrows and splat?
> The Array.from() static method creates a new, shallow-copied Array instance from an array-like or iterable object[0]
So, do this instead:
So, do this instead:
Array.from($nodeList, myFn)
I never knew this mapping variation of Array.from, that is slick!
Also serves as a great example of how JS is standardizing useful patterns that were previously accomplished via bending the language a bit.
Also serves as a great example of how JS is standardizing useful patterns that were previously accomplished via bending the language a bit.
You should forget about that too. It's applying a function from one object to something else that it wasn't designed for. It happens to work in this case because $nodeList and Arrays are both array-like, but that's a lucky happenstance.
Array prototype methods are designed to be applied to other objects. There's explicit language about it dating back to the first edition of the ECMAScript spec: "The map function is intentionally generic; it does not require that its this value be an Array object. Therefore it can be transferred to other kinds of objects for use as a method."
Yep, I just looked it up and it does indeed say that, at least for the 2016 version when all of these features were introduced. Fine! Carry on applying your maps to your non-Arrays!
Personally I think Array.of($nodeList).map(…) should be guaranteed to allocate once and then there’d be no more discussion here.
https://262.ecma-international.org/7.0/#sec-array.prototype....
Personally I think Array.of($nodeList).map(…) should be guaranteed to allocate once and then there’d be no more discussion here.
https://262.ecma-international.org/7.0/#sec-array.prototype....
You could do it like this:
const mapNodeList = (...nodeList) => nodeList.map(myFn);
mapNodeList(...$nodeList)That creates an entire extra list of garbage.
Doesn’t the compiler optimise it away?
Those aren't the same types. One is a DOM array and the other is a JS array. They don't share the same constructor or the same prototype chain.
const mapNodeList = (...nodeList) => nodeList.map(myFn);
mapNodeList(...$nodeList)
Or simply [...nodeList].map()
I don't think you can use splats with a NodeList. At least, the TypeScript compiler complains about it.
`[ ...document.body.childNodes ]` is legal. You need to have the `DOM.Iterable` enabled in your compilerOptions.libs` for TypeScript to permit it, though.
Works for me. Splats work for any iterable.
If the goal is to call functions on things whose prototype does not define them, then yes arrow functions cannot replace `call` and `apply`. They can't replace `bind` in such a situation either, but the precondition of this subthread was where `bind` can be replaced with an arrow function, ie the bound function is being called on the same `this` in the first place.
You can do it without either of those with this:
Array.from(nodeList$).map(myFunc)
or if you want to spread
[...nodeList$].map(myFunc)
Array.from(nodeList$).map(myFunc)
or if you want to spread
[...nodeList$].map(myFunc)
That creates a new array that must be GC'd.
Sure if you want to get nitty gritty, but you just asked how to replace it in the context of someone saying you can go without call and apply, which both of these do with the same input and output.
Unless your nodelist is insanely large, this is going to be a trivial GC to perform.
Unless your nodelist is insanely large, this is going to be a trivial GC to perform.
You know, people say stuff like this a lot, and I used to believe it.
But the web just feels like it’s getting slower, grinding up CPU. I think in aggregate, this stuff does matter and it’s just wishful thinking to say it doesn’t.
It’s like at some point as a profession we took the mantra of “don’t prematurely optimize” as an excuse.
Honestly, js feels like a much better language today, especially with ts, and hopefully there are improvements that can be made with modern approaches at the JIT layer, but until then, I’d love it if we could just have a more performant web. It might not matter to you on your powerful dev machine, but it does to me now that I’ve given up the powerful dev machine.
But the web just feels like it’s getting slower, grinding up CPU. I think in aggregate, this stuff does matter and it’s just wishful thinking to say it doesn’t.
It’s like at some point as a profession we took the mantra of “don’t prematurely optimize” as an excuse.
Honestly, js feels like a much better language today, especially with ts, and hopefully there are improvements that can be made with modern approaches at the JIT layer, but until then, I’d love it if we could just have a more performant web. It might not matter to you on your powerful dev machine, but it does to me now that I’ve given up the powerful dev machine.
any loop in a few hundred elements is going be trivial regardless of the amount of work you do.
I don't think the web is getting slower because we're using more map() instead of for...of loops. It's getting slower because what is being developed is getting more complex.
Feature bloat and excessive network load are the main reasons that the web feels slower imo.
I don't think the web is getting slower because we're using more map() instead of for...of loops. It's getting slower because what is being developed is getting more complex.
Feature bloat and excessive network load are the main reasons that the web feels slower imo.
I’m not sure this is a true disagreement is what I’m saying.
I can tell you that when I navigate around the web doing nothing more than having some web apps open, the UI for the whole OS will start stuttering and the fans will kick into action. `top` says this is all chrome.
I buy that the problem is “feature bloat,” but I also think a great deal of these features are possible with a heck of a lot less code and a heck of a lot less pointless GC etc.
.filter().map() may not itself be alarming for a few hundred elements…but it is for a few hundred elements multiplied by a few hundred features. If you still want those few hundred features, maybe it would be nice if some thought had gone into making them individually perform better.
Tangent: I love the Unix philosophy! Do one thing well. Nothing more satisfying than being able to pipe inputs to outputs and put together little programs out of modular components. But when you want to build a program, you don’t do that, because you care about the “well” part of “do one thing well.”
Context does matter for a lot of this, and I think there’s probably a lot of grey area here. Doing something high level? Whatever, just get the job done, focus on readability, don’t worry about the weird performance edges of it. It’s just that those chunks have a tendency to become bigger chunks and get included where they were never intended, or where their underlying implementation is accidentally replicated multiple times for slightly different outputs (in the abstract, like doing .map().map().map()).
Anyway I can tell I’m losing the thread and ranting mindlessly now…
I can tell you that when I navigate around the web doing nothing more than having some web apps open, the UI for the whole OS will start stuttering and the fans will kick into action. `top` says this is all chrome.
I buy that the problem is “feature bloat,” but I also think a great deal of these features are possible with a heck of a lot less code and a heck of a lot less pointless GC etc.
.filter().map() may not itself be alarming for a few hundred elements…but it is for a few hundred elements multiplied by a few hundred features. If you still want those few hundred features, maybe it would be nice if some thought had gone into making them individually perform better.
Tangent: I love the Unix philosophy! Do one thing well. Nothing more satisfying than being able to pipe inputs to outputs and put together little programs out of modular components. But when you want to build a program, you don’t do that, because you care about the “well” part of “do one thing well.”
Context does matter for a lot of this, and I think there’s probably a lot of grey area here. Doing something high level? Whatever, just get the job done, focus on readability, don’t worry about the weird performance edges of it. It’s just that those chunks have a tendency to become bigger chunks and get included where they were never intended, or where their underlying implementation is accidentally replicated multiple times for slightly different outputs (in the abstract, like doing .map().map().map()).
Anyway I can tell I’m losing the thread and ranting mindlessly now…
Is there actually a performance hit, though? Smells like premature optimisation to be worrying about this over readable code until you’ve profiled the actual effects.
yes, there is a performance hit.
In this case, the code size is about the same if you run as-is (if you're doing DOM manipulation, performance is likely a real concern). I'd agree it would be premature optimization if we were talking about moving from a map to a full-blown loop or something, but it's hardly a huge change.
Another great example is chaining myarr.filter().filter().map().map() or some such that I sometimes see. Lodash shortcuts normal map with the assumption of arrays without holes and then uses their own iterators to avoid multiple copies. This results in a huge performance boost.
A final consideration here is transpiling. The above methods would actually increase the code size quite a bit trying to work around any edge cases and hit performance even more.
"Premature Optimization" is always a matter of opinion. Some people might consider implementing quicksort instead of bubble sort to be a premature optimization. Others might disagree with me and believe that you should always use loops instead of forEach or map. In any case, this is hardly the only case for using call/apply.
In this case, the code size is about the same if you run as-is (if you're doing DOM manipulation, performance is likely a real concern). I'd agree it would be premature optimization if we were talking about moving from a map to a full-blown loop or something, but it's hardly a huge change.
Another great example is chaining myarr.filter().filter().map().map() or some such that I sometimes see. Lodash shortcuts normal map with the assumption of arrays without holes and then uses their own iterators to avoid multiple copies. This results in a huge performance boost.
A final consideration here is transpiling. The above methods would actually increase the code size quite a bit trying to work around any edge cases and hit performance even more.
"Premature Optimization" is always a matter of opinion. Some people might consider implementing quicksort instead of bubble sort to be a premature optimization. Others might disagree with me and believe that you should always use loops instead of forEach or map. In any case, this is hardly the only case for using call/apply.
Obviously there is a performance hit, my point is whether that hit is noteworthy at all. JavaScript VMs are incredibly efficient and have all manner of optimisations that aren’t apparent at first sight. Absent profiling data we can’t know and any best practises are really just shooting in the dark. For example: is Array.prototype.map just as efficient on non-arrays? What does it do internally, do we know it doesn’t create an array anyway?
The fact that NodeList doesn't have a native map feels to me like a wart, and doesn't really justify `Array.prototype.map.call` having to exist as a fallback in the language.
[deleted]
no they can not.
arrow binds a different "this" than call and apply. Call and apply get the this passed in at call time. Arrow gets the this at creation time.
arrow binds a different "this" than call and apply. Call and apply get the this passed in at call time. Arrow gets the this at creation time.
I figure there’s 3 possibilities: I’m just dumb, I don’t use it enough, or JavaScript is poorly designed. For some reason, even after 20 years of using JavaScript on and off and reading a dozen books about it, I can’t articulate exactly how the language works, how scope is evaluated, the composition of objects and prototypes which has some kind of turtles-all-the-way-down thing going on with it. When I read explanations in books it’s like hmm ok.. I guess that makes sense. Then a week later I don’t remember. The languages I’ve spent the most time with are SQL, PHP, Bash, and Clojure, and I never felt that way about them. Maybe it’s just me.
Prototypes are quite simple. An object may have a prototype. If it does then that prototype is just another object, which is considered the first objects parent (which works with method calls like class based inheritance). The chain ends because it's also possible for an object not to have a prototype.
My advice is to start of with javascript by forgetting 100% about classes, inheritance, prototypes, and so on.
Just use vanilla functions and objects, and when in need of something that looks like a class, reach for the revealing module pattern:
https://gist.github.com/zcaceres/bb0eec99c02dda6aac0e041d0d4...
Just use vanilla functions and objects, and when in need of something that looks like a class, reach for the revealing module pattern:
https://gist.github.com/zcaceres/bb0eec99c02dda6aac0e041d0d4...
Not recommended if you have lots of objects with this interface. Each object will have its own copy of each function. Using a class with the methods in a prototype ensures there is only one copy for all object instances.
It also makes specialization and calling super methods super verbose.
And you've ultimately not done anything other than reimplementing OOP, poorly.
It also makes specialization and calling super methods super verbose.
And you've ultimately not done anything other than reimplementing OOP, poorly.
You're not supposed to use `super` or specialization with factory functions, call the functions you need instead.
OOP inheritance does not belong in this pattern, even if you could hamfist it in (which you've already observed as unwieldy).
OOP inheritance does not belong in this pattern, even if you could hamfist it in (which you've already observed as unwieldy).
I've used this pattern before, but run into issues when you want to write tests for "private" functions (like loadSong() in this example). What I've done is name them like _loadSong and expose them anyways, but that doesn't feel great.
Is there a better way?
Is there a better way?
You don't write tests for private methods.
Of course private methods should be tested. These are unit tests, not functional/integration tests.
You don't unit test private methods, the "unit" is the exposed surface of the class.
Why not?
Because it’s assumed those private methods’ usage happens within public methods, which should be tested. By testing the public methods and all of its use cases you are also testing private ones. That way you can arbitrarily modify private methods without touching the tests (presuming you’re refactoring and don’t need to modify behavior).
This seems to be building on rocky foundations though. It's unlikely a functions entire test vector gets checked during testing. This is a known risk (you can't test everything) but by leaving all the functions under a public function untested there is no safety net.
If the code of the private methods cannot be fully exercised through the class' public interface, then that code never executes and should not even be in the function.
The most obvious reason is that they're private and not normally reachable from your test code.
But even conceptually there are problems with testing private methods. For example they likely expect to be called only while the class is in some specific state or in the middle of some atomic operation. Otherwise they could have just been made public.
But even conceptually there are problems with testing private methods. For example they likely expect to be called only while the class is in some specific state or in the middle of some atomic operation. Otherwise they could have just been made public.
+1
Maybe I don't write very complicated material, but I can't think of a single time I've needed to use the more OOP features of JS because one of them was the best or only solution.
Maybe I don't write very complicated material, but I can't think of a single time I've needed to use the more OOP features of JS because one of them was the best or only solution.
I also had this trouble, because for all other languages you can just tead the spec once and that’s it. But ES specs are too technical to be used as such. After few years I just read non-boring parts of ES6 and it cleared all dark corners.
I’d say all of the articles on the internet are rehashing the spec in (at best) a dubious and ritualistic way, and have zero technical value if you ask me.
I’d say all of the articles on the internet are rehashing the spec in (at best) a dubious and ritualistic way, and have zero technical value if you ask me.
FWIW the scoping in JavaScript is exactly the same in Go, so it's not something obscure that only JavaScript cooked up.
JavaScript is poorly designed. It was barely designed at all; Brendan Eich wrote it in ten days, and we would be better off if he had been a worse developer and hadn't been able to accomplish that. Instead Netscape shipped what should have been an internal 0.1, and got its deficiencies enshrined as documented features so they could never be fixed.
Ten day Mocha had strict ==, so better in that regard. History is detailed at https://youtu.be/krB0enBeSiE. Rather than assuming a too-simple version, check out the details for how things went down.
Do-overs not possible, by better new forms over time helped. Honest q: Do you actually use modern JS at all?
Do-overs not possible, by better new forms over time helped. Honest q: Do you actually use modern JS at all?
You get "clean and DRY" at the expense of "not beginner-friendly" and "you need be to very careful".
Thanks, but no thanks. I'll take clear, understandable code over clever footguns any day.
Thanks, but no thanks. I'll take clear, understandable code over clever footguns any day.
> Incidentally, we should also discard `this`, unless directly inside an instance method of a class.
We should discard classes instead. People have trouble understanding `this` because they insist on thinking in terms of classes and methods which are second class concepts in Javascript. Once I understood objects and prototypes, `this` also became easy to understand.
Programming with Object.create produced the cleanest code I've ever seen. Nothing but functions, objects and prototypes. I simply don't understand why the new versions of Javascript insist on adding even more of this class stuff.
We should discard classes instead. People have trouble understanding `this` because they insist on thinking in terms of classes and methods which are second class concepts in Javascript. Once I understood objects and prototypes, `this` also became easy to understand.
Programming with Object.create produced the cleanest code I've ever seen. Nothing but functions, objects and prototypes. I simply don't understand why the new versions of Javascript insist on adding even more of this class stuff.
I've literally never used them during my 8 years of working as a JS dev. Maybe I'm doing it wrong.
Edit: actually I did use .bind with React before arrow functions came
Edit: actually I did use .bind with React before arrow functions came
Until for..of came around, `Array.prototype.map.call($nodeList, myFn)` was pretty much the way to iterate over things that were "array-like" but didn't actually inherit from Array, so didn't have such methods.
They were pretty widely used (especially in library code) before arrow functions were added to the language.
There is literally NO substitute for either call or apply as they are low-level JS primitives. Arrow functions can go a long way toward handling .bind() scenarios, but I believe there are situations where you must still use .bind() to prevent constantly creating new functions (and the related garbage).
Show me some code you can only write using either call, apply, or bind.
Anything that substitutes ‘this’ but doesn’t want to put a function into that object.
const {filter} = []
class Foo {
less() {
return filter.call(this, sometest)
}
}
I would rather re-implement `filter` in a way that is specific to `Foo`, than to attempt to use an array method on my class.
.bind() does create a new function, though it has far less “slots” than a regular one. It doesn’t modify the original function. The spec doesn’t specify anything beyond that, afair, and if binds aren’t cached in some way (easy to check with === or roll up your own cachedBind()), GC barely can make any benefit out of collecting slightly smaller objects (but the interpreted part of a runtime may still process bound functions a little faster than closures doing the same thing).
As of source code or p-code or by whatever structure {<code>} body is represented inside, it is always* static for all closures, so there is no overhead apart from a closure itself between:
* of course jit may blur this distinction a lot, but that’s unrelated
As of source code or p-code or by whatever structure {<code>} body is represented inside, it is always* static for all closures, so there is no overhead apart from a closure itself between:
function foo() {<code>} // func
for (;;) foo()
let i = 0
for (;;) {
let j = 0
function foo() {i++; j++; <code>} // closure
foo()
}
* of course jit may blur this distinction a lot, but that’s unrelated
> Incidentally, we should also discard `this`, unless directly inside a class method.
When you say it has to be "directly," do you mean we should never use arrow functions (or use them only for looks)? Since the purpose of those is to add "this" support to inner functions?
When you say it has to be "directly," do you mean we should never use arrow functions (or use them only for looks)? Since the purpose of those is to add "this" support to inner functions?
Sorry, yeah, I did allow for closures inside class methods with that statement. That's fine by me.
I've had to cache a secure reference to call() in a JS library intended to exist in potentially hostile environments.
This call helper is often used to avoid prototype pollution vulnerabilities when patching native prototypes.
This call helper is often used to avoid prototype pollution vulnerabilities when patching native prototypes.
Very interested to learn more about this use case. This is to protect against hostile environments blocking function calls by polluting prototypes?
I do a lot of work on SDKs which run in semi-hostile environments, so prototype pollution is something I'm frequently running up against.
I do a lot of work on SDKs which run in semi-hostile environments, so prototype pollution is something I'm frequently running up against.
> This is to protect against hostile environments blocking function calls by polluting prototypes?
Correct. I go into more detail about into our problem space and use cases here: https://transcend.io/blog/defeating-cookie-banners
Correct. I go into more detail about into our problem space and use cases here: https://transcend.io/blog/defeating-cookie-banners
How do you want to do partial application if not through bind? All the other methods are much more verbose.
Sadly (or not, really) there are no class/instance methods in javascript, cause its key lookup model is prototype-based and ‘method’ functions just get ‘this’ lexically (in x.y.f(), f() operates on x.y). The combination of these two facts builds up an entire OOP in js. If you really want to free your code of these ideas, it’s much easier to use some js-transpilable language out there.
> in x.y.f(), f() operates on x.y
Yep, and I think that determining `this` at the call-site is really awful, and has been the cause of many more bugs than is reasonable.
OOP you can do in JS with just `class` and `extends`, you no longer need to care too much about prototypes and how they work. Prototypes have become much more of an implementation detail in recent years.
Yep, and I think that determining `this` at the call-site is really awful, and has been the cause of many more bugs than is reasonable.
OOP you can do in JS with just `class` and `extends`, you no longer need to care too much about prototypes and how they work. Prototypes have become much more of an implementation detail in recent years.
I think that determining `this` at the call-site is really awful, and has been the cause of many more bugs than is reasonable
That’s what almost all (more or less) dynamic languages do, except those that don’t have an arbitrary “object” struct. Out of few dynamic languages only python does what you need, at the cost of the enormous GC pressure. It’s okay for python because it was meant to be slow as hell by design.
And even then the solution would be more error-prone than the “issue” itself. Consider this code:
Your frustration is understandable, but I assure you that python’s “bound methods” are really awful to debug as well (been there done that), because the issue is not in functions taking “this” one way or another, but in a mismatch between developer’s expectations and reality.
That’s what almost all (more or less) dynamic languages do, except those that don’t have an arbitrary “object” struct. Out of few dynamic languages only python does what you need, at the cost of the enormous GC pressure. It’s okay for python because it was meant to be slow as hell by design.
And even then the solution would be more error-prone than the “issue” itself. Consider this code:
app.use(sass({
src: “.”,
log: console.log,
log2: function () {…},
}))
Your frustration is understandable, but I assure you that python’s “bound methods” are really awful to debug as well (been there done that), because the issue is not in functions taking “this” one way or another, but in a mismatch between developer’s expectations and reality.
I agree with you, it's definitely a trade-off between developer ease and perf.
I get around that in js mostly by avoiding classes and `this` entirely unless I'm sure I'm going to have a large number of instances of something. But there is the mental overhead of "Do I need to wrap this function in an arrow function before passing it around to avoid getting an unexpected `this`?"
So yeah, not saying I have a great solution -- just that none of the existing solutions really seem ideal.
I get around that in js mostly by avoiding classes and `this` entirely unless I'm sure I'm going to have a large number of instances of something. But there is the mental overhead of "Do I need to wrap this function in an arrow function before passing it around to avoid getting an unexpected `this`?"
So yeah, not saying I have a great solution -- just that none of the existing solutions really seem ideal.
Prototypes have become much more of an implementation detail in recent years.
First of all, it’s just a single-handed point of view. I’m using them from time to time, because js doesn’t end with reactjs hooks or frontend, and even frontend doesn’t end with just writing “frontend glueware”.
But even if it did, what exact mechanism do you propose to bind methods to instances? Automagic? It’s not just an “implementation detail”, it is a way of doing OOP in dynamic languages. Do you want all your objects to contain references to bound copies of all of the inherited methods? The way it is is for a reason, and the reason is, it doesn’t come for free.
First of all, it’s just a single-handed point of view. I’m using them from time to time, because js doesn’t end with reactjs hooks or frontend, and even frontend doesn’t end with just writing “frontend glueware”.
But even if it did, what exact mechanism do you propose to bind methods to instances? Automagic? It’s not just an “implementation detail”, it is a way of doing OOP in dynamic languages. Do you want all your objects to contain references to bound copies of all of the inherited methods? The way it is is for a reason, and the reason is, it doesn’t come for free.
We shouldn't use 'class' either
I came here to write exactly that.
There was once a time when such 'js ninja' skills were appropriate, but now they almost represent an anti-pattern in normal usage.
For some kind of framework, maybe.
But otherwise, they're just going to cause problems and they don't really provide something really valuable wherein another more basic use case wouldn't be better.
A pragmatic approach might be to 'stick to a solid version of Typescript' and even then be wary of the fancy stuff unless it's truly needed. (Say, you're building a lib or some core module).
There was once a time when such 'js ninja' skills were appropriate, but now they almost represent an anti-pattern in normal usage.
For some kind of framework, maybe.
But otherwise, they're just going to cause problems and they don't really provide something really valuable wherein another more basic use case wouldn't be better.
A pragmatic approach might be to 'stick to a solid version of Typescript' and even then be wary of the fancy stuff unless it's truly needed. (Say, you're building a lib or some core module).
My one annoyance with these is that they aren't supported in Typescript i.e no return types.
If you enable strict (https://www.typescriptlang.org/tsconfig#strict) or use the `strictBindCallApply` flag (https://www.typescriptlang.org/tsconfig#strictBindCallApply) it should check the types on call, bind and apply.
Cool, I never knew that
How much call, apply and bind is abstracted away in reactjs?
I also agree that the assignment of "this" is pretty difficult to grasp, especially in large codebases with callbacks, fn as arguments, and the issue still remains, despite fat arrow functions, async/await and promises. Someone mentioned prototypes, that's a double edged sword, it can help to have own prototypes but it can cause so much confusion.
I also agree that the assignment of "this" is pretty difficult to grasp, especially in large codebases with callbacks, fn as arguments, and the issue still remains, despite fat arrow functions, async/await and promises. Someone mentioned prototypes, that's a double edged sword, it can help to have own prototypes but it can cause so much confusion.
apply/bind/call aren't really abstracted away at all in react. In older versions they did do the binding magically for you, but when they made the switch to es6 classes they stopped doing that in favor of writing JS more like vanilla JS with less magic, outside of JSX of course.
Now with hooks/function components being the most common way of writing apps, there's almost no need for binding or dealing with "this" at all.
Now with hooks/function components being the most common way of writing apps, there's almost no need for binding or dealing with "this" at all.
I have probably used these functions only a handful of times since ES6 came out
I usually ace front-end interviews right until I feel insecure because I’m seriously asked about concepts I haven’t used in production after working in this field for 10 years.
My answer to this on an interview question is that I deliberately don’t use them and avoid using this because it unnecessarily increases complexity. If that’s a deal breaker then I’ve done us both a favor.
[deleted]
Yup! I know how these work, but it’s not in active working memory...definitely takes a minute. I generally consider them to be almost a code-smell.
Having done front-end for over 10 years, these interview questions still scare me, because I haven't used any of those in the real world.
Last time I used call, apply and bind was when a co-worker decided to roll his own JS framework.
It was as bad as it sounds.
It was as bad as it sounds.
Yeesh, it's a long article for a simple thing. They just let you control the implicit this arg to a function call.
fn.call(t, x, y, ...) calls fn(x, y, ...) with t as this.
fn.apply(t, args) is fn.call(t, ...args).
fn.bind(t, x, y, ...) is (...args) => fn.call(t, x, y, ..., ...args).
fn.call(t, x, y, ...) calls fn(x, y, ...) with t as this.
fn.apply(t, args) is fn.call(t, ...args).
fn.bind(t, x, y, ...) is (...args) => fn.call(t, x, y, ..., ...args).
Agreed, this article takes a long time to explain the easy part and slides right past the hard part, which is the mess that is the this argument in general.
> Call, Apply, and Bind help keep our code clean.
In my experience, the exact opposite is true. Modern JS is much cleaner with arrow functions and classes. If I see things like apply/call/bind now, I immediately think it's a smell left over from the ES5 days. I think there are still use-cases in library code, but I pretty much never want to see that in application code.
In my experience, the exact opposite is true. Modern JS is much cleaner with arrow functions and classes. If I see things like apply/call/bind now, I immediately think it's a smell left over from the ES5 days. I think there are still use-cases in library code, but I pretty much never want to see that in application code.
[deleted]
[deleted]
This all makes me remember the bad days of bind and bindAll and such and how I never ever have to think about this problem anymore and it’s just wonderful.
Can’t remember the last time I saw a ‘this’. Functional programming forever!
Can’t remember the last time I saw a ‘this’. Functional programming forever!
This sparked my memory of using "var self = this;" and "var _this = this;" Can't put my finger on it, but _this_ seems quite funny looking back on it (not to say it didn't work...)
I use this… but in classes in typescript and I’m quite happy to do so.
I’ve tried to use classes in TS and they’re just so weak that I always regret it.
I tried to have a base class with a default serializer method and bam, right back to binding problems.
I tried to have a base class with a default serializer method and bam, right back to binding problems.
Seriously. It feels like an entire area of JavaScript I pretty much never wade into anymore.
Why not?
Untechnically speaking: Arrow functions preserve the `this` in their declaration point, whereas regular functions change `this` if they're called as methods.
class Foo {
thisCouldBeAnything() {return this}
thisIsDefinitelyFoo = () => this
}
new Foo().thisCouldBeAnything.call('use me')
// 'use me'
new Foo().thisIsDefinitelyFoo.call('unused')
// Foo
New features were added to the language that make this sort of stuff unecessary.
Oof. These days, there are really only two uses cases I see for things like call and apply.
First, you're building some fancy clever JavaScript library (as opposed to regular nuts-and-bolts programming). Then sure, you know what you're doing.
Or second, you've got some really funky array/arguments processing that they either enable, or enable you to do in 1 line instead of 5. But for the love of god, avoid this if you can, and if you absolutely must, then please put it in its own descriptively-named function and/or write a helpful comment explaining it too! Usually, most people reading your code base will have no idea what the line does...
First, you're building some fancy clever JavaScript library (as opposed to regular nuts-and-bolts programming). Then sure, you know what you're doing.
Or second, you've got some really funky array/arguments processing that they either enable, or enable you to do in 1 line instead of 5. But for the love of god, avoid this if you can, and if you absolutely must, then please put it in its own descriptively-named function and/or write a helpful comment explaining it too! Usually, most people reading your code base will have no idea what the line does...
Maybe an unpopular opinion, but it feels like there is a new trend in celebrating this type of articles that does nothing but repeat already-known concepts without references, adds nothing new, and basically just there to pollute search engine results in the hope of self-promotion. If MDN Web Docs are not enough, there are better sources like YDKJS.
This is why I can't stand browsing any of the "programming" or "JavaScript" sections on Medium anymore. We get it already. You learned how promises or fp work. Move on.
Agreed, the only surprising thing is that this isn't a Medium post and (from glancing at the comments but not the article) it isn't glaringly wrong.
It is a Medium post.
> adds nothing new, and basically just there to pollute search engine results in the hope of self-promotion.
The web is big, messy and free (as in free speech), there is not a corpus of carefully written articles trying to extend human knowledge or something. It’s search engine fault for letting SEO (which feels like Spam Engine Optimization) pouring and making it into the index of supposedly relevant information based on your query.
The web is big, messy and free (as in free speech), there is not a corpus of carefully written articles trying to extend human knowledge or something. It’s search engine fault for letting SEO (which feels like Spam Engine Optimization) pouring and making it into the index of supposedly relevant information based on your query.
It does not return 8, it returns a function that returns a function that multiplies by 2. So multiplyByTwo()(4) would return 8.
The whole idea of currying with bind() is flawed, as it requires the programmer to think about `this` and can prefill many arguments at once, when currying is, in its essence, about breaking 1 function with N arguments into N functions with 1 argument.
There are more problems with other examples. The use of call() in the following snippet is also questionable:
multiplyMany could just be written as `return args.reduce(this.multiply)`. Why set the context twice with the empty array `[]` and then call(args,...)?
The rest of the article has plenty of unnatural or retorted demonstrations of call(), apply() and bind() that are neither illustrative nor educational.