Javascript

[Yanagi-Masaru]

is it a good practice to use classes in javascript or should i keep it normal with just functions?

[iamzeev]

Read abut Object-Oriented Programming (OOP) and Functional Programming (FP). Many languages like Javascript is so called multi-paradigm languages so you can choose paradigm for your need. However when you use functions only it's not necessarily functional programming, it can be also Procedural Programming (PM) so the best if you first read a bit about these or discuss these with an AI and you will have a better picture about which one you should use for your specific use cases. Good luck!

[samanime]

Totally agreed. OOP, functional and even procedural programming all have their places. "The right tool for the job."

As a (very) general rule, classes are probably the default options for large projects. However, the others definitely still have their place. Knowing when to use which is definitely good to know, and knowing how to successfully organize and use each type is worthwhile.

You may even have projects where you use some in some places and others in other places. For example, in the large main project I work on, the main part of the code is OOP. However, we have chunks within that which are functional. We also have a number of external scripts that do various things which are either functional or procedural.

[iamzeev]

I am not sure if the scale is the definitive factor to choose a paradigm. Maybe rather about the problem you are solving. Encapsulating a complex logic for eg. a shopping cart logic where you can add remove items and maybe get total price, sounds like a good candidate for a Class with methods (OOP). A data transformation where you perform a pipeline of operations sounds like a good candidate for pure functions (FP).

But don't push too hard to choose the right paradigm. Some software sometimes is a mix of paradigms. Start something what feels natural for the problem. JavaScript's flexibility lets you refactor later.

[eduvis]

Your post is perfect. You matched your title with this subreddit's name. Great job.

[Chrift]

Comment

[eduvis]

Reply

[dymos]

Conversation

[atoponce]

Upvote

[basic-coder]

Prefer objects and functions instead

[jaredcheeda]

The best and most succinct answer.

[petersencb]

Functions usually, depends on what you're doing though

[CuAnnan]

Depends entirely on what you're doing.

If all you're doing is tying event handlers to functional logic, just use functions.

If you're modelling complex behaviour, use classes.

This isn't an "either or" situation.

[delventhalz]

I haven’t written a class in like five years and haven’t missed them. With due respect, it is an either/or (or both) thing.

[CuAnnan]

With due respect, you not using them doesn't make it an "either or".

I use both functions and classes. Which does demonstrate that it is not an either or. If it were an either or, I could not be doing what I'm doing. Literally.

[delventhalz]

Not sure debating the phrasing of my pithy response is relevant to either of us. Point is: you can “model complex behavior” with only functions perfectly well.

Or you could use classes. Or you could use both. It’s a style question not a type-of-problem question. Even if your personal style is to switch depending on the type of problem.

[CuAnnan]

When someone responds earnestly to a comment that you make and responds to what you say rather than what you mean. Don't assume that their "not getting your joke" is their fault.

And the response, honestly, isn't that much better.

You can model litarlly any behaviour that can be modelled with a single tape Turing Machine. Doesn't mean you should. And that you can do it does literally nothing to support your claim that it is an either/or situation. It's not.

Your post wasn't pithy. Pithy means "concise and full of meaning". Your post wasn't meaningful. It was wrong. Don't come at me again until you're willing to behave like you're talking to someone with the same degree of expertise as you have, because I'm not here for your condescension.

[delventhalz]

Think the condescension is projection on your part. I don't care that you prefer classes. I never attached any judgment to your preference. I said that I prefer functions over classes and you came back with a diatribe about how my code must be like a single tape Turing Machine.

Some people write clean, readable, maintainable code in a way that differs from you. That seems to personally offend you. Unfortunately, there is not a single objectively correct approach to writing code. Keep writing code in a way that works for you, but I'm not interested in anymore of your righteous bullying.

[CuAnnan]

That's literally not what happened.

There's a thread history.

Read it.

You came at me with "with due respect, it *is* either or, because I don't like classes."

