0

In Google developers article about JavaScript code optimization, they recommend in the section "Defining class methods" to use prototype to add methods as properties to a function (which is considered as an object in JavaScript).

for instance, instead of defining the methods inside the function constructor body this way: 

baz.Bar = function() {
// constructor body
this.foo = function() {
// method body
};
}

methods should be defined using prototype this way: 

baz.Bar = function() {
// constructor body
};

baz.Bar.prototype.foo = function() {
// method body
};

But, I have seen a different approach of adding class methods and creating reusable JavaScript code that is used in frameworks like d3.js to implement the core methods which is based on JS closures, for instance: 

var nameSpace = {}; 
nameSpace.myModule = function(module){

   var myVar = ''; 

   function exports(){

   }

   //getter and setter for myVar 
   exports.myVar = function(_x){
       if(!arguments) return myVar; 
       myVar = _x; 
       return this; // to allow for method chaining 
   }

   exports.method1 = function(){
     //do something 
   }

   exports.method2 = function(){
     //do something 
   }

   return exports;

 }

and then to use the module:
var test = nameSpace.myModule(); 
test.method1();

Would this last approach be the answer to the performance and reuse of JavaScript code, otherwise why it is extensively used in framework implementation?

Thanks & regards Mohamed Ali

Mohamed Ali JAMAOUI
  • 14,275
  • 14
  • 73
  • 117
  • In that graph `Non Prototype` is the worst by far... – elclanrs Sep 20 '13 at 08:03
  • the question is edited, would u please have another look – Mohamed Ali JAMAOUI Sep 20 '13 at 08:06
  • Most javascript libraries are not very optimized, for reasons such as priority or ignorance. This pattern is indeed one of the worst things you can do to performance and offers mainly a tiny code size advantage due to not having to repeat `this.` so much. – Esailija Sep 20 '13 at 10:09
  • 1
    There is some outdated and counter-productive advice in that article. String concatenation is fine now and optional properties are actually worse for performance because the constructor will create objects with different hidden classes even though they conceptually share the same class. – Esailija Sep 20 '13 at 10:18
  • 1
    See http://jsperf.com/12312412354 for how bad optional properties are – Esailija Sep 20 '13 at 10:44
  • thanks, very interesting comments! could you please point to more up to date recommendation for JavaScript code optimization – Mohamed Ali JAMAOUI Sep 20 '13 at 11:27

1 Answers1

0

As a user, modules impose a performance hit when they contain lots of methods and classes that you don't use. If you just need a few members, you are better off creating them individually as classes instead of importing a full module.

As a browser, there is small computational overhead in initializing a module and namespace, and memory overhead in tracking, but likely not significantly different than the equivalent set of classes and class methods outside of a module.

As a writer, organizing your code into modules when you think the user will typically need all the members is good practice. Better to have a few modules with several related components (a "package") than 25 raw components or one module with all of them. This ease of use and understanding, the compartmentalization into a namespace (which lets you use meaningful names without conflicts to other namespaces), and the grouping of related classes and functions into various modules is why it is typically used in a framework, where you are likely to use most of the components for each module.

wwwslinger
  • 936
  • 8
  • 14