Web 2.0

The road leading to now
It certainly has been a long way since the conception of the web and web technologies. Everything has undergone such drastic change in the last 10-15 years that even their inventors probably wouldn't recognize them.

The unofficial first version of the Web - Web 1.0, The pilot version of the Web - of course paved the way for the technical maturity of web technologies. The hard work and perseverance  of some of this century's most brilliant minds.

However Web 1.0 was fraught with inconsistencies. Being birth out of necessity and hastiness to deliver, many versions of it were published by entities around the globe.

Until now web standards setting have been controlled by the few with power and influence.
However, ironically, with the widespread adoption of the Web, the power is now dispersed amongst the committees of the best and the brightest from major corporations as well as many non-affiliated yet influential individuals. W3C is one of these committees.

Web 2.0 - The browser is aware
After a lot of hard work comprising of many of the recent years, a mature standard has emerged. Adoption of this standard is still on-going and comprises of several endeavors each playing a part in the whole of the global standard.

Web 2.0 (pronounced "wehb too point oh") however is not the result of an evolution of technologies and concepts. It is not the introduction of HTML5 and ES5 (soon to be ES6). It is not the maturity of server-side technologies like that supplement the request-response model.
In my opinion, Web 2.0 is the result of evolution of a delivery process.
Web 2.0 is a delivery platform which delivers rich, multi-type media and highly functional content to a variety of devices.

Technologically, the introduction of HTML5, ECMA Script 5, XHR2.0, CSS3 and some other technologies have been milestones in the realization of Web 2.0. However the true realization of Web 2.0 lies in the extending of capabilities and filling of holes which were previously done by 3rd party libraries.

Extension of capabilities by providing new tags, selectors and elements which actually mean something to the browser rather than just gray javascript code.

The browser understands now
When <header> , <footer> and some other seemingly trivial tags were introduced in HTML5, people scoffed... I did too. I wondered what was the point of coming up with a new spec and highlighting new tags like <nav>.
It took a while but I realized that these tags have semantic importance to the browser. If a scrolls down the <article>, the browser can choose to float/fix the <header> as you go.
Introduction of semantically significant tags and elements are key to expanding what the browser understands about your web page. For more info, see [1]


When you animate a div to expand it's dimensions, you probably want to move everything else out of the way. Previously you ended up doing this yourself, either literally or through 3rd Party libraries most popular of which is jQuery .
But the point is, this is something the browser should know about and do for you. When you change the layout of your page, you really want the browser to know about it.
Now through a wide arsenal of css3 additions, the browser can manage these changes for you and act accordingly. [2]

The browser understands now..


The road forward
Earlier I mentioned technical maturity. Although we are reaching a major milestone in the progression of web technologies, the developer mindset to adopt these new standards is not yet mature enough.

The modern web developer has to be aware of the rapid changes and emerging standards.
The pragmatic programmer learns from the past, acts in the present and is aware of the future.

Many major browser vendors have taken drastic steps to ensure they are up-to-date with the latest standards and also to make sure they are not held back by out dated technologies.

The web has changed and will continue to change our lives for a long time.
We are fortunate to be a part of these times.

Web 2.0 - The browser is aware
Web 3.0 - The browser is aware about YOU

With limited adoption of Web 2.0 standards still, Web 3.0 is far from being standardized.
However the focus of Web 3.0 will be personalized, localized, context-aware content presented just for you. [3]

Google, Amazon and many others have already made giant breakthroughs in these fields so expect big things in the not-so-far future...

I've hidden 3 CSS jewels in this page somewhere. The first person to find and comment on them will receive a special mention in my next post . Happy hunting !

Citations
1. HTML5 sematics - HTML5 Semantics | Smashing Coding
2. CSS3 overview - Presentation - HTML5 Rocks
3. Web 3.0 - HowStuffWorks "How Web 3.0 Will Work"

Image source: Wikimedia

The Functional Way of Things

In my last post, I talked about how closures instrument a way to package behavior encapsulating state; instead of dumb(mute, not stupid) objects encapsulating state and behavior.

Before I go on to how closures enable this changed train-of-thought (in the next post), I thought it best to discuss this paradigm shifting way to address programming.

Object oriented approach

Client :     Hey I need my pencil sharpened.

Service :  I can help you. Here's a sharpener. You can use it to sharpen your pencil.

Client :     Uh OK. I'll just find the method on that to sharpen my pencil.

Function oriented approach

Client :     Hey I need my pencil sharpened.
Service :  I can help you. Here's the ability to sharpen. :)
Client :    Cool ! I can directly use that to sharpen my pencil.

To truly think in a functionally oriented way, the thought shift is one that requires us to think in a plane that is beyond our normal plane of thought.
In this physical world we cannot help but use objects as the boundaries of things. We recognize that a sharpener is different from a chair because of their appearance and ability to sharpen and ability to be sat on.

And up till now we have designed our applications to reflect this perception of reality. Our account objects, customer objects and sharpener objects reflect the boundaries of things in a program.

