1

I want to document the differences between classes and closures in JavaScript. Both class-based, object-oriented and functional JavaScript exist in the wild. For example in React, both class components and function components with hooks are supported.

I don't want to assert that you would ever choose one programming paradigm over another purely based on their performance, but is it possible that in modern JavaScript engines classes have a better chance to be optimized due to their language support?

I was under the impression that classes were just syntactic sugar for inheritance implemented with a prototype chain, but while this still appears to be a popular point of view, it is not correct.

In addition, their are new proposals such as decorators and private fields which continue to put more distance between classes and their alternatives. While decorators are just the composition of higher-order functions and private fields can be emulated, I expect that JavaScript engines may not perform identical optimization in all cases.

I am also aware that JavaScript engines employ techniques such as hidden classes to improve their performance. To my knowledge this optimization is not class specific. However, this made me curious...

Are their any optimizations that current JavaScript engines perform on classes, that are may not be applied in cases where classes are avoided? Would their be invariants that might be easier to identify and exploit due to the consistent nature of the class-based syntax?

I did try to read through the source code of the V8 engine, but it is large and complex, and I expect would take me a significant amount of time before I could even create a hypothesis. Therefore, I think this question is better left to someone with more experience than me in this domain.

So far my quest has led me from the parser to the abstract syntax tree and then to the bytecode generator used by the interpreter. I am aware that the interpreter (Ignition) is just the first stage of the JIT, and is followed by the compilers Sparkplug and Turbofan, which then transform the bytecode into machine code.

Indeed, classes do appear to have specific bytecode generation as seen in the BuildClassLiteral in the BytecodeGenerator class. However, I am unaware if this could yield better performance further into the pipeline of compilers.

scottwillmoore
  • 450
  • 2
  • 9
  • Do you have more examples than React? According to my experience, React is the exception and not the norm. Angular and Aurelia use classes. Vuejs uses objects. React has function components and class components. I wouldn't say that **a lot of** modern libraries avoid classes and therefore this isn't an indicator for bad performance with classes. – jabaa Apr 29 '23 at 10:01
  • The question wasn't aimed in particular at React, but rather the idea of avoiding object-oriented in JavaScript. I also implied the opposite, that classes might perform *better* due to their popularity. Without being exhaustive, there are definitely many libraries that are built without classes such as [`tinybase`](https://github.com/tinyplex/tinybase), [`jotai`](https://github.com/pmndrs/jotai) and [`zustand`](https://github.com/pmndrs/zustand). New frameworks such as [`solid`](https://github.com/pmndrs/zustand) and [`qwik`](https://qwik.builder.io/) also make some effort to avoid classes. – scottwillmoore Apr 29 '23 at 10:15
  • I understand that the question wasn't aimed at React, but your premise is based on React and I think your premise is wrong. Yes, not all modern libraries use classes, but they don't try to deliberately avoid them. Sometimes other design pattern fit better. Some developers don't like OOP and some even think it's an anti pattern. Some developers prefer functional programming. I don't think performance is the reason for this choice. – jabaa Apr 29 '23 at 10:21
  • @jabaa: No. My premise was not to imply that performance was the reason for this choice. Nor to imply that these you should prefer one programming paradigm over another. I just wanted to establish that both OOP and non-OOP code exist and are popular. Then, is it possible that modern JavaScript engines have additional optimizations for classes due to their more rigid definition and syntactical support? What conclusion you draw from the answer to this question is up to you. – scottwillmoore Apr 29 '23 at 11:08
  • @AndyPreston: As I discuss in the question. This is not correct, while mostly syntactic sugar, JavaScript classes are [more than just syntactical sugar](https://stackoverflow.com/questions/36419713/are-es6-classes-just-syntactic-sugar-for-the-prototypal-pattern-in-javascript). In addition, as I discussed, the bytecode generated for JavaScript classes is unique: [BytecodeGenerator::BuildClassLiteral](https://github.com/v8/v8/blob/3b36641300ca404a214548a62f4dc130f3a0c2c6/src/interpreter/bytecode-generator.cc#L2743). – scottwillmoore Apr 29 '23 at 11:13

1 Answers1

4

(V8 developer here.)

I think this can largely be answered with "no", but the question is rather broad.

One issue is that I'm not sure what you're comparing. Are you comparing classes to non-class-based (e.g. pre-ES6) OOP, or to some definition of "functional programming" that avoids using objects entirely? If the latter, then the the answer is both trivial (yes, engines have lots and lots of optimizations that deal with objects and hence are only applicable to objects) and useless (because that doesn't say anything about whether using objects or not using objects will be faster overall).

Comparing classes to class-avoiding OOP, there isn't a big difference in optimization potential, because classes don't provide additional guarantees or invariants. For example, you can still add and remove properties of class instances, you can change which prototype they point at, and what fields and methods are present on that prototype. Locking down these things might give more optimization opportunity, or at least would make existing optimizations more reliable and less speculative, but that's not what classes do today. As it stands, JavaScript classes are mostly for the benefit of JS programmers, not for the benefit of JS engines. If they affect JS performance, then that's probably mostly by making a few particularly inefficient coding patterns less likely (such as installing methods as fields in the constructor).

"Is it possible...?", sure, everything is possible. I'm not aware of an example, but that doesn't mean that there isn't or can't ever be one: as you note, the V8 source code is large and complex, and I'm far from knowing all of it in detail. I could try to make a few guesses and toy around with some examples, but even if I managed to find some artificially crafted case where class-based code is optimized better than some non-class-based alternative, would that really help you?

As a general note, keep in mind that "optimization" isn't something binary, in the sense that the situation is far more nuanced than "feature X is optimized, feature Y is not". To make an analogy: when cleaning up your house, there are clearly many more states than "this room is cleaned up" and "this room is not cleaned up". Even a statement like "I've spent the entire day cleaning up the kitchen" doesn't imply that the kitchen is the best-cleaned-up room now: maybe it was such a mess to begin with that it's still less clean than the bedroom, even though nobody has been working on the latter today. The existence of kitchen-specific clean-up techniques (such as running the dishwasher) doesn't imply that kitchens have a general tendency to be cleaner than other types of rooms. And also, there's always something more that one could do, if only there was a little more time left in the day...

jmrk
  • 34,271
  • 7
  • 59
  • 74
  • Awesome, thank you so much for your answer! Yes, you're right the comparison should be about the difference between classes and non-classes that are still prototypical OOP (such as pre-ES6), not "functional programming". – scottwillmoore Apr 30 '23 at 03:24
  • This isn't really a specific question... As you addressed, the difference in optimization of classes and closures is far much more distinct, and also more important in my opinion. For example, both classes and closures can have private fields, but they accomplish this in different ways. I guess a good first step would be to create a good set of benchmarks and test cases to highlight these differences. Then, this would yield some conclusions, but also many more questions that could be discussed. – scottwillmoore Apr 30 '23 at 04:00
  • Some questions that I think I can answer, that might be interesting to ponder? Q: Due to the class syntax being more concise than pre-ES6 OOP, it would result in smaller JavaScript bundles and thus parse time should be reduced. A: Yes? But, the performance impact is most likely negligible. Q: Private fields (which are unique to classes), may provide future potential for optimization, that would separate them from pre-ES6 OOP. A: Yes? Of course possible, but as you mention, there is only so much time in the day to implement these optimizations. – scottwillmoore Apr 30 '23 at 04:03
  • @scottwillmoore Private fields are a great example of a feature that helps JS developers but not engines. I'm not aware of any optimization that would be enabled by having private fields. – jmrk Apr 30 '23 at 16:05