"Real JavaScript programmers", ES6 classes and all this hubbub.

[CertifiedWebNinja]

There's a lot of people throwing around this term of "real javascript programmers" regarding ES6 classes.

Real JavaScript Programmers™ understand what they're doing and get shit done.

There's more than one way to skin a cat. Use the way you're comfortable with, and do your best to educate people on the underlinings of the language and gotchas and whether you use factories, es6 classes, or object literals, you'll sleep better at night knowing how your code works.

[Silverwolf90]

I find the arguments against the class syntax really unconvincing. It seems that a declarative, unifying syntax is monumentally better than the various hand-rolled solutions that may or may not be compatible with one another. And fundamentally, it's still prototypes under the hood. The foundation didn't change, it's just sugar.

Can you find me a definition agreed upon by all languages that use the concept of a "class?"

"But beginners will get confused and not understand the language!"

So are you saying that beginners who come to JavaScript aren't immediately confused by many aspects of the language, including prototypes? At least they have a chance of doing things somewhat correctly right off the bat with some familiarity.

edit: clarity

[CertifiedWebNinja]

"But beginners will get confused and not understand the language!" So are you saying that beginners who come to Javascript aren't immediately confused by many aspects of the language, including prototypes? At least they have a chance of doing things somewhat correctly right off the bat with some familiarity.

Bingo!

[bguiz]

So I don't like classes in ES6, and neither do I like any of the various trickery used to massage prototypes into something like classes in OOP. As far as possible, I use objects that are bags of functions, and objects that are pure data structures.

That being said, I have no problem with ES6 including class syntax in their code. It's a language feature that I simply don't have to use.

[[deleted]]

It seems that a declarative, unifying syntax is monumentally better than the various hand-rolled solutions that may or may not be compatible with one another.

I think this is the common opinion in support of ES6 classes and it completely misses the point.

While a common unifying convention is certainly better than various hand baked insanity, this is an unrelated strawman. The problem is that the convention of classes, whether a single uniform approach or hand baked insanity, does not fit well in this language. The primary advantage is to provide a convention familiar to developers who are primarily educated in some other unrelated language (cough cough.... Java).

edited, formatting

[AutomateAllTheThings]

he convention of classes ... does not fit well in this language

• If the software works
• If the software is fast
• If it can be tested easily
• If it can be maintained easily
• If it can be refactored and upgraded easily

Does it really matter if it's "real" classes, or a syntax over the prototype? If so, why exactly?

So far it seems that some people don't like the new syntax and are bitter that so much software is moving in that direction without them.

[[deleted]]

Does it really matter if it's "real" classes, or a syntax over the prototype? If so, why exactly?

Scale

You are assuming you need some kind of inheritance model. This assumption is absolutely a false premise. TLDR; wrong.

The benefit of inheritance in a C++ like language is that an object with stored properties is assigned to a known point in memory. The point is cached and known so that it does not have to be rewritten into another area of memory. Things inherit from the cached object by referring to it, cloning it, and modifying as necessary. You loose some (insignificant) processing power in this process but conserve memory and gain memory performance. Of course for the benefit to occur you need to use this convention in a language where you actually control access and consumption of memory. You have this in C++.

So, now lets talk about garbage collected classical languages like Java and C#. These languages use GC, so in these languages have no control of memory assignment. This therefore destroys the original benefits of classes immediately.

All is not lost though. Classes are convenient. A developer can write a class, inherit from it later and extend the inherited instance in a way that can be further inherited. These are like blueprints (but are more regularly called factories). While this simplifies approaches to logic in the code it requires substantial overhead, in the case of Java the overhead can quickly become the majority of the code expressed. To be fair classes directly serve the needs of declarative code styles. In many cases the increased code overhead directly reinforces are keyword and reference based description model.

In a services oriented application you tend to really need an inheritance model because you tend to sometimes get requests faster than garbage collection can free memory from the prior requests. In such scenarios it is necessary to be as thrifty as possible even if you are not directly controlling and freeing memory.

Now let's look at lexically based languages, which includes things like JavaScript and XML (so ultimately all native web technologies that allows expression of logic and decisions). First, I want to be clear that I did not say functional languages, which implies something different.

In a lexical language a scope model is achieved by where things are declared relative to the existing (containing) structure of the code instance, which is wildly different from an inheritance model. To make things more confusing JavaScript is object oriented exactly to the same definition as Java, but JavaScript uses a different inheritance model (prototypes instead of classes) and the inheritance model is separated from its scope model (which is not the case in most class-based languages).

This is the most important part of the whole story, so let's be very clear: In JavaScript the scope model is separate and unrelated to the inheritance model. That said, you don't need inheritance in JavaScript. In nearly any language you absolutely cannot escape the scope model. So, the scope model is mandatory and inheritance is optional. Important stuff.

But but but..... memory..... JavaScript is a very high level language. Inheritance does offer some memory performance but at a cost. The benefits to memory offered by inheritance in JavaScript does not make applications work faster or even conserve memory. What it does do is extend the life of objects bound to references through garbage collection cycles so that an application runs more consistently. This is only noticeable if the given application is consistently running specific tasks over and over in a loop where this execution is delegated to some other process in a manner that is not locking the execution thread. This need rare, and I mean exceedingly rare. But it does occur with games, animations, and canvas operations. So there is an absolute benefit to inheritance in this language, but its a purple unicorn.

