Category Archives: Javascript

Mini Review of “Secrets of the JavaScript Ninja” By John Resig & Bear Bibeault

jsninj-150x150I have started reading the new book of John Resig, which in case someone don’t know, is the creator of jQuery. I’m just in the beginning (page ~60) – but i still have a few insights that I would like to share:

A free e-book!

When you buy the book, inside of it you get a code which you can use to get the e-book version for free. That was a very nice gesture from Manning that i really like. That way i don’t need to choose, I get both. and it is a great surprise since I was not aware of that.

About the book

I really like how the book is organized, it is well written and addresses the reader in a way that reminded me a private tooter. It does not uses high language and it is very easy to follow, both the text and also the examples.

Who the book is for?

This book is not for a novice developer. If you have a good grasp of JavaScript then this book is for you, it will uncover some of Javascript black magic, with a fun approach. if you are a newbie in Javascript – this book is not for you. you should start with a more basic material and only then read this book. I think every front end developer should read this book – but if you just beginnin – read some more basic stuff and only then return to this book.

Scoping – A small point that was overseen

When the writer is explaining about scoping, he wrote that the function scope is within the entire current scope even if it is defined at the end of the current scope. And in the example that was given it was implied that a variable is not acting like that… But it is! It is available. It is only that the assigned value is available after the assignment, but the variable itself exist in the scope. That maybe sounds like an unimportant point but it could cause an unexpected bugs like in this example:

You would think that the value of ‘test’ will be “I’m out” according to the book explanation, but because of the hoisting nature of Javascript it is actually will be ‘undefined’, hoisting is not only for functions it is also for variables. The only difference is that functions will be defined even if the declaration is after the function call while in variables it is not.

So we can actually say that the above code will actually behave like the next one:

Best practice – implementing a collection view in Backbone.js


Lately I was working a lot with Backbone.js, I really love this tool! It is so easy to encapsulate my code into separate components.

What I had a lot of thought about but with no real answer is what is the best way to implement a collection view?

As I see it there is mainly two ways to approach this:

  1. Implement the model with a model view and the collection view will just be the container that contain all the model views.
  2. Implement the collection view to render also the models in it.

Each of these approaches has upsides and downsides. And the difference is really the question of where to render the model? in the model view? or in the collection view? the intuition is to do it in the model view – but that is making a few disadvantages of interaction between the models.

The downside I have with the 2nd approach is that for any addition / subtraction from the collection the entire collection view (with all the models) will need to re-render, in a collection with thousands of models – that is a huge problem! But it has an upside too – if the models have some kind of interaction between them (sorting, filtering) it is much more easy to implement it in the 2nd approach.

The downside of the 1st approach is the upside of the 2nd and vice a versa. So I could say that I should select the solution according to my needs, and that is what I did until now. Until the day that I needed both upsides…

So the question is – is there a way to implement the 1st approach but to also have the ability to have sorting and filtering on the UI? The only way I could think about that happening is that the collection view will also hold all of the model views but that just does not sounds right…

Go with the Model-View approach

Well, it is the combination of both that solves this problem. How can it be both? it is actually the first approach, each model has it’s own model view, so adding to the collection will not need to render the entire collection view. Only when we want to sort / filter – the entire collection view will be re-render.


This solution is really a best practice since the models does not know about the sorting / filtering that can be made to them – this will be implemented in the collection and the final visual result will be rendered in the collection view

Untitled drawingSo when we want to render all the models that a ‘filter’ function returned us. we will run on each model and we will create it a model view and then we will append all the model views to the collection view.