JavaScript used to be a nice prototype based programming language...
Anyway, I'm more interested in how this site is being published. I'm on iOS and in vertical format words are cutoff with dashes properly for that format and when I switch to landscape other words are cut off that fit that format.
Is this some simple css attribute I missed completely?
> JavaScript used to be a nice prototype based programming language
"this" binding depending on the call site never made sense to me. Why do you think it became worse with arrow functions and Function.prototype.bind?
In case I'm not misunderstanding you. Tbh I haven't read the article so I'm only responding to your first sentence, since the CSS hyphens thing has been cleared up already.
By the way, CSS hyphens have been my most-wanted feature ever when I was working for a web design agency. So glad to see it gain traction over the years.
There are JS libraries for this, and of course they cause ugly page reflow and/or overhead.
Prime example of what should be in the CSS domain, and such a frequent problem when putting real content into design templates.
To be fair, most of these complaints about functions in JS are because its roots are still a nice prototype-based programming language and the `class` syntax sugar implies class-oriented things that JS doesn't deliver and confuses prototype-oriented features as class-oriented bugs. You can still use them as features, though we are getting close to the point where using them as features is an art form for arcane wizards that will make many, many JS users scream in terror and confusion.
There is a bit more nuance in using `this` in a named function that wasn't covered. Named functions defined in classes are scoped outside of the class, meaning they are not bound to the class. To use `this` in your named function, you usually have to bind it in the constructor using `this.functionName.bind(this)`
Arrow functions defined within a class are scoped and bound to the class automatically. Hence, arrow functions do not require calling the .bind in constructor, and you can happily use `this` inside arrow functions.
Late binding is also what the above poster is complaining about and they mention the habit some have in class constructors for "early binding" to try to avoid it.
The `class` keyword is as much "just" syntax sugar for stuff you can do without the `class` keyword. The behaviors are the same.
Late binding happens whether or not the function is a part of the Object's prototype chain or directly attached. JS is built so that's all mostly the same thing. That's why late binding exists. Maybe you copy a function from one prototype to another to create a new sort of prototype with a bit of "code-sharing", which is the same if you want to copy a function directly from one object to another. You want that function to work in all these cases, you don't want to redefine the function explicitly for a different kind of prototype or a different kind of object, you want to pick up what it is bound to by how it is called (thus late binding). Late binding is an ancient feature of JS that feels like a bug if you think `class` works like it does in OO languages like C++ or Java or C#. Late binding feels like a bug if you think of an Object's prototype as being a strongly formed contract and not a runtime object that itself can change at any time, or can be used as a lego brick to construct other types of objects and code-sharing beyond traditional class-based OOP "inheritance" models.
The difference between a "regular object" and thing constructed from a `class` in JS is effectively nonexistent. It's the same stuff, just a few syntax niceties. (In the old days, it was a lot harder to build a clean prototype, `class` makes it a lot cleaner. But that's all it does, it makes it cleaner to write, but under the hood it is entirely the same as it was.)
> in the constructor, using arrow functions?
The example above was the related but similar thing of doing `this.a = this.a.bind(this)` in a class constructor. It's very similar to using `this.a = () => …` arrow functions to early bind `this`. (Assigning a function to itself in a constructor with a `bind()` is also an idiom pattern that predates arrow functions and class syntax. Constructors predate class syntax, but they used to look a lot different. You can still write that form of constructor if you want, but class syntax is a lot cleaner.)
Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding.
Yes, I think we are on the same page. I did not want to include "legacy" prototype-based inheritance examples because I'm on a phone and didn't want to make complexity
explode here.
Also I made a weird statement here:
> That can also be done after the class was declared?
That doesn't make much sense for binding "this" to the class that was declared, I wsd mixing up arrow function class properties inside the class declaration with adding prototype properties (which is exactly what one doesn't want for classes with many instances).
In the scope of the class declaration, all methods of adding methods to the prototype are awkward, I guess.
Regarding the "early-binding" using .bind or arrow functions in constructor, I see your points, and it's the subtle and hard-to-explain differences that are really annoying.
JS really requires some discipline and sticking to a pit of success, while it's still essential to know the basics.
> Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding
Yes, that's what I was going at, thanks for making clear the difference between arrow functions (lexical scoping) and using `bind` (arbitrarily fixed "this").
I was lately (no pun!! really coincidence, it just wasn't only recently) using late binding with object literals in tests with Jest and TS and had to ignore TS there, it's pretty much the major reason I'm commenting here. It was convenient and succinct for a mock object implementing an interface otherwise used by class instances to use late binding.
By traditional media I mean blogs. I'm saying there are already a trillion high quality blog posts on this very topic. There's YT, wikis like MDN, bootcamps, real life or digital curriculum. These are all examples of "traditional" as opposed to chat bot style learning, which is completely new to the education space.
Also we definitely don't need more of this as training material, for humans or machines. It's not like you can't write a better introduction to JS, but by now the bar is very high and the likelihood of writing something good without pedagogical conviction is pretty bad, and this blog post is no different.
It has a mock pedagogical voice that people do when they think they're writing in a friendly way, a kind of pedagogical style developed in isolation from all other educators, whether traditional like YT & MDN or otherwise.
I would go to Gemini with specific questions I want answers to, while I'd go to Sinclair's JS blog for deep dives into topics I'm familiar with but don't thoroughly understand (or in some cases forget critical/helpful things that I once knew). They are different types of discovery and are both very valuable.
It might also help to know that this blog is well pre-chatgpt
I'm curious what's meant by "traditional media" here: do you mean specifically books? I can't imagine there are tv or radio broadcasts dedicated to web dev, at least not U.S.
Also, even before chatgpt you could bet that at any given time there are probably a couple of hundred blogs that are competently written by fairly smart people about the same topic. That wouldn't be pedagogical, it would just be a coupole of hundred blogs competently written by fairly smart people :shrugs:
JavaScript used to be a nice prototype based programming language...
Anyway, I'm more interested in how this site is being published. I'm on iOS and in vertical format words are cutoff with dashes properly for that format and when I switch to landscape other words are cut off that fit that format.
Is this some simple css attribute I missed completely?
> JavaScript used to be a nice prototype based programming language
"this" binding depending on the call site never made sense to me. Why do you think it became worse with arrow functions and Function.prototype.bind?
In case I'm not misunderstanding you. Tbh I haven't read the article so I'm only responding to your first sentence, since the CSS hyphens thing has been cleared up already.
By the way, CSS hyphens have been my most-wanted feature ever when I was working for a web design agency. So glad to see it gain traction over the years.
There are JS libraries for this, and of course they cause ugly page reflow and/or overhead.
Prime example of what should be in the CSS domain, and such a frequent problem when putting real content into design templates.
css hyphens?
https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens
I totally missed that. :) as long as the browser has a hyphenation dictionary for the language being used it will work.
To be fair, most of these complaints about functions in JS are because its roots are still a nice prototype-based programming language and the `class` syntax sugar implies class-oriented things that JS doesn't deliver and confuses prototype-oriented features as class-oriented bugs. You can still use them as features, though we are getting close to the point where using them as features is an art form for arcane wizards that will make many, many JS users scream in terror and confusion.
There is a bit more nuance in using `this` in a named function that wasn't covered. Named functions defined in classes are scoped outside of the class, meaning they are not bound to the class. To use `this` in your named function, you usually have to bind it in the constructor using `this.functionName.bind(this)`
Arrow functions defined within a class are scoped and bound to the class automatically. Hence, arrow functions do not require calling the .bind in constructor, and you can happily use `this` inside arrow functions.
The article misses even more nuance, independent from classes.
If you define
then will return "Hello"while
will throw an error.This predates generator functions and classes (which are only syntax sugar AFAIK).
And it seems like a glaring omission giving the submission title.
I'm ashamed though if it's in there and I missed it.
The behavior is called "late binding".
Late binding is also what the above poster is complaining about and they mention the habit some have in class constructors for "early binding" to try to avoid it.
Thanks for explaining, maybe I was missing the point there.
I was replying with this because it happens without using the "class" keyword (or "constructor") at all.
Not sure what you mean with the class constructor thing, but that's on me. I still don't understand these properly:
> Named functions defined in classes are scoped outside of the class, meaning they are not bound to the class
> the habit some have in class constructors for "early binding" to try to avoid it.
You mean using sth like
in the constructor, using arrow functions?I guess I'm missing something here.
That can also be done after the class was declared? The class keyword is only syntax sugar.
Anyway, I might be missing something important here.
That's why I brought up an example using an object literal, which has the prototype
Try it: These shenanigans are why I sometimes hate JS, but also agree that we should aim to understand the basics first.I love MDN for that.
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
The `class` keyword is as much "just" syntax sugar for stuff you can do without the `class` keyword. The behaviors are the same.
Late binding happens whether or not the function is a part of the Object's prototype chain or directly attached. JS is built so that's all mostly the same thing. That's why late binding exists. Maybe you copy a function from one prototype to another to create a new sort of prototype with a bit of "code-sharing", which is the same if you want to copy a function directly from one object to another. You want that function to work in all these cases, you don't want to redefine the function explicitly for a different kind of prototype or a different kind of object, you want to pick up what it is bound to by how it is called (thus late binding). Late binding is an ancient feature of JS that feels like a bug if you think `class` works like it does in OO languages like C++ or Java or C#. Late binding feels like a bug if you think of an Object's prototype as being a strongly formed contract and not a runtime object that itself can change at any time, or can be used as a lego brick to construct other types of objects and code-sharing beyond traditional class-based OOP "inheritance" models.
The difference between a "regular object" and thing constructed from a `class` in JS is effectively nonexistent. It's the same stuff, just a few syntax niceties. (In the old days, it was a lot harder to build a clean prototype, `class` makes it a lot cleaner. But that's all it does, it makes it cleaner to write, but under the hood it is entirely the same as it was.)
> in the constructor, using arrow functions?
The example above was the related but similar thing of doing `this.a = this.a.bind(this)` in a class constructor. It's very similar to using `this.a = () => …` arrow functions to early bind `this`. (Assigning a function to itself in a constructor with a `bind()` is also an idiom pattern that predates arrow functions and class syntax. Constructors predate class syntax, but they used to look a lot different. You can still write that form of constructor if you want, but class syntax is a lot cleaner.)
Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding.
Thank you for responding!
Yes, I think we are on the same page. I did not want to include "legacy" prototype-based inheritance examples because I'm on a phone and didn't want to make complexity explode here.
Also I made a weird statement here:
> That can also be done after the class was declared?
That doesn't make much sense for binding "this" to the class that was declared, I wsd mixing up arrow function class properties inside the class declaration with adding prototype properties (which is exactly what one doesn't want for classes with many instances).
In the scope of the class declaration, all methods of adding methods to the prototype are awkward, I guess.
Regarding the "early-binding" using .bind or arrow functions in constructor, I see your points, and it's the subtle and hard-to-explain differences that are really annoying.
JS really requires some discipline and sticking to a pit of success, while it's still essential to know the basics.
> Late binding is an old feature that feels like a bug today, so a lot of people work very hard to early bind functions or only ever use arrow functions because they don't trust late binding
Yes, that's what I was going at, thanks for making clear the difference between arrow functions (lexical scoping) and using `bind` (arbitrarily fixed "this").
I was lately (no pun!! really coincidence, it just wasn't only recently) using late binding with object literals in tests with Jest and TS and had to ignore TS there, it's pretty much the major reason I'm commenting here. It was convenient and succinct for a mock object implementing an interface otherwise used by class instances to use late binding.
Of course it's an error. 'a' isn't defined.
Lol, thanks, edited
I appreciate the article but I was waiting for Monads to appear.
one of my favorite JS bloggers, love his deep dives
[flagged]
Traditional media and chatgpt are just aggregators. Random blogs like this are where much of the training data for communication style comes from.
By traditional media I mean blogs. I'm saying there are already a trillion high quality blog posts on this very topic. There's YT, wikis like MDN, bootcamps, real life or digital curriculum. These are all examples of "traditional" as opposed to chat bot style learning, which is completely new to the education space.
Also we definitely don't need more of this as training material, for humans or machines. It's not like you can't write a better introduction to JS, but by now the bar is very high and the likelihood of writing something good without pedagogical conviction is pretty bad, and this blog post is no different.
It has a mock pedagogical voice that people do when they think they're writing in a friendly way, a kind of pedagogical style developed in isolation from all other educators, whether traditional like YT & MDN or otherwise.
> ChatGPT would thoroughly cover with probably zero fault?
If I'm trying to learn something, I want that probably in “probably zero fault” to be far smaller than an LLM can legitimately promise.
I would go to Gemini with specific questions I want answers to, while I'd go to Sinclair's JS blog for deep dives into topics I'm familiar with but don't thoroughly understand (or in some cases forget critical/helpful things that I once knew). They are different types of discovery and are both very valuable.
It might also help to know that this blog is well pre-chatgpt
I'm curious what's meant by "traditional media" here: do you mean specifically books? I can't imagine there are tv or radio broadcasts dedicated to web dev, at least not U.S.
Also, even before chatgpt you could bet that at any given time there are probably a couple of hundred blogs that are competently written by fairly smart people about the same topic. That wouldn't be pedagogical, it would just be a coupole of hundred blogs competently written by fairly smart people :shrugs:
you'd have to think to ask the question first.
these sort of deep cuts people generally learn by osmosis, it bobs up through the blog roll, in conversation, at code review, ...