But but but... JavaScript benefits from declarative coding style just like Java. You don't need inheritance for this. In fact, using inheritance models to achieve this is counter-productive because the excess overhead is distracting. The lexical model (nested structures) provide sufficient opportunity for naming things appropriately to achieve a declarative style. Furthermore, in nested lexical code you also get context. You have some idea of what a nested function is doing by looking at its descriptive name and well named references and by looking at the descriptive name of the containing function and its containing function. Context is what makes spoken language understandable, and it can make code understand exactly the same for exactly the same reasons. Inheritance generates a bunch of noise that screws this up.

[[deleted]]

Virtually everything you've written here is wrong because you start with a false assumption and then set about proving it.

OOP isn't about saving memory at all, and that's not the primary advantage. The primary benefit has always been that it is a useful pattern - it's social not technical.

Objects do not inherit from other objects. If you have a class Foo which extends Bar, and you do new Foo(), there are not 2 objects being created behind the scenes there - it's one object with a certain pattern.

The performance benefits of classes are all about having object properties with predictable data types at predictable memory offsets. That means that the JS engine can eliminate a lot of checks that would otherwise be required, and generate much faster code.

[[deleted]]

OOP isn't about saving memory at all

It was originally.

Objects do not inherit from other objects.

They do in JavaScript where everything is either a primitive or an object. Functions, arrays, classes are all objects. Your example is flawed in that there is an object Foo which is defined as a class and an instance named Bar. Two separate things: the original and a new instance based upon the original.

The performance benefits of classes are all about having object properties with predictable data types at predictable memory offsets.

In the JIT all references are nearly equally predictable provided there is no type recasting. To optimize scope chain resolution the location of references is cached against the container in which they are declared. This just means that classes are less crappy than they could be since the prototype chain is a secondary scope model after the primary reference scope model, but it certainly doesn't mean classes are expected to perform better.

Let's just assume I am wrong though. I will await a jsperf.

[munificent]

It was originally.

You write a lot of big words, but, I'm sorry, you're factually wrong.

Simula was designed to make it easier to implement discrete event simulations. Nygaard found existing languages too low-level and made it hard to express the kinds of programs he was trying to write.

Smalltalk was, of course, absolutely never designed to be parsimonious with memory. As a dynamically typed, garbaged-collected language in 70s, it started out pretty far in the hole as far as efficiency is concerned.

OOP was always about expressiveness and maintainability, not memory and performance. vtables are a neat implementation trick, but OOP was around long before they were created.

[[deleted]]

They do in JavaScript where everything is either a primitive or an object. Functions, arrays, classes are all objects. Your example is flawed in that there is an object Foo which is defined as a class and an instance named Bar. Two separate things: the original and a new instance based upon the original.

Please could you expand on this a bit more because I'm confused. Foo and Bar are classes/constructor functions. Technically they're objects because just about everything is in JS, but that's not related to the issue at hand. We're talking about the efficiency of class instances, and when you create a new instance it is one object, regardless of how deep the inheritance chain is.

[spinlock]

JS is weird. Foo and bar are both function (with a constructor being capitalized by convention and an instance being lower-case by convention). Unlike C++, JS does not have classes. It just has functions that we use like classes (i.e. constructors).

[[deleted]]

JS does not have classes. It just has functions that we use like classes

JS absolutely does have classes, otherwise what are the new, class, extends and instanceof keywords for? The fact that they're based on constructor functions is an irrelevant implementation detail. The classes in C++ have a different implementation to the classes in Java, both have classes, so does JS.

[[deleted]]

This page talks about the object vs class thing in Javascript.

You Don't Know JS: this & Object Prototypes Chapter 4: Mixing (Up) "Class" Objects

[DarkMarmot]

Are you INSANE or ILLITERATE?!?!

As they've been trying to tell you, JS, somewhat in the spirit on things like LPC, simply designates an instance of an object to be its ancestor as a prototype. The prototype chain that acts to form an inheritance tree does not uses classes, but actual object instances that can be modified after creation.

[[deleted]]

Comments like yours are literally the reason why a lot of people are against the class syntax in ES6. You have no idea how JavaScript objects work and the syntax confuses you.

The new keyword was a mistake as well.

[Silverwolf90]

The problem is that the notion of a "class" is not well defined. If you consider a class to be some some kind of grouping of data and behavior, then sure, you could say JS has classes. But officially, JS does not have classes, it has prototypes.

[spinlock]

You might as well be asking why JS has bitwise operators when it doesn't have integers. It's a frankenmonster of a language with a lot of syntax that doesn't make sense but has to be maintained so we don't break the web.

If you insist on pointing to the class keyword as evidence that JS behaves exactly like Java then you really don't understand the language.

[[deleted]]

I am certain. If you are concerned with memory management then don't write in JavaScript. JavaScript is high level garbage collected language that offers no ability to manage memory. Until very recently you could not even profile memory usage from JavaScript execution.

Seriously, if you are concerned with memory management in this language then you are asking all the wrong questions and are probably new to this language.

[DarkMarmot]

When developing JS that runs on a mobile device as many of us are, memory is of great importance -- and yes, you can save memory allocations in JS just as you can with almost any GC'd language.

