7 ms·

While it is good to understand how Javascript prototype inheritance works, I find it is best avoided , along with `this` and `class` syntactic sugar). It is ra

While it is good to understand how Javascript prototype inheritance works, I find it is best avoided , along with `this` and `class` syntactic sugar). It is rarely required and most anything can be achieved with very basic JS objects and functions which are simpler to work with, easier to reason about and easier to write tests for.

watty 9y ago
I disagree - not adapting to the latest language paradigms because you find it more difficult is code smell.
- mjburgess 9y ago
  Code smell describes code which has incurred technical debts among other things. People do not have it. The "latest language paradigms" in this case are JavaScript adopting a style of programming 40+ years old (Simula) -- despite its originating model being younger (self). Adopting paradigms because they are "recent additions" to a language is cargo cultism. Paradigms come with idioms that suit some problems better than others, and have all sorts of trade-offs and considerations. Inheritance is now widely regarded as a design approach, overall, best avoided. "easy to reason about" =/= hard to understand. The ease of reasoning about something is a feature of how complicated it makes it (partly, its incidental complexity). It's not to do with how dumb you are. Inhertiance, for example, creates systems that are often needlessly hard to reason about.
- hajile 9y ago
  We had a whole generation of class-heavy inheritance-ridden frameworks and applications. It's bad enough in static languages. In JS, it quickly becomes an unmaintainable pile of spaghetti. Object literals with small doses (read: 1-2 levels at most) can be good. Going further risks multi-level breakage because properties are bound to get added/removed across the codebase over time due to the dynamic nature of JS.
plurgid 9y ago
Yeah I dunno. There's like at least 3 or 4 different ways of constructing "classes" without the Class keyword. Frankly, that's a mess. I get that each has it's own advantages etc, but I don't WANT to figure out some hipster's clever new way of managing inheritance chains. I want to use the supported method of creating classes within the language. I prefer usage of the "Class" keyword because no matter how the language changes from here on out, it's a pretty safe bet that "Class" is going to always be the rightest way to do it, and the one that everyone else will understand.
- Can_Not 9y ago
  He's saying to prefer not using any version of classes, including the "hipster" alternatives to the class keyword, not just the class keyword itself. And I agree with him. But if I find the right use for classes, I enjoy using them. He was advocating for FP over OOP.
thebokehwokeh2 9y ago
I agree with prototype inheritance. I don't know how you avoid `this` and `class` though, especially with all client side code heavily relying on these. I don't know about you, but coding in mid 2000s where these things didn't exist was toothache inducing levels of pain. At least `class` syntactic sugar standardizes how things look. Just a cursory look at how an entire react would be written without class already sends shivers down my spine.
nostalgeek 9y ago
class Foo { Bar(){} } and a list of methods is in my opinion more readable than function Foo{} Foo.prototype.Bar =function(){} As for "avoid this". Really? this is part of Javascript, developers should understand it instead of "avoiding" it. > It is rarely required and most anything can be achieved with very basic JS objects and functions which are simpler to work with, easier to reason about and easier to write tests for. This is straight out false. It's no harder to "reason about" or "to write tests for". I get the impression that a tiny group of people are trying to push these ideas desperately for whatever reason, but it makes no sense, you're not the custodians of the language.
- thomasrognon 9y ago
  He's not telling people to not learn things or advocated changes to the language. Nor is he advocating the code you strawmanned above. He's saying he's found that `this` and `class` are best avoided. And I agree. I also agree that it's easier to test and reason about functional/procedural code or, more generally, code with fewer side effects and implicit state than OO code. People usually share these thoughts, not out of desperation or ulterior motive, but because they've had experience with many paradigms and they've found these the most effective.
  - nostalgeek 9y ago
    > He's not telling people to not learn things or advocated changes to the language. That's something he should be explaining himself instead of giving random advices about what he considers "good practices". Neither you or him did elaborate nor give justifications to your beliefs. And that's the biggest issues. According to my experience, there is nothing wrong with `class` and or `this`. These are features a Javascript developer should be comfortable with or they are not Javascript developers, because they are used everywhere in the JS ecosystem, including DOM api. It's very telling when you people never elaborate on what's wrong with `class` and `this` and just seem to repeat ready made talking points about what's `considered harmful`...
    - thomasrognon 9y ago
jordan801 9y ago
Work with D3.js and try to avoid "this". You'll be basically writing your own SVG manipulation library. Avoiding prototypes and classes, means you've got no normalized objects. Which, I suppose works, if you're more procedural and less object oriented. But, in most of the projects I've worked on, it'd be a hindrance far greater than simply understanding the caveats. I'm at about four years of JS development and I really haven't ran into issues like this. Maybe it's my lack of experience.

