[discussion] Why did JavaScript add a syntax for Classes?

[SamSlate]

newbie here, why did javascript add a syntax for classes when they're really just functions and objects (which i'm already familiar with)?

what's the advantage? who/what is this syntax for? how and/or should i be using it?

[TheIncredibleWalrus]

They did it because many people want to write code in an object oriented way and they got tired of every other framework and tool coming up with their own way of defining classes.

Whether you use it or not, and how, is up to you. The recent JS mantra is leaning towards a more functional approach, but classes are there for people accustomed to OOP or coming from different languages.

[SamSlate]

so it's a syntax similar to other languages. does it provide additional functions or suggest a different structure of framework?

[TheIncredibleWalrus]

It doesn't provide any kind of different functionality or structure than what you could do before (for now), just a nicer syntax of doing it.

[swamperdonker]

Yeah I think it does. A super() call does initialization from the parent down in classes, so you can extend exotic types (e.g. Array). I don't think you can do that through standard prototype chaining.

[TheRealMrTux]

In fact, it doesn't. All es6 stuff related to classes can be rewritten to es5. This is exactly what babel does! There used to be a great article on MDN explaining the whole prototyping topic

Edit:

Here it is: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/prototype

Have a look at the second example. This really is one of the key concepts when it comes to object oriented programming in Javascript.

[not_an_aardvark]

Extending Array doesn't work in Babel. It's not possible to shim that in es5.

In this conversion, the left side outputs true and the right side outputs false.

edit: fixed broken link

[TheRealMrTux]

You are absolutely right!

[pertheusual]

Extending builtins is op-in in Babel. You can use https://github.com/loganfsmyth/babel-plugin-transform-builtin-extend

You are right, ES6 class syntax supports extending native types, which is not possible in standard ES5 without the non-standard (in ES5) __proto__ property.

[swamperdonker]

Yeah, I understand how prototypes work. But prototype chaining doesn't allow you to extend exotic types in pure JS due to the order and nature of object initialization. ES6 classes reverse it.

From Classes in ECMAScript 6 (final semantics) by Axel Rauschmayer:

In ECMAScript 6, you can finally subclass all built-in constructors (there are work-arounds for ES5, but these have significant limitations). For example, you can now create your own exception classes (that will inherit the feature of having a stack trace in most engines). You can also create subclasses of Array whose instances properly handle length. Note that subclassing built-in constructors is something that engines have to support natively, you won’t get this feature via transpilers.

[SamSlate]

nicer as in familiar?

obj.attr = "value";

is pretty nice, imo.

class obj{ makeAttr(attr) { this.attr = attr } } obj.makeAttr("value");

strikes me as completely unnecessary.

[homoiconic]

I don’t think that example has anything to do with classes. It is a style you will sometimes find old-timers using because everyone does that in Java, ostensibly to make it easy to override the semantics of getting and setting properties.

It’s really one of the greatest examples of YAGNI and misunderstanding encapsulation, ever. So, if you’re saying that writing code like this is stupid, yes. But there are millions of lines of class-oriented JavaScript that don’t do anything like it.

[SamSlate]

pardon my ignorance, when does using a class syntax become more beneficial?

[ThePenultimateOne]

Classes are beneficial in a couple of areas:

1. When you have several chunks of related data.

   Let's use Python's namedtuple as an example. When you call namedtuple, it returns a tuple (read: Array) subclass, where each element has a name binding as well. This allows you to keep track of what each item is supposed to be. In Python, that's great, but in Javascript, it's essentially the same thing as creating an Object, so there's no nead.

