In one of his Javascript talks, Crockford provides an example of an object creation function that he believes should have been included in JavaScript itself. The YUI(3) team, however, opts to use "new" despite Crockford's recommendations. This discrepancy highlights a conflict within the language, which mixes prototype-based inheritance with elements of traditional class-based languages.

Despite these theoretical debates, the reality is that JavaScript is what it is, so developers are advised to simply go ahead and use "new" for object creation. If interested, Crockford's object creation function can be found here.

 if (typeof Object.create !== 'function') {
     Object.create = function (o) {
         function F() {}
         F.prototype = o;
         return new F();
     };
 }
 newObject = Object.create(oldObject);

An updated version of Crockford's object creation function is available on his website.

It's worth noting that modern browsers support Object.create(...), eliminating the need for Crockford's custom function. However, performance considerations may lead some developers to continue using the traditional new Constructor() approach instead.

As the industry moves towards wider acceptance of ES6 classes, there may be compelling reasons to explore both Object.create and traditional instantiation methods. Ultimately, the choice between the two approaches may depend on the specific requirements of each project and the preferences of individual developers.

Personal experiences vary, but some developers, including myself, have embraced ES 2015 Javascript and moved away from using new extensively. By adopting a more functional programming style without relying heavily on objects and classes, I have found greater convenience and power in my projects. While there are no hard and fast rules, it's always beneficial to experiment and find the approach that works best for your needs.

When it comes to avoiding the use of new Date() or new XMLHttpRequest(), I must admit that I am not entirely sure myself. However, I have found a way to steer clear of using 'new' for my custom types.

To begin, I rely on Object.create(). Although this method is part of ES5 and may not be universally supported, I can easily include it by utilizing the es5-shim.

Embracing the module pattern, I encapsulate my type within a self-invoking anonymous function as follows: var Xyz = (function() {...})(). This approach provides me with a private environment in which to operate without cluttering the global namespace. My returned object contains a create() function for users to instantiate my type and a prototype property for potential inheritance purposes.

For instance, consider the following example:

var Vehicle = (function(){
        var exports = {};
        exports.prototype = {};
        exports.prototype.init = function() {
                this.mph = 5;
        };
        exports.prototype.go = function() {
                console.log("Going " + this.mph.toString() + " mph.");
        };

        exports.create = function() {
                var ret = Object.create(exports.prototype);
                ret.init();
                return ret;
        };

        return exports;
})();

And when exploring inheritance:

var Car = (function () {
        var exports = {};
        exports.prototype = Object.create(Vehicle.prototype);
        exports.prototype.init = function() {
                Vehicle.prototype.init.apply(this, arguments);
                this.wheels = 4;
        };

        exports.create = function() {
                var ret = Object.create(exports.prototype);
                ret.init();
                return ret;
        };

        return exports; 

})();

It's unwise to dismiss the use of new and blindly adhere to Crockford's teachings.

Master JavaScript and strive for excellence in your code. Embracing the new keyword is fundamental to object-oriented programming in JavaScript.

Avoiding new means potentially overlooking valuable opportunities to enhance your JavaScript code.

Instead of arbitrarily limiting your coding capabilities, take the time to understand and properly utilize all tools at your disposal.

Crockford often condemns any aspect of JavaScript that has caused issues in his own code.

I personally believe that "[a]n even better coping strategy is to be competent."

To bypass the use of new, you can opt for constructing factory functions:

var current = Date.getCurrentDate();

(Just so you know, evasion of using new doesn't apply to the factory function itself:)

Date.getCurrentDate = function() { return new Date(); };

I recommend creating such functions only if it enhances semantic meaning (like in the example above) or allows defaulting constructor parameters. In essence, don't resort to this technique solely to evade the use of new.

This query has already been addressed and resolved: Is JavaScript's "new" keyword considered harmful?

According to Raynos, mindlessly adhering to Crockford (or any other authority) without comprehending the rationale behind their assertions is foolish.

In my opinion, the suggestion to avoid using new altogether should be seen as more of a theoretical concept rather than a strict rule to follow. One exception to this guideline is when working with the Date class in JavaScript, where using new is necessary to create date objects.

When it comes to creating instances of custom objects without using new, there are alternative methods that can be employed. For example, one approach is to use factory-like functions instead of constructors. These functions can accept an object instance as input and modify it to fit the desired type. Here's an example:

var createNewCar = function(obj) {
  obj = obj || {};
  // Define methods and properties for 'obj' here...
  return obj;
}

When it comes to creating objects, you don't have to rely on the 'new' keyword for other people's code. However, for your own code, there are ways to avoid the issues that come with using both 'this' and 'new'.

(Interestingly, the problem doesn't actually lie with 'new' itself. Instead, when an object is instantiated with 'new', it often involves the use of 'this' internally. Working with 'this' can introduce subtle bugs due to JavaScript's nature of requiring the caller to bind the called method correctly to the object. Detecting incorrect bindings before runtime can be challenging.)

In short:

If you want to steer clear of using 'new' to create objects in your code, simply return an object from any function. Within that function, attach methods to the object and handle initialization tasks. That function serves as both your class definition and constructor.

For a more detailed explanation with an example:

The 'self' pattern provided below eliminates the need for 'new' and 'this'. While this pattern does result in multiple copies of methods being stored in each object, this won't pose an issue unless you're generating numerous objects during runtime. In such cases, you can consider implementing the 'flyweight' pattern outlined at . (It may require slight modifications to adapt examples from that page to the pattern described below.)

// This function serves as a "class" -- the entire function acts as the constructor
function Foo(x) {
    // Define and initialize the desired object type here
    var self = {x: x};
    
    // For subclassing purposes, you can also do:
    // var self = Baz(x);

    // Public method
    self.foo = function() {
        return self.x;
    };

    // Another public method
    self.bar = function() {
        console.log(self.x);
        logger();
    };

    // Private method
    function logger() {
        console.log(self.x);
    }

    // Other constructor components can be added here

    // Remember to return self
    return self;
}

var f = Foo(1); 
var g = Foo(2); 
setTimeout(f.bar, 1000);
setTimeout(g.bar, 1000);

console.log(g.foo()); // 2
g.x = 5;
console.log(f.foo()); // 1
console.log(g.foo()); // 5

// ...after 1 second:
// 1  (from f.bar)
// 1  (from f.logger)
// 5  (from g.bar)
// 5  (from g.logger)

// Uncommenting will cause an error
// f.logger();

define function F() { return { /* add properties and functions here */ } }

Avoid using the "new" keyword by returning an anonymous object and incorporating a closure in your constructor function. This technique also allows you to conceal private data effectively.

For example:

function CustomCounter(start) {

    var counter = start;

    return {
        getCounter: function() {
            return counter;
        },

        increaseCounter: function() {
            counter++;
        }

    };
}

To utilize this, simply follow these steps:

var myCustomCounter = CustomCounter(5);
myCustomCounter.increaseCounter();
console.log(myCustomCounter.getCounter()); // output should be 6

The advantage here is that there's no need to remember using "new", although it won't cause any issues if you decide to use it.

var anotherCounter = new CustomCounter(5); // it still functions correctly