watty 9y ago

I disagree - not adapting to the latest language paradigms because you find it more difficult is code smell.

mjburgess 9y ago
Code smell describes code which has incurred technical debts among other things. People do not have it. The "latest language paradigms" in this case are JavaScript adopting a style of programming 40+ years old (Simula) -- despite its originating model being younger (self). Adopting paradigms because they are "recent additions" to a language is cargo cultism. Paradigms come with idioms that suit some problems better than others, and have all sorts of trade-offs and considerations. Inheritance is now widely regarded as a design approach, overall, best avoided. "easy to reason about" =/= hard to understand. The ease of reasoning about something is a feature of how complicated it makes it (partly, its incidental complexity). It's not to do with how dumb you are. Inhertiance, for example, creates systems that are often needlessly hard to reason about.
hajile 9y ago
We had a whole generation of class-heavy inheritance-ridden frameworks and applications. It's bad enough in static languages. In JS, it quickly becomes an unmaintainable pile of spaghetti. Object literals with small doses (read: 1-2 levels at most) can be good. Going further risks multi-level breakage because properties are bound to get added/removed across the codebase over time due to the dynamic nature of JS.

plurgid 9y ago

Yeah I dunno. There's like at least 3 or 4 different ways of constructing "classes" without the Class keyword. Frankly, that's a mess. I get that each has it's own advantages etc, but I don't WANT to figure out some hipster's clever new way of managing inheritance chains. I want to use the supported method of creating classes within the language. I prefer usage of the "Class" keyword because no matter how the language changes from here on out, it's a pretty safe bet that "Class" is going to always be the rightest way to do it, and the one that everyone else will understand.

Can_Not 9y ago
He's saying to prefer not using any version of classes, including the "hipster" alternatives to the class keyword, not just the class keyword itself. And I agree with him. But if I find the right use for classes, I enjoy using them. He was advocating for FP over OOP.

thebokehwokeh2 9y ago

I agree with prototype inheritance. I don't know how you avoid `this` and `class` though, especially with all client side code heavily relying on these. I don't know about you, but coding in mid 2000s where these things didn't exist was toothache inducing levels of pain. At least `class` syntactic sugar standardizes how things look. Just a cursory look at how an entire react would be written without class already sends shivers down my spine.

nostalgeek 9y ago

class Foo { Bar(){} } and a list of methods is in my opinion more readable than function Foo{} Foo.prototype.Bar =function(){} As for "avoid this". Really? this is part of Javascript, developers should understand it instead of "avoiding" it. > It is rarely required and most anything can be achieved with very basic JS objects and functions which are simpler to work with, easier to reason about and easier to write tests for. This is straight out false. It's no harder to "reason about" or "to write tests for". I get the impression that a tiny group of people are trying to push these ideas desperately for whatever reason, but it makes no sense, you're not the custodians of the language.

thomasrognon 9y ago
He's not telling people to not learn things or advocated changes to the language. Nor is he advocating the code you strawmanned above. He's saying he's found that `this` and `class` are best avoided. And I agree. I also agree that it's easier to test and reason about functional/procedural code or, more generally, code with fewer side effects and implicit state than OO code. People usually share these thoughts, not out of desperation or ulterior motive, but because they've had experience with many paradigms and they've found these the most effective.
- nostalgeek 9y ago
  > He's not telling people to not learn things or advocated changes to the language. That's something he should be explaining himself instead of giving random advices about what he considers "good practices". Neither you or him did elaborate nor give justifications to your beliefs. And that's the biggest issues. According to my experience, there is nothing wrong with `class` and or `this`. These are features a Javascript developer should be comfortable with or they are not Javascript developers, because they are used everywhere in the JS ecosystem, including DOM api. It's very telling when you people never elaborate on what's wrong with `class` and `this` and just seem to repeat ready made talking points about what's `considered harmful`...
  - thomasrognon 9y ago

jordan801 9y ago

Work with D3.js and try to avoid "this". You'll be basically writing your own SVG manipulation library. Avoiding prototypes and classes, means you've got no normalized objects. Which, I suppose works, if you're more procedural and less object oriented. But, in most of the projects I've worked on, it'd be a hindrance far greater than simply understanding the caveats. I'm at about four years of JS development and I really haven't ran into issues like this. Maybe it's my lack of experience.