But functionally oriented programs can go beyond that. One step beyond what is defined in the physical realm. Being able to define boundaries at a finer level - namely behavior and abilities - allows developers to have greater control over what is exported.


Object oriented approach
Client : Hey service thanks for the sharpener. I see that it has some dimensions, color, a handle, blades and a mechanism for rotating them. Hmm I can't seem to access those.
But hey ! Here's the sharpen method. I can use that. It'll probably use some or all of these other things, but I don't care. My pencil is sharpened.

Function oriented approach
Client : Hey service thanks for the ability to sharpen. I can use it to sharpen my pencil. I don't care how it did it or what it used to do it. My pencil is sharpened.


In the object oriented way of things, the fact that the client doesn't care about the implementation details is implemented by visibility.  By hiding whatever the developer thinks the client doesn't need to know, the developer only exposes the behavior as the said public API.
But the point is that whatever is exported is still an object !
An object with identity, an object with state(relevant and irrelevant), an object with a plethora of behavior, an object which just seemingly happens to have the behavior the client actually wanted in the first place.

Of course you could give a minified version of the object back to the client with just the required behavior and related state, but that's just a bad way. It could break in a lot of ways.

It's like removing a filer from a Swiss army knife and giving that to the client, because that's the only thing he's interested in.
Of course this was a bad example... for a reason - as I mentioned, you can't apply the functional approach to the real world. You can never be handed the ability to sharpen, or to file, or to learn new things (though I understand this is possible in The Matrix). If that were possible no one would attend school.

So in the functional way of things, the export is the actual behavior the client needs. Two things can happen here.

1. The function is stateless and only operates on it's parameters.
2. The function requires state and the relevant (and only the relevant) state is bundled along with it. (Closure)

Of course if the client wanted the object itself, you could return the object. But now we have finer grain of control over what we export.


In summary, functional approach is really changing the way we link up modules and choose what to export.

In the next post I will talk about how closures facilitate the Functional Way of Things...

The big deal about closures (and why you should think so too)

Whoa hey! You just stumbled onto my blog! Whether you came here by accident thinking this article is about how to get over that person who just left you, or by my devious design (muhahaha), feel free to read on..

So this article is about closures – functional closures to be more precise – a concept in functionally oriented languages that allows functions to hold onto state (in a nutshell).

Feeling dizzy already??

Here’s a little example from a little language we all know and love

function addN(n){
   var num1 = n;
   return function(num2){                //Returning a function !!
   return num1 + num2;
   };
}
var add1 = addN(1);
console.log(add1(2));
var add10 = addN(10);
console.log(add10(2));

The first most important thing to glean from this snippet is that in functionally oriented languages, functions are first-class citizens. So you can

·         return a function,

·         pass in a function as an argument,

·         store a function in a variable and invoke it,

·         and in some languages like javascript, you can even have properties on functions as they are ultimately objects

If you didn’t already know this, drill it into your brain…

Now that that’s out of the way, the code snippet clearly defines a function and

uses it in the last 4 lines. The function itself returns another function which is assigned to the variables add1 and add10 with values of ‘num1’ being 1 and 10 respectively…

But hang on… When add1(2) is called, isn’t ‘num1’ out of scope because addN has finished execution?

Here’s when the magic of closure comes, so hold on to your hats...

The variable num1 is still in scope because the returning function holds on to it, closing around it (Hence closure)... No one else can access it; it is only kept alive by the function, almost like a ghost imprint... [See 1 below]

So in this example add1 is a version (for lack of a better word) of addN with num1 = 1 and add10 is another one.

Let’s be clear: you can’t access either of the num1’s outside of the function code because it doesn’t exist. So add1.num1 doesn’t exist.

However the code inside the function can access num1. (Does this remind you of something?) [See 2 below]

So what does closure imply?

·         Closure implies scope (lifetime) [1]

·         Closure implies visibility (hence encapsulation) [2]

·         Closure implies shared and unshared state (unshared in this example, a demo of shared in an upcoming post)

So all that is neat, but what is it useful for?

So now we know that functions can carry around scope. They are essentially stateful (as compared to OO languages where they are stateless).

Functions in OO languages can access object state and operate on passed-in parameters but they themselves are stateless.

So functions in functional languages can have attached state and can access that state wherever it’s executing. Repeat, the function will continue to have that attached state wherever it’s executing. When a function is passed around and executed it will still have its initial scope and access to scope members.

The ability to do this is what sets functional languages apart and I cannot stress this enough.

Alex Russell of Google neatly puts it as
“Instead of passing around objects which have state and happen to have behavior which can perform tasks on that state, we have behavior passed around which can operate on its associated state” [citation 1]

Steve Yegge also has a rant about this on his blog. That blog post was one of the finest pieces of literature I've ever read on a technical topic. [citation 2]

It isn't just another way to think or approach programming. There are actually some problems that cannot (or extremely tough to) be solved  by the traditional OO approach.

A demo of this in one of my upcoming posts so stay tuned…



Citations:

[1] Alex Russel talks about the good parts of javascript http://youtu.be/seX7jYI96GE?t=22m6s

[2] Steve Yegge's blog post : http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of-nouns.html