I've been getting paid to write JS/TS for about 10 years. I think I've used the `class` keyword less than 5 times in the last 5 years and feel better off without it. I've found that a more functional style leads to better separation of state/data from any logic you have to write, allowing for a better testing experience and an easier time refactoring. Plus it means I have to think way less about what `this` means.

At the end of the day, features of languages are just tools, and sometimes they fit the problem you're trying to solve. I think it's also important to decide what tools to use in the context of what experience you and your team already have.

Also, it's hard to have small .js files when you use classes, and I love small files. I think Go made a great design decision to allow functions on structs to be implemented in separate files.

I once heard someone tell me that good OOP ends up looking very functional. I've taken that to heart, and I believe the code I write is better as a result.

I do use the `class` keyword in my js, but I'm also on a team of C++/Ruby programmers who are forced to write js, so the more I can do to make it more familiar, the better. As you said, it's just a tool. Some people like nails and some people like screws; there are objective advantages to each, but either one will hold a house together.

> I once heard someone tell me that good OOP ends up looking very functional.

Immutability and thinking about if a class should really be stateful are the major wins.

I was recently looking over some code that essentially just did transformations, but all the inputs and outputs were member variables, so it took some effort to track what creates what and what depends on what. The members also had empty defaults, so if you mix up the order you call the functions in, the code still appears to work. It wasn't "wrong;" it was hard to follow and error-prone.

Using 'classes' doesn't imply OO. They're a perfectly good way to organize data, at very least for data objects in TS.

It's fine to want to go functionally heavy, but if you're not using classes - which are the foundation of 'types' - then why bother with 'type'script? (Unless you mean to say 'interface'? Which is obviously not 'class' but implies the same usage of OO-founded keywords)

In TypeScript classes are in no way foundational. At the type level they are roughly implemented as a combination of two types: the instance type and the "newable" constructor function type.

Typescript works perfectly well without classes, even better sometimes (see decorators and Typescript).

The shape of data is more foundational than classes. An object without a class is a perfectly good way to organize data too, based on its shape.

Pure functions, polymorphism, inheritance, composition, factory functions, classes... All of those are tools. They have benefits and drawbacks that are circumstantial (they depend on the language, the problem, the time pressure to ship, the skill level of the team, and many more other factors). Extremely successful codebases have been written using almost any combination of those tools. What those codebases have in common is that the people who wrote them understood their tools. So if I were you I would strive for understanding.

In that spirit, it's good that you question what experienced people tell you. What about asking your friend to explain why, at a fundamental level, their recommendation is good? "Always use classes and inheritance" as a hard-and-fast rule is not very helpful.

This is a great answer. Life is about tradeoffs. Asked to tell the best way to do something, a good engineer pretty much always will answer "Well, it depends..." and list pros and cons of a tool.

I’m mostly the opposite: classes in JavaScript feel like a kludge invented to pretend JavaScript’s version of OOP is what people were familiar with in languages like Python, Java and C++.

If I’m going to write OOP JS, I generally prefer to use object literals and Object.create. However, I’ve mostly switched to the “Unix philosophy” style that libraries like Ramda promote: lots of sharp tools that are composed to build your programs.

I'm generally on your side. Functional style and composition are better styles than inheritance since inheritance is too rigid for most things. Inheritance often results in substantially more refactors required, and possibly even worse when at some point it's impossible to refactor.

With that said, in real-world projects, the bigger problem is to find the "greatest common divider" - which are the most common skillsets people are familiar with and settle with that. For example, in many full-stack projects, people are more familiar with the backend language which is mostly OO, and it might be a good idea to settle with OO style in the front-end as well. If the functional style is desired in the future, make sure to educate everybody, have a plan, set the direction so everybody can head toward it.

Some Scala projects are struggling with this issue. It results in mixed codebases, where OO guys cannot understand half of the codebase, and the functional guys are angry at OO guys who wouldn't learn, while keep introducing new novelty every month. Operating a team is more than technology, a key part is to keep everybody aligned, and make sure everybody was well taught with the knowledge they need.

> a friend of mine insists that I always use classes and inheritance, and that functional style / composition is bad

If that is really what your friend is saying, I would not listen to him. The world (including the world of programming) is bigger than "always use / do X".

Yes, your friend is wrong. Like langager, I've been getting paid to write JS/TS for some years now (okay not 10!). Maybe because I started off in Clojure/Script, I still tend toward a functional style - and even React these days is very functional.

I certainly am not opposed to using classes. If the problem begs to be thought of as a noun, then I will reach for a class to represent it. Especially if we have a collection of nouns, which are related.

But in general I prefer to code in verbs, piping data through a series of functions and then mapping over them at last to produce components, for instance.

Your friend is opinionated. I work on a large TS project which has classes at its core. While it does make sense to use Classes at some locations, it's not always an obvious choice. Writing and understanding Unit tests is painful in some places with classes. I keep business logic in classes and move the utility functions somewhere else(where I ensure functional paradigm). Writing Units Tests for such code is a breeze.

Tangentially, is there something implicit about class hierarchy and game development? Most engines and libraries are built on deeply-nested, hard to follow, inheritance models. I read about entity-component systems, but there's seemingly no big, functionally-oriented game engines. Why? Legacy? Typical languages (C++, C#, etc.)?

In my personal experience, the class syntax specifically gets used very infrequently. Proper prototypal inheritance was more common “back in the day” but my own preference and I _think_ what a lot of others are leaning towards these days is composition.

Learn to use both and make up your own mind!

The only valid use of class is to create nominal types in TS. Take a hint from the react devs, who even switched from compositional classes to functions (never inheritance though).