I had a thought today that maybe some of the javascript seniors can answer.
What is the estimated DOM overhead in creating multiple classes in Mootools?
Good OO design dictates that any reusable bits of code should go in a Class. But since every created Class in mootools explicitly inherits from “Class” it of course get a lot of extra instantiated.
So my – more or less philosophical – question is, how much does that impact performance in the Browser as all code is instantiated onload and with for instance using a DTO pattern with hundreds or thousands of Classes in an array, compared to simple objects.
Ponderously,
Michael
Right. Here is how I see this. First and foremost, a quote from @keeto:
staying classy
”The last part is important. While classes are a very good way to implement modular code, they’re not the only way to do it. I find that there’s a distasteful tendency nowadays for some developers to use classes for everything. Like the proverbial hammer, classes are being used for every coding nail—which is unfortunate, because not all things are supposed to be classes.
Classes are great for creating reusable code that can be used across projects, and I personally stick to that criteria. Unless I’m sure that something I’m building will be used more than once, I won’t turn it into a class. And in case you haven’t noticed, you can use MooTools without having to define a single custom class. After all, just because MooTools has classes doesn’t mean you’ll have to code in JavaScript like it’s Java.*”
Source: http://keetology.com/blog/2010/10/01/modules-and-callbacks-going-hollywood-with-mootools
This is very subjective as it largely depends on how you write your classes and javascript in general.
Using a class is NOT without a penalty and an overhead. Dependent on the type of Class you instantiate, this will differ. For example, if your class is a simple data abstraction that does not touch other objects or output to the DOM, it is relatively cheap to make instances. The costs will be around processing options objects and (sometimes) copying properties into your instance constructor.
During Class definition itself, MooTools does loop through all constructor object properties and tries to deal with all the special ones and the mutators (eg,
initialize,Implements,Extends,binds(from -more) etc). This is a one-off, though. Once the constructor function has been created, you can use it fast.It will also do something else – it will wrap all properties that have function values so that you can decorate them as private (via
.protect()in the current API) so any function you run will get curried for you. Additionally, you often tend to use.bind()as method decorators as well, which means 2 wrappers for the actual code that runs.The more complicated your Class is (extending and implementing from different class protos), the more work can be involved in creating instances of your class. In reality, you need to create an absolute monster to start noticing this as anything other than memory allocation (delays on start or garbage collection). Of course, cpu-heavy or async / blocking stuff in constructor functions won’t be nice either, if you do it lots…
Events, event listeners and so forth can also stack up.
Saved references to objects will stack up over time.
Then, there are classes that bind to DOM elements, add events, listen to events, export their own events…
Put it all together and it can become somewhat costly. You are creating Objects that inherit (hopefully by reference via the prototype chain) from many places. Even so, the definition of your class constructors itself is fast and it won’t be until you create 1000s of instances that things will start getting interesting and put a modern browser to the test.