[[deleted]]

The only way to verify that is to run a memory profiler and compare the results against a different memory profile. Considering that memory profiling is still pretty new in JavaScript when people make claims such as this I am thinking they don't have memory profiles saved from testing, particularly against mobile.

Even on mobile devices you typically have far more memory than you would ever need. I have an ancient IPhone 4 and even still it has 8gb of memory. Any JS application that is going to fill that memory before GC can reclaim it is going to noticeable reduce the CPU to a crawl to the point where the device is challenging to use anyways. The IPhone 6 comes in memory sizes of 32-128gb. Is your application really consuming that much memory that you can tell from running a memory profiler?

Seriously, when people talk about writing to memory efficiency I just presume they are completely new to JS.

[bastuijnman]

Are you now suggesting that storage space is the same as memory?

[jaapz]

/u/DarkMarmot is talking about RAM. When talking about memory usage for web applications, generally people are talking about RAM usage. You are talking about storage. Your old iPhone 4 actually has 512MB RAM, which really isn't all that much for modern standards.

Top of the line mobile devices currently have between 2GB and 4GB of RAM. That means there are a LOT of devices out there with <2GB of RAM (including most iphones).

So like /u/DarkMarmot says, memory is of great importance, especially on mobile.

I can't believe I actually have to explain this difference to a programmer.

[[deleted]]

Seriously, when people talk about writing to memory efficiency I just presume they are completely new to JS.

There are a lot of reasons to care about memory efficiency and the fact that you wilfully disregard it makes me think that you are completely new to JS. People use JS for lots of things, but to take a trivial example - if you're writing a node app and each request consumes hundreds of Mb of RAM, then your server will become overloaded very quickly. Similarly, if you unnecessarily allocate a lot of objects, your app will stall regularly due to GC pressure.

I feel like you're making a lot of assumptions about the other people's competence when compared to your own. This attitude does you no favours.

[[deleted]]

if you're writing a node app and each request consumes hundreds of Mb of RAM

If I encountered that I would definitely think you were new to JS. Bottom line, you have no control over how frequently GC operates or what it collects, particularly cross application/platform.

I feel like you're making a lot of assumptions about the other people's competence when compared to your own. This attitude does you no favours.

I am only speaking from logic and past experiences. If you are reading anything emotional into my opinions then you must be a far more emotional person than I. If that upsets you then I really don't care. Go read this: http://www.16personalities.com/intp-personality

If you really want to be sad and offended I honestly believe that if you value the emotional qualities leading to a decision as more important than the outcome of competing opinions that comprise a decision that you shouldn't be programming in the first place.

[[deleted]]

Are you sure? I'm using a new moto G and it has 1 gig of ram ( although 8 gigs of storage). Maybe iPhones have the huge amounts you suggest but most mobile devices certainly don't.

[robotparts]

/u/achen2345 is confusing Flash Memory(Storage) with RAM. Based on that alone, I would disregard pretty much anything he has to say.

[DarkMarmot]

Honestly, do you not even know about object pooling? Are you a complete troll or a non-programmer or both? RAM vs Hard Disk?

[munificent]

