> Classes in JavaScript are just sugar around functional closures.
One of the key red flags I look for in articles like this are whenever the "overhead" of classes is mentioned, such as with "there’s no need to allocate space to a class instance", without any actual metrics showing what this "space overhead" or "performance penalty" amounts to.
It seems like more of a misconception about how JavaScript works. There may be some overhead, but do we know what it actually is in a real world application? Or are we just going on assumptions about what we feel is "light" versus "heavy", often frequently with a biased opinion because we simply don't like OOP concepts?
Performance and classes are a complicated subject.
In short classes execute very fast in V8 jsVM for similar reasons they benefit lower level languages like C++. That improvement applies to the syntax only and almost exclusively to micro benchmarks. The problem with classes, and OOP in general, is that there is a lot of decoration that goes into the code in real world use cases. That decoration is generally not beneficial to performance, such as: getters, setters, a bunch of unnecessary implicit reference calls, access to the DOM using a bunch of unnecessary abstraction layers, and so forth. If you are the kind of JS expert that is easily capable of not using OOP you can probably get this right and make really fast use of classes, but that’s not the primary audience.
One of the key red flags I look for in articles like this are whenever the "overhead" of classes is mentioned, such as with "there’s no need to allocate space to a class instance", without any actual metrics showing what this "space overhead" or "performance penalty" amounts to.
It seems like more of a misconception about how JavaScript works. There may be some overhead, but do we know what it actually is in a real world application? Or are we just going on assumptions about what we feel is "light" versus "heavy", often frequently with a biased opinion because we simply don't like OOP concepts?