Refactoring Legacy JavaScript Code to Use Classes | Hacker News Reader

Refactoring Legacy JavaScript Code to Use Classes

arxiv.org

48 pointsbreck55 comments

While I'm a huge fan of what ES2015 has brought to JavaScript, the "class" keyword was a huge mistake. There are no classes in Javascript, there are only objects. By embracing prototypal inheritance you will write cleaner code with fewer errors.

> the "class" keyword was a huge mistake. There are no classes in Javascript, there are only objects

That's true if you define the word "class" to not include JS classes, but in that case, you can use the keyword and still "embrace" prototypal inheritance, since as you say, it's all just objects (even if you use the class keyword).

Alternatively if you use a more flexible definition of the word class, then your assertion is not true, because JS does have classes, they just are implemented via prototypes.

Either way, I don't see how your comment is correct. Is it all objects, or not? :)

> the "class" keyword was a huge mistake

There is not a single fact proving that statement. People want to write Javascript in different ways, Javascript is no less OO that it is FP. I don't see why one camp should be more privileged than the other.

> prototypal inheritance you will write cleaner code with fewer errors.

JS Classes use "prototype inheritance". compare that :

    function Foo(){}

    function Bar(){
       Foo.call(this)
    }

    Bar.prototype = Object.create(Foo.prototype)

with that :

    class Foo{}

    class Bar extends Foo{}

There is absolutely no debate as to what is more readable, cleaner,easier to parse for IDE, and less error prone. ES6+ is considerably making writing JS easier and safer. There is very little reason today to deal with prototypes directly. And in strict mode, calling Foo or Bar without using new yields an error.

Encouraging inheritance in the first place is the mistake. Using composition with Object.assign is far less fragile than inheritance. An article with concrete examples: https://medium.com/javascript-scene/master-the-javascript-in...

> Encouraging inheritance in the first place is the mistake.

Yes.

> Using composition with Object.assign is far less fragile than inheritance.

Absolutely not. Object.assign is an example of inheritance, not composition, and it's just as fragile as the others. Eric Elliott is well known for calling "composition" what everyone else calls "multiple inheritance". See, eg:

http://wsieroci.github.io/elliott/inheritance/composition/20...

https://www.reddit.com/r/javascript/comments/3oy9c3/composit...

It's almost a running joke on the /r/javascript subreddit at this point.

How is Object.assign not a "has-a relationship"? From the first article you posted, this example of composition was given:

  {
    author: createAuthor(),
    posts: createPosts() 
  }

How is that different from this?

  Object.assign({}, author, post)

In both cases you end up with an object that has an instance of an author and a post. What am I missing?

> In both cases you end up with an object that has an instance of an author and a post.

But you don't; not even close.

The first one is a has-a relationship; the object contains two references (`author` and `posts`), which presumably point to an instance of the Author class and a collection of instances of the Post class (or whatever). This is composition.

The second is an is-a relationship; the object has the properties of the author and post objects copied over the top of it. There is now only one object (not three), and if we're lucky, it implements the interface contracts of both the Author class and the Post class.

Consider if Author has a title field that contains their preferred prefix (Mr, Ms, Mrs, Dr), and Post has a title field that contains the subject line.

With the first approach, we could do `foo.author.title` or `foo.posts[0].title`, using our references to the underlying Author or Post instances.

With the second approach, we can do `foo.title` or...`foo.title`. Whups. We have no references, there is no underlying Author or Post instances; there's just a single object which is trying to inherit the behaviour of both the Author and the Post class, and failing.

It's not a horrible way of implementing multiple inheritance in JS, but it's still inheritance. And in it's single inheritance form (`Object.assign({}, author)`) it's yields an identical result to normal prototypal inheritance or the class keyword.

Edit: This becomes even clearer when you start to flesh out the examples. Eg, https://jsbin.com/kigewonepe/1/edit?js,console