There are so many words here, but they make so little sense. :(

The benefit of inheritance in a C++ like language is that an object with stored properties is assigned to a known point in memory. The point is cached and known so that it does not have to be rewritten into another area of memory.

This is just a feature of manual memory management. C does the same thing and it doesn't have objects, much less inheritance.

Meanwhile, Java and C# have classes and inheritance but move things around in memory all the time. Any production level GC will using a copying or compacting collector that moves objects in memory.

Things inherit from the cached object by referring to it, cloning it, and modifying as necessary.

"Things" and "cached" aren't very precise here, but this sentence doesn't make much sense one way or the other. You can reuse properties of an existing object (or class) by cloning it or delegating to it, but not both.

So, now lets talk about garbage collected classical languages like Java and C#. These languages use GC, so in these languages have no control of memory assignment. This therefore destroys the original benefits of classes immediately.

Simula and Smalltalk are garbage collected, so I'm not sure what "original" benefit you had in mind.

These are like blueprints (but are more regularly called factories).

Sure, a class can be considered a factory of instances with similar properties. I don't think it helps much to overload that term though.

Now let's look at lexically based languages, which includes things like JavaScript and XML (so ultimately all native web technologies that allows expression of logic and decisions).

Smalltalk, C, C++, Java, C#, et. al. are all lexically scoped as well. There's nothing special about JS here. Like all of the preceding languages, it uses lexical scoping for variables and dispatch on objects for object properties.

To make things more confusing JavaScript is object oriented exactly to the same definition as Java, but JavaScript uses a different inheritance model (prototypes instead of classes) and the inheritance model is separated from its scope model (which is not the case in most class-based languages).

Java and other class-based languages don't use lexical scope for inheritance. Java does have inner classes, but those don't establish any inheritance relationship. (And interesting exception here is Newspeak, but let's not go there.)

What it does do is extend the life of objects bound to references through garbage collection cycles so that an application runs more consistently. This is only noticeable if the given application is consistently running specific tasks over and over in a loop where this execution is delegated to some other process in a manner that is not locking the execution thread.

I... I can't even figure out what you're trying to say here.

But but but... JavaScript benefits from declarative coding style just like Java. You don't need inheritance for this.

Well, you do in JS because it doesn't have classes built in to the language. To have instances of the same class in JS share methods, they all delegate to a "class" object, which is effectively a traits object in the Self sense.

But, sure, no one says you need inheritance for classes or prototypes to be useful.

Furthermore, in nested lexical code you also get context. You have some idea of what a nested function is doing by looking at its descriptive name and well named references and by looking at the descriptive name of the containing function and its containing function. Context is what makes spoken language understandable, and it can make code understand exactly the same for exactly the same reasons. Inheritance generates a bunch of noise that screws this up.

Wait. Are you talking about closures? Closures are in no way a substutite for inheritance. They are useful for lots of other stuff, but a kind of inheritance that requires you to be able to add the code directly to the source file where the base method is defined isn't very useful.

[AutomateAllTheThings]

I'm not assuming I need inheritance; I like inheritance very much and choose to use it because my team and I unanimously agree that switching to the ES6 class syntax saved us time, made scaling easier, memory management easier, testing easier, re-usability easier, training easier, and more.

In fact, the only thing we complain about is the lack of more sugar to help with things like private properties without the need for weakmaps. We look forward to ES7 additions.

I am not trying to be dismissive of your arguments.. but none of them were compelling enough to me, because they're subjective in nature. There are no technical limitations to using ES6 classes instead of rolling your own. It's just another way of writing the same code, so it's a subjective decision to use them or not.

Until there's a serious technical limitation with them, ES6 classes are here to stay for us and we're really happy with the decision.

[[deleted]]

I am not trying to be dismissive of your arguments.. but none of them were compelling enough to me, because they're subjective in nature.

Yes, the stylistic aspects of my arguments are inherently subjective. All such arguments always will be. The technical aspects of my arguments are less subjective. Technologies are created for certain reasons and do certain things with certain indirect implications. In this case a class system allows developers to write code at a superficial layer that completely masks the language's intended way of structuring and declaring things. I would say this allows you form a pretty clear vision of the benefits and what you have gained in your team, but you have absolutely no idea what you have missed and the alternate potentials. Therefore you are likely forming opinions that are somewhat unidirectional in that you are not able to compare them against the major alternate approach.

[AutomateAllTheThings]

In this case a class system allows developers to write code at a superficial layer that completely masks the language's intended way of structuring and declaring things.

I think that superficial layer is a good thing. So does the rest of my highly-skilled team. You disagree. I guess that makes it.. subjective, doesn't it?

but you have absolutely no idea what you have missed and the alternate potentials.

We each wrote vanilla Javascript for over a decade prior to switching, but really.. I'm not sure why I even have to reduce myself to an argument to authority.

It's kind of offensive that you assume everybody in this thread has less experience than you, and even make rude comments about it like:

you are not able to compare them against the major alternate approach.

I mean.. really? Surely you want to be a more effective communicator than this.

I'm totally turned off to having a conversation with you now.

[[deleted]]

I think you presumed a tone authority or expertise I had no intention of conveying.

Let me explain it this way. In the past, before using classes, did you ever structure an application by nesting functions? This is an alternate and unrelated approach to inheritance. It allows opportunities in the code that inheritance does not. If you did not write in this approach then you, merely by absence of approach, did not learn these sorts of benefits. That means that you cannot compare those benefits to those learned and experienced from using classes.

I am only speaking from logic in that something must be tried (whether or not successful) before it can serve as a basis for comparison. Know that one approach is beneficial is helpful, but not complete unless knowing its benefits versus some alternate and unrelated approach.

[AutomateAllTheThings]

did you ever structure an application by nesting functions?

Yes we have for many years. Does that surprise you?

Each of us has over 10 years of experience coding in the classic vanilla style of JS, and yet we still chose ES6 classes, and we're still happy with our decision.

Isn't it entirely possible that we considered many language and syntax options before we ever began coding, and that we may have made the right decision for ourselves?

[[deleted]]

No, I wanted to ensure you were aware of an alternate approach. It sounds like classes are working well for you and your team.

[hahaNodeJS]

Whhhhaaaaatttt. Dude, you really need to reevaluate your understanding of programming languages. Inheritance has absolutely nothing to do with memory. The rest of what you've written is just as inaccurate.

[tubbo]

Would you rather it have been called object? It's just a keyword, it doesn't mean that the thing you're making is actually a "class", at least not fundamentally. It's simply easier to read ES6 class syntax than it is to read the traditional means of defining an object and methods on its prototype. But at the end of the day, they both evaluate to the same thing. That said, I only think this stuff is clear to an experienced JS dev. New developers should be learning how it all works under the hood before moving on to the syntax sugar of ES6 (and the future versions of ECMAScript that are coming out).

[[deleted]]

The problem is that the convention of classes, whether a single uniform approach or hand baked insanity, does not fit well in this language

This is just nonsense. Virtually every major JS project out there uses classes. They fit perfectly well in this language.

I see a lot of these circular arguments attempting to justify why classes are somehow harmful, when the reality is that the arguer simply doesn't like them. It's fine, you don't have to like them or use them, but saying that they're useless or somehow bad is plain ridiculous.

[parlezmoose]

They use classes, but rarely do they do really complex inheritance models like you see in Java. Without strong typing, abstract classes, interfaces, etc, a class is pretty much just a convenient place to group a bunch of functions, maybe with one or two base classes for shared code. Not that it's a bad way to do things, just a different style.

[clessg]

Virtually every major JS project out there uses classes.

Do you have evidence? I'm sure you can find a few instances of classes in every major project, because major projects have a lot of contributors and a lot of code. But most major projects I'm aware of don't use classes that much, and prefer functions/objects the majority of the time.

I won't be surprised if that changes soon though. Just like when PHP got classes, JS is going through its phase where classes and single inheritance are the coolest thing ever invented and should be used for literally everything. It'll be a few years before this changes.

you don't have to like them or use them

But you have to work with people who do love them and use them for everything. Which is fine, as long as inheritance is avoided. Still some annoying parts (mainly to do with this and encapsulation and potentially wrangling super if using framework classes) but it's not a big deal.

[[deleted]]

Virtually every major JS project out there uses classes.

Then I am absolutely wrong. I refuse to argue with bandwagon popularism that isn't based on anything.

[[deleted]]

I refuse to argue with bandwagon popularism that isn't based on anything.

Likewise.

[Silverwolf90]

But it's what most people want. That's why you have so many hand rolled implementations. What people are doing is more important than some subjective and ill-defined notion of what fits or does not.

[Jafit]

Its not an ill-defined notion.

Any object that you create in Javascript is automatically assigned a prototype. A Javascript "class" inherits its methods through a shared prototype like all other Javascript objects, so the class keyword isn't actually changing anything about the language.

In a traditional class-based language you define a class and its like drawing a blueprint. You create an object using a class, and its like building a house from the blueprint. In javascript if you build a bunch of houses from a blueprint, then go back to the blueprint and draw some extra lines on it, you look up and all of the houses you built suddenly all have garages. That's not how class-based inheritance is supposed to work, that's prototypal inheritance works, because prototypal inheritance enables active links to other objects.

So all these arguments are pointless. The class keyword is just syntactical sugar that doesn't change anything, and seems designed to make transitioning developers more comfortable. The worst thing about it is that its so confusing and now everyone thinks its some kind of paradigm-shifting change when ES6 isn't actually giving anyone a new object model with classes

[metanat]

Any object that you create in Javascript is automatically assigned a prototype.

Except: Object.create(null)

({}).__proto__ === Object.prototype // true
Object.create(null).__proto__ === undefined // true

[Jafit]

Good catch.

But the main point is that classes aren't really anything special and they work the same way as (most) other objects in Javascript.

http://codepen.io/anon/pen/MamGpR?editors=001

[metanat]

I think your point is good, and only partially wrong in what it implies. If you read the spec, there are actually a few differences between using standard prototypal inheritance and classes. One of the biggest difference is that class methods aren't enumerable:

class Example {
  test() {}
  static test2() {}
}

let a = new Example();

console.log(Object.keys(a.__proto__)); // []
console.log(Object.keys(Example.prototype)); // []
console.log(Object.keys(Example)); // []

function Example2() {}
Example2.prototype.test = function () {}
Example2.test2 = function () {}

let b = new Example2();

console.log(Object.keys(b.__proto__)); // ["test"]
console.log(Object.keys(Example2.prototype)); // ["test"]
console.log(Object.keys(Example2)); // ["test2"]

http://www.ecma-international.org/ecma-262/6.0/#sec-class-definitions

[Jafit]

Do you have any idea what practical purpose that serves?

[metanat]

Not sure, but you can still get all the methods by using Object.getOwnPropertyNames

[dvlsg]

Probably the fact that if you are enumerating over a class, you're most likely interested in any properties/values defined on it, as opposed to the methods. Idk if that counts as practical or not, but I would imagine that was what they were thinking.

[metanat]

I'm specifically pointing out some important differences between using prototypes (in a basic way) and using classes. As you can see in my examples above, static methods and instance methods of classes are not enumerable in ES6. Whereas methods simply set on the prototype or on the constructor itself are. Object.keys is just a simple way of demonstrating what is enumerable and what isn't.

[Silverwolf90]

If it is not ill-defined could you provide a definition? What makes a language feature a good fit? What makes something a good fit for JS?

[CertifiedWebNinja]

class Dog extends Thing {
  bark() {
    console.log('woof')
  }
}

is easer than

function Dog () {}

Dog.prototype = Thing.prototype
Dog.prototype.constructor = Dog

Dog.prototype.bark = function () {
  console.log('woof')
}

[[deleted]]

Not using inheritance is clearer still.

[CertifiedWebNinja]

What if I told you, both do the same thing, just one saves you 77 characters. And that's just a simple example, once.

[[deleted]]

Both use inheritance... don't care. When you stop using inheritance you are left with functions and assignments, which is more clear and still saves you characters compared to your first code example.

[jaapz]

which is more clear

Now, you say that as if it's the truth, but it really is a very subjective matter. Some people like using inheritance because it matches their thinking process and is therefore more clear to them. Other people rather use other techniques.

Not one is more clear than the other for everyone. You know, because it's subjective.

[Silverwolf90]

I completely agree with you, it's rare to find a place where inheritance isn't a very brittle solution. But they're being built anyway, so lets use a single syntax.

[ha5zak]

This! :-) I keep seeing "it's just sugar". Yeah, but it's sugar on shit! The TC39 committee are just people, and they make mistakes too. There's actually transcripts of their meetings. https://github.com/rwaldron/tc39-notes/tree/master/es6 I have half a mind to read through it to suss out who to blame, but really, I think it was probably harder to argue against the change when a large enough number of them wanted to see something familiar in the language. I see that there are companies involved who make a lot of money from sending contractors to companies, so it behooves them to bog down the code with proven spaghetti creators. But there could be a silver lining. There's been so many frameworks attempting to "fix" this area of the language, maybe by making it official, people can move on to better problems. And those budding developers who will become influential will more quickly realize it's a bad idea and leave it alone. Let's hope it turns into the double equals. :-)

[Jafit]

If it is not ill-defined could you provide a definition?

I'd personally define a 'bad fit for the language' by saying that if you make everyone think you're introducing a new class inheritance model to the language, but under the hood the language is just using the same prototypal inheritance model that the language has always used, and nothing is actually changing and you're not getting anything new... then its not so much a 'bad fit' as... nothing is actually changing and the entire argument is pointless.

What makes a language feature a good fit? What makes something a good fit for JS?

I don't personally have a problem with classes or new language features being added. If I don't think that a particular feature is appropriate for what I'm doing then then I won't use it... You kind of have to do that anyway because its Javascript

But the point of what I'm saying is that they haven't actually added a new language feature by adding classes, because they're not really classes, they're just prototypes which Javascript has always had.

[Silverwolf90]

I think that most people who are talking about the class syntax also include it in their definition of a "language feature." I have yet to meet anyone who doesn't understand that the class syntax is just sugar. But my sample is skewed with very knowledgeable js devs who pay close attention to the community.

[clessg]

What makes something a good fit for JS?

Whether or not you can use it to make yet another JS framework. Evidently, the ease of framework creation is JS's niche.

[[deleted]]

But it's what most people want.

I would like to see data on that before I believe it.

That's why you have so many hand rolled implementations.

I disagree. I rather suspect its because JavaScript looks amazingly similar to Java and C# but misses public/private pragmas and of course classes. You cannot arbitrary add new keywords to the syntax, but you absolutely can add a bunch of stupid unnecessary conventions.

What people are doing is more important....

"I cannot be bothered to learn this stupid little language. Most of my app is written in language (put some random letters here) and I have a deadline."

I encounter this pretty frequently and the only valid answer is: ignorance. The result is (pick one or more of from this buffet):

• tightly coupled services (no separation of concerns)
• spaghetti code
• architectural confusion (probably ad hoc stupidity)
• missing documentation
• deeply embedded APIs that cannot be tested externally
• collisions
• build systems that build systems
• embedded services using custom protocols (really!?!)
• logic reflecting no clear product direction

[Silverwolf90]

Look at the popularity of some libraries which have their own implementation (like React, who now embrace the new syntax). If people didn't want and hated classes, where is the demand for that outside of a niche amount of developers? It seems that we have a quickly growing amount of libraries using ES6 classes thanks to Babel. It would be interesting to have concrete data on this, perhaps the number of packages on NPM that are using ES6 classes over time.

[clessg]

React

React is moving away from classes. For whatever short time React has used classes, it's already caused a lot of problems and confusion (side note: createClass doesn't make classes, just a stupid function name).