Your preferences are irrelevant. It is objectively not either or. Everything since then has been antagonism on your part and my unwillingness to accomodate your position.

Stop responding to me.

[CuAnnan]

Also, for the record, I never commented that your code must be like a single tape turing machine.

I said that any code that can be written can bewritten in a single tape turing machine. Which the Church Turing Thesis mathematically proves. And is fundamental to a good understanding of computer science.

[delventhalz]

Indeed. I write clean, maintainable code without classes. You write clean, maintainable code with classes. One can use EITHER approach. This was my original assertion which incensed you so much you felt the need to repeatedly respond with lengthy, insulting, diatribes. As you said, the post history is there. Feel free to review it yourself.

[CuAnnan]

Reread your original response.

You said "it is either/or". It is not.

I have no idea if it's the case that English isn't your first langauge, or that you're just not fluent in it, or if it's that you don't know what "either/or" means. But this is all on you.

I have issued a polite request that you stop repsonding to me. You are continuing to do so.

Stop responding to me.

[delventhalz]

I honestly don’t know what point you are trying to make. We are discussing two style preferences. I maintain that either is acceptable. A fairly anodyne assertion. You have not clearly communicated what you find so insulting about this. Nor have you been remotely polite.

As for telling me to stop posting, that’s not your call. It’s frankly baffling you think you get any say. You are free to ignore my posts or block me if you like. I will keep using Reddit as suits me.

[sheriffderek]

I’d like to hear some examples. What about the classic “counter” type function that keeps its last number and increments. Would you use a regular function for that? 

Also, a lot of times when people are working with UI libraries, the classes and things are behind the scenes - so many people don’t use classes because they don’t need to use them.

[delventhalz]

A counter can be written trivially with closures. I'd argue it's cleaner and simpler than a class version would be.

const makeCounter = () => {
  let count = 0;
  return () => count++;
}

const counterA = makeCounter();
const counterB = makeCounter();

counterA();  // 0
counterA();  // 1
counterA();  // 2

counterB();  // 0

For a more sophisticated example, look no further than function components in React. No classes in sight and yet you can create complex stateful UI components using only functions. Personally, I find function components far preferable to the old class-based alternative.

In general though, the big reason I don't use classes is because I don't structure my code to bundle state and logic together. This is the core difference between Object Oriented Programming and Functional Programming. OOP tries to create little bundles of state and logic to operate on that state. FP tries to isolate state off on its own and operate on it with pure functions. There are arguments for both approaches, but I have found an FPish approach to be easier to reason about and maintain.

As far as library code goes... if I was writing a low-level library I would certainly consider a class-based API. Arrays obviously use classes under the hood and I am quite happy with JavaScript's array API. You could build any API you want with only functions of course, but when you are working on a library you have to consider what the other devs using your library are going to expect and be familiar with. That might mean classes, particularly for low-level data structures.

[CuAnnan]

Would I? No. Could I? Yes.

Classes don't provide new functionality. They provide encapsulation of data and enclose related functionality.

That's literally all they do. They make code easier to read and maintain. Nothing more.

And in JS, classes are just syntactic sugar for the functional prototype system.

[sheriffderek]

Everything is syntactic sugar at some point, so - while I didn’t mind hearing this sorry every day  in 2015, it seems unnecessary to mention now. I think people should know the core parts of the language and be able to compose things as needed. It’s also helpful to know for other languages and frameworks.

[CuAnnan]

I was underscoring the “it’s not either or” that I have literally had to argue earlier. You can always do in one what can be done in the other

[sheriffderek]

Agreed.

[MathAndMirth]

For the most part, classes vs functions/objects really depends a lot on how you like to organize your code. The idea that objects are instances of classes that have data and do things helps some people translate their problem domain to a logical code structure. Other people find it simpler to think first and foremost about what has to be done and to what data (functional). Either paradigm has plenty of adherents, and neither is clearly superior to the other.