Note how obj2 has a `fullName` method (which only Author's do), because it is an author. Except note that it returns the wrong string when you run it, because obj is also a post. Where obj1 works correctly because it has an author and it has a post, without trying to be either of them. Composition over inheritance, just like the Gang of Four said. :)

I can get foo.author.title and foo.post.title no problem using Object.assign:

  Object.assign({}, { author: author }, { post: post });

Can you give a better example of where a reference to an instance is any different than copying an instance?

EDIT: I fixed your example. https://jsbin.com/zamuqoropa/1/edit?js,console

EDIT 2: In fact, my Object.assign does exactly the same thing as your example of composition. And

  console.log(obj1.author === obj2.author);

produces 'true'.

https://jsbin.com/vafudizumo/1/edit?js,console

Either you're doing composition wrong, or I'm not doing inheritance like you are claiming.

    Object.assign({}, { author: author }, { post: post });

Yep, that's composition and it's identical to my composition example. Of course, you're not actually using Object.assign() to do anything; your code is 100% identical to just saying:

    {author, post};

Not that there's anything wrong with that...but do note that it's also the exact opposite of what Elliott is advocating for, not what he shows off in his code examples, not what his Stampit library does, etc.

> Either you're doing composition wrong, or I'm not doing inheritance like you are claiming.

Your first example (and Elliott's examples) are inheritance. Your second example is composition. The difference is enormous.

Edit: Elliott says here[0]

"Similarly, you can use `Object.assign()` to compose any number of objects together with last-in priority:"

    let ninjamouse = Object.assign({}, mouse, ninja);

1) That's not composition, that's inheritance.

2) That's the same as your first example, but fundamentally different than your second.

He's trying to make a "ninjamouse" which has the properties and methods of both mice and ninjas, because it is a mouse and a ninja. (That's inheritance, and it's fragile for all the reasons inheritance is always fragile).

Your second example makes an object that has both a mouse and a ninja. That's composition.

"This technique is called concatenative inheritance"

By absolutely no one ever. :)

[0]: https://medium.com/javascript-scene/common-misconceptions-ab...

I agree now that what Eric Elliot is doing is not composition. But it's not inheritance as it is commonly known either. If I inherit from a prototype, then inherited objects can use the prototype methods via prototype delegation. If I change a method in the prototype, inherited objects will see that change. Which is similar to class based inheritance, but can happen at run time. That will not happen with Object.assign because it is cloning or copying. If I make a change to a prototype I cloned from, the cloned object will not be changed. This is also known as concatenative prototyping. Yes, it's considered a type of inheritance, but I think different enough from prototype delegation and class inheritance that it should be pointed out when claiming it is inheritance. Because copying feels closer to composition than than it does to OO inheritance or prototype delegation IMO. Composition still wins though. Good discussion.

"By absolutely no one ever. :)" Actually, quite often. A few examples below:

https://en.wikipedia.org/wiki/Prototype-based_programming#Co...

http://aaditmshah.github.io/why-prototypal-inheritance-matte...

http://www.datchley.name/understanding-prototypes-delegation...

> But it's not inheritance as it is commonly known either.

Wikipedia disagrees; do you have a citation in mind?

> Which is similar to class based inheritance, but can happen at run time.

That's not a distinguishing feature of class based inheritance; many implementation do this. Python's class based inheritance is extremely flexible and absolutely allows run time modification; to a greater or lesser extent this is true of many dynamic language (Ruby, Perl, etc.).

What do you think the defining feature of class based inheritance is that allows a clean distinction between JS and Python? Because I don't personally see much of one.

> Because copying feels closer to composition than than it does to OO inheritance or prototype delegation IMO.

Well, opinions are subjective. My experience has been the reverse, however.

> Wikipedia disagrees; do you have a citation in mind?