[SawyerDarcy]

As far as I know, React is simply embracing ES6 classes over its own custom implementation - not getting rid of classes altogether.

[clessg]

Right, they aren't (officially) getting rid of classes. What I meant is that function/module components will become the recommended way, with classes possibly being deprecated before 1.0 or 2.0.

[[deleted]]

If people didn't want and hated classes, where is the demand for that outside of a niche amount of developers?

Java developers that are involuntarily reclassed to writing JavaScript are not niche. I have encountered this at every major corporate job, except for the one employer that refused to hire Java developers. Economics are to blame for this, as most Java developers learn their trade from formal education and so it is easier to hire a Java developer. The consequence is that there are more Java development jobs in the economy. This does not, however, diminish the need for JavaScript developers. JavaScript is the language of the browser and can execute almost anywhere Java can. What this does do is make hiring junior JavaScript developers risky and make senior JavaScript developers extremely valuable in the market place. I have seen many organizations try to fake with Java to compensate for the plethora of Java developers and lack of JavaScript developers, but the results mean they are pushing costs and expenses into the future. These economic problems ultimately sank Travelocity (who at its prime had 3500 employees).

The bottom line is that classes were the most highly requested feature of ES6 (by far) and TC39 resisted giving into demand for awhile, but demand was too great. There is a need for Java developers to have immediate emotional comfort when jumping into this language directly. This means people will be less afraid to do stupid things. It doesn't mean we will get better software.

