1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags

Definitely worth checking out if you need to tweak every ounce of performance you can get on certain pages.

Rhino…was written with an eye for performance. The Rhino code base reads almost like C code: it avoids allocation and does as much as possible with jump tables to avoid the overhead of virtual method lookups. It has two code paths: a bytecode interpreter that runs in a tight loop, and an optimizing Java bytecode compiler that turns many expensive-ish JavaScript property lookups into Java local or instance-variable lookups. It’s a pretty serious piece of software.

When you start digging into Rhino, you find unexpected depth. JavaScript (unlike Perl, Python and Ruby, at least today) actually has a real specification, and Rhino follows it rigorously, aiming for complete SpiderMonkey compatibility within the bounds allowed by the different language platforms. Rhino also offers rich configurability, has well-defined multi-threading semantics, has a full set of hooks for debugging and profiling, and much more besides. There’s a lot under the hood.

Oh, and Sun is now bundling it with the JDK; it’s javax.script in Java 6. With that kind of endorsement it would have been hard to justify using anything else, even if some language other than Jython or JavaScript had been up for consideration.

With an endorsement like that and the potential for easy integration in an IDE with Google’s GWT you can expect to hear a lot more about Rhino on Rails in the coming year.

void foo(int a, int b = 42) {
//b is set to 42 automatically if no value is defined
...
}

I felt an urge to do it, so I sat down for a few minutes, trying to conjure something nifty that would be intuitive enough for even me to use.

The solution I came up with, and that hopefully will put an end to the default-arguments rant for good.

The solution is quite simple, and very intuitive. It may have some shortcomings but keep in mind I didn’t explicitly write it for you. You could probably modify my solution to fit your needs anyway.

I’ve seen a lot of developers (including myself, long time ago) using this pattern as a workaround for the lack of built-in support for default-arguments.

function foo(a, b)
{
a = typeof(a) != 'undefined' ? a : 42;
b = typeof(b) != 'undefined' ? b : 'default_b';
...
}

Which most developers probably find sufficient, I don’t.

The solution may look scary at a quick first glance, but bear with me. I’ll start by writing the framework-code. The code that will be required for this thing to work.

Function.prototype.defaults = function()
{
var _f = this;
var _a = Array(_f.length-arguments.length).concat(
Array.prototype.slice.apply(arguments));
return function()
{
return _f.apply(_f, Array.prototype.slice.apply(arguments).concat(
_a.slice(arguments.length, _a.length)));
}
}

See that wasn’t so scary .

In order for this to work you have to declare you functions in a special way. There are basically two ways of declaring a function.

function foo(a, b)
{
...
}

Is identical to (apart from the lexical difference, and some other minor things)

var foo = function(a, b)
{
...
}

In order for this solution to work you have to declare all functions on which you wish to have default-arguments the latter way.

Usage

var foo = function(a, b)
{
...
}.defaults(42, 'default_b');

Is identical to the first code-block but without adding any code in the function-body.

Example

var bar = function(a, b)
{
}.defaults('default_b');
bar();
// a = undefined, b = 'default_b'
bar(1);
// a = 1, b = 'default_b'
bar(1, 'some_value');
// a = 1, b = 'some_value'

This tutorial is clean and concise, covering basics such as variables, functions, events, math and dates. A nice feature is the code doesn’t look like it dates to 1998. The tutorial is actually several tutorials, and also covers popular topics such as AJAX for Noobs and JSON. An excellent resource for those just learning the language or eager to dive into more advanced topics but lacking fundamentals.

While none of the scripts are new they are all both nice and potentially useful for sprucing up your site or webapp. Some of the scripts aim at visual effects such as loading and fading an image or putting hot spots on a map, while others such as Lightbox are regularly mentioned on the irc channel. There are also updated versions of ubiquitous tools like a date picker calendar and auto complete.

These are not just snippets of code but full blown scripts, so you should get productive results from them right away, and all are free for anyone to use.

A lot of prototyping toolkits exist, with Prototype (yeah, they stole the name) being the most popular one, but at 92KB, some consider Prototype a bit heavy for what they need. If you happen to be one of those people, then you may be interested in picking and choosing prototype methods from the following two resources.

The first is Svend Tofte’s Usefull Prototype Methods for JavaScript (sic). Svend’s collection of a dozen methods weighs in at a tiny 2KB, and it’s all modular enough that you can pick and choose the methods you like the most.

The second is Henlock’s Ten JavaScript Tools Everyone Should Have. I find his methods to be a bit more useful than Svend’s, and he mentions a few additional resources at the bottom of his page.

So what prototype methods are a must for you?

Everyone should have some sort of quick reference when it comes to JavaScript, the language’s ease of use lends itself to a light document that can quickly be looked up. Personally I’ve only ever used O’Reilly JavaScript Pocket Reference as my JS book. For anything more complicated I was always better served by Google.