5 ms·

I don't understand the need for the ever-growing list of "enhancements" to JS. Take Class for example. Class is entirely unnecessary and, essentially, tries to

I don't understand the need for the ever-growing list of "enhancements" to JS. Take Class for example. Class is entirely unnecessary and, essentially, tries to turn JS into a class-oriented language from its core which is object-oriented. I never create classes. I always create factory functions which, when appropriate, can accept other objects for composition. And I don't use prototypes, because they are unnecessary as well. Thus sparing me the inconvenience, and potential issues, of using 'this'. In my dreams those who want to turn JS into c# or Java should just create a language they like and stop piling on to JS. But, at least so far, the core of JS has not been ruined. That said, there are some new features I like. Promises/async/await, Map, Set, enhancements to Array being among them. But to my way of thinking they do not change the nature of the language in any way.

imbnwa 2y ago
>And I don't use prototypes, because they are unnecessary as well. Thus sparing me the inconvenience, and potential issues, of using 'this'. Eh, prototypes share, instead of create, method references. I guess you can use delegate objects too though unless you're just doing pure functions.
- zanethomas 2y ago
  Sure, but imo unless one is creating very many objects each with their own set of functions it's not really a significant issue. Sometimes programmers spend way too much time optimizing code which doesn't really need it. In my experience how data is structured is almost always the most important factor when it comes to performance. Good data structure + simple code === performance.
wruza 2y ago
Otoh, I create classes, use prototypes and it’s natural and useful in many of my cases. In my dreams those who want to turn JS into c# or Java should just create a language they like and stop piling on to JS. We could even share this dream if browser vendors weren’t such whos the boss iam da boss when it comes to extensions and alternatives. So we have to live in a common denominator, which surprisingly isn’t as bad as it could be, really.
- zanethomas 2y ago
  I wonder why it seems natural to you? I'm guessing JS wasn't your first language and you didn't learn the power of composition instead of classes.
  - wruza 2y ago
    Because I think in objects (non-strictly related groups of data and methods) and it’s natural to how my business processes work. Light OOP creates neither translation nor maintenance layers to it. See https://news.ycombinator.com/item?id=41808034 https://news.ycombinator.com/item?id=41808034 I'm guessing JS wasn't your first language Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts is only a recent addition, so I might have missed some fashion ideas. Tongue in cheek aside, if you’re an old dev, there’s nothing you have to listen to because you can see whether you have a problem yourself and decide for yourself. You can be your own advisor. I see both “classes” and “just functions” ways clearly and can convert my current codebases in my mind between these two. Nothing really changes for the latter, apart from bulky import sections, lots of * as ident imports, context-arg passing and few dispatch points. Objects (non-strictly related groups of data and methods) still exist and hold refs to event/callback emitters. So my reasoning isn’t why, my reasoning is why not. I have a tool, I have a business logic, pen pineapple apple pen. Don’t overthink it is my main principle. Do I need to introduce composition? Do I have it already? How is it better than what I’m doing? Is it? What am I missing? What are they missing? What if they don’t? What if we speak of different things? These are the questions of a restless butt that cannot find rest on any stool. Instead it should ask: Do I have a problem?
    - zanethomas 2y ago
      :) I started with 6800 machine language. Then c, smalltalk, scheme and etc. Rather than spend a lot of time and botch a comparison between classes and factory functions I'll link you to an article. He went further, introducing something he calls stamps, but I found them to be awkward the only time I tried to use them. https://medium.com/javascript-scene/javascript-factory-functions-vs-constructor-functions-vs-classes-2f22ceddf33e https://medium.com/javascript-scene/javascript-factory-funct...
andai 2y ago
I like JS's flexibility too, but I have to point out that your object-oriented JS code is compiled into C++ classes by the v8 optimizer! (Unless you change their structure, in which case it gives up (deoptimization).)
- zanethomas 2y ago
  Does it compile something like this into a c++ class? makeThing(options, usethistoo) { let foo = options.foo; let thistoo = usethistoo; return { functions... } }
  - unchar1 2y ago
    I'm not sure if "C++ class" is the right term, but it will certainly compile into a class behind the scenes [1] You can use d8 to check what the class structure ends up looking like [2] --- [1]: https://v8.dev/docs/hidden-classes https://v8.dev/docs/hidden-classes [2]: https://v8.dev/docs/d8 https://v8.dev/docs/d8
