Saumya

This is not a surprise for me, but if you are new to the modern web development and working on Javascript stack, chances are that you come acrcoss these in everyday life. It may come from anywhere, your collegue, your senior, may be from an interviewer. But the cool thing is, you are right in those cases. All you have to do is ignore them and move on. I had seen this while working on Flash platform, when people were saying things about Flash and Flex. Now the platforms are changed but situation are same.

• NodeJS is a different language.
• NodeJS is not javascript.
• NodeJS is bad for not having X, which Y language has
• Jquery is a different language.
• JQuery is not javascript.
• JQuery is better than javascript.
• HTML5 is a programming language.
• HTML5 is different from HTML.
• Have you worked on HTML5? If yes, have you worked on DOM?

While I could answer to all these in single lines but then the interpretation would be wrong.
The point is people coming from traditional languages like, Java and C# and still working on those, think they know all. I would suggest, please come out from that and even if you want to target JVM, use a modern language like SCALA instead. Well, if these guys try to code in a modern platform like NodeJS, they suddenly make the simple solution, to a complex process, as per the old knowledge they were having. Even the elegance of these new modern platforms like Ruby, NodeJS etc seem to be bad in their eyes. Well, the problem is these guys are sitting on top positions in traditional service based companies. So, if you join one of these companies, or even appear for interview in those companies, chances are you will come across these scenarios. The best part is, you are right and they are wrong. So no need to feel bad if they talk like that. Just ignore and move on but never leave learning.
Another big problem for working in frontend is, these conventional people think, they can do a better architecture in frontend too, just because they can use an ORM in backend. So all those frontend elegant solutions provided by modern stacks will be bent according to these guys to a point where the elegance becomes a pain for you as a frontend developer. They will talk that “we had done these before this way”. Common, that way is over, that time is gone. Now learn something from the modern stack developers and make an elegant backend. I have even seen, these backend guys mentoring ObjectiveC guys, how to do an iPhone Application architecture, without knowing the iOS environment. This is not specific to iOS, but any mobile platform in general. Web is not mobile and there are different considerations and architecture depending upon the platform. While the modern web stack has changed and you simply do not understand it, how you can mentor a mobile application developer! Talking of backends, these guys even think traditional databases are the best, no need to try any other. They even hesitate to try a NoSQL! Common! Thats backend, at least update yourelf there before coming to frontend. Ask any new modern stack web developer, they will blow your mind with the stuff like NoSQL to responsive web applications. Even the enterprise is shifting to modern stack, but these are people who hold on to the past.The end result is, everyone suffers. But again, if you are new to the scenario, then do not worry, they will learn from their mistakes and all these time you have to live with it. All these, for someone on top does not know how to deal with new technology.
My honest suggestion to all you people starting your career in web development is, learn from the web, there are plenty of brilliant tutorials and examples available online and move on. Better, if you can, shift to a company where they know, what they are doing, rather than what they used to do.

Happy Coding.

The fun in working with BackboneJS is freedom. The library is so decoupled that, one can really do any kind of architecture for an application. This freedom will come in your way if you do not know what is happening behind. We will be focusing on ‘Event’ here.
Working with BackboneJS often involves working with jQuery too as a DOM manupilation library. When we work on HTML and DOM, in terms of BackboneJS we are working on View. At this point we must understand, that this BackboneView can dispatch event and the DOM we are dealing with also is capable of dispatching event. The point to note here is event dispatched through BackboneJS framework, does not bubble. Where as the default DOM events bubble. Well, since we generally work with jQuery for DOM manupilation, events fired through jQuery also has the same effect as DOM events, they bubble. Working with a BackboneJS ViewObject, we deal with el of the ViewObject. BackboneJS also provides a $el on each view. Take a note of this $el, which is a jQuery object.
Dispatching an Event in BackboneJS is done as

//somewhere inside the View
this.trigger('myEvent',{'data':'myValue'});

The basic syntax for dispatching an event in BackboneJS is

object.trigger(event, [*args]) 

Remember that the second parameter in the trigger is data to be passed to the event-handler. Registering the listener for the event will be as

this.listenTo(this.viewObject, 'myEvent', this.onMyEvent);

Now writing a handler for this event will look as

//handler
onMyEvent: function(eventdata){
    console.log(eventdata);//example: getting data from the event
}

So, we get the whole data ( passed to the trigger() method as second parameter ) , as the arguement to the handler.

Now lets focus on the DOM event for the same scenario. The dispatcher code will look as

this.$el.trigger('myEvent',{'data':'myValue'});

Here, actually it seems that we are using BackboneJS Event, but since we are dealing with $el, we are actually triggering a DOM event through jQuery. Since this is a DOM event, it has all the three phases in its life cycle; capture, target and bubble. So, we can really catch this event on a parent view of BackboneJS and the code would be like

events: {
    'myEvent': 'onMyEvent' //this is actually listening to DOM event
}

The handler code will look as

onMyEvent : function(event,data){
    event.preventDefault();
    //code as required by application
    //But, see the second arguement is actually 'data', passed to 'trigger()'
    return false;
}

Note the difference in event handler here. We have now two arguements and the second arguement is the data that is passed in to trigger() call above. All that is to it is, how you trigger the event, from the two ways below.

1. From the [BackboneJS] View
2. From the DOM element

And then, writing a proper event-handler for the respective Event.

In BackboneJS, sometimes you need to deal with situations, where you just want to listen for events without knowing the other Views. That way de-coupling the application. There is Mediator design pattern to do a central event dispatching system for the whole BackboneJS application. Then there is this little but powerful thing, called bubbling, already available to native DOM.

Here are the links to the two trigger methods;

1. jQuery trigger
2. BackboneJS trigger

Happy Bubbling.

It will come to you very soon, if you are trying to develop any decent webapp or phonegap mobile app using jQuery. The problem is, if we have the same GET request multiple times, by default jQuery will cache the request. The end result is the response same as the first response!! Well, there is a setting in jQuery AJAX setup, where in we write cache:false and that should work. Well, depending upon how the API is written on the server side, this call might not work! There are many reasons as to why it may not work, one simple reason is, to understand, how jQuery behaves, when we set cache:false as below.

var apiURL = "my/api/server/URI";
$.ajax({
    url:apiURL,
    cache: false,
    success:function(result){
        //
    },
    error:function(data){           
        //            
    }   
});

Now, jQuery will append _={timestamp} to the GET parameters. Here is the official documentation of the same. The service call will fail, if this extra parameter is not handled properly. A little workarround, fixed this for me, which is appending the timestamp mannually by hand instead of setting cache: false in AJAX setup of jQuery. The modified code looks as this.

var timeStamp = new Date().getTime();
var apiURL = "my/api/server/URI/"+timeStamp;
$.ajax({
    url:apiURL,
    //cache: false,//not needed now
    success:function(result){
        //
    },
    error:function(data){           
        //            
    }   
});

Well, that worked for me as my API end point was not handling ‘_’(underscore) properly, but could handle the extra parameters.
Depending upon the situations, find a right place and add timestamp mannually, to fix the AJAX cache instead of setting it in the setup.

Happy Coding.