Prudent Object Inheritence (that isn't classical)

Don't even think about classes. I'm really just tired of them, and you should be too. Forever we have been chained to classical inheritance (which I admit is faster for compiled languages.) Yet, maybe it's time we broke free from our bonds of definition and un-define ourselves in a meaningful way.

Hello Inheritance

It is prudent that we remember that our world is not defined. No matter how much science we throw at it, no matter how much the book of definitions grows, there will always be unknown. Our code will never be able to match the vastness of our comprehension and definitions. Clearly there is never a way to get around the fact that computers live in a supremely deterministic world. For this reason, every program should be known as art.

The very first definition of art when googling [Definition of Art]:

"the expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power."

We should remember that we actually make a living off of the fact that programmers take something defined and absolute to create something amorphous and functional. Programmers also take requirements and turn them into something displayed on a screen. This alone is remarkable. In the context of art, we are untypical, yet we try to produce works to be appreciated by their physical or tangible power, rather than their beauty or emotional power. (Or maybe you do?)

The Chains of Determinism and Convention over Configuration

Given the example, I show you inheritance that actually makes sense. When you inherit a simple interface in C#, things become more generic and happy. Do not confuse this for complicated inheritance chains that convolute your code. Applying an interface to multiple objects makes your code flow better and work with different definitions faster. These specific kinds of contracts are exactly what you need.

It also bodes us well to remember that javascript ascends beyond this need to define. It takes all the deterministic work out of your code. What you are stuck with are the conventions you use to define your work, and the configurations you provide to your client.

Why not instead of classes, think of your javascript code like you would a composer? The composer cares not about determinism. In fact, some composers would say their work leads them to the solution. The composer applies musical conventions and not configurations to define their pieces. In fact, most configurations are left up to the conductor who interprets the pieces created by the composer.

Even if you can define the notes used to compose a piece, it makes sense that those notes would mean something so much more!

What does this mean for you?

You are not a composer, (or maybe you are,) and thus, should act accordingly. Instead of relying on supreme indeterminism, rely on some convention in your code. Convention will make your code faster and smaller. Of course, definitely do type checking, but be willing to be flexible where you do it. Wherever your API interfaces with a developer, be flexible enough to call Object.prototype.toString.call(object) and really see what is going on. You may be accepting the input of another library (hopefully with the right conventions) but in complete honesty, you never know what you are going to get.

So throw in the towel, right?

HECK NO.

You should instead, play into javascript like you mean it.

Have the courage to do something like this:



Yeah. I totally went there.

The only adjustment you need to work with javascript is your attitude towards it. Javascript cannot be deterministic. So embrace it's functions and super generic objects, and enjoy your smaller (and somehow faster) code base.

You won't regret it.

Lastly, here is a sample of the stuff you can do with a very small (2kb minified) library that I wrote by hand.



This is the way object coding should be (minus the pyramid syntax that plagues the gist's version of callback hell.)

You define repeatable closures and mixin objects. Suddenly, you have a repeatable way to generate objects. Just don't forget that those pieces can be called directly like this:



Want to actually use it in your project? The command is simple (for node anyway:)



In functional health,
~function Josh(){}()

Native vs Functional Loops

Native loops...

...are a functional portion of the javascript language and allow you to repeat functionality of code for a certain number of times specified by the conditions of the loop.

These examples are fairly easy and trivial. If you are not proficient in javascript loops, I highly recommend learning how to construct one from scratch here.

Functional loops provide a different mechanism for looping over the items in an array. They also have much larger implications for memory management and coding techniques.

Example: a user wants to loop over items in an array and perform a static operation.

This example is obviously bad, because the same result could be achieved by calling target = array.slice();, but look a little bit closer at the example below.

Boom. Now you can enclose objects with functions and local variables.

So now that we have our toolset, let's make a few rules on when certain loops are needed.

Native loops

• When a functional context is not needed
• Concatenating strings
• Looping through strings
• Anywhere that performance matters greatly

To put it simply, if the code requires speed and performance, chances are a for loop may be indicated. Especially for simple operations.

Lastly, the indications for functional loops...

Functional loops

• When a closure is needed(I.E. Variables need to be obscured)
• Chaining Maps (see example below)
• When the calling function needs to be called multiple times in other places in the code (using a named function)
• When Performance probably doesn't matter (and trust me, javascript is pretty fast)
• When file size DOES matter

The code looks more fun, and is more expressive. It's less terse, but that's the price you pay for a functional language expression

In functional health

-Josh

Replacing the jQuery.each function

http://api.jquery.com/jQuery.each/

Compare the following examples:

Example 1 (Using jQuery):

   $("section").each(function(index, element){
       //do something with element
   });

Or even better

   $.each($("section"), function(index, element){
       //do something with element
   });

Example 2 (Native javascript):

   var elements = document.querySelectorAll("section");
   for(var i=0;i<elements.length; i++){
      var element = elements[i];
   }

Note that these pieces of code do the exact same thing.  They loop through all the elements in an array.  In fact the first solution looks very elegant.  Some might even argue it's the functional way a javascript developer should code.

Nobody, however, should argue which one gets better performance when run in browser.

Honestly, anyone can read the examples, but who really benefits from code like Example 1?  It's not the page viewer, because the client had to download a 45kb library to get "foreach" functionality that makes the page run slower.  It's also not the developer, because the developer missed out on making their code faster. I guess the answer is that nobody truly benefits except for beginners, who get shortchanged unknowingly.

There is however one more suggestion:

 [].forEach.call( nodeListReference, function (node) {
  // now do whatever you want to do with node
});

Feel free to comment below. All opinions are valid and welcome.