Back to Notes
JavaScript was created in ten days
Blog post
A meditation on this, and "this"
[Brendan Eich](https://www.youtube.com/watch?v=krB0enBeSiE&ab_channel=LexFridman)
created JavaScript in ten days. It started as a way to add interactivity to the browser, effectively a hacker's tool, and now it's the world's most popular programming language. And just like English, its usage is diverse and constantly adapting to new situations.
I'd like to trace that versatility in a single world: `this`.
If you're coming from another object oriented language and start using JavaScript more seriously, at some point you come across the weirdness of `this`. It changes context. It's determined during runtime, which can be implicitly or explictly determined, depend on the style of writiing a function, and whether or not you're in `strict` mode. It doesn't just refer back to the object instance.
This behavior made DOM manipulation easier in the 90s, and jQuery relies on it heavily. However, during the early days of React, this behavior was really throwing me off. Consider this example:
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.handleClick = this.handleClick.bind(this);
}
handleClick() {
console.log(this); // will log the component instance
}
render() {
return ;
}
}
```
Before React introduced functional components and hooks, a component had to extend the `React.Component` class in order to use lifecycle methods. A common use case would be to add an event listener after the DOM element is rendered, or remove it after it's unmounted. Rather than dump everything into a render method, which should be responsible for rendering, it made sense to place the event handler into its own method.
But here's the rub: the render component creates a DOM element, which through user interaction adds an event to the event queue. The context of `this` at the moment is not the React component that rendered the DOM element, but the DOM element itself. That is why an explicit binding is required to the component:
```js
this.handleClick = this.handleClick.bind(this);
```
This is so counter intuitive, it's led to long and heated debates as to whether JavaScript can even be considered an object-oriented language at all. I believe the general verdict is "yes", but I'm no authority. JS supports objects, classes, inheritance, encapsulation, and polymorphism. Mozilla goes so far as to call JavaScript ["heavily object oriented"](https://developer.mozilla.org/en-US/docs/Glossary/OOP). Even functions are a type of object in JavaScript.
But `this` was just trying to be helpful.
## ES6 and hooks
Language moves much faster than modeling, both in spoken word and in software. Since hooks were introduced in React 16.8, the industry standard is to write functional components:
```jsx
import React from 'react';
function MyComponent() {
return (
);
}
```
In this new example, `this` will log as `undefined`, not the DOM element. That has nothing to do with React's new functionality, but with a feature in ES6. The `onClick` is passed an [arrow function expression](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions), which does not have its own `this` context. For this use case, it makes things much easier to read. So that's an example of the language specification evolving.
But the evolution of its usage, in this case during the introduction of hooks, I find just as interesting. Blog posts on hooks tend to focus on reusability or compactness as the reason why hooks are "awesome". But sticking to functions reduces what a developer needs to know so they can focus on rendering interface components. We don't need a world filled with working ontologists.
## Respect the "dumb"
Easy-going conversation in every-day life is filled with presumption. If I write a script to find a button element, and I want "this" to become disabled after a click, I expect the interpreter to understand what I mean. They say assumptions make an ass out of you and me, but those people have rich daddies and no deadlines.
React owes its popularity in large part to a certain graduation (rather than separation) of concerns, from the "smarter" data components responsible for fetching, routing and state management, which are mostly unique per application, to the "dumb" components that render the user interface. That spectrum of smart to dumb is not about the intelligence or skill of the developer, but about the level of dynamic context in a component. The scalability and popularity of React lies in these dumb components. Context is explicit in the form of `props` --- until it isn't. And then I get critical.
### Further reading
- https://enlear.academy/prototype-vs-class-the-javascript-split-personality-20d984d2fe2
- https://youtu.be/krB0enBeSiE?t=422