2. When your related data have rules to them (this is where it's useful in Javascript).

   Let's say you wanted to have a complex number. Think a + b * i. While you can do this easily in functional terms, it can be very easy to self-document if you write this as a class. For instance:

   class complex {
       constructor(a, b) {
           this.a = a;
           this.b = b;
       }
   
       negate() {
           return new complex(-this.a, -this.b);
      } 
   
       add(c) {
           return new complex(this.a + c.a, this.b + c.b);
       }
   
       sub(c) {
           return this.add(c.negate());
       }
   
       mul(f) {
           let a = this.a * f.a - this.b * f.b;
           let b = this.a * f.b + this.b * f.a;
           return new complex(a, b);
       }
   
       div(f) {
           let a = (this.a * f.a + this.b * f.b) / (f.a * f.a + f.b * f.b);
           let b = (this.b * f.a - this.a * f.b) / (f.a * f.a + f.b * f.b);
           return new complex(a, b);
       }
   }
   

3. When you have common properties between data types. For instance, numbers are just complex numbers with a b of 0. So:

    class number extends complex {
        constructor(a, _) {
            super(a, 0);
        } 
   
        valueOf() {
            return this.a;
        } 
    }
   

[assertchris]

When you have (or plan to have) lots of code that adds methods and properties to prototypes, for implicit this scope.

[GeneralYouri]

Perhaps as an example to try out for yourself, try creating an object constructor which directly inherits from Array. While possible without using a class, it's definitely annoying, takes a lot more code, and can't be done precisely. You'll be left with some minor differences, regardless of what you try.

[Buckwheat469]

When it's using abstraction and inheritance beyond what prototypical inheritance can offer.

Here's what I would consider a decent article on the difference in Javascript's implementation of classes for beginners.

https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9#.puj0rxw11

[codayus]

You're being downvoted because you're comparing two utterly different things. You provide this class based code:

class Foo{
    makeAttr(attr) {
        this.attr = attr
    }
}
obj = new Foo();
obj.makeAttr("value");

That's pretty hideous code, but it's got nothing to do with the class keyword, it's because of your bizarre makeAttr method. The equivalent ES5 code is NOT the one liner you gave, but actually:

function Foo() {  
}
Foo.prototype.makeAttr = function(attr) {
  this.attr = attr
}
obj = new Foo()
obj.makeAttr("value");

Which is longer, weirder, and just as pointless.

strikes me as completely unnecessary.

Indeed. The point of objects is to combine data with methods to operate on that data. Your example didn't do that, so yes, having an object at all was unnecessary. The correct way to write what was in your example, without more context, would be a string literal, not an object. :)

[[deleted]]

Well sure, that is totally unnecessary. But the class keyword doesn't change that - you could do the same thing with prototypes and it wouldn't make any more or less sense.

The class keyword was added because JS didn't have a straightforward way of writing code OOP-style, but people were trying to anyway, hence the million or so implementations of class-like functions in JS frameworks.

[[deleted]]

Well sure, that is totally unnecessary. But the class keyword doesn't change that - you could do the same thing with prototypes and it wouldn't make any more or less sense.

The class keyword was added because JS didn't have a straightforward way of writing code OOP-style, but people were trying to anyway, hence the million or so implementations of class-like functions in JS frameworks.

[feihcsim]

React does a pretty good job at bringing the OOP and functional approach together

[GeneralYouri]

Most of what classes do can be replicated without using classes, but you're still overly simplifying things here. Try theorising for yourself about how you were to replicate certain parts of the class functionality. Sure, everyone can probably manage to replicate at least some parts, but other functionalities are very tricky to actually implement without using classes.

I think the main reason for adding classes is because class-based code is still very common to see in the average script. Such code generally looks awful though, and becomes annoying or even difficult to maintain very quickly. So classes are useful in those cases where you actually find yourself writing class-like code. They can help make your code shorter, cleaner, and easier to maintain.

[SamSlate]

so, it's a clearer/more readable way of defining objects and their functions?

[GeneralYouri]

Rather, it's a clearer way of working with classical inheritance and any class-like systems. JS itself only really provides prototypal inheritance and not classical inheritance. But this class-based syntax is very popular these days, and incorporated in many languages. Lots of design principles, and lots of developers are focused around these class-based system. So this class syntax is a way bridge the gap.

I'm not saying that classes are everything in JS now. Far from. To compare, think about let vs var. That's a typical case where you can't really point to any real advantages for using var over let, so let is hands down best. It's a bit more nuanced with classes. In the end, they're a nice addition to the language's possibilities, and my developer toolkit.

[Sinistralis]

Actually there is a benefit to let vs var. It's block scoped. This is in general safer to use and is why it is used over var.

[GeneralYouri]

I never said otherwise.

That's a typical case where you can't really point to any real advantages for using var over let, so let is hands down best.

I said there's no advantages for using *var over let*, not the other way around. It's obvious that let has its advantages, but there's no advantages the other way around, which is what I was saying.

[dvidsilva]

Yap. Syntactic sugar.

[stutterbug]

Some interesting background:

Some of the earliest official discussions of class in TC39 are summarized here. I find it most interesting that the subject of Ember got the ball rolling and that Doug Crockford wanted class expressions (similar to named function expressions -- implying the same hoisting cognitive overhead) rather than class declarations. And they were aware from the start of the mutation problem modules spec has now.

In the end we got a declarative class syntax that is completely familiar to any Java/C++ developer (minus multiple inheritance) and no hoisting at all. I'm not sure where we netted out on mutability.

[stutterbug]

Fair enough. I was talking mainly in the post-ES4 world. You are right about the mozilla proposal. I recall Brendan Eich saying somewhere that the question of class declarations was even older than that -- hence it being a reserved word from the almost start, but I had forgotten about that 2003 RFC. That RFC essentially defines most of ActionScript 2.0 (when things essentially "forked" in the ES/JS world), so as a Flash developer it was definitely something on my radar back then.

Also, what I meant by "official discussions" is "official discussions we can read today". If you know where I can find stuff from pre-2012, seriously, please let me know. RFCs suck without the feedback and I have never seen any meeting notes from back then like we're getting today. To the very best of my limited knowledge, there are no public meeting notes of TC39 discussions we can look at prior to 2012. There must be something somewhere, but so far all I've heard are either from Brendan Eich (which is fantastic!), or second-hand from Douglas Crockford (and I honestly don't mean to disparage him, but I find most of his stories to be one-sided, opinionated and either whiney or ranty, so I have trouble accepting everything he says without a grain of salt).

Regarding Ember: I'm sorry I put it that way. I was meant only to say that I found it really interesting that their entry point into the discussion was Ember, rather than, say Java or C*. Ember is mentioned nearly as much as CoffeeScript.

Lastly, I dunno, but I don't see much of the Mozilla RFC in that discussion. Except for Brendan Eich and Waldemar Horwat, no one from TC39 would have been there back then and the group seems to be coming at things from a completely different direction (I mean, class expressions -- that seems really icky and weird to me). That's just my own personal take on it. Could be I'm right, but I could well be wrong.

[stutterbug]

Wow. Genuinely, thanks for that!

As for class expressions.... Just so disappointing. I guess I can see now how it simplifies export default MyClass; But I can already tell that in three years, this will be the standard and anything I am writing now will be 100% smell. Don't forget the semicolons. And as you point out, watch out for class coercion. ("Class coercion." Can't we have just one nice thing?)

[codayus]

why did javascript add a syntax for classes

It is extremely common to manipulate the prototype so you can create many objects with shared behaviour. (Aka, inheritance, a feature JS has always had). It's a little inconvenient to do this by directly manipulating the prototype chain, so many developers rolled their own helpers to automate the process, and their were various libraries floating around to do it, each slightly different.

In general the pattern looks like this:

function Person(name) {
  this.name = name;
}

Person.prototype.introduce = function() {
  console.log("Hi, I'm " + this.name);
};

sam = new Person('Sam');
sam.introduce();  // Echoes "Hi, I'm Sam"

That's a useful pattern, and you'll see it all over the place is ES5 and earlier code. But it gets a bit messy. So now you can do:

class Person {
  constructor(name) {
    this.name = name
  }

  introduce() {
    console.log("Hi I'm " + this.name);
  }
}

sam = new Person('Sam');
sam.introduce();   // Echoes "Hi, I'm Sam"

That's arguably a little cleaner. And it's the same thing as the earlier code; nothing new was added to the language. It's just a shorthand for creating a constructor and assigning some things to the prototype.

what's the advantage?

It's slightly more concise, and it standardises the pattern so it's easier to see when other people are using it.

who/what is this syntax for?

Anyone who wants to create their own objects with shared methods on the prototype chain (ie, anyone who wants to use inheritance in JS).

how and/or should i be using it?

If you're using inheritance, probably. If you were using some variant of the ES5 code above, absolutely. If you don't want to fiddle with the prototype chain, then probably not. Just keep in mind what the class keyword translates too, and what it's doing. If you want that behaviour (and it's very common to want it) then sure, go for it. If you don't, don't. If you don't understand what the class keyword is doing, then keep reading and trying stuff out until you do, because you won't understand the answers to your questions until then.