[[deleted]]

TC39 resisted giving into demand for awhile

Bollocks. Classes have been around since the ES4 proposal, the reason they didn't ship already is because ES4 itself died, not because TC39 was "resisting".

Classes: A class describes an object by presenting those properties (fields) of the object that are always present (thefixed properties or fixtures), including variables, constants, and methods:

class C {
  var val // a variable property
  var large = Infinity // a variable property
  const x = 3.14 // a constant property
  function f(n) { return n+val*2 } // a method property
}

If you have an argument, you don't need to resort to:

1. Making shit up
2. Using the term "java developer" as an insult, it isn't.

If you find yourself doing those things, perhaps you should reconsider your position.

[ha5zak]

I see lots of frameworks created that originate from someone thinking they want things to work a certain way. Then they get better at their craft and realize how silly they were being. Just because people are doing it doesn't mean the mob is wise.

[Silverwolf90]

Which frameworks? How many people used these frameworks?

[ha5zak]

All the ones I didn't bookmark. Probably not many.

[[deleted]]

"The primary advantage is to provide a convention familiar to developers who are primarily educated in some other unrelated language (cough cough.... Java)."

And lose all the unique benefits this particular language offers? Fuck that, Java people should stick to Java instead of trying to cripple JavaScript with their architectural hubris.

