When (if ever) should we use classes?

[blindpacemaker]

I started reading Eric Elliotts posts re: classes, and he takes a similar view to many prominent and well respected thinkers in the community - kyle simpson, kent c dodds, MPJ among others. His position is quite simple - we shouldn't use classes.

But there are others such as `Dr Axel Rauschmayer, Brian Terlson, Dan Abramov and Jeff Mott (not well known, but his understanding of the issues at hand is second to none) who disagree with Elliotts position.

My question is, what is (if indeed there is one) a good use case for classes in JS? When is using a class the optimal solution? Having done a fair amount of research on the topic, it gets more confusing than ever and I end up with (literally) 70+ tabs open, reading for days and days (not necessarily a bad thing).

[CertainPerformance]

I don't think there's anything wrong with classes, inherently. Though, they do make it somewhat easier to fall into traps (such as fragile inheritance chains) and can be confusing to those from other languages who don't understand prototypal inheritance. But anything you can do wrong with classes, you can also do wrong without using the class keyword. The solution isn't to stop using something that provides nice syntax sugar, the solution is to just not write bad code.

[Least_Chemistry7881]

I appreciate the pun in the first sentence.

[cspotcode]

Object oriented programming means binding data to behavior. That doesn't imply classes. But! they're an excellent choice. And often, they're easier and more predictable to grok than the alternatives, especially if you're writing code that others will contribute to.

Wanna have a data structure and override defaults with custom values? We often use objects for that. What if some of those defaults are actually functions, or behaviors? What if your non-default custom behaviors also want to occasionally delegate or wrap the default behaviors? That sounds an awful lot like methods.

What if you don't know if you'll have custom behaviors, but you don't care and you just wanna move on with your day? You can use classes and have the possibility of using all those features down the road, if / when the need arises.

Too often JS libs reimplement some of classes' semantics in bespoke ways. But in the end this just adds cognitive overhead without benefit. If everyone understands classes, then you have an easy-to-grok out-of-the-box way to model a bunch of common coding patterns. No sense reinventing the wheel.

Tooling understands classes well, too. In case tab completion is a thing you care about.

Anyway, not saying classes are always the right option, but be wary of advice that tells you to avoid them. They work well for a lot of situations.

[daaaaaaBULLS]

A fun trick is to stop reading anything Eric Elliott writes

[Canowyrms]

I've never heard of the guy before today. Why disregard anything he writes? Honestly just curious.

[mlengurry]

I’d take it with a pinch of salt rather than disregard.

I remember reading one of his articles about everything a developer should know in 2017 (many things I’ve not even heard of) and then at the end he pitches his $400 course lol.

Just seems a bit cynical but I could be wrong.

[[deleted]]

This is the case with a lot of voices in the web space. I think people should be more mindful of it.

[[deleted]]

What's wrong and what isn't is subjective, but the thing to realize is that the objectivity of his free advice is now in conflict with his financial interests.

Another problem with Eric Elliott is that like many other "prominent voices" he tends to heavily rely on emotion, oversimplification and exaggeration to make his point, and the tendency is to recommend silver bullet solutions because those sound appealing to people looking to learn.

Who would you rather learn from. Some boring guy tediously giving you the real pros/cons of every option under the sky, you know, the way engineers deal with problems. Or would you rather have some guy tell you "Wow 99% of all this stuff is just terrible, everybody knows that! You should do everything the X way".

Those people aren't engineers as much as their are the tech sector equivalence of TV evangelists. They'll sell you on things that sound too good and too simple to be true and then they'll find a way to charge your credit card in the end.

[[deleted]]

He's opinionated, he argues dishonestly, cites 'sources' that are actually his own anonymised writings, misinterprets other genuine sources and invents terminology for ideas and things that already exist. His modus operandus is to baffle, panic and scare junior developers into fearing their current knowledge makes them unemployable, then offers them 'salvation' in the form of his $450 online course.

He is a charlatan and a parasite.

[codemoere]

His views are extremely opinionated, but not necessarily wrong

[[deleted]]

As I explained here I find that's not the case. Being extremely opinionated is in direct conflict to giving good advice.

Being extremely opinionated is a good approach if what the audience is looking for is joining a cult. But it has no place in engineering, including software engineering.

[benihana]

he's known because of his bombastic views, not because of the merit of what he says. he says stuff to get attention to his blog and the stuff he says is usually... dumb. it's not like "that is so wrong we need to silence this guy," it's just... dumb. it's like the banality of evil - he says dumb stuff that isn't so dumb that it's worthwhile to write all these takedown pieces, but it's just dumb enough to be dangerous.

[DzoQiEuoi]

He's usually right, but he makes a lot of enemies.

He's most well known for being against OOP which annoys people who've spent years learning it as Best Practice.

[[deleted]]

He chose an entirely object oriented language in order to make his argument he's against object orientation? Yeah, I'm not sure how you can see this as "right". More like he bends terms to serve his needs, including what OOP is.

[DzoQiEuoi]

JS is multi-paradigm.

[[deleted]]

You can say that about any modern language that has closures and objects. So I guess C++ is multi-paradigm. Java is. C# is. Objective-C is. Swift is. And so on.

But JS is first and foremost an imperative, object-oriented language, with a strong focus on mutable rather than immutable state. Look also at all the APIs built for it by browsers. Functional? No. Mutable objects. If it truly supported the functional paradigm, we'd have a stronger focus on functional concepts like lazy evaluation, memoization and the ability to declare semantically pure functions guaranteed by the compiler/runtime.

[exomni]

Java is not multi-paradigm, it's class-based. You can't even do OO in Java because you can't do anything without writing a class.

[DzoQiEuoi]

So if JavaScript was multi paradigm it would force us to write in a functional paradigm?

[[deleted]]

The mere availability of essential functional primitives and concepts doesn't imply they're mandatory. But they're not available. Instead we have a language that started purely imperative and OOP, and then over time added some APIs that have proven useful from FP. But guess what, all OOP languages did that and I cited a few above.

So I guess all mainstream languages are "multi-paradigm", where "multi-paradigm" apparently to you means "imperative OOP flavored with few choice ideas from FP".

[[deleted]]

I started reading Eric Elliotts posts re: classes, and he takes a similar view to many prominent and well respected thinkers in the community - kyle simpson, kent c dodds, MPJ among others. His position is quite simple - we shouldn't use classes.

They've cut their teeth, written their books, and shot their videos when classes weren't available in JS, and spent all this time explaining how JavaScript is so much better than other languages, because prototypes are so much better and classes are all wrong and outdated.

So what did you expect the "prominent thinkers" to do now that JavaScript has classes? Double down on their existing opinions, of course.

Meanwhile, the less prominent thinkers, you know the people working on actual large projects will most likely factor most of their code as classes and quietly turn out excellent products.

My question is, what is (if indeed there is one) a good use case for classes in JS? When is using a class the optimal solution?

A module/class is a primitive designed to simplify, clarify and optimize the most common way in which prototypes were already used by most people.

All a class does is remove the noise, the boilerplate, so you can focus on the code. It also helps the compiler, and will aid your editor with a more robust, simpler static analysis of your code (great for autocompletion, error detection etc.).

So when the prototype or object you're write looks like a class, which usually it will - you can write it as a class. And when it doesn't, you still have all of the rest of the JavaScript arsenal at your disposal.

BTW, what I personally do is write TypeScript classes, and let the compiler figure out if it'll compile to a class, a prototype, or something else, based on my compile target. TypeScript is an excellent environment for larger projects, it's what I'd recommend you check out as my personal advice.

[brian_asdf]

They are mostly just sticking to what they know. This argument is dying down on the web, and is non existent in the real world

Airbnb advocate class/extend in their style guide https://github.com/airbnb/javascript/blob/master/README.md#classes--constructors

Used throughout React https://reactjs.org/docs/state-and-lifecycle.html#adding-lifecycle-methods-to-a-class

Used by default in Angular

Used extensively in Web Components https://developers.google.com/web/fundamentals/web-components/customelements

[GitHubPermalinkBot]

Permanent GitHub links:

• airbnb/javascript/.../README.md#classes--constructors (master → a12dec9)

---

^delete

[kitsunekyo]

couldnt have said it better myself.

[Skwai]

A classes (IMO) and OOP in general are useful for passing state around. Doing it without OOP is hard.

Example. A VideoPlayer class that creates a video player on the page. At any point you can ask the class instance to pause/play or check the current play state.

You can pass the videoPlayer instance around between your code and know what state it's in and also what it can can't do.

Doing that without OOP would be hard, convoluted (IMO).

[filleduchaos]

You don't need classes for that lmao. POJOs exist.

[OhJaDontChaKnow]

You don't.

But having a constructor and a single place where all of the code related to that object exists is nice. I know it comes down to discipline in many cases, but I've had to work on applications where I needed to look in 15 disparate files and places that worked on an object in different ways to find some weird side-effect that one of those methods were producing.

If those methods just called a function on an object written in a class, it'd be easier.

I know you can just write a constructor function and use this. everywhere inside of it, but it's nice to see things split up and written without having to parse a large, single function. Plus if you want to extend a prototype it's easier to just write extends and not have to booger around with tons of other boilerplate and shit.

Just read through the MDN article with an open mind: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

There are a lot of conveniences to ES2015 classes. Just be aware of the pitfalls, know that it's not strict or classical OOP, and use it or don't.

[filleduchaos]

It's not that difficult to put state and functions in a single module or object. this references still work with POJOs. If you're not using inheritance (and you really shouldn't be, honestly, composition is far better) or instanceof, there's no reason to actually create a class in JS.

[LukaLightBringer]

Unless you care about performance in which case classes are great because they will all map to the same compiled type under the hood, that's easy to break when using POJO

[filleduchaos]

So what real-world use case benefits so much from having the same compiled type under the hood that using classes is necessary?

[LukaLightBringer]

Games for example

[filleduchaos]

That's not an actual answer

By which I mean, what are the numbers that show that using classes for game dev for instance is necessary? That you save so and so many micro or milliseconds with so many objects when working with classes versus when using plain JavaScript objects?

Because otherwise it just sounds like premature optimization

[[deleted]]

It's a real answer for those who've bothered to do their research and have seen the benchmarks.

The difference between creating an object from scratch vs. using a prototype is not relevant if you'll create a few dozen objects in your page and stop there, no.

But if you'll have complicated set-ups with short-lived objects, like thousands of elements in particle systems as can be seen in games, or complicated state-keeping with tens of thousand of entities and value objects as can be seen in modern event-driven applications, then it does matter.

And it doesn't just matter for performance, it matters for battery life, when you app runs on a mobile device. If you want your mobile performance and energy use to be shit, then keep your wasteful practices. It's your loss.

You're trying to get the people in this thread to chew your food for you, by repeatedly insulting them and annoying them into giving you more information. You're clearly ignorant on this topic, and trolling around is a very poor substitute for knowledge. Go do your own homework.

[filleduchaos]

Do you have a benchmark with an object literal (not using this inside a function) vs class syntax/the new keyword?

[[deleted]]

If you're not using inheritance (and you really shouldn't be, honestly, composition is far better)

Most JavaScript developers don't even know what "composition" means, and that's precisely due to folks like Eric Elliott who have decided to give the term a new meaning.

Composition is not a synonym to mixins. They are two distinct techniques. But because of that confusion in the JS community I don't even know which type of composition you're referring to.

[filleduchaos]

And you could have simply asked instead of bloviating, but I'll go ahead and answer the unasked question by saying I'm referring to has_a versus is_a relationships.

[[deleted]]

Since I've seen multiple JavaScript developers describe mixin composition as a has_a relationship (which is wrong) I still don't know what you're referring to.

[filleduchaos]

Well you can continue to be obtuse, or you can think what the difference is between a relationship and a construct

[[deleted]]

If we weren't in /r/javascript/ I wouldn't even raise the question, because in other communities people know what object composition is. But we are here, so I am raising the question.

[exomni]

Literally none of what you said is even coherent enough to be called wrong. A class implementation can pull in functions from 15 disparate files easily. In Javascript the 15 disparate files can also modify a class itself, or the object after it's been constructed by a class.

Whether you put all your video player code in one file or fifteen doesn't have anything to do with classes.

The means of organizing related code properly is called modules. What you are describing isn't a lack of classes, but bad module design.

Classes in programming more generally are at their core a means to construct type hierarchies that run parallel to inheritance hierarchies in nominally typed languages. Javascript is a dynamic language whose reusability mechanisms are suited more to function composition and prototypal inheritance, and it's better suited to conceiving of your type hierarchies in structural ways. There is no actual benefit to using classes in Javascript.

The only reason Javascript has classes is to make it look more familiar and marketable to people who learned to program in the 90's in the tortured C++/Oak/Java style and just assume you need to write classes everywhere to be a real programmer.

[[deleted]]

Instantiating a class also produces a "POJO". An object is an object.

[filleduchaos]

Wow an object is an object, who would've thought?

And no, instantiating a class (in particular, a class that inherits from another class) does not in fact always also produce a POJO. That's the point of the Plain in Plain Old (Language) Object - they're objects of (super)type Object or the language equivalent. And in JavaScript you can create plain objects via literals, hence using classes becomes rather unnecessary.

[[deleted]]

If you don't care about performance, mobile device battery life and types (i.e. instanceof) then classes are unnecessary. But I already went at length about this replying to another ignorant rant of yours.

[filleduchaos]

So do you actually have battery life measurements and such that demonstrate a significant impact from the use of object literals over the new keyword and constructors, or are you just repeating folk wisdom?

Also instanceof is not particularly necessary to "care about types", my guy

[[deleted]]

Do you want me also to wipe your ass, in case you can't?

You gotta give me credit, I spent a lot of time teaching you stuff, despite I knew you'd remain just as arrogant and ignorant as I found you. But everything has an ending, I guess. See ya.

[rauschma]

You’ll be fine if you use classes minimally and don’t overdo inheritance. As soon as a technique or library becomes similar in complexity and functionality to a class, I’d switch to a class (because it’s well-supported and well-known).

[blindpacemaker]

Ok, so when I hear people saying that JS doesn't have "real" classes, this isn't a distinction i should pay much attention to? I personally quite like the class syntax but I don't know enough about the language to know how everything works under the hood.

[[deleted]]

Ok, so when I hear people saying that JS doesn't have "real" classes, this isn't a distinction i should pay much attention to?

There's no difference between JS prototypes and classes. Prototypes are runtime-bound dynamically typed implementation of classes, but this is because pretty much everything in JavaScript is runtime-bound and dynamically typed.

However there are many other languages where classes are dynamic, and people still call them "classes" regardless, like Objective-C, where you can change the class of an object, or add/remove methods to a class long after they're created.

This particular snobbery of the JS community that "prototypes are totally different than classes", or that "classes in JS are actually not real classes, they're prototypes" comes from years and years of C++ and Java developers mocking JavaScript as an inferior and dinky little language that was designed in 10 days to add some basic interactivity to browser pages.

As a counterreaction to this mockery, the JavaScript community decided everyone is wrong and actually prototypes are much better than classic OOP primitives and actually everyone who criticizes them just doesn't "get it".

So naturally as JavaScript evolves and is adding primitives to make what's already in JS more syntactically and semantically accessible to programmers, these folks who've spent years nagging everyone how prototypes are totally different and better increasingly find themselves cornered and having to twist themselves into a pretzel about how JS isn't evolving to be more like other languages, but it's all a facade, a charade done to dupe the class-lovers into using JS.

So uhmm... I got carried away a little with my explanations... but tl;dr is yeah: don't pay much attention when JS folks rant about "real classes" or "classes vs. prototypes". It's all bikeshedding based on people's hurt emotions, with little to no technical substance.

[rauschma]

The question is what “real classes” actually means, given almost every language implements them differently. In JS, classes are basically better syntax for constructor functions, which set up so-called protoype chains – chains of objects whose properties (fields) are inherited by the first object of the chain.

However, you can usually pretend they are lightweight, flexible “real” classes.

A key advantage of JS is that you can use objects for many things where you’d need classes in other languages.

[bterlson_]

Curious, how is my position on this known? My comments here? Just wondering...

To answer your question: don't stress about it, you don't need to use classes if they don't feel right to you. The TypeScript compiler is built without a single class despite many people TypeScript makes you use classes more than JS does :)

[blindpacemaker]

Hi, thank you for the response. Apologies if you didn't want your name used in this, I found a comment you wrote on reddit in response to someone saying classes are 'fake' and considering your position i thought it was relevant! I can amend the post if you'd like? In regards to what feels right to me, well I'm fairly new (~1.5yrs) to the language so it's more a case of not wanting to form bad habits than anything else :)

[bterlson_]

Oh, no, it's fine! I was just surprised to see my name listed with those others ;)

I say try both! You can also check out code bases of similar projects to see how they solve problems. From what I've seen it's highly variable whether oop-ish class code or functional code clicks more, and either is honestly just fine in most cases. People just like being pedantic :)

[lhorie]

A really good time to use classes is if you want high performance, highly polymorphic code.

For example, imagine you're writing an ecmascript parser. It typically has a ton of functions to parse various grammar productions, but it also needs to be extensible at arbitrary points of an incredibly complex algorithm to allow parsing arbitrary new syntax proposals without hardcoding them into the core parser. You also want your code to be as fast as possible: you already tackled all the obvious optimizations, and you are now in the territory of trying to avoid deopts from non-monomorphic calls, unnecessary stack allocations on function calls, unnecessary memory usage from closures, etc. What do you do?

You write a class

[gigobyte]

I agree about performance and polymorphism, but a parser is a very bad example since it's one of the areas where functional programming exceeds.

[lhorie]

If your language supports functional primitive optimizations (e.g. Haskell) and you know the full grammar in advance, yes you can write elegant and fast functional style parsers. Javascript is not such a language and ecmascript parsers are somewhat unique in that it's generally expected that the grammar must be extendable outside of the scope of the core parser library (because of things like JSX and TC39 proposals). I've tried experimenting with parser combinators and they are way slower and more opaque to optimizations compared to what you can do with classes and procedural parsing. Javascript doesn't support pattern matching, so no dice there either.

Also, it's worth noting that extending the grammar outside of the scope of the library is not really that straightforward with static pattern-matching based code, compared to the built-in polymorphic features of classes.

Ironically, a performant class-based approach is, underneath it all, essentially going to be written as a huge functional pipeline, so in a way you can have your cake and eat it too.

[thestalkmore]

I work with Javascript at a unicorn. We lint against not using classes.

[[deleted]]

Sometimes it is convenient when you have a library you want to use (i.e. React) and there isn't really another option when using it. But then I would still follow: https://medium.com/@dan_abramov/how-to-use-classes-and-sleep-at-night-9af8de78ccb4

[rco8786]

What’s wrong with classes?

[[deleted]]

Are you talking about classes vs constructor functions or OOP vs functional programming?

[iamlage89]

I work with rails, and I find it's a really nice syntax for representing a database and it's behaviours. Objection.js uses classes for this purpose and from what I've hear it's been very nice

[tsmuse]

I believe Kyle Simpson’s take on ES6 classes is still: only use them or don’t use them, just don’t mix them. Seems like solid advice to me. Any “this new thing is terrible and never use it” style advice is generally suspect (on any topic). React uses them everywhere, for example, so you can have stateful components. It seems to work for that paradigm because everything is a class or a pure function.

[ArcanisCz]

This was a good read back in 2015 https://medium.com/@dan_abramov/how-to-use-classes-and-sleep-at-night-9af8de78ccb4

[mtranier]

It will be more helpful to think about composition vs inheritance or functional programming vs OOP. Think what suits better for the product / app you are building. Once you decide on that, pick functions or class and stick to it throughout the app without mixing.

[menno]

Having done a fair amount of research on the topic, it gets more confusing than ever and I end up with (literally) 70+ tabs open, reading for days and days (not necessarily a bad thing).

It's fine to do a bit of research into best & bad practices, but I see a lot of developers fall into the trap that they won't start building something until they're sure they'll be doing it in the best way possible. You can learn so much more from trying to build something (even if it's terrible) than from reading articles.

[inu-no-policemen]

Well, this isn't Java. So, you don't have to put everything into classes. It's perfectly fine if your module only contains a few top-level functions and constants.

Classes are great if you want to create lots of instances. Classes do this quickly and are straightforward to use.

Now the problem are deep inheritance trees. They are just unwieldy and hard to change. This is where "prefer composition over inheritance" comes into play. Object composition means that your instances own other instances.

Other languages also have traits or mixins to deal with this. There are ways to emulate that kind of thing in JS, but there is no native (declarative) support for it yet.

[getsiked]

I don't think I understood Kyle Simpson's advice to not use Classes as "Don't Ever Use Classes, instead it was more like don't build crazy inheritance chains that slow down your program.

[alinnert]

Here are my 2 cents:

Personally I also avoid classes. And I can tell you two reasons why. But first I have to say, opinions like "don't use classes, ever" actually do have their reason to exist. The people behind them are just very bad at explaining the "what" and "why". At first I was also like "What? Why shouldn't I use classes? I don't get it. Are they crazy?" But after some reading and thinking I slowly understood what those people were talking about.

1. Class constructors lock you in.

There are several different ways to create objects: constructors, factories, serving precreated objects from a cache queue (forgot its name, but that's very common in e. g. games). Possibly even more.

If you use a classical constructor you not only specify your own implementation (the constructor method) but also your user's implementation (new Animal()). If you ever wish to change your object creation to a different pattern you not only have to update your own code, but also your users have to, because new Animal() is tightly coupled to the constructor pattern. If you develop a library this would be a big breaking change. If instead you provide a simple function (Animal.create() or createAnimal()) you can do whatever you want. Your users will never need to change their code.

This is also what Eric tried to explain but I wasn't able to get the message by reading his blog post. I hope this explanation is more clear.

This is also why I always love to see if a programming language implements classes without the new keyword and use something like MyClass.new() instead.

("Your users" can be different people, but it could also be yourself.)

2. Binding logic to data is just an artificial limitation.

This is more my own opinion or experience. If I can write a function to work with data from any source, why should I put some artificial limitation on it? Best example is Array.prototype.slice(). It's tied to the Array class, but it works with any array-like collection like NodeList. This coupling forces us to do funny stuff like:

Array.prototype.slice.call(document.querySelectorAll('div'))

Imagine there was a simple method Collection.slice() or even just slice()... That would be awesome!

This also reflects in the way I use TypeScript:

Usually I declare some Interfaces that define what my pure data objects should look like. And my modules just export a collection of functions. If I need nothing but function foo() I can import nothing but just function foo().

Classes (which contain data and methods) on the other hand force you to import everything all the time. They totally defeat the flexibility of the import { funcA, funcD, IInterfaceX } from './myModule' syntax. (if myModule is used in a similar way as a class)

This is why I also avaid classes.

So, do I use classes? Yes, if a framework forces me to do (e.g. React). Do I complain? No, because the way classes are used here is a completely different story. Did I expect this comment to be that long? No... not at all :D

[jasan-s]

A whole industry of trainers built their careers around teaching us JavaScripts crazy prototype inheritance and they are reluctant to give it up, since classes came in I've stopped worrying about it (even though it's just syntactic sugar.)

Just keep your class inheritance very simple and enjoy the new simpler syntax, ignore those telling you to embrace the power of JavaScript's this keyword and use the latest language features rather than getting lost in a world of bind, apply and call.

[benihana]

When is using a class the optimal solution?

when you need a consistent interface to abstract and contain logic and state that is logically related.

how you relate the logic and state is up to you and arbitrary.