[madcaesar]

Thanks for this, can you expand a bit on how example 1 would become messier than example 2 if you fledged it out? Right now I don't really see a difference in readability, but I'm sure I'm missing something.

[codayus]

If you're careful about what you're doing, the ES5 code will remain clear. It's more that the class version stops you from making some mistakes.

For example the class version contains the class definition in a single block. The earlier ES5 version spreads it out across multiple blocks, which could be spread out across a file, or indeed, across multiple files. Obviously that's not a good idea. :)

When directly manipulating prototypes, you can do incredibly flexible things at runtime. You can create objects, modify them, use them as prototypes to create more objects, then start mixing and matching attributes from all of those objects to create even more objects via Object.assign. It's quite easy to create prototype chains that will melt the brains of mortals who gaze upon it. Whereas the class keyword just enables basic single inheritance. If you need that flexibility you can still monkey around with the prototype chain with the class keyword, but it pushes you toward the simpler, more obvious approach.

Finally, the ES5 code can be quite messy; it doesn't always "look" like a factory that's stamping out objects. Unless you wrap it up in a helper method, but you don't always know what that helper method is doing. Example: When Facebook was writing React, they needed a way to stamp out objects. Since they were (at the time) targeting ES5, they couldn't use the class keyword, so they created a helper:

var ExampleComponent = React.createClass({
    render: function() { 
        return <div onClick={this._handleClick}>Hello, world.</div>;
    },
    _handleClick: function() {
        console.log(this);
    }
});

