3 ms·

I think if you ever have to interact with prototypes directly with JavaScript, it's by and large a smell: it's fraught with pitfalls (the notorious for...in iss

by vore 4y ago

I think if you ever have to interact with prototypes directly with JavaScript, it's by and large a smell: it's fraught with pitfalls (the notorious for...in issue of Prototype.js from years ago), more syntactically tedious than using ES classes, and is too dynamic to play nicely with static typing in a lot of cases. The model is historically interesting but probably not what you should be dealing with in 2023.

yamtaddle 4y ago
Seconding. Doing anything "interesting" with the distinctive features of the prototypal model is practically always a bad idea. Unless there's some much-better implementation out there in another language, I'd regard the whole model as basically a dead end. One giant obfuscatory foot-gun with nothing particularly necessary it enables that can't be accomplished well-enough with some other model.
deathanatos 4y ago
I think one spot where it is dicey is, obj[dynamic_property] = /* … */; … for which you must, rather unfortunately, be aware of prototypes. (And if you can use Map, you probably should… it avoids the JS footgun here.)
dmitriid 4y ago
The thing is, you can't really avoid them. It's an important part of the language, and not understanding my bring you pain. In mid-late-2000s when the first idea of adding classes to the syntax came up, even Microsoft eventually said: nah, it's a bad idea. It's grafting incompatible concepts onto a language that doesn't need them. And then Google in their "wisdom" went and forced classes onto the language. Take a guess why you need this for methods to work the way you expect them: class Logger { constructor () { this.method = this.method.bind(this); } method (some, params) { this.do_stuff() } /// ... }
- vore 4y ago
  I don't think you need prototypes to understand this, though it is maybe a consequence of them. If you remember that functions are just always free functions and calling them without a context means `this` has no context (unless they are bound or declared with a fat arrow), then I think that gets you 100% of the way there. `this`, of course, is a whole other bag of worms :(
  - dmitriid 4y ago
    > I don't think you need prototypes to understand this, though it is maybe a consequence of them. You do indeed need to understand prototypes to explain this behavior. "Free functions" doesn't really make sense, because it obviates the need for classes.
- imbnwa 4y ago
  Part of my gripe when React moved to class syntax was the loss of auto-binding, not that its an inherent part of prototypes or anything but I didn't get why that should be sacrificed for 'a standard', unless there was stuff I'd forgotten were important gains
  - dmitriid 4y ago
    > was the loss of auto-binding, not that its an inherent part of prototypes It is, because classes are a thin wrapper over prototypes, but the whole "classic C++-like" class shenanigans translate very poorly to Javascript. And yet, with maddening bravery browsers have spent 10 years trying to make them work in some capacity (and don't get me started on the whole private members thing, or the autobind proposals, or...)
- nicoburns 4y ago
  You can also do class Logger { method = (some, params) => { this.do_stuff() } /// ... } But your overall point stands.
- mikojan 4y ago
  > Take a guess why you need this for methods to work the way you expect them This is not Google's fault. It is the fault of Java developers. They expect everything to work like Java. They expect to find Java APIs everywhere. I have never written classes like that. In fact, if I were to see a method being used in the way you are insinuating I would believe to have found a bug. I strongly dislike class-based object orientation in general. But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore.
  - dmitriid 4y ago
    > This is not Google's fault. It quite literally is. In there desire to push web components they also pushed quite a few (often questionable) solutions. See 17:59 here: https://youtu.be/y-8Lmg5Gobw https://youtu.be/y-8Lmg5Gobw > But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore. There never were "dozens of ways". There always was only one: prototype based. And now there's this weird contraption on top that pretends its classes from C++-like languages (C++, Java, C# etc.) but is not.
jalino23 4y ago
this statement is naive. there are legacy codebases that dont use build systems or transpilers, still uses ES5 syntax. the minifier is a make file that concatenates the js files. its pitfalls should be understood and avoided instead of being afraid of JS prototypes
- vore 4y ago
  I agree, but you certainly shouldn't be dabbling with them for greenfield code.
- threatofrain 4y ago
  ...which is almost always true for any forward-looking prescription. If someone says "you don't need var anymore, just let and const", of course you can append to that conversation and say "isn't that so naive? what about codebases where you don't have a choice? You should understand var." I feel like the people who are in that situation know who they are. The rest of the world benefits from knowing what subset of the ecosystem they want to work with, as opposed to "you should know everything", which is the most inclusive and the least useful statement.

by vore 4y ago

yamtaddle 4y ago

Seconding. Doing anything "interesting" with the distinctive features of the prototypal model is practically always a bad idea. Unless there's some much-better implementation out there in another language, I'd regard the whole model as basically a dead end. One giant obfuscatory foot-gun with nothing particularly necessary it enables that can't be accomplished well-enough with some other model.

deathanatos 4y ago

I think one spot where it is dicey is, obj[dynamic_property] = /* … */; … for which you must, rather unfortunately, be aware of prototypes. (And if you can use Map, you probably should… it avoids the JS footgun here.)

dmitriid 4y ago

The thing is, you can't really avoid them. It's an important part of the language, and not understanding my bring you pain. In mid-late-2000s when the first idea of adding classes to the syntax came up, even Microsoft eventually said: nah, it's a bad idea. It's grafting incompatible concepts onto a language that doesn't need them. And then Google in their "wisdom" went and forced classes onto the language. Take a guess why you need this for methods to work the way you expect them: class Logger { constructor () { this.method = this.method.bind(this); } method (some, params) { this.do_stuff() } /// ... }

vore 4y ago
I don't think you need prototypes to understand this, though it is maybe a consequence of them. If you remember that functions are just always free functions and calling them without a context means `this` has no context (unless they are bound or declared with a fat arrow), then I think that gets you 100% of the way there. `this`, of course, is a whole other bag of worms :(
- dmitriid 4y ago
  > I don't think you need prototypes to understand this, though it is maybe a consequence of them. You do indeed need to understand prototypes to explain this behavior. "Free functions" doesn't really make sense, because it obviates the need for classes.
imbnwa 4y ago
Part of my gripe when React moved to class syntax was the loss of auto-binding, not that its an inherent part of prototypes or anything but I didn't get why that should be sacrificed for 'a standard', unless there was stuff I'd forgotten were important gains
- dmitriid 4y ago
  > was the loss of auto-binding, not that its an inherent part of prototypes It is, because classes are a thin wrapper over prototypes, but the whole "classic C++-like" class shenanigans translate very poorly to Javascript. And yet, with maddening bravery browsers have spent 10 years trying to make them work in some capacity (and don't get me started on the whole private members thing, or the autobind proposals, or...)
nicoburns 4y ago
You can also do class Logger { method = (some, params) => { this.do_stuff() } /// ... } But your overall point stands.
mikojan 4y ago
> Take a guess why you need this for methods to work the way you expect them This is not Google's fault. It is the fault of Java developers. They expect everything to work like Java. They expect to find Java APIs everywhere. I have never written classes like that. In fact, if I were to see a method being used in the way you are insinuating I would believe to have found a bug. I strongly dislike class-based object orientation in general. But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore.
- dmitriid 4y ago
  > This is not Google's fault. It quite literally is. In there desire to push web components they also pushed quite a few (often questionable) solutions. See 17:59 here: https://youtu.be/y-8Lmg5Gobw https://youtu.be/y-8Lmg5Gobw > But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore. There never were "dozens of ways". There always was only one: prototype based. And now there's this weird contraption on top that pretends its classes from C++-like languages (C++, Java, C# etc.) but is not.

jalino23 4y ago

this statement is naive. there are legacy codebases that dont use build systems or transpilers, still uses ES5 syntax. the minifier is a make file that concatenates the js files. its pitfalls should be understood and avoided instead of being afraid of JS prototypes

vore 4y ago
I agree, but you certainly shouldn't be dabbling with them for greenfield code.
threatofrain 4y ago
...which is almost always true for any forward-looking prescription. If someone says "you don't need var anymore, just let and const", of course you can append to that conversation and say "isn't that so naive? what about codebases where you don't have a choice? You should understand var." I feel like the people who are in that situation know who they are. The rest of the world benefits from knowing what subset of the ecosystem they want to work with, as opposed to "you should know everything", which is the most inclusive and the least useful statement.