Whatever you do, I'd recommend using Typescript to give you some type safety with your JS.

I don't like/use the class keyword in JS, because I quite like the paradigm with prototypes & stuff, and that keyword tries to make it fit into a totally different paradigm, which doesn't really work IMHO.

With TS, I find it even more useless, because I can use TS as a functional language, with POD, functions and interfaces only. I've written entire projects without ever using and needing this keyword, which is a proof IMHO that it's an unnecessary addition. Not sure how unpopular is my opinion tho 😅

BTW, I've developped a few strats to have my own style in TS that I like quite a lot. I can tell more if you're interested.

The class keyword exists for a reason and it has a perfectly fine use case when you need to make use of creating new objects. I think it may be disliked because people come over from Java assuming you need to define everything as objects/classes when we have modules and other methods of doing the same thing with a little bit less clutter. I recommend reading up on the underlying functionality and how classes and objects work compared to modules.

Probably on the "sparingly" end. As long as you're opting for composition over inheritance, it's probably fine.

Javascript isn't one of my main language, but using class avoids a few of the footguns Javascript has. You can't forget new, and extends/instanceof are far saner than duck typing.

Just dont throw away js classes just to use a framework with methods and components that act just like classes. I've seen that enough.

Also sometimes it just makes sense to use classes. Like with UI frameworks.

Classes are very great for their intended use case: the classification of objects.

It's very useful to combine a group of functions that only exist, and can only exist, in conjunction with another object. You also have the ability to take a type and morph it, allowing that one type to have large effects on everything that comes after it. But it has to be intentional. For example, a Button can be split and become an IconButton, or a ToggleButton, etc. It is a double-edged sword, since you can over complicate things when you don't need inheritance.

Many people make the mistake of throwing functions everywhere, but don't see the chain they create. For example: createFoo() will create an object. Then they'll make another function, or a set of functions, that can only work the result of that function. You essentially made a broken apart class. I saw this recently in lit. Their render function returns TemplateResult. Then they have a bunch of functions that only accept TemplateResult as input. That can be rebuilt as a class and have those functions part of the class. Breaking them up instead of using a class isn't necessary. It becomes extra weight to lug that result around instead of having the functions bound to it with this.

There is a good solid excuse for this practice, but it's not a logical one, but an unfortunate consequence of our build tools. Tree-shaking loose functions is much easily done than a class. Because class functions can be invoked by name, it becomes nearly impossible to tree-shake.

People also, sometimes, confuse declarative syntax with functional programming. You can take a class, and use it declaratively, if you build out some helper functions. For example, take a look at [https://github.com/clshortfuse/materialdesignweb/blob/ec892c6f646ea7155edd8f7579389b27d02aa2fb/components/Button.js](this code). It's still a class, that allows extensions, inheritance, function grouping, and construction, but you can manipulate it via a declarative syntax.

That's one of the reasons classes in JavaScript get a bad rap. It's structure is somewhat sporadic and can be hard to follow. But that's a syntax issue, not a construct issue.

That said you should strive to use both functions and classes. If you can simplify your functions to allow mostly any primitive input, that's great. It can be reused many times throughout your code. But if you have certain operations that only work with one type, then don't be afraid to use a class.

Classes are great for structuring code.

If you're just starting out, use them. To at least get a feel for them. Even if you later decide against them - in general or selectively.

You've asked about my favorite soap box! Thank you.

If possible, read this in the voice of that fast ad-copy guy who does medical disclaimers:

Classes suck in Java. Classes suck in C#. Classes suck in JavaScript.

Getting down in the weeds a bit, but bear with me:

Class objects are usually a crutch for keeping needless complexity isolated, but babied like a pet, rather than getting rid of it. A particular sign that this is happening is if there's inheritance in play, or a factory method.

Inheritance is bad and it should feel bad.

Most factory patterns owe more to a developer's massive ego, than to any emergent elegance in the problem space.

Everything good that comes from classes comes from interfaces. Interfaces are great, and they can do everything that classes can, but in a procedural way.

This message was brought to you by that weird cult some of us join after we try Haskell for the first time. It's a great cult. We have cookies every other Friday.

My opinion is you should use it when it's useful, but not when it's unnecessary. Their main use case is when you need to couple the functionality of functions to a shared state, and it's particularly useful when you have multiple interdependent functions that need to be tied to multiple codependent states.

I find it relatively rare when I really need to use a class. Between first class functions and closures and modules and other features, I find JavaScript has a lot of tools to avoid needing classes. Classes add complexity so I only use them when the complexity they add is less than the complexity of the task they're needed for.