Nowhere in the wikipedia main article about inheritance does it cover concatenation inheritance (https://en.wikipedia.org/wiki/Inheritance_(object-oriented_p...). You only find it in the article about Prototype based programming (https://en.wikipedia.org/wiki/Prototype-based_programming). It's also my personal experience (started with Java when it was first released...) that inheritance means class-based inheritance to a lot of devs. I'm sure that changes depending on which devs you hang out with.

If I understand right, concatenation is more commonly called a mixin? At least the way it's done in javascript. In which case the wikipedia article on that says 'Mixins are sometimes described as being "included" rather than "inherited". Mixins encourage code reuse and can be used to avoid the inheritance ambiguity that multiple inheritance can cause'

Based on that last quote, I'm confident I'm not the only one with the opinion that concatenation inheritance isn't a strict "is-a" relationship and might veer towards "has-a". Maybe "has-a-trait" type relationship? That's also how Eric Elliot was using Object.assign. A guitar has distortion, volume, and a cabinet. Let's not go in circles: I still agree his code isn't composition. But mixins sure do blur the lines between composition and inheritance for me.

> That's not a distinguishing feature of class based inheritance

It was an aside. Not very important to the point I was making. The point was that prototype delegation and class inheritance are similar in the way that methods are inherited, and that's different from how concatenation treats methods. But thanks for the info, I didn't know that about Python.

I can get foo.author.title and foo.post.title no problem using Object.assign:

  Object.assign({}, { author: author }, { post: post });

Can you give a better example of where a reference to an instance is any different than copying an instance?

EDIT: I fixed your example. https://jsbin.com/zamuqoropa/1/edit?js,console

EDIT 2: In fact, my Object.assign does exactly the same thing as your example of composition. And console.log(obj1.author === obj2.author); produces 'true'. https://jsbin.com/vafudizumo/1/edit?js,console Either you're doing composition wrong, or I'm not doing inheritance like you are claiming.

The point the OP was making that the class keyword was a mistake, not that inheritance was a mistake. This is an entirely different topic.

Furthermore, Javascript classes make writing mixins AKA composition a breeze, compared to before:

http://justinfagnani.com/2015/12/21/real-mixins-with-javascr...

This link is an excellent rebuttal to Eric Elliot article and how he achieve composition through copying by the way.

So even if you like composition over inheritance, Javascript classes still allow you to write safer and clearer and cleaner code. Now you can do away with ugly factories and property copying.

> Object.assign is far less fragile than inheritance

You realize the using Object.assign means copying properties from object to object over and over and increase memory requirements in order to run a script.

So my point still stands, there is not a single disadvantage introduced with the class keyword.

Thanks for the article, it's a long read that requires some thinking so I'll get to it tomorrow. In the meantime I'll put a Kyle Simpson chapter out there as a rebuttal to "there is not a single disadvantage introduced with the class keyword". He makes a good case that there is more than one disadvantage to the class keyword. https://github.com/getify/You-Dont-Know-JS/blob/master/this%...

How about Parasitic Inheritance? http://www.breck-mckye.com/blog/2014/05/why-i-prefer-parasit...

You can get rid of "this" and all it's problems, and the code is even cleaner.

> By embracing prototypal inheritance you will write cleaner code with fewer errors.

[citation needed]

Classes are fine, they're just sugar over prototypal inheritance.

Yes, this why the class keyword is great. Also it fixes inheritance which is not easy to do with prototypes.

  class A {}
  > class A {}
  class B extends A {}
  > class B extends A {}
  new B instanceof B
  > true
  new B instanceof A
  > true

There is just 1 way to do this with classes, it is very concise, and it is impossible to do wrong, e.g., by forgetting to call the super class constructor. Try doing that with prototypes.

That's the thing, with prototypes you don't use inheritance, which is the good option. Now it's easy to do the wrong thing. Thanks ECMA!

> with prototypes you don't use inheritance

That is 100% wrong. Prototypes are inheritance. Quoting from wikipedia:

"Prototype-based programming is a style of object-oriented programming in which behaviour reuse (known as inheritance) is performed via a process of reusing existing objects via delegation that serve as prototypes."

I have no idea what you were trying to say, but what you wrote is nonsense.

Well arguably the definition of inheritance there doesn't meet the poster's idea of inheritance. Prototype 'inheritance' is a kind of delegation and some prototype OO languages make that explicit by using different terminology (Self says 'delegate' and not 'parent' for example).

But then arguably in class-based OO languages, classes don't "inherit" either and really just delegate to other classes.

(FWIW I wrote a big chunk of the prototype-OO article on WP at one point. Not sure how much of that text still exists)

It's sort of wrong, but not really if we are using the commonly used definition of inheritance where we think of the strict hierarchical inheritance provided by classes. And you mention prototype delegation which is only one type of inheritance provided by javascript and is also hierarchical. There are two other types of inheritance you can use with javascript: functional inheritance, and concatenative inheritance. Concatenative inheritance is so different from class inheritance that most people don't even call it inheritance. They call it object composition. Which has been preferred over class inheritance as far back as the GoF "Favor object composition over class inheritance." More here: https://medium.com/javascript-scene/master-the-javascript-in...

What I was trying to say is that without the class keyword, people used inheritance less, prototypal or whatever. Which is good, because inheritance sucks.

> By embracing prototypal inheritance you will write cleaner code with fewer errors.

Do you have a concrete example in mind? Code sample A is cleaner and has fewer errors than its class equivalent B?

Can you give an example of errors introduced by using "class"?

There's a lot of reasons against classes in JS. This list has a lot of articles. https://github.com/joshburgess/not-awesome-es6-classes A common point seems to be against the brittleness caused by inheritance (including prototypical) in general. Personally, I find that the tiny amount of performance you give up by using factory and composition patterns is generally worth not having to deal with binding the right context

Grand-parent comment asked for an example of an error introduced by using class that would've been avoided with prototype inheritance, and you respond with an "awesome" "curated" list of opinion pieces and conference talks by famous devs and rockstars...

This is what's wrong with the JS community and why everything is so hype driven... this list gives the impression that if you want to be a good JS developer you should've even THINK about trying to use classes in your JS because if you do then you don't truly "get" JS.

Think for yourself and decide if classes will improve your code in the way you plan to use it. Classes have hugely improved my company's JavaScript, it works well considering our developers understand OOP much better than they do functional programming, which I think is pretty common.

We don't rely on inheritance, we reuse by composition (which is just as easy to do with class as it is to do with protypes).

Classes are fine! Use them if you want to! Don't use them if your existing code relies heavily on prototypal inheritance, but if you just wanna wrap some methods around some internal state and you like the way the class syntax looks compared to the prototype syntax don't let some think piece on medium try to convince you that classes are bad.

EDIT: sorry to go off on a slightly OT rant on your comment... I just got frustrated by the link you posted.

That list is actually making fun of what you're describing in the JS community. "Not Awesome" is a play on the "Awesome" lists like this [https://github.com/sindresorhus/awesome]

JS classes were extremely hyped up a year ago. Taking a stance against classes was going very hard against the hype.

How well your devs understand the code is the only real metric. If you understand OOP better, stick with it!

Huh, I must have missed the "classes are great" wave. I only remember the "classes are bad" FUD represented by this list... HN is my main connection to the hype train these days since I quit Twitter.

> How well your devs understand the code is the only real metric. If you understand OOP better, stick with it!

Agreed.

That doesn't really answer OPs question though?

He's asking about why manipulating prototypes directly is better than doing so via the class keyword sugar, and your response seems to explains why you probably shouldn't do either one.

Kyle Simpson has a good writeup of the class keyword from his series of books "You don't know Javascript". https://github.com/getify/You-Dont-Know-JS/blob/master/this%... You can read through the gotchas section and come up with your own conclusions.

Classes enforce a strict hierarchical relationship which is rarely how the real world works. And you also inherit everything from a parent class whether you need it or not. One alternative to class inheritance possible with javascript is object composition (usually Object.assign()) which does not enforce a hierarchical relationship and you can use only what you want from other objects. More flexible, less brittle. Eric Elliot goes into details with concrete examples in this article. https://medium.com/javascript-scene/master-the-javascript-in...

yeah, let's write js as pure functional language.

Check fantasy-land and ramda

Agreed that `class` was a mistake, but I try to use inheritance (of any kind) as sparingly as possible.

If you are interested in this sort of work, we've been doing this for years at Facebook and are publishing all our "codemods" in a repo:

- JS: https://github.com/cpojer/js-codemod/tree/master/transforms

- React: https://github.com/reactjs/react-codemod/tree/master/transfo...

We built and ran the codemod they talk about in this paper many years ago across thousands of files. Unfortunately, we didn't have the infra open sourced so the actual codemod didn't get open sourced.

Indeed. I also spoke about this topic a lot: https://www.youtube.com/watch?v=d0pOgY8__JM

All of a sudden, perfectly working JS becomes "legacy" code due to the introduction of a new feature in the spec. There's that saying, only the software industry is more driven by trends than the fashion industry.

This new feature allows you to make code more structured and maintainable. Of course people are going to use it, and even change old code to use it. `Array.forEach` and `Object.keys` were new features in ES5, should people just leave their old `for` loops anyways? Refactoring old code is a good way to keep your codebase consistent and maintainable.

Hahaha, no. Every time the argument for "maintainability", or some other subjective quality like "readability" is mentioned, another question must be answered "to who?" The class keyword was added a few years too late to accomodate the horde of desktop Java/.NET developers moving to the web platform, who simply did not grok prototypal inheritance. Now they don't have to.

>`Array.forEach` and `Object.keys` were new features in ES5, should people just leave their old `for` loops anyways?

Emphatic yes, people should keep using their "old" loops. They do less and are much faster.

Given the topic was Javascript class-based programming in-the-large, I was surprised this paper didn't mention the use of closures as a means to implement encapsulation. Especially during the part about supporting static properties shared between objects. One method to implement something like a static property is to declare a variable (and optional getter/setter) in an anonymous function that also contains the "class" definition.

The most surprising part is the title "... The Good, The Bad, and The Ugly" given that Crockford's similarly named Javascript book brings up relevant cases that I didn't see addressed.

This seems like a big mistake to me.

Classes are a nice tool to cleaner code if used correctly.

People are using them all over the JS-verse already, just manually and verbose using inconsistent and incompatible implementations.

I fail to see why everyone here are so negative to actually standardizing something everyone is already doing anyway.

Someone please enlighten me?

I think some JavaScript developers feel a sort of stockholm-syndrome attachment to the features of JavaScript that make it unique.

We've been hearing for so many years that our bread and butter language was terrible, so we told ourselves that other people just hadn't spent the time to take advantage of the less commonly understood features of JS (not unique, just lest common among popular industry languages like python, java, etc). This leads to people claiming that prototypal inheritance always better than classical inheritance (everyone else who uses classes are just misguided), or that JavaScript is "functional" just because it has first class functions.

I used to feel this way about classes too. Now that I've started using them at work I feel like there is a great desire to justify the amount of time that has been spent hacking on prototypal inheritance to behave like classes.

When the language featured prototypal inheritance as its main workhorse, it was stupid to try and hack classes together simply because you couldn't wrap your head around prototypal inheritance. That's like if I started to use python and instead of using classes I hacked together a prototypal inheritance system because classes were too outlandish for me.

Now that the newest versions of ES brings classes out of the box the point is moot. Use the one you are comfortable with or the one your team agreed with.

I agree, in the past, it would've been better for everyone to adopt prototypal inheritance instead of the dozens of half-baked class implementations we have now, but the fact that people tried to hack classes into JS shows that prototypal inheritance was the wrong design choice in the first place. JavaScript developers (in the general, not just the ones on HN) wanted classes.

I think it really depends in what order you learn things.

If you start your career with web technologies and your first programming language is JS, you have no issues with prototypal inheritance.

The problem is when have developers that are used to classical inheritance and expect them to do a bit of JS on the side. Of course they wouldn't want to learn a new mindset simply to "add some blink on the website".

TBH, I think the main difficulty is caused by people claiming there's some huge difference between prototype based and class based OO. There isn't, really (at least, not if you're comparing JavaScript and other widely used dynamic OO languages; prototype-based languages which emphasise copying, rather than delegation, are a bit more different).

In both cases, you can share behaviour between objects by putting that behaviour in another object and attaching it in a special way to the objects that should have similar behaviour - in JavaScript it's called __proto__, in Python it's called __class__, etc. Python (and Ruby, Smalltalk, and others) introduce an additional "meta" level of shared behaviour between all these class objects, whereas JavaScript (and Self) don't, but that's a comparatively technical implementation detail. Most languages other than JavaScript are include slightly more language-level support for one particular pattern of using this shared behaviour, which gives users of these languages a strong hint as to how to use these capabilities.

The addition of a class keyword to JavaScript is good because it emphasises what JavaScript shares with other dynamic OO languages.

Exactly. I don't get what secret superpowers I'm supposed to be gaining by using prototype OO over classes. One of them is just more familiar to the vast majority of programmers.

> The problem is when have developers that are used to classical inheritance

That's a very, very broad category, and some implementations are very close to JS. Python is normally considered to have "classical inheritance", but as a practical matter for day-to-day programming Python inheritance works very similarly to how JS prototypes work (eg, having an inheritance chain and checking methods as you go up the chain until you find something that implements what you're looking for).

I find that when people try to emphasise how different JS is from other languages, what they generally mean is how different it is from Java. :)

People need to take the time to learn JS instead of forcing their understanding of programming upon it.

Is my understanding of ES6 classes wrong, or is the first migration rule in paragraph 3.1 missing the static keyword?

I'd think it should be:

  // ES5
  C.m3 = function(p3) { B4; }
  // ES6
  class C {
    ...
    static m3(p3) { B4; }
  }

You're correct. Appears to be a typo.

I remember that when classes were proposed (in the defunct ES4 and again for ES6) much of the opposition was of this changing the semantics of ES from using prototype chains to classical inheritance, which was viewed as a step backwards.

On the contrary though, since classes are carefully designed to be just syntactic sugar around prototypes, it should be easy to migrate, right?

Well no, because the one thing that became obvious was that, since there were no standards, and no clearly and obviously idiomatic way to do prototype chains, nobody was doing them in a correct, consistent way.

So trying auto-migrate is almost certainly doomed except in trivial cases, because as the article implies there's a high chance of it just being flat wrong anyway.

> ...although the language is prototype-based, the latest JavaScript standard, named ECMAScript 6 (ES6), provides native support for implementing classes...

Ohhh boy. I predict trouble ahead.

Reply on news.ycombinator.com