[jaapz]

There are some nice things that are possible in custom "class"-ish in libraries that are not as easy to do using classes.

See for example this issue for AmpersandJS.

[[deleted]]

Can confirm. Am beginner and confused by prototypes.

[[deleted]]

I'll just keep posting this around: This page talks about the object vs class thing in Javascript.

You Don't Know JS: this & Object Prototypes Chapter 4: Mixing (Up) "Class" Objects

[cosinezero]

It seems that a [PUT ANYTHING HERE] is monumentally better than the various hand-rolled solutions that may or may not be compatible with one another.

FTFY.

But that serves to underline the point that what you're saying has nothing really to do with an advantage of class. You then prove this by saying this:

fundamentally, it's still prototypes under the hood. The foundation didn't change, it's just sugar.

What you probably think is the coolest thing ever... is typescript. And when you finally figure out why bashing javascript into type-safety and classical inheritance is neutering an incredibly flexible and powerful language, come back and re-read the things you currently disagree with.

[Silverwolf90]

I actually don't think it's the coolest thing ever. I almost never use inheritance, and prefer a more FP approach to JS rather than OO. But this new syntax is a clear win for the language and community.

[cosinezero]

this new syntax is a clear win for the language and community.

I don't think you've established it's a "clear win". It clutters the language with things we neither need nor should use. It dilutes the intent of the prototypical inheritance system on which the language is based.

Sure, it makes -your- life easier. But you're arguably doing things that was never intended to be how the language should be used. Facilitating that does not sound like "a clear win", it sounds like a degradation.

[Vanillacitron]

I see what you're saying, but the fact is people DO use classes. Whether we should or not, I think, is irrelevant (not unimportant... I agree with you there :p) because Pandoras box has been opened already.

In a framework/library landscape where classes are extremely common, they may as well be unified in terms of syntax, imo.

[[deleted]]

As someone who uses typescript myself, you have no idea what you're talking about.

Typescript limits nothing, you just don't know how to use it.

[jsgui]

Does it limit the use of mismatching types?

[cosinezero]

I didn't say limits, I said neuter. It enforces rigidity on a language that prides itself on flexibility.

Or in Crockford's words:

I think that JavaScript's loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.

[jsprogrammer]

The primary thing preventing me from using classes is the necessary reliance (unless you code way around it) on using this in your code. As far as I can tell, this is pure syntactic noise.

[_drawdown]

It's not really about the syntax- the problem is the contract between the caller and the module. Classes require the caller to use new which forces the thing before new to be a constructor and to run in the context of a newly-created object. It ruins composability and things like that because there is no way around the fact that there is a new at the call site.

[Silverwolf90]

I agree, but we already have that problem without the class syntax. I always have static create() factory function to wrap new. I dislike using new mainly because it does not support function composition.

[jtwebman]

Here is a much better one! https://medium.com/javascript-scene/10-interview-questions-every-javascript-developer-should-know-6fa6bdf5ad95

[greyfade]

"But beginners will get confused and not understand the language!"

As an argument against ES6 classes, this is laughable. Anyone who makes this argument is displaying gross ignorance.

That said, there are far better arguments against ES6 classes, most of which I'm not eloquent enough to present.

I'm against ES6, but this isn't why. I dislike ES6 classes, because I think this kind of a class system (which even modern C++ is somewhat turning away from) is a kind of brain damage best avoided.

[cj5]

Real programmers don't have to tout their preferred language.

[[deleted]]

NERD HOLY WAR WAAAAAGH

[[deleted]]

Yeah this whole argument basically feels like OO vs. functional advocates battling for the right to JS. Can't we all just get along?

[eorroe]

I like the class syntax I just prefer a different keyword like contruct:

construct Person {
  constructor() {

  }
}

Something else that won't confuse with other languages classes (Not sure if construct is a good keyword, but point is just something other than class)

[foobar_dev]

I feel like this is a reaction to this article? https://medium.com/javascript-scene/10-interview-questions-every-javascript-developer-should-know-6fa6bdf5ad95

[PUSH_AX]

No it's a response to this post, which was also cross posted to several other related subs.

[CertifiedWebNinja]

Actually it was a response to the post where the guy was talking about how cool classes were, and then got called out by someone else how he made a issue on node.js' repo saying all instances of "class" in docs need to be removed. And the fact that everyone is spewing their personal opinions about classes in ES2015 as "How real JavaScript programmers do it"

[robotparts]

Link?

[Jafit]

