[lucisferre]

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.

[nostalgeek]

    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]

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]

> 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]

If it's not clear, the issue isn't about the keywords, which are clearly an improvement compared to ES5. The issue is about doing OOP in JS. Much has already been written about OOP vs functional/procedural so I'm not going to rehash that. The OP's point is that you don't have to write OOP code in JS and that he believes JS code is cleaner without it. I think it's a good point to bring up because many developers have difficultly imagining non-OOP code and bring in patterns from C++/C#/Java because it's what they know.

[hungerstrike]

I prefer OOP in JS and I have plenty of experience with functional JS. OOP code is more readable since functions have context and easier to reason about since there is way less indirection.

I wouldn’t say that apps written with functional style JS are cleaner at all.

[plurgid]

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]

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.

[jordan801]

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]

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

[mjburgess]

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]

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.

[thebokehwokeh2]

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.