9 ms·

Refactoring Legacy JavaScript Code to Use Classes

48 points by breck 10y ago

baron816 10y ago
This seems like a big mistake to me.
grabcocque 10y ago
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.
vjeux 10y ago
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 https://github.com/cpojer/js-codemod/tree/master/transforms - React: https://github.com/reactjs/react-codemod/tree/master/transforms 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.
- cpojer 10y ago
  Indeed. I also spoke about this topic a lot: https://www.youtube.com/watch?v=d0pOgY8__JM https://www.youtube.com/watch?v=d0pOgY8__JM
pg_bot 10y ago
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.
- namelezz 10y ago
  Can you give an example of errors introduced by using "class"?
  - JSDave 10y ago
    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 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
    - chickenfries 10y ago
      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.
thegigaraptor 10y ago
People need to take the time to learn JS instead of forcing their understanding of programming upon it.
scj 10y ago
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.
draw_down 10y ago
> ...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.
daliwali 10y ago
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.
- pitaj 10y ago
  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.
  - daliwali 10y ago
    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.
    - deleted 10y ago
      [deleted]
josteink 10y ago
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?
- chickenfries 10y ago
  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.
  - Raphmedia 10y ago
    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.
    - chickenfries 10y ago
      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.
jorgenhorstink 10y ago
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; } }
- pitaj 10y ago
  You're correct. Appears to be a typo.

48 points by breck 10y ago

This seems like a big mistake to me.

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.

vjeux 10y ago

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 https://github.com/cpojer/js-codemod/tree/master/transforms - React: https://github.com/reactjs/react-codemod/tree/master/transforms 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.

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

pg_bot 10y ago

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.

namelezz 10y ago
Can you give an example of errors introduced by using "class"?
- JSDave 10y ago
  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 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
  - chickenfries 10y ago
    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.

thegigaraptor 10y ago

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

scj 10y ago

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.

draw_down 10y ago

> ...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.

daliwali 10y ago

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.

pitaj 10y ago
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.
- daliwali 10y ago
  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.
  - deleted 10y ago
    [deleted]

josteink 10y ago

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?

chickenfries 10y ago
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.
- Raphmedia 10y ago
  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.
  - chickenfries 10y ago
    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.

jorgenhorstink 10y ago

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; } }

pitaj 10y ago
You're correct. Appears to be a typo.