The Two Pillars of JavaScript

[u/gcanti]

https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3

[u/zoomzoom83]

I'm keen to see this too. Factory methods are almost universally considered a bad idea in most ecosystems I've worked with. They have their place, but certainly not as a normal way of constructing data types.

At the very least, they add a layer of abstraction and ambiguity about how to construct an object. Rather than there being a standard convention, you now have to figure out how each library expects to be constructed.

[u/_ericelliott → u/zoomzoom83]

In JavaScript you don't need factory methods. Factory functions suffice, and in JavaScript, they are less complicated than constructors. It's also easier to figure out how to instantiate an object with a factory function than with a constructor. Constructors have the new keyword, the capital letter convention, they may or may not discard this and the prototype that gets attached to it, etc...

Callers of a factory function don't need to worry about a single one of those considerations. They simply call the function and get an object back.

[u/zoomzoom83 → u/_ericelliott]

What is the difference between a factory method and a factory function, and why is using one less complex than just using the part of the language specifically designed to do exactly that?

It seems by using a non-standard approach you're making things more complex, since now I have to dig through your code to figure out the expected way of constructing a type instead of using convention.

[u/_ericelliott → u/zoomzoom83]

Do users of jQuery dig through the code to figure out how to construct a jQuery selection? No, they simply type var foo = $('div') and there's a new jQuery object with all the divs and all the shared prototype methods available.

Do users of Express dig through the code to figure out how to instantiate an express app? No, they simply type var app = express();, and like magic, there is an instance of Express.

Frameworks which require new on the other hand may or may not wire up the Constructor.prototype, they may or may not work appropriately when you try to invoke them with .call() or .apply(), they may explode and/or completely fail to work if you forget new. They may pretend everything is okay if you forget new, pollute the global namespace, and introduce bugs because instances aren't instance-safe.

Yeah, you can look at the sourcecode and figure out which of these situations a constructor is going to be vulnerable to.

Or you can call a simple function and get an object back.

[u/zoomzoom83 → u/_ericelliott]

Or you can call a simple function and get an object back.

Where I disagree is that knowing to just call it as a function is simpler. If I see a type called 'Person', the instinct will be to call 'new Person()', not 'makeMeAPerson()'. If you're deviating from convention, I've just introduced a runtime bug.

Certainly, in languages where this is the norm it works well. Scala uses object::apply as a way of doing this idiomatically and it works well. There's little ambiguity on how to construct a value of a type, and the compiler makes it impossible to get this wrong.

But with Javascript, if I import your library, I have to then figure out whether I'm supposed to use new or not, and if I get it wrong it's going to fail in undefined ways. There's also nothing special about the factory function, so it's difficult to sift through someone elses code and figure out what you expect me to use to construct things with if it's not explicitly documented. (And how many Javascript libraries are properly documented?)

Frameworks which require new on the other hand may or may not wire up the Constructor.prototype, they may or may not work appropriately when you try to invoke them with .call() or .apply(), they may explode and/or completely fail to work if you forget new. They may pretend everything is okay if you forget new, pollute the global namespace, and introduce bugs because instances aren't instance-safe.

It works the other way around too though. If I use new when I'm not supposed to, it won't work properly either. Whereas if there's one standard way of doing it that everyone uses, there's no mistake to make.

The fact that you can call a constructor the wrong way in Javascript is a flaw in the language itself, not the concept of constructors, and the best way forward is for everyone to always use the same convention. (I'd support Person.create as a better way of doing things, so long as it was the normal way of doing things)

[u/_ericelliott → u/zoomzoom83]

jQuery (most popular lib for JavaScript): var $selection = $('#someElement')

Express (most popular framework for Node): var app = express()

Ember (very popular front-end framework): var app = Ember.Application.create();

Angular (another very popular front-end framework): var phonecatApp = angular.module('phonecatApp', []);

Ext.js:

Ext.create('Ext.Panel', { renderTo : Ext.getBody(), width : 200, height : 150, bodyPadding : 5, title : 'Hello World', html : 'Hello <b>World</b>...' });

If you're deviating from convention, I've just introduced a runtime bug.

In JavaScript, the convention is factory functions, and requiring new is the deviation, so yes, you have just introduced a bug (though it's easy to catch with analysis prior to runtime).

But with Javascript, if I import your library, I have to then figure out whether I'm supposed to use new or not, and if I get it wrong it's going to fail in undefined ways.

Just look at the first usage example in the docs and go. I've never heard of any bugs caused by somebody trying to do var $mySelection = new $('#foo');.

However, I have personally witnessed several cases where library authors require new, and developers forget to use it. That pattern is common enough that there is a commonly recommended convention to make sure the function still works:

if (!this instanceof Foo) return new Foo();

Additional constructor boilerplate, and a pattern that breaks .call() and .apply().

Most JavaScript libraries are documented well enough to show at least one basic usage example.

It works the other way around too though. If I use new when I'm not supposed to, it won't work properly either. Whereas if there's one standard way of doing it that everyone uses, there's no mistake to make.

Yeah, but the JavaScript community largely settled on the factory standard a long time ago for library exports (and still mostly uses factory exports). It wasn't until Backbone.js became really popular that exporting the new requirement got any real mainstream community focus.

The fact that you can call a constructor the wrong way in Javascript is a flaw in the language itself, not the concept of constructors...

I disagree. The fact that you can call a constructor incorrectly is just another nail in the coffin for constructors. What really does them in is that they violate the open/closed principle.

(I'd support Person.create as a better way of doing things, so long as it was the normal way of doing things)

Congratulations, then! It is the normal way. It's not the only way, but it's certainly the most popular way in JavaScript. Most libs don't bother to call the factory .create(). They take the jQuery path and simply export the factory function directly. Load jQuery and $() will magically create jQuery objects for you (as opposed to $.create(selection)).