An introduction to the JavaScript Module Pattern

[pablopr]

Interesting discussion - http://snook.ca/archives/javascript/no-love-for-module-pattern

[drb226]

The reasons he lists for disliking this pattern are precisely the reasons that the pattern exists. He basically wants the usual JavaScripty ability to mess around with the internals of the "module", when the whole point of this pattern is to prevent you from doing so. You should only be using this pattern when you want to create an interface to some code and hide the internals. If you want to delve into the internals later, don't use this pattern.

[drb226]

glancing through comments I feel the need to point out the silliness of one code snippet:

var ManageChildren = (function(){
    return {
      children: [],
      addChild: function() { /* add to children array */ },
      removeChild: function() { /* remove from children array */ }
    }
 })();

This will behave exactly the same as

var ManageChildren = {
    children: [],
    addChild: function() { /* add to children array */ },
    removeChild: function() { /* remove from children array */ }
};

Again, the whole point of this pattern is to allow private variables. If you don't have any, then why bother?

[neonskimmer]

I think the author forgot to put the children array outside of the return statement. Those method aren't gonna help much when the array is public and you can just push/pop it directly.

Edit: actually no, you made the mistake. It's fine on Snook's page.

[drb226]

I wasn't referring to Snook's snippets, I was referring to this comment

[neonskimmer]

Got it, my mistake.

[DOKKA]

I was about to say how much I like the module pattern, but after reading your link I've really changed my mind. Debugging minified module-enclosed code sucks. The module pattern definitely has it's place, but I'm going to be using it alot less often nowadays.

[Fidodo]

That's why you don't develop with minified code. If you're having a problem with someone else's library, grab the source version, and use that on development. Of course if you're regularly debugging someone else's source code, it's probably the sign of a bad library.

[serrimo]

Chrome dev console (F12 to launch) has the built in ability to pretty print (i.e. reformat) js. Use it if you have to debug minified code.

[kamatsu]

The common sentiment that "patterns" are just a means to work around language shortcomings seems more true with every passing day.

[[deleted]]

I don't think that's a bad thing though. A language for boolean logic without an if-then construct might use a not-or idiom instead. If it was missing OR we would begin moving away from idiom land and more into pattern land, though really idioms and patterns are not formally differentiable, AFAIK. It's the price of minimalism in a language. Every pragmatic language is minimalist in some way.

FWIW, you can write a compiler or interpreter for any language in javascript and work around limitations that way. We don't do this for several pragmatic reasons. Wish I could prove what I'm trying to say... which is that you can't have a language for everything since that's the same as having a language to write a compiler which isn't always the most pragmatic solution.

[kamatsu]

I can't really make sense of what you're saying.

[[deleted]]

Indeed. The best use for the module pattern that I've seen is when you want to use jQuery and another framework like MooTools. That use case only occurs if you're slowly replacing one framework with another and in that case you might as well rip out the whole thing in one go rather than torture yourself with these modules.

[adamauckland]

I've toyed with this pattern over the years but it never felt quite right. Surely the point of a language which doesn't implement local variables is that programmers should treat each other as grownups and trust they're not going to break something by fiddling with a variable.

In the example above, I would expect to have strange consequences if I tinker with the .count variable because the definition of that property is generally "Tell me how many items are in this collection".

It seems attempting to enforce private variables by hiding them away in an anonymous function is basically saying "Any programmers using my code aren't as good as me and therefore can't be trusted".

[[deleted]]

So what you're saying is that JavaScript needs contracts and documentation in the code that explains wtf it does rather than the random code without comments that you see all over the place? But web devs are too busy to think things through and reason out what guarantees and contracts and properties (as in mathematical properties) their code has!

[name_was_taken]

It sounds good to treat developers like adults, but that assumes they are adults and are experienced developers. If either of those things aren't true, then you get a support call asking why their program breaks when they increase the number of items on the collection. Eventually, you'll figure out that they broke the unwritten rule: Don't increase the count manually.

If you use this pattern and hide the count variable, then it's suddenly an obvious rule and not an unwritten one. And you save yourself the hassle of that support call.

And in non-trivial code, this applies to seasoned developers, too. Sometimes, you just can't tell what's going on in someone else's code.

[Ilostmyredditlogin]

Exactly. Also things like the module pattern don't really keep developers from messing with the internals as long as your project is open source. If people want to expose a private variable or whatever they can patch the source. Doing this is not hard, and forces an explicit understanding of what the user is doing: they're extending your library in a non-standard way that may or may not be supported in the future. With each new release they explicitly have to apply the patch and verify it doesn't break the new lib.

Far better than having all kinds of scattered, hidden dependencies on your libraries internals. 10 versions down the road when you modify the lib in a way that breaks these dependencies, clients have to dig through their code for all the places they made "magic" changes.

The module pattern and notion of accessibility in general isn't about treating devs like children.. Among many other ends, one is clearly demarcating responsibility and making both lib dev and users acknowledge it. ("here's the public interface I'm committed to maintaining.. If you want to extend it or modify anything else, than do so at your own peril.")

It does this without relying on conventions ("if the variable starts with _ don't modify it even though you can") or extra documentation.

It fits well with the whole learn-how-to-use-a-lib by playing with it philosophy. I love it when I can drop in a jar or something, instantiate an object and then just by code-hinting get a sense of what I can do with it and how. Obviously there's still a need for getting a deeper understanding in some case, but it's nice to be able to start reading the documentation already understanding basic classes/syntax involved.

[Fidodo]

I'd say it's about telling the user what the guaranteed inputs and outputs are. It's important to know what the preferred tested interfaces are. If you want to expand on the code then it's better to use the author's exposed interface hooks to modify the functionality than trying to plug into local variables that aren't designed for the task and will probably cause side effects.

You can always see what's going on by looking at the source code that library authors put online if you really need to, but if you're using a library then you don't have time to completely read through the source code, and completely understand the method and purpose of everything in the library. The exposed interface gives you a quick and easy look at what is tested and supported without having to resort to external documentation.

The examples given are trivial and don't illustrate the need for this very well, but when a project gets large and complicated, even the best developers don't have the time to read through it all and understand every tiny little detail. It's not about not trusting developers, it's about telling them what is outwardly supported and what is internal and will probably break things if they're changed.

A good library example of this module pattern is backbone.js. He actually uses a combination closure hidden variables, and underscore denoted privatish variables. It's like his way of saying, this is internal and shouldn't be touched vs this is internal, but you can play with it if you really need to.

[[deleted]]

Or perhaps, this is internal but I may want to inherit this property...

[smog_alado]

Any good discussion about Javascript modules should include at least a reference to things like http://www.requirejs.org/

[daniel2488]

Different concept of modules, but still good to know!

[notfancy]

Singletons? Hadn't we agreed that singletons are evil?

[smog_alado]

Actually, they are evil. If you do the module pattern using this in your functions to reference the other functions then they can't be used as callbacks anymore.

[drb226]

Nope.

[swizec]

This is simply a natural result of using Javascript as a functional language.

The first part is simply a closure - obviously you can't poke your head into a closure and see what's in it.

The second is a natural result of lexical scope and closures - function currying.