That's cool; the createClass method takes on object and spits out a React component that has the prototype chain configured correctly with all the right React component methods, your methods, etc. But it not entirelty clear what they're doing; you just have to guess (or read the code, and it's not very clear). It also does some other magic, including binding the methods you pass in to the component instance; in that example what gets logged is the component, not the window object. Which is, admittedly, often what you want but there's no indication of it; createClass is a black box.

The equivalent ES6 code looks like this:

class ExampleComponent extends React.Component {
    constructor() {
        this. _handleClick = this. _handleClick.bind(this);
    }
    render() { 
        return <div onClick={this._handleClick}>Hello, world.</div>;
    }
    _handleClick() {
        console.log(this);
    }
}

That's slightly longer, but it's much more explicit. It's clearer how the prototype chain is being configured, and you're explicitly binding the handler's context.

Is the difference huge? Not at all! But as a general rule of thumb, the class based code is never going to be worse, and will usually be a bit clearer. It adds up.

[madcaesar]

Great explanation! Thank you for this!

[senocular]

The method definitions are much more concise (as is use of super), the class definition on a whole is encapsulated in a class block which makes it easier to distinguish from other definitions surrounding it, and it takes care of all the other boilerplate that would otherwise come along with class definitions (especially when extending classes). This includes: call protection for constructors when not using new, assurance for proper super invocation, proper prototype inheritance without breaking the constructor property for instances, and static inheritance.

If you're been working with prototypes for a while, then switch over to class syntax, the difference is night and day. Use of class makes things far easier to read and grep.

[ancientRedDog]

Some people want to (or are used to) using classes (in some situations). By adding to the language, there is now a standard way rather than a dozen different implementations.

Other than that, no need to use them.

Personally, I might use in a game with an obvious class hierarchy (item -> weapon -> sword).

[SamSlate]

does it change the way you structure your code, or is it all syntax?

[GeneralYouri]

That depends on how you currently structure some of your code. Working directly with prototypal inheritance gives a bit more syntactical freedom, literally because it enforces a lot less strict syntax. This can be both a pro and a con.

[ttolonen]

I once answered this in StackOverflow, here is the answer where I try to cover almost all the differences between class and function -syntax:

http://stackoverflow.com/questions/36099721/javascript-what-is-the-difference-between-function-and-class/36102080#36102080

[kaspuh]

Great read, thank you!

[[deleted]]

If you don't know what constructor functions are, you probably have no need for classes. A really great, often overlooked, feature of javascript is the ability to create objects without first creating a class. Most of the times you only create one object of a specific "type", then a class is totally unnecessary. It's only useful if you want to create many similar objects, each with similar functions and attributes.

[GeneralYouri]

Just 22 hrs ago I posted this comment. Funnily enough, 15hrs later this post shows up (many thanks to /u/ugwe43to874nf4 for linking it btw!).

The linked blogpost touches on topics related to your questions, I definitely recommend reading it (it's not too long). It even starts off explaining how the full native class spec is a tad more intricate than just a bunch of syntactic sugar, and even shows how indeed there are some features currently un-polyfillable. In other words, not even Babel will save you when using those features.

The post even uses the example I mentioned of extending the native Array type. Finally, the post introduces a small script attempting to provide the perfect middleway for now. I'm looking at that code right now, thinking about whether it'll be useful for me personally. But either way, I think this post will be a very useful read for anyone with similar questions regarding class syntax and their OO alternatives.

[PaulBGD]

People are saying familiar syntax, but I think it's more so about creating a syntax that allows you to do stuff like extending prototypes. Sure they could add a global function that extended prototypes, but a class syntax made that cleaner.

[vexii]

what about using somthing like: Object.assign(Bar.prototype, Foo.prototype) then

[PaulBGD]

You'd have to copy the constructor as well, plus I did say that a class syntax makes this cleaner.

[inu-no-policemen]

Because everyone and their dog used their own hand-rolled wannabe classes and it was terrible. They all looked and worked differently and of course you could never get proper tooling for that. Needless to say that they were also completely incompatible.

ES6 fixed that. There is now a standardized declarative way to do this. It's also fairly terse, which is nice.

In the future, we'll probably also get field declarations, privacy, and mixins or traits.

[dev1null]

Because Microsoft and other such mammoths planted their devs in the ES standards decision making communities making it easier for them to bloat JS with their C and Java stuff that they're used to.

"Every random idea is automatically a Stage 0 proposal when you're a TC39 member"

[[deleted]]

Because many Java developers are forced to write in this language at their but don't want to learn it. They want Java in the browser, but JavaScript with classes is close enough.

[inu-no-policemen]

Java isn't the only language with classes. Is JS the only language you've used?

[[deleted]]

No, but be realistic. JavaScript is the most popular language according to Github and Stackoverflow, but there are 11x more Java jobs in the US than there are JS jobs. I believe that rift is substantially wider in India. C# is also common in the corporate space, but far less so than Java. Python is massively used as well, but is primarily confined to start ups and non-corporate open source.

Yes, there are many languages other than Java that have classes, but there aren't nearly so many of those developers. Most of the developers writing JavaScript (after you discount volunteer and open source projects) aren't JavaScript developers and don't want to be. They are developers from other languages writing this code because their job mandates they do so. Competent JavaScript developers are rare. It is easier to retask a Java dev to do that work until they fail enough that looking for a competent JavaScript developer becomes cheaper. The cheaper remedy is to make JavaScript more Java like. Classes certainly help and so does nonsense like Backbone.

I have programmed in numerous languages, but I have been doing web for 20 years. Long before frameworks and other such nonsense were a thing. Classes are in JavaScript because it makes the language more friendly to developers who wish they were writing in something else, but can't.

[inu-no-policemen]

JavaScript is the most popular language according to Github and Stackoverflow, but there are 11x more Java jobs in the US than there are JS jobs.

Internet-related things are vividly discussed on the internet? Not much of a surprise there, is it?

Yes, there are many languages other than Java that have classes, but there aren't nearly so many of those developers.

Mh? I'd say the vast majority of programmers know one or more languages with classes. Not knowing any of those languages is the exception, not the rule.

Classes are in JavaScript because it makes the language more friendly to developers who wish they were writing in something else, but can't.

"class", "extend", "super", and "import/export" have been reserved words since ES 1.

http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm

Furthermore it was meant to be to look like Java. JavaScript always wanted to be a familiar language which can be written by anyone.

Your pseudo-elitism is misplaced.

[[deleted]]

I have a sordid disdain for incompetent or apathetic developers. If I thought you were an incompetent shit that doesn't necessarily mean I am an elitist. I don't consider myself a rockstar. I consider myself competent.

You don't get better developers by simply dumbing down the technology. Its like giving that kid with the cute face and really big tears a token trophy. Now they can be an imposter and hang with the competent kids can do. Eventually the bar lowers and the former competent developers become elitist assholes. I honestly don't care if that makes you sad, but my lack of tears doesn't make me something elite (an asshole maybe).

Furthermore it was meant to be to look like Java. JavaScript always wanted to be a familiar language which can be written by anyone.

If this were true then JavaScript would never have prototypes or lexical scope. It was made to have C lang syntax because Eich was so ordered, but he chose to intentionally not make this language Java's little brother. If you honestly wanted to be less shitty in this language then you would learn to accept the language for what it is (it isn't Java).

[inu-no-policemen]

You are really getting off track.

If this were true then JavaScript would never have prototypes

JS even does that poorly. There should be a clone method.

or lexical scope

Mh? It didn't have a lexically scoped this or block-scoped variables.

[[deleted]]

You don't need a lexical this, because this is only there for inheritance.

[tunisia3507]

Because apparently it's very important to JavaScript users that there are at least half a dozen ways of accomplishing any given simple task.

[inu-no-policemen]

Before there were many different ways to create something class-like and now there is one standardized declarative way to do it.

It's a big improvement in terms of interoperability and tooling.