Mozilla Research:

Contracts.coffee is a dialect of CoffeeScript with built-in support for contracts. It is inspired by the contract system found in Racket.

Contracts let you clearly—even beautifully—express how your code behaves, and free you from writing tons of boilerplate, defensive code.

Personally, I think that this update to coffeescript is actually more significant that coffeescript itself. The ability to define invariants (static constraints on data) is something badly needed for new projects.

The likeness to Coffeescript contracts and Haskell types is significant and likely to draw a lot of comparison. Haskell folks might argue that it's still not static typed -- and they'd be right -- but I think they would be missing the bigger picture that this is a huge leap forward for usage of invariants in a (somewhat) common language.

With all the benefits that CSS transforms and animations can offer -- namely better performance & lower power consuption -- it would make sense to wrap it in an API similar to what we've seen with other javascript APIs.

The animation of transform properties can be hardware accelerated because modifying them doesn’t force a reflow of the page; 

-- Extralogical.net

Coming from the perspective of a web developer and having to give up access to HTML, Javascript, DOM, and CSS is difficult. I spent the time to learn how Javascript works and the intricacies of CSS. And even supposing there is a benefit to GWT's compiled Javascript, I would need to learn a ton to make use of it. (I'll bypass the fact that a developer can't be ignorant of what's happening behind the scenes)

But now, what if we flipped the idea on it's head and offered a full web application stack, built from the ground up on javascript? Both the client and server sides share the same code-base, Javascript interpreter and DOM; and can (conceivably) render portions of a web app on either side. Consider it, because it's almost here.

Dav Glass presenting on YUI used sever-side on NodeJS (link: quicktime movie - 36 minutes )

Dav Glass presents a compelling argument for a server-side DOM. I really suggest you check it out if you have the time.

By having a DOM on the server-side, you can use the same Javascript code to manipulate elements and update the DOM with new information. You can create the html for a tabview on the server and then attach events on the client-end for interactive use... or just leave it server-only and let progressive fallback provide links to the alternate states of the tabs. Only one set of code is needed for both types of operation.

We can see the gains to be made from this kind of technology, but certainly it can't be for everybody. The web projects that, even now, work best with a clear separation of roles (i.e. PHP always equals server-side code, JS always equals client-side code). People get a nice sense of safety out of believing that one type of code should remain separate from another. And this is not for those people.

In fact, what we might see is less of a clear separation of domains and more of a spectrum of domains. Conceivably we could even have a slider that would adjust between being all static and all dynamic (supposing, of course, that we could tie those values to different functionality being turned on and of.)

NodeJS is gonna kill PHP

There are some merits to that statement.

• NodeJS is moving along quickly, with new modules getting added daily.
• Many of the web methodologies transition easily to Node
• Javascript is a strong language with a strong history of development.
• Asynchronous from the top to the bottom. AWESOME!
• YOU GET TO USE ALL THE JAVASCRIPT YOU'VE EVER WRITTEN. (emphasis added)
• Atwood's Law (Anything that can be written in Javascript, will be written in Javascript)
• PHP is unable to advance.

At the same time, I (almost) never consider an argument valid unless there are counter-examples which help to paint a complete picture. If all I see is perfect, I must not be living in reality. As a side note, this is why if you ever listen to two programmers argue, you'll inevitably find that they will swap roles and start arguing against their original idea. It's really pretty funny if you watch for it. Regardless, I think the same rule is at play. We all want to explore the problem domain.

So what are the downsides to NodeJS (and yes, they do exist):

• Non-Classical inheritance structure — It's hard enough teaching someone inheritance, I won't even venture to try to explain prototypes.
• Heavy usage of anonymous functions — Another tricky thing to teach.
• Lack of a sponsor company to direct development in advantageous directions
• Will probably never catch on in enterprise environments (due to last point)

The nice thing about these problems that they are all pretty easy to overcome. John Resig has written a handy class that emulates classical inheritance. And anonymous functions can be rewritten to work as named functions, so that's out. What's left is the difficult problem of having a stable platform that can be used by enterprise environments. In the end this is a social problem and it will just take successful companies to take the leap and others to follow.

