Leveraging CoffeeScript with Grails

thechangelog:

Batman.js from Shopify is an extremely slick looking framework for building single page apps in Node.js.

Batman lets you define observable events on your objects via the @event macro.

class Gadget extends Batman.Object
  constructor: -> @usesLeft = 5
  use: @event (times) ->
    return false unless (@usesLeft - times) >= 0
    @usesLeft -= times

You can then observe changes to properties in this way.

gadget.observe 'name', (newVal, oldVal) ->
  console.log "name changed from #{oldVal} to #{newVal}!"
gadget.set 'name', 'Batarang'
# console output: "name changed from undefined to Batarang!"

Custom accessors also make working with object properties a lot nicer:

class Person extends Batman.Object
  constructor: (name) -> @set 'name', name
  @accessor 'name',
    get: (key) -> [@get('firstName'), @get('lastName')].join(' ')
    set: (key, val) ->
      [first, last] = val.split(' ')
      @set 'firstName', first
      @set 'lastName', last
    unset: (key) ->
      @unset 'firstName'
      @unset 'lastName'

Be sure and check out the well done project site and source code for details.

Man, this is so cool. I don’t quite feel like a DJ yet but its a start!

thechangelog:

Head JS is a 2.3kb script that speeds up, simplifies and modernizes your site.

The HEAD section is the worst place to load scripts. It’s painfully slow. The more and the bigger the worse it gets. When you move your scripts to the end of the document you aren’t able to use HTML5 or CSS3 safely or you run into dependency problems.

That’s where Head JS comes into play.

So what’s the problem with loading on top?

A huge majority of the sites you visit everyday often have many SCRIPT tags in the HEAD section of the document.

Let’s take a peek at apple.com:

<script src="http://images.apple.com/global/scripts/lib/prototype.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/lib/scriptaculous.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/browserdetect.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/apple_core.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/search_decorator.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/global/scripts/promomanager.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/home/scripts/ticker.js" type="text/javascript" charset="utf-8"></script>
<script src="http://images.apple.com/home/scripts/promotracker.js" type="text/javascript" charset="utf-8"></script>

Apple is loading just 8 scripts here, but when you first hit the page you’ll have to wait for all these scripts to be loaded before the rest of the page gets rendered. In programming this is called blocking.

It can get even worse. Older browsers such as Firefox 3.5 load these scripts in sequence. The next script starts loading only after the previous script is fully loaded. This means that the first page render will be painfully slow.

A common solution to this is to move the script tags to the bottom of the document, just before the end of BODY tag.

So what’s the problem with loading on bottom?

When all scripts are included on the bottom of the page you’ll end up fighting with these issues:

• HTML5 and CSS3 can’t be used and sad side effect is the treacherous FOUC (Flash of Unstyled Content). To avoid this ugly FOUC effect you need to load the script on top.
• JavaScript organization gets hard and you can’t do scripting that depend on these scripts before they are included.

How does Head JS solve these problems?

The single best solution to these universal problems is to include Head JS on top of the page and load rest of the scripts with it and make it the only SCRIPT in your HEAD.

A small job with following benefits:

• The page continues to load after the small 2kb head.min.js file is loaded
• You can use the latest CSS3 techniques and provide alternate CSS for IE and other old school browsers
• You can safely use HTML5 tags even with IE
• You can define JavaScript code on the middle of the page that depend on the scripts on the bottom
• You’ll have a fast, parallel, non-blocking script loader at your disposal

In addition, you can:

• Target CSS for specific screen widths, browsers, paths, etc.
• Style your pages differently depending on the application state, such as whether the user is logged or not

How do you use Head JS?

All script loading is done with head.js()

// the most simple case. load and execute single script without blocking. 
head.js("/path/to/file.js");

// load a script and execute a function after it has been loaded
head.js("/path/to/file.js", function() {
  ...
});

// load files in parallel but execute them in sequence
head.js("file1.js", "file2.js", ... "file10.js");

// execute function after all scripts have been loaded
head.js("file1.js", "file2.js", function() {
  ...
});

// files are loaded in parallel and executed in order they arrive
head.js("file1.js");
head.js("file2.js");
head.js("file3.js");

// the previous can also be written as 
head.js("file1.js").js("file1.js").("file3.js");

There are even more examples in the usage section at the Head JS homepage that cover:

• Script organization
• Labeling scripts
• CSS3 feature detection
• Screen size detection
• Browser detection
• CSS Routing
• JavaScript feature detection

[Source on GitHub] [Homepage]

An interesting read why the development community should pay attention to NodeJS.  

The Twitter guys & gal explain how they pulled off their new interface.  Its an interesting read if you are a developer

bry4n:

Making fancier maps with this javascript library.