Return to Answer

Encapsulating data within an object makes it modular, in addition to protecting it from clobbering. Here is the pattern:

This is a really important pattern!

Encapsulating data within an object makes it modular, in addition to protecting it from clobbering. Here is the pattern:

This is a really important pattern!

The reason is that it allows you to encapsulate all your variables within a named objest. But be warned. Allowing one object to communicate with another namespaced objects is, yet another, advanced topic.

To keep these nicely modular objects decoupled, the solution is generally to send off events not direct references (it is so easy to do so), but it will hurt you in the long run. Look up PubSub or evented views for this. Don't worry it is worth it, as you watch the language expand vertically and horizontally through this pattern. Let me explain...here.

Such a good question, worthy of a psychological or socialogical review. And we do not have time, but, more often than not, when speaking about Advanced JavaScript - for whatever reason... a strong negative reaction can occur. We have all experienced this, yes?

First off, it may be that the original question is inflammatory,

The other possibility is that, potentially, there is a negative reaction external to your question. This is what is interesting. Why?

There seems to me, an unspoken stigma. Something, somehow embedded rection ... or so. And this is what I see with JS. It has a tangled history with Sun naming similar to Java, misunderstood as a 'Toy-Language' and yadda yadda yadda,

(look up Enter the Dragon - Dmitry Baronovski) but there is another point I wish to raise here that is far more important and that is.... flexibility.

Flexibility

JavaScript is very flexible language. No? It is so flexible, to the point, that it can be squeezed out one hole and become a server(node.js), another and become a datbase (MongoDB), another and become MVC (backbone) and yet another and become a rich enterprise framework (ExtJS or jQuery)... don't forget phonegap, grunt, or three.js. This is remarkable. It is like play-doh. Yes a toy-language indeed.

This comes full circle, now, to the very first controversial point that was required here to be made on "functional programming" and how it, might be, in all respect, "distracting" - me.

The fact is, JavaScript can be seen in so many different ways (paradigms), that we should actually try viewing it through different lenses.

It is so flexible that it can be understood in completely separate ways.

The problem though, with this, is us. Honesty is the best policy here and here is my humble pie. I call it 'the metaphore invisible fruit'. Please bear with me, I make sense - eventually...

The notion is this: we all like our programmatic fruit, but code is, essentially invisible - because it cannot be consumed/digested/conceptualized... in a single glance. So we tend to go... with the fruit that we know. And yes, this means that if some other person hands you their invisible fruit, saying, check this out it is great... there are the options of agnosticism, or aversion. Because, hey wait! This is not my fruit! In order to intellectually consume the paradigm, one must make a blind leap-of-faith and - "take a bite".

Do you know what I mean? We see this often when some refuse to take a bite of code methodology because, perhaps in the past, they have been burned. I have in Clarion & Magik (sorry uber-fans).

The take-away is this. Perhaps, we will need to begin to think about lowering our defenses, in this language of the web - this multi-paradigm, meta-morphing language, our old pal JavaScript - and see it through separate lenses.

Time and again we find, the solution depends on the context. But time and again we defend doggedly - our minority experience.

JavaScript is larger than any one of us and it will eventually outgrow capability to fully consume/digest/understand it.

The reason is that it allows you to turn JS into an oozy play-doh like substance. What the heck do I mean? Encapsulate all your variables within a named object. Now they can maintain state and float around in your single global member "namespace". Why is this a flexible substance? I'll get to that in the answer to the second question, as they seem related. But for now realize that this pattern allows JS to become highly transient: once modular.

Be warned, this is the beginning of Advanced JavaScript - not the end. Allowing one object to communicate with another namespaced objects is, yet another, advanced topic.

Quick Tangent:

*To keep objects nicely modular and decoupled, send events between an intermediary not direct references (it is so easy to do so) between all objects. References become a maintenance-nightmare. Look up PubSub or Evented Views for this tangent. 

Let me explain why flexibility may cause mixed-reaction.

Such a good question, worthy of a psychological or socialogical review. And we dont have time. More often than not, when speaking about Advanced JavaScript - for whatever reason... a strong negative reaction can occur. Have you observed this in practice, yes?

1. it may be that the original question is inflammatory,

2. The other possibility is that, potentially, there is a negative reaction external to your question. Wait that is strange? What? Why?

There seems, an unspoken stigma. A misconception. Anyone know what I am talking about - have you observed this? Something, somehow, somewhere - there is a n embedded reaction... JS has a tangled history with naming, confused with Java,... misunderstood as a 'Toy-Language' and yadda yadda yadda,

(look up Enter the Dragon - Dmitry Baronovski) That said, there is another > point I wish to raise here that is far more important and that is.... flexibility.

Flexibility

JavaScript flexibility causes... different perspectives.

JavaScript is very flexible language. No? It is so flexible, to the point, that it can be squeezed out one hole and become a server(node.js), another and become a datbase (MongoDB), another and become MVC (backbone) and yet another and become a rich enterprise framework (ExtJS or jQuery)... and don't forget Mobile; phonegap, or Build: grunt. This is remarkable. It is like play-doh. Yes a toy-language indeed.

So now lets consider how JS exists in CoffeeScript, or GWT, Dart, or Windows 8. They are remarkably different beasts.

This comes full circle to the controversial point raised earlier that "functional programming" conversation might be "distracting". In all respect, let me clarify, "functional programming", while it can be defined at wikipedia - has a very good chance of a spudo-philosophical meaning that ends up meaning something slightly different to all of us.

The fact is, JavaScript can be seen in so many different ways (paradigms), that we should, at some point, think about viewing it through different lenses. JS exists in many context domains, it is a point of significant growth, and will be even moreso in the future.

The problem here, with this, is us. Honesty is the best policy and here is my humble pie. The problem is that it is an 'invisible fruit'. Please bear with me, I have a point...

Invisible-Fruit

The notion is this: we all like our programmatic fruit. But code is, essentially invisible - because it cannot be consumed, digested, conceptualized... in a single glance or sitting. It must be consumed. So we tend to go... with what we know. This is primarily because, often times we bite into a pit, sometimes an orange-peel, and in the most unfortunate of occasions - a lump of coal.

It is for this reason that if some stranger hands you their invisible fruit, saying, check this out it is great... no matter what they may say - you are suspicious. Aren't you?

There are two options: 1 of agnosticism, 2 of aversion. 

In order to intellectually consume the new programmatic paradigm, one must make a blind leap-of-faith and - "take a bite". Do you observe this is in practice?

But more often than not, because we are biting-into a lump of code that is beneficial to another engineer in another context - but is just not beneficial to us.

Do you know what I mean?

Did you ever fervently consider the notion, which is better: jQuery, ExtJS, YUI, Dojo, MooTools, Backbone, Underscore, Require, etc...

The take-away is this.

JavaScript is so malleable (through the advanced code that begins with the namespace pattern) it can transcend technologies in a way that makes JS not really better or worse implementations, but just different tools for a different jobs. And some are a better fit than others. I still hear many conversations accidentally fall into this.

Perhaps, we can -eventually- begin to think about lowering our defenses. in this language of the web - this multi-paradigm, meta-morphing language, our old pal JavaScript - and see it through separate lenses.

Time and again we find, the solution depends on the context. But time and again we defend persistently- our minority experience.

JavaScript is larger than any one of us.

This is a good thing. "Enter the Dragon"

This is a good thing. "Enter the Dragon"