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.
class Foo {
Bar(){}
}
function Foo{}
Foo.prototype.Bar =function(){}
> 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.
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.
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`...
I wouldn’t say that apps written with functional style JS are cleaner at all.
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.
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.
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.
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.
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.