unchar1 2y ago
Classes generally point you towards writing more performant code. Factory functions allow you to achieve the same performance, you just have to be a bit more careful not to cause a depot :) For example, 1. field declarations [1] make sure that the fields are always initialized in the same order. That way most of your functions end up monomorphic, instead of being polymorphic [2] 2. Method declarations are also (almost) free, since you only pay for them once, during class initialization. You also get a few other niceties such as private properties. You can emulate private properties with closures in factory functions but V8 has a hard time optimizing, unfortunately. --- [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#class_body https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://www.builder.io/blog/monomorphic-javascript https://www.builder.io/blog/monomorphic-javascript
- zanethomas 2y ago
  The difference in performance is negligible for all but the most demanding applications. In which case I would still use factory functions, but just be more careful.
  - unchar1 2y ago
    I agree. But it's one reason why someone who is concerned about performance, may prefer classes by default.

imbnwa 2y ago

>And I don't use prototypes, because they are unnecessary as well. Thus sparing me the inconvenience, and potential issues, of using 'this'. Eh, prototypes share, instead of create, method references. I guess you can use delegate objects too though unless you're just doing pure functions.

zanethomas 2y ago
Sure, but imo unless one is creating very many objects each with their own set of functions it's not really a significant issue. Sometimes programmers spend way too much time optimizing code which doesn't really need it. In my experience how data is structured is almost always the most important factor when it comes to performance. Good data structure + simple code === performance.

wruza 2y ago

Otoh, I create classes, use prototypes and it’s natural and useful in many of my cases. In my dreams those who want to turn JS into c# or Java should just create a language they like and stop piling on to JS. We could even share this dream if browser vendors weren’t such whos the boss iam da boss when it comes to extensions and alternatives. So we have to live in a common denominator, which surprisingly isn’t as bad as it could be, really.

zanethomas 2y ago
I wonder why it seems natural to you? I'm guessing JS wasn't your first language and you didn't learn the power of composition instead of classes.
- wruza 2y ago
  Because I think in objects (non-strictly related groups of data and methods) and it’s natural to how my business processes work. Light OOP creates neither translation nor maintenance layers to it. See https://news.ycombinator.com/item?id=41808034 https://news.ycombinator.com/item?id=41808034 I'm guessing JS wasn't your first language Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts is only a recent addition, so I might have missed some fashion ideas. Tongue in cheek aside, if you’re an old dev, there’s nothing you have to listen to because you can see whether you have a problem yourself and decide for yourself. You can be your own advisor. I see both “classes” and “just functions” ways clearly and can convert my current codebases in my mind between these two. Nothing really changes for the latter, apart from bulky import sections, lots of * as ident imports, context-arg passing and few dispatch points. Objects (non-strictly related groups of data and methods) still exist and hold refs to event/callback emitters. So my reasoning isn’t why, my reasoning is why not. I have a tool, I have a business logic, pen pineapple apple pen. Don’t overthink it is my main principle. Do I need to introduce composition? Do I have it already? How is it better than what I’m doing? Is it? What am I missing? What are they missing? What if they don’t? What if we speak of different things? These are the questions of a restless butt that cannot find rest on any stool. Instead it should ask: Do I have a problem?
  - zanethomas 2y ago
    :) I started with 6800 machine language. Then c, smalltalk, scheme and etc. Rather than spend a lot of time and botch a comparison between classes and factory functions I'll link you to an article. He went further, introducing something he calls stamps, but I found them to be awkward the only time I tried to use them. https://medium.com/javascript-scene/javascript-factory-functions-vs-constructor-functions-vs-classes-2f22ceddf33e https://medium.com/javascript-scene/javascript-factory-funct...

andai 2y ago

I like JS's flexibility too, but I have to point out that your object-oriented JS code is compiled into C++ classes by the v8 optimizer! (Unless you change their structure, in which case it gives up (deoptimization).)

zanethomas 2y ago
Does it compile something like this into a c++ class? makeThing(options, usethistoo) { let foo = options.foo; let thistoo = usethistoo; return { functions... } }
- unchar1 2y ago
  I'm not sure if "C++ class" is the right term, but it will certainly compile into a class behind the scenes [1] You can use d8 to check what the class structure ends up looking like [2] --- [1]: https://v8.dev/docs/hidden-classes https://v8.dev/docs/hidden-classes [2]: https://v8.dev/docs/d8 https://v8.dev/docs/d8

unchar1 2y ago

Classes generally point you towards writing more performant code. Factory functions allow you to achieve the same performance, you just have to be a bit more careful not to cause a depot :) For example, 1. field declarations [1] make sure that the fields are always initialized in the same order. That way most of your functions end up monomorphic, instead of being polymorphic [2] 2. Method declarations are also (almost) free, since you only pay for them once, during class initialization. You also get a few other niceties such as private properties. You can emulate private properties with closures in factory functions but V8 has a hard time optimizing, unfortunately. --- [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#class_body https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://www.builder.io/blog/monomorphic-javascript https://www.builder.io/blog/monomorphic-javascript

zanethomas 2y ago
The difference in performance is negligible for all but the most demanding applications. In which case I would still use factory functions, but just be more careful.
- unchar1 2y ago
  I agree. But it's one reason why someone who is concerned about performance, may prefer classes by default.