This is something different.

As web applications get better, there is more Javascript.

Caching has been a big help to this—even though only effective for about 40-60% of your audience. The problem with caching however, is that when a new version of the code is released the user must download all of it again.

Diffable JS makes this less of an issue becuase the user might only need to download 10KB of changes instead of 200KB. It also sticks close to #1 rule of web developement: make browsers download as few files as possible.

I think this project is awesome and I need to spend some time giving this a proper look-over.

Diffable JS: http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-deltas

"Huh, that looks pretty cool. A modular, lightweight framework that has great UI tools. What's not to love!?"

I wanted then to write a post back then detailing how excited I was about it, but enough people wrote good pieces early on ( here, here, and here) and I didn't want to add to the noise.

In the meantime, I decided to use Google's Closure in one of my projects. I needed to build an RIA (Rich Internet Application) type website that needed to dynamically pull in a lot of data. Having gotten through most of that project I feel like I can substantiate a review of the framework.

Great for UI, not so great for the basics

I initially got exicited about Closure becuase of the quality of UI elements that Google was distributing with the API. I assumed that everything has this same level of abstraction from the nitty-gritty and would simplify my code.

The failings of Closure exist in the simple tasks not the complicated ones, adding HTML to the DOM, doing an Ajax request, and even element selection. I'll go into detail about each of these.

HTML Insertion

It's easy to use element.innerHTML, but some work needs to be done to allow those added element to respond to events in all browsers. For example, IE6 will not register an event fired by an element created via innerHTML. If, however, that innerHTML is applied to an element outside the DOM and afterwards added via appendChild, then it works.

The following is a comparison of the same code:

Raw Javascript (5 steps)

var html = "<ul><li>a</li><li>b</li><li>c</li></ul>";
var el = document.getElementById( 'id_of_element' );
var container = document.createElement( 'div' );
container.innerHTML = html;
el.appendChild( container );

Google Closure (4 steps)

var html = "<ul><li>a</li><li>b</li><li>c</li></ul>";
var el = goog.dom.$('id_of_element');
var fragment = goog.dom.htmlToDocumentFragment( html );
el.appendChild( fragment );

jQuery (2 steps)

$('#id_of_element').html(
    "<ul><li>a</li><li>b</li><li>c</li></ul>"
);

Doing an Ajax Request (specifically JSON):

Here is a quick example of handling an Ajax request w/ some minor JSON validation. You don't use eval() do you?

Raw javascriptTo be fair I don't know if this one works

// Assumes we have a valid XmlHttp object via GetXmlHttpObject()
xmlHttp=GetXmlHttpObject();
xmlHttp.open("GET","form.php?format=json",true);
xmlHttp.onreadystatechange = function() {
    if (xmlHttp.readyState == 4) {
        var data = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
	    text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
            eval('(' + text + ')');
        // …
    }
});

Google Closure (4 steps)

goog.net.XhrIo.send( "form.php?format=json", function( event ) {
    if ( event.isSuccess() ) {
        var data = event.target.getResponseJson();
        // ...
    }
);

jQuery (2 steps)

$.getJSON('form.php?format=json', function(data) {
    // ...
});

Element Selection

I'll admit, this is an unfair test since jQuery will always win this one. But the point is that Google doesn't even try to make this easier for the programmer. Aside from some convenience functions there is nothing special. In my mind this proves the point that Google is much more focused on solving the complex problems and not the simple ones.

Raw Javascript

var el = document.getElementById('id_of_element');
var myDivs = []; // … just not worth writing this by hand

Google Closure

var el = goog.dom.$('id_of_element');
var myDivs = goog.dom.getElementsByTagNameAndClass('div','menu-item');

jQuery

var el = $('#id_of_element');
var myDivs = $("div.menu-item");

Conclusion

It's not that Google Closure is bad, it's not. And don't discredit it because I don't want to use it. There are a ton of great applications for it and I am very happy they released it. The main issue as I see it, is that just isn't designed for rapid development — a feature I put high emphasis on. I don't want to downplay any of their hard work but from my perspective I don't see as much value in it as I used to.