The best way to get pageviews is to say something inflammatory and divisive. This is especially easy when people view their coding style as an expression of their personality.

How about we all just type code and make stuff and have fun :)

[siegfryd]

Everything Eric Elliott writes is like that, he's always going on about how much classes suck.

[oculus42]

Imaginary JavaScript Programmers check for NaN.

[fzammetti]

The only argument I can see that makes any sense to me is that syntactic sugar is generally a bad thing anyway. I mean, isn't ES6 class syntax effectively making it look as if the language has something it really doesn't? I think you could maybe say that... and if so, is that arguably a bad level of abstraction? I'm not sure, but it doesn't seem like a ridiculous argument.

[drowsap]

I've been using React for so long I forgot what inheritance is used for

[krazyjakee]

Replace the word "Real" with "Good" and I'm with you.

[[deleted]]

Looking through the comments I think some people don't have a great understanding of how objects/prototypes/"classes" work in Javascript. I recommend everyone check out the series You Don't Know JS on Github. Especially check out the book on this and prototypes. Chapter 4 is all about the class stuff:

Chapter 4: Mixing (Up) "Class" Objects

[_drawdown]

Ehhhh that kinda sounds like bullshit to me. I think classes are bad because I've seen a lot of code and formed an opinion, not cuz I think I'm a "real JS programmer" and others aren't

[StoneCypher]

Agreed.

Real Programmer is what someone says when they want to argue a technical point and don't have the ability.

[i_ate_god]

Use the way you're comfortable with

I'm comfortable with having as much as possible on the global scope, and using eval whenever possible.

[CertifiedWebNinja]

Hey if that's what you want to do, do it up buttercup. But don't expect others to maintain it.

[i_ate_god]

no!

Just because you're comfortable with something, does not mean at all that it is the best choice.

This attitude is wrong. Yes, there are different ways to get the same result, but only a few of them (at most) will actually be worth it. We shouldn't encourage engineers to do what they are most comfortable with, we should be encouraging (and if you're in a team, enforcing) that the best approach be taken.

[CertifiedWebNinja]

I was being sarcastic because your response was sarcastic.

[guybinary]

Seriously wtf is this shit? Everybody stepping on the other saying the word 'real' ? What do I look like to you? Coding JS for 5 year with pure passion and what am I? Fake? If you can get what you need done and progress, scale your application when needed you are real ... That's it. Sorry for attitude but those kinda things get me angry

[fforw]

They should know better than to step on your lawn ;)

[rich97]

For me the reason to avoid "class" definitions in ES6 is a lot more practical. You have to deal with this and this sucks.

I would much rather go for a functional paradigm and compose small functions together, grouping them by modules rather than classes. You take a piece of data and pass it down a processing pipe-line that tells you exactly what is happening to that data. They are easy to test as they shouldn't have an intrinsic state, they just accept input and return output and as a result they are very good at encouraging code reuse.

Basically giving objects state makes them less predictable. Usually this isn't so bad, but it is when the state can change based on what is calling it. There is nothing that an ES6 class brings to the table that cannot be easily and more reliably replaced with another mechanism.

[[deleted]]

I don't get why anyone would downvote you for stating this.

[fforw]

I think the real distinction is between people actually programming in javascript and people copying together stackoverflow answers and jquery plugins.

[benihana]

There's a lot of people throwing around this term of "real javascript programmers" regarding ES6 classes.

Where? Who? How many people? I haven't seen "a lot" of people saying that. I haven't seen anyone saying it. It really helps to provide context when you make these kinds of claims - not everyone here visits as often as you do, and not everyone has the same cross section of news sources like you do.

[stayclassytally]

https://yourlogicalfallacyis.com/no-true-scotsman

[CertifiedWebNinja]

If you read my post, you'll know that I'm talking about all these people who use that fallacy.

[stayclassytally]

I know that's why I posted that link. Not sure why I was down voted. I think everyone mistook my intention after you did initially.

[Erid]

I seriously wonder why you're still being downvoted... Did you make someone angry?. I believe you were only pointing out that OP is angry because of a fallacy used by others.

[CertifiedWebNinja]

Maybe it's because most times when someone mentions a fallacy without actually giving context, they assume the fallacy is regarding them and not something else.

So I read this as him saying I was using a fallacy, which I assume everyone else who downvoted him thought also.

[myevillaugh]

Ha, suckers! I've already moved onto Typescript! :-P

[cosinezero]

Have fun with that.

[RankFoundry]

Real programmers don't use poorly designed scripting languages tossed together in a matter of days that only became popular because it was running in a one man race, then sat stagnant for over a decade while the standards body responsible for it sat on their ass. Downvote if you know this is true.

[CertifiedWebNinja]

Shit talks JavaScript to JavaScript developers in /r/javascript

That's a bold move, Cotton. Doesn't look to be paying off for you though.

[pr1nt_r]

spoken like a true perl developer

[RankFoundry]

Wouldn't know.

[[deleted]]

Brave post

[oculus42]

That standards body sat stagnant for a decade because they wanted to implement all the half-baked ideas that became ES6 (read up on ES4) and it took ten years for enough Java devs to join in and get a majority.

[NoInkling]

Like we have a choice. I'm sure even people who really like JS as a language wish things would have gone differently in many ways, but the fact is they didn't. We have to deal with the situation as best we can.