Ben Alman

This one bit me the other day and forced me to switch JavaScript compressors because the one I was using (it was python-based) didn't get the IIFE (http://benalman.com/news/2010/11/immediately-invoked-function-expression/) right when appending files together.

In this blog posting Jacob writes:

The majority of lines however don’t end with semicolons because they simply aren’t necessary and I prefer the minimalist aesthetic. For me, \n character is enough and the semicolon character is redundant.

He then points to the izs blog posting about it:

http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding

Jacob calls it more 'minimalist' however it does require you to know (and think about) the rules of when Javascript accepts a newline as a line terminator and when it doesn't. In terms of cognitive minimalism 'semis-everywhere' wins. @izs even acknowledges that part of the advantage is forcing the developer to learn:

To the extent that there is an objectively “better” choice, it appears to me that the minimal-semicolon/comma-first style is slightly superior, both because it is fundamentally more scannable and because it encourages programmers to better understand the language they use.

and later:

If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write…

Imo, the most important technique (besides standard ajax with js lib of choice) is making use of hashchange and organizing your behavior into 'routes' based on the hash. You'll notice that Gmail does this -- it has URIs ending with #inbox, #label/action, etc.

Using hash routes allows you to keep track of state and decouple event handlers that set state from code that updates the page. Plus you get back button functionality and bookmark support.

Some background info on hashchange: http://blog.whatwg.org/this-week-in-html-5-episode-3

jquery library for dealing directly with hashchange: http://benalman.com/projects/jquery-bbq-plugin/

Higher-level jquery library for handling hashchange: http://code.quirkey.com/sammy/ . It has more assumptions and imposes more constraints on the structure of your code. But in return you get route parsing and a DSL.

If you go through the examples/tutorials in those two libraries you should gain enough knowledge to get started.

It does work in FF4, but it's not widely supported enough to rely on just yet, you're right.

I also find the best thing to do is use a hybrid approach (pushState where available, hashbang as a fallback.) If anyone else is interested in implementing this, there are some good frameworks[1][2] to give functionality similar to pushState via the fragment identifier.

Note that these constantly poll the hash in browsers that don't support the onhashchange event. It's a good idea to turn down the polling frequency to half a second or so, because I've found it can cause performance problems in IE.

[1] http://code.google.com/p/reallysimplehistory/

[2] http://benalman.com/projects/jquery-bbq-plugin/

Yes, if I were forced to use JS for loading the primary content I would do that too. There are a couple of options for doing so if you don't want to roll your own (and you don't - it is actually a very complex thing to get working cross browser), JQuery History [1] which is nice and simple, and JQuery BBQ if you need a bit more control.

Personally I think it's a little early for pushState, and degrading to #! is really ugly, so for now I would say just use normal page loads like everyone else unless you have a really good reason (good reason: GMail. bad reason: glorified blog.)

[1] http://tkyk.github.com/jquery-history-plugin/
[2] http://benalman.com/projects/jquery-bbq-plugin/

You're mostly right.

The console var is assigned the result of an immediately-invoked anonymous function (http://benalman.com/news/2010/11/immediately-invoked-function-expression/).

The result of this function is an object which contains the console functions (log, warn, error, etc). Moreover, these functions only exist inside the scope of the anonymous function, so the only way to access them is through the returned object. This prevents the global namespace from being polluted.

So when you call console.log('hello'), you're applying one of those functions in the object returned by the anonymous function.

I don't believe this is "the most practical explanation of closures out there" as the author claims, but it does present a use-case. The most important thing to grasp if you're fussed about naming concepts in JavaScript is the difference between a function, a scope [1], a closure [2], and an IIFE [3].

[1] https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions_and_function_scope

[2] http://unscriptable.com/2011/10/02/closures-for-dummies-or-why-iife-closure/

[3] http://benalman.com/news/2010/11/immediately-invoked-function-expression/