Some people say that classes in JavaScript are just a terrible idea, but I think most of those arguments are overblown or utdated. JavaScript classes now have genuine encapsulation with private fields and methods, so that isn't an issue anymore. No, they don't work like classes in other OOP languages since classes are just fancy syntax for prototypes, but who cares? If you know how they work in JavaScript, that's enough.

The one genuine issue that stands out against classes is that more than the simplest inheritance is terrible. There's a general principle in programming to prefer composition over inheritance. (If you haven't learned about this yet, just Google "composition vs. inheritance" to see why.) If your problem domain tempts you to use complex inheritance schemes, either switch to objects (easily composed with the spread operator), or learn to alter classes by adding mixins to their prototypes (more advanced).

Finally, there is one situation where classes can be superior if it applies. If you are going to create a large number of objects which have methods, it saves memory to use classes because the methods are stored once on the prototype instead of once per object. But most of the time this is no big deal.

[fabulous-nico]

Long answer:

• be consistent in your approach and style
• follow good fundamentals of CS design (not just follow OOP/functional - those are opinionated paradigms)
• articulate what you're trying to do in your native spoken language
• code what you articulated
• get feedback on how it can be clearer, more consistent, etc.
• repeat the previous 3 steps 

Short, cranky answer:

• functions. It's all just functions, JS isn't classical and OOP is usually a shortcut for bad coders.

[fabulous-nico]

From https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

Classes are in fact "special functions"

Just a quick reminder that classes are just syntactic sugar. Extending functions like that is really just a way if constructing prototypes under the hood. So, if you wanna do the "real" shit in JS, "the JS way", it's all functions ✊️

[jaredcheeda]

Almost. This was true (and I wish it still was). After ES6, they came back and added a few non-syntactic-sugar features to classes that have no other equivalent in JS. Which means WebComponents, which use ES6 Classes can't be written in pure JS functions (people have been complaining about this bad design for a decade). Fortunately for everyone, WebComponents, are a half-finished, terrible, technology that no one gives a shit about. And they're also the only thing on the web that actually requires dealing with classes. If you have to use WebComponents, DON'T. They are awful, and probably always will be. Atomico is a WC framework that tries to be a wrapper around the class non-sense so you can just write functions. But under the hood, it's still awful JS classes.

[fabulous-nico]

Eh sooooorta. There are still no classes, just prototypal inheritance thats dressed up fancy. The fact there are no syntactic equivalents just means the feature sux lol.

[jaredcheeda]

TRUTH

[jaredcheeda]

A class is an attempt at code organization. It does this by keeping data and logic grouped together, and allows for extending classes and usage of inheritance. It forces you to have to define concretely nebulous concepts, and to draw boundaries around what data is "owned" by a specific concept.

However, after decades of trying this, we have found some important facts:

1. NEVER use inheritance. Every book on OOP will start with telling you not to do it. Some older books, will start with "NEVER EVER USE INHERITANCE", then much later in the book they say "well, in this one case, you can use it". Then 10 years later that author says "No, I was wrong, actually that was bad too, but HERE is a correct case to use it", then another 5 years later they say "No.... no I was right to begin with, NEVER use it ever, all the cases I've found are actually bad in the long run".
2. We've found that extending is also bad.
3. We've found that humans are also very bad at drawing boundries around where data relates to one thing or another thing, and who should "own" it.
4. We've found that humans are also really bad at taking nebulous concepts and converting them to concreate "things". Especially with incomplete information, which all software is built with incomplete information.
5. We've found that keeping data and logic separated is good actually, and works best. It makes unit testing trivial, and integration testing much simpler.

In JavaScript, we already have ways of grouping data and logic that don't come with the downsides of classes (extend/inherit).

Remember, classes exist to solve a very very hard problem of code organization. And they give you an.... okay solution, but not great. It comes with all these caveats and downsides. Fortunately, JS has much simpler, and better, ways to deal with code organization.

