4 ms·

Classes and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, o

Classes and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, or files. Try stepping outside of JavaScript for a while, broaden your experience.

c-hendricks 3y ago
So you're just gonna ignore that whole "the JS community" bit then, ok. Is this what $200/hour consultancy looks like?
- andrewmcwatters 3y ago
  Try writing some code in not just JavaScript but also C, C++, Java, and others. Classes aren't some relic. You use prototypes in JavaScript every single day.
  - c-hendricks 3y ago
    You're still just blowing past "the JS community". To fill you in on the context of the thread you inserted yourself into, classes have fallen out of favour _in JS_. It's pointless to say "but they're still used in other languages!" because we're not talking about other languages, we're talking about JS.
    - andrewmcwatters 3y ago
      I, too, am talking about JavaScript. Everything in JavaScript is prototype-oriented whether you ignore it or not. You can choose to write functions for everything, but you're still always using object prototypes. There are several large popular libraries in JavaScript which do not orient themselves around functional object orientation, too. So you might work in one corner of JavaScript where all you experience is functions, but that's not the case everywhere. They haven't "fallen out of favor," whatever that means.
devjab 3y ago
I think we may be talking a little bit in two different directions, because when you write this: > Classes and types and methods exist for a reason. What that reads like to me is actually the exact explanation as to why the JS community has fallen out of love with things like classes. Because JS doesn't have static types, and without those, well... Classes don't actually exist. At least not in the way they do in other languages like C++. You can pretend you're working in a regular OOP language, and use the prototype object like you would a C# or Java class but since you don't have static dispatch at compile time, you're frankly playing this part of JS as a weakness instead of a strength. Which is why the JS community has been "growing beyond" classes. If working with classes in JS is more comfortable for you, then I think you should do so, but ultimately a JS class is just a function. Once you grow comfortable with working with modules and functions, you're very rarely going to be writing classes when working with JavaScript. You're still going to do so from time to time, when it makes sense, but often its both unnecessary, less efficient and harder to maintain something that is build like a C++ class rather than than a JavaScript function. While working with JavaScript, being a key part of it. This is not an attack on OOP in general, just an explanation as to why the JS community has "moved beyond" pretending JS is an OOP language the same way Java is an OOP language. > Try stepping outside of JavaScript for a while, broaden your experience. I do so regularly.
- andrewmcwatters 3y ago
  A JavaScript class is syntactic sugar for prototypes, not functions. JavaScript is a prototype-oriented language.
  - devjab 3y ago
    > A JavaScript class is syntactic sugar for prototypes, not functions. Again you're basically speaking into exactly what I'm trying to say. Because what are JavaScript functions? It is also a prototype. I'll try to put it a different way. The JS community has "moved beyond" classes because they are functions. Both classes and functions are prototypes, but functions are often easier to work with, more maintainable and more efficient. I'm not trying to say that you should never write another JavaScript class in your life. I write them myself when it's prudent to build things in a structure that resembles classical OOP. The reason I don't personally use that sort of coding style, if I can avoid it, is because it's an act. It looks like classical OOP, but everything is mutable at any time which means it's very easy for consumers of the code to break it by accident. This is less of a problem when you build things as isolated modules, based on individual functions, because there simply isn't any complexity to "misuse". This is sort of similar to why the virtual DOM became so popular in frontend JavaScript. Because it's harder to work directly with the DOM itself. It's not necessarily better to use functions, it's just "safer", because they come with less risk of someone doing something bad by accident down the line.

c-hendricks 3y ago

So you're just gonna ignore that whole "the JS community" bit then, ok. Is this what $200/hour consultancy looks like?

andrewmcwatters 3y ago
Try writing some code in not just JavaScript but also C, C++, Java, and others. Classes aren't some relic. You use prototypes in JavaScript every single day.
- c-hendricks 3y ago
  You're still just blowing past "the JS community". To fill you in on the context of the thread you inserted yourself into, classes have fallen out of favour _in JS_. It's pointless to say "but they're still used in other languages!" because we're not talking about other languages, we're talking about JS.
  - andrewmcwatters 3y ago
    I, too, am talking about JavaScript. Everything in JavaScript is prototype-oriented whether you ignore it or not. You can choose to write functions for everything, but you're still always using object prototypes. There are several large popular libraries in JavaScript which do not orient themselves around functional object orientation, too. So you might work in one corner of JavaScript where all you experience is functions, but that's not the case everywhere. They haven't "fallen out of favor," whatever that means.

devjab 3y ago

I think we may be talking a little bit in two different directions, because when you write this: > Classes and types and methods exist for a reason. What that reads like to me is actually the exact explanation as to why the JS community has fallen out of love with things like classes. Because JS doesn't have static types, and without those, well... Classes don't actually exist. At least not in the way they do in other languages like C++. You can pretend you're working in a regular OOP language, and use the prototype object like you would a C# or Java class but since you don't have static dispatch at compile time, you're frankly playing this part of JS as a weakness instead of a strength. Which is why the JS community has been "growing beyond" classes. If working with classes in JS is more comfortable for you, then I think you should do so, but ultimately a JS class is just a function. Once you grow comfortable with working with modules and functions, you're very rarely going to be writing classes when working with JavaScript. You're still going to do so from time to time, when it makes sense, but often its both unnecessary, less efficient and harder to maintain something that is build like a C++ class rather than than a JavaScript function. While working with JavaScript, being a key part of it. This is not an attack on OOP in general, just an explanation as to why the JS community has "moved beyond" pretending JS is an OOP language the same way Java is an OOP language. > Try stepping outside of JavaScript for a while, broaden your experience. I do so regularly.

andrewmcwatters 3y ago
A JavaScript class is syntactic sugar for prototypes, not functions. JavaScript is a prototype-oriented language.
- devjab 3y ago
  > A JavaScript class is syntactic sugar for prototypes, not functions. Again you're basically speaking into exactly what I'm trying to say. Because what are JavaScript functions? It is also a prototype. I'll try to put it a different way. The JS community has "moved beyond" classes because they are functions. Both classes and functions are prototypes, but functions are often easier to work with, more maintainable and more efficient. I'm not trying to say that you should never write another JavaScript class in your life. I write them myself when it's prudent to build things in a structure that resembles classical OOP. The reason I don't personally use that sort of coding style, if I can avoid it, is because it's an act. It looks like classical OOP, but everything is mutable at any time which means it's very easy for consumers of the code to break it by accident. This is less of a problem when you build things as isolated modules, based on individual functions, because there simply isn't any complexity to "misuse". This is sort of similar to why the virtual DOM became so popular in frontend JavaScript. Because it's harder to work directly with the DOM itself. It's not necessarily better to use functions, it's just "safer", because they come with less risk of someone doing something bad by accident down the line.