Binding things in the HTML helps you keep in your head what is going on in a particular page. It also helps you answer things like how an element is bound (was it ".submit-button", "#page-submit-button", or "form > .submit-button"), and makes sure that it's easy to find when searching for code later.

Caveat:
One caveat to look out for is the order of loading of JavaScript files. The above code requires jQuery loaded for $(document).ready() to work. One alternative is to use window.onLoad(), though that waits for the entire DOM and assets to load.

2. Understand how this works in Javascript

Everything is lexically scoped in Javascript. Except for 'this', which is something that is set depending on how a method is called. Some libraries like jQuery even set the value of 'this' to mean things like the object on which a callback is called.

3. Structure your JS code into logical units

Javascript is a prototype based language. There are a lot of cool things you can do with a prototype based language, but very few of them will help you write a good UI. Most people take the lack of 'class' keyword in Javascript to mean the lack of Object Orientation.

This is a trap because you aren't able to group logically related methods together. This would be similar to a bunch of static methods on your server side.

The Solution:
Build some sort of object oriented abstraction over your javascript functions. You can either hand roll your own using javascripts prototype functionality, or you can just drop in something like class-js

4. Use client side templates to render content

Again, this can go into another blog post by itself, and I'll be writing about this soon.

The Trap:
Having your server return HTML output as the response to an AJAX request, and having the client just dump it into the DOM somewhere

The Solution:
Use something like Mustache.js to render your server side template. I'll be posting more about this soon.

5. Test your javascript

Just because this is javascript, and not the backend code, does not mean that you should ignore your JS. JS faces just as many (if not loads more) regression bugs than your backend code.

The Trap:
A lot of code without any test coverage

The Solution:
Test your code with something like jasmine. Use one of the addons to jasmine like jasmine-jquery, which lets you bootstrap your tests with a sample DOM, and then run your tests against that DOM.

8. Use CoffeeScript

CoffeeScript is a neat little language that compiles down to JS, and has support for almost all of these features baked right in. It namespaces things for you, and fixes the this/self problem, and provides a lot of the functionality that underscore would provide.

As an additional benefit, it's much less code to read. And it's baked right into rails.

Yeah, I'll give you the indentation aware language argument. It's my biggest gripe with CoffeeScript as well. But I still find it more readable than JS. If someone made a version of CoffeeScript stripping out the indenting part, I'd always use that.

Your points #2, #3 and #6 are merely a common-place misunderstanding of what Javascript is. Javascript is unfortunately treated like trash, while it is a very powerful language that has a programming model quite different from your average OO language. Trying to fit the OO model onto JS is like driving a Ferrari on our potholed roads :)

Once question I keep asking around, is what kind of apps naturally lend themselves to the javascript prototyping? Javascript is a classless OO language. As an application developer what benefits do I get because of it?

Dear Tejas Dinkar,I would like to comment your examples for at least #1. The others - another day :)

jQuery doesn't actually bind anything to the DOM element (perhaps it does in older versions...don't know for a fact). Newer versions of jQuery has an, lets call it; internal memory bank. Each DOM element that gets any handler bound to it, is tagged with the expando-attribute (the key). When an event is triggered, jQuery reads the "key" value and opens the corresponding "safe". The "safe" contains a stack of all handlers that was bound to the element and starts to dispath them one by one, with the right context (-> this) etc.

If an element is removed with jQuery's help, then the corresponding safe is emptied...but if the element is removed without jQuery's help than the safe remains untouched, causing unnecessary memory allocation. Get this right - this is much better solution than letting GC for JS and DOM trying to clean up...thanks to jQuery, the "garbage" is at least not in the "limbo".

The problems with your examples, both the problem och solution, are that you are binding anonymous functions. Consequenences of doing that way are;

1. You can't unbind functions

2. If your page contains multiple submit-button's, then the function has to be instantiated in memory, in order to be put in their own "safe". IOW; if you bind an anonymous function to 1000 elements, in jQuery bank, they have to exist individually in each safe, instead of referencing to named function.

So, the correct way to "bind" an handler to an element is to first create a reference to the handler/function and bind using the reference.

In any case, the point I am trying to emphasize is #1 is not to let your JS be the entry point, purely because if you do any binding in the JS, it's typically harder for a developer to track down what's happening. As such, it's orthogonal to your point.

However, are you saying that the first problem can be improved as follows?var submitCallback = function(event) { server.submit(); };$(".submit-button").click(submitCallback);

I, myself, create a singleton object and structure my ojbects and functions, helping me to develop as well as re-read my old code - hence an easier codeflow and structure.

Having said that; I like that pattern and promote that way, of course. But everyone should write what ever suits them best. For me, it's easier to "follow" named functions. This kind of discussions tend easily blow out to unnecessary loud debates and that's not what I desire :)

Though, one thing I would like to suggest is to use;

'use strict';

...if I was a beginner, and I was only allowed to give myself one advice, this would be it. It has many advantages. Among others;

1. eliminates the potential risk of variables ending up in the global scope...resulting in slow execution performance (scope chain)

2. minimizes (but not eliminating :( ) the risk of silent errors. I truly hate when browsers are failing silently.

Hi, Great.. Tutorial is just awesome..It is really helpful for a newbie like me.. I am a regular follower of your blog. Really very informative post you shared here. Kindly keep blogging. If anyone wants to become a Front end developer learn from Javascript Training in Chennai . or Javascript Training in Chennai. Nowadays JavaScript has tons of job opportunities on various vertical industry. ES6 Training in Chennai

Another feature is that it can be used on client side as well as server side. A JavaScript has access to Document object model of browser; you actually change the structure of the web pages at run time.web design lessons

This is an awesome post. Really very informative and creative contents. This concept is a good way to enhance knowledge. I like it and help me to development very well. Thank you for this brief explanation and very nice information. Well, got good knowledge. WordPress development company in Chennai