Wow, execution context, lexical scope and closures were the biggest topics I wanted to write about. It's like you've made my dreams into a reality. Thank you lol! I'll be sure to check it out later and save these two articles for whenever I need a resource to refer somebody else to. I believe that many new Javascript developers don't have a solid grasp on these fundamentals because they learn them without really understanding the "context" of what's going on under the hood (of the Javascript engine) ;). So your articles are gold!
Thank you so much! Much appreciated 👍 I'm writing one more next week on 'this', 'bind', 'call'. I'm just ensuring I'm reading up first and understand them before writing them up. So, stay tuned!!
Ah yes, 'this', how could I have forgotten about that! My understanding of the 'this' object is that it's set based on the call-site of the function and falls under one of 4 rules: default binding, implicit binding, explicit binding, and "new"/constructor binding. It could also fall under more than one rule, then the order of precedence will apply. Learnt that from YDKJS.
And it might be good to provide some background by comparing 'this' between different programming languages:
In languages like Ruby or Java, this (or in case of Ruby self) will always point to the object in which your method is defined. So in Ruby if you are working on the foo method inside the Bar class, self will always point to the object which is the instance of the Bar class.
JavaScript works quite surprisingly here. Because in JavaScript function context is defined while calling the function, not while defining it! This is what can surprise many when coming to JS from different fields. Such late binding is a powerful mechanism which allows us to re-use loosely coupled functions in variety of contexts. reactkungfu.com/2015/07/why-and-ho...
Wow! That's well written :-) I'm from a Java background. For a long time, I detested learning JS primarily because I felt the language had too many loopholes and Typescript was sorta the answer to most of the language goofups that happened. Also, I would say until I moved to mgmt I viewed one language as a holy grail of things. But when I did become an engineering manager, I could see things in a much broader perspective. I understood that technology is an enabler for solving business problems and each piece of tech has their own set of strengths and weakness. It is for important for us to understand them and choose them wisely for the use case that needs to be solved. Unfortunately, I realised this almost a decade later. I cringe especially when people over-engineer things for the sake of learning new technologies. For e.g. I've seen several architects directly pitch in Kafka for a simple messaging system which even an Active MQ would suffice. The worst part is that they justify the decision by throwing the word scalability in the mix. Sorry for digressing. It is good to enjoy a good conversation after a long time. Thank you for your comments.I enjoyed reading them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Wow, execution context, lexical scope and closures were the biggest topics I wanted to write about. It's like you've made my dreams into a reality. Thank you lol! I'll be sure to check it out later and save these two articles for whenever I need a resource to refer somebody else to. I believe that many new Javascript developers don't have a solid grasp on these fundamentals because they learn them without really understanding the "context" of what's going on under the hood (of the Javascript engine) ;). So your articles are gold!
Thank you so much! Much appreciated 👍 I'm writing one more next week on 'this', 'bind', 'call'. I'm just ensuring I'm reading up first and understand them before writing them up. So, stay tuned!!
Ah yes, 'this', how could I have forgotten about that! My understanding of the 'this' object is that it's set based on the call-site of the function and falls under one of 4 rules: default binding, implicit binding, explicit binding, and "new"/constructor binding. It could also fall under more than one rule, then the order of precedence will apply. Learnt that from YDKJS.
And it might be good to provide some background by comparing 'this' between different programming languages:
Looking forward to your article!
Wow! That's well written :-) I'm from a Java background. For a long time, I detested learning JS primarily because I felt the language had too many loopholes and Typescript was sorta the answer to most of the language goofups that happened. Also, I would say until I moved to mgmt I viewed one language as a holy grail of things. But when I did become an engineering manager, I could see things in a much broader perspective. I understood that technology is an enabler for solving business problems and each piece of tech has their own set of strengths and weakness. It is for important for us to understand them and choose them wisely for the use case that needs to be solved. Unfortunately, I realised this almost a decade later. I cringe especially when people over-engineer things for the sake of learning new technologies. For e.g. I've seen several architects directly pitch in Kafka for a simple messaging system which even an Active MQ would suffice. The worst part is that they justify the decision by throwing the word scalability in the mix. Sorry for digressing. It is good to enjoy a good conversation after a long time. Thank you for your comments.I enjoyed reading them.