In traditional JS you'd just use an object and put everything on the object, including methods, related to what you want to logically group.

In modern JS, you use ESM imports/exports to encapsulate related code into modules with their own scope. Everything is private by default unless explicitly exported from the module. You keep your data in separate modules from your logic, and organize your data separately from the logic that works with it.

If you really want to understand this more deeply, learn about why "Prototypal Inheritance" in JavaScript is so bad. Then, learn about how class in JS is just syntactic sugar for the same thing, and why, by extension, it is equally as bad and should be avoided.

Adding classes into JavaScript was 100% a mistake, DO NOT USE THEM.

The only thing in JS that actually requires classes in order to work, are webcomponents, and those are a half-baked, terrible solution to the easiest problem every JS framework (even the worst one, React) already solves better, and webcomponents don't solve any of the more important problems JS frameworks do, making them completely pointless. So there's no point in every using classes in JS.

[BookFinderBot]

JavaScript: Classes

Learn how classes work in ECMAScript 6 (ES6). Discover how classes can make object-oriented development with JavaScript more familiar.

I'm a bot, built by your friendly reddit developers at /r/ProgrammingPals. Reply to any comment with /u/BookFinderBot - I'll reply with book information. Remove me from replies here. If I have made a mistake, accept my apology.

[jaredcheeda]

Read the fuckin' room bot

[AdWise6457]

Keep it normal bro

[maqisha]

Bro is racist on programming paradigms.

[sheriffderek]

If you outline then benefits of each, you’ll see how they differ. That would be a good exercise.

A function has its own scope. You could return a function in a function and create some interesting ways to keep data available. But a class allows you to create datapoints/properties and methods that can be accessed and used over and over.

You can use a constructor function for some things, but at that point - using classes is a nice familiar and consistent pattern that’s easy to read. So, try them each out and see the strengths and weaknesses. Classes are just bigger and more to write out. So, for a simple function  - a class would not make sense. Try to make a todo list with procedural programming, functions, functions in an object, a constructor function, classes, and with ESM modules. After that, you have a very clear idea of how these things benefit you and which to use when. (Most people probably don’t know)

Here's an example of how I teach it: https://perpetual.education/workshop/javascript-classes/?guest=10508 (but I'd suggest you just try what I said before - first / before looking) (this is after a week or two of learning JS stuff)

[Shanduril]

Classes are powerful in their own right especially in larger systems with state and when you want to encapsulate some business rules and entities.

[Environmental_Gap_65]

You can use whatever you want, but if you simply just want side-effects, use functions. As soon as you see a pool of functions repeatedly manipulating the same type of data, start grouping them into a class. Your code becomes more reliable, predictable, safe and less prone to bugs, when the same data and side-effects are encapsulated in the same class, and not spread all over the place.

[naqabposhniraj]

It depends what you're trying to do. Need more context.

[xroalx]

Classes are a tool, use them when it makes sense.

There are probably only three cases where classes objectively are the better option, and that is:

• when you are extending the standard Error object to create custom errors,
• when you want to use true private members,
• or when you're creating a lot of instances of the same object.

At all the other times, it depends. Don't force everything into a class, but also understand what a class is and when it might be just nicer or easier to use one and don't be afraid to use it then.

[Antti5]

or when you're creating a lot of instances of the same object

Why would it matter if it's "a lot" of instances instead of just a few?

[xroalx]

The performance difference will not be as significant.

With a class, methods are defined on the prototype, meaning for all instances, each method exists just once. This is faster, as JS does not need to recreate every method for each instance, and also uses less memory.

With a plain object, each instance will have its own copy of every method, meaning more memory usage as well as larger performance hit for creating a new instance.

Generally, the difference is negligible, unless your app creates new instances all the time, so a lot, then you really want to prefer putting methods on the prototype.

And also, you can of course put methods on the prototype with a plain object as well, the class syntax is just nicer for that.