// A:
function myFunction () {
  if (somethingWrong) {
    throw 'This is my error'
  }
  return allGood;
}

and

// B: async Node.JS-style callback with signature `fn(err, …)`
function myFunction (callback) {
  doSomethingAsync(function () {
    // …
    if (somethingWrong) {
      callback('This is my error')
    } else {
      callback(null, …);
    }
  });
}

In both cases, passing a string instead of an error results in reduced interoperability between modules. It breaks contracts with APIs that might be performing instanceof Error checks, or that want to know more about the error.

Error objects, as we’ll see, have very interesting properties in modern JavaScript engines besides holding the message passed to the constructor.

The stack property

The fundamental benefit of Error objects is that they automatically keep track of where they were built and originated.

The mechanism of how this happens is specific to each JavaScript engine and/or browser that implements it.

V8 (Node.JS)

The way that V8 handles this, which directly affects us who develop in Node.JS is described by the StackTraceApi document.

We can test its behavior by simply initializing a Error object and inspecting its stack property:

// error.js
var err = new Error();
console.log(typeof err.stack);
console.log(err.stack);

∞ node error.js
string
Error
    at Object.<anonymous> (/private/tmp/error.js:2:11)
    at Module._compile (module.js:411:26)
    at Object..js (module.js:417:10)
    at Module.load (module.js:343:31)
    at Function._load (module.js:302:12)
    at Array.0 (module.js:430:10)
    at EventEmitter._tickCallback (node.js:126:26)

As you can see, even without throwing or passing it around, V8 is able to tell us exactly where that object was created, and how it got there.

By default, V8 limits the stack trace size to 10 frames. You can alter this by changing the Error.stackTraceLimit during runtime.

Error.stackTraceLimit = 0; // disables it
Error.stackTraceLimit = Infinity; // disables any limit

Custom Errors

If you wanted to extend the native Error object so that stack collection is preserved, you can do so by calling the captureStackTrace function. This is an example extracted from the Mongoose ODM

function MongooseError (msg) {
  Error.call(this);
  Error.captureStackTrace(this, arguments.callee);
  this.message = msg;
  this.name = 'MongooseError';
};

MongooseError.prototype.__proto__ = Error.prototype;

The second argument passed to the captureStackTrace prevents unnecessary noise in the stack generation by hiding the MongooseError constructor calls from the stack.

Beyond stack strings

As you might have noticed in my previous code example, I purposedly printed the typeof of the stack property. As it turns out, it’s a regular String with a format optimized for readability.

V8, much like Java, allows complete runtime introspection of the stack. Instead of a string, we can access an array of CallSites that retain as much information as possible about the function call in the stack, including the object scope (this).

In this example, we override the prepareStackTrace function to access this raw array and examine it. We call `getFileName` and other methods on each CallSite (all the available methods are described here)

function a () {
  b();
}

function b () {
  var err = new Error;

  Error.prepareStackTrace = function (err, stack) {
    return stack;
  };

  Error.captureStackTrace(err, b);

  err.stack.forEach(function (frame) {
    console.error(' call: %s:%d - %s'
      , frame.getFileName()
      , frame.getLineNumber()
      , frame.getFunctionName());
  });
}

a();

This is an example of the output this script produces:

∞ node error-2.js
call: /private/tmp/error-2.js:3 - a
call: /private/tmp/error-2.js:23 -
call: module.js:432 - Module._compile
call: module.js:450 - Module._extensions..js
call: module.js:351 - Module.load
call: module.js:310 - Module._load
call: module.js:470 - Module.runMain
call: node.js:192 - startup.processNextTick.process._tickCallback

All this functionality would of course be non-existent if we were to pass around strings, therefore drastically shrinking our debugging panorama.

For real-world usage, restoring the original prepareStackTrace after overriding it is probably a good idea. Thankfully, TJ Holowaychuck has released a tiny callsite module to make this painless.

Browsers

Like the V8 document states:

The API described here is specific to V8 and is not supported by any other JavaScript implementations. Most implementations do provide an error.stack property but the format of the stack trace is likely to be different from the format described here

• Firefox exposes error.stack. It has its own format.
• Opera exposes error.stacktrace. It has its own format.
• IE has no stack.

A very interesting solution to this is provided by javascript-stacktrace, which attempts to normalize a printed stack trace across all browsers.

On IE (and older versions of Safari), for example, it uses a clever method: it recursively looks for the caller property of a function, calls toString on it and parses out the function name.

var currentFunction = arguments.callee.caller;
while (currentFunction) {
  var fn = currentFunction.toString();
  var fname = fn.substring(fn.indexOf("function") + 8, fn.indexOf('')) || 'anonymous';
  callstack.push(fname);
  currentFunction = currentFunction.caller;
}

Conclusions

• When doing async I/O (in Node.JS or otherwise), since throwing is not a
  possibility (as it results in uncaught exceptions), Errors are the only way to
  allow proper stack trace collection.
• Even in non-V8 browser environments, it’s probably a good idea to still initialize
  Errors. The API exists in all browsers, and the extended API facilities that V8
  provides are bound to be available to most engines in the future.
• If you’re throwing or passing around strings for errors, consider switching today!

The examples in the beginning of the post can thus be rewritten this way:

// A:
function myFunction () {
  if (somethingWrong) {
    throw new Error('This is my error')
  }
  return allGood;
}

and

// B: async Node.JS-style callback with signature `fn(err, …)`
function myFunction (callback) {
  doSomethingAsync(function () {
    // …
    if (somethingWrong) {
      callback(new Error('This is my error'))
    } else {
      callback(null, …);
    }
  });
}

Alex Russell – “Google Chrome Frame”
Post: http://alex.dojotoolkit.org/
Slides: http://alex.dojotoolkit.org/10/jsconf/gcf.html

Francisco Tolmasky – “Socratic: Documentation Done Right”
GitHub: http://github.com/tolmasky/socratic
Slides: ?

Aaron Newton – “Programming To Patterns”
Slides: http://www.slideshare.net/guest2ee5e2c/programming-to-patterns-presentation (not up-to-date)

Jed Schmidt – “A (fab) approach to web apps”
GitHub: http://github.com/jed/fab
Slides: http://www.flickr.com/photos/tr4nslator/sets/72157623883700702/show/

Dmitry Baranovskiy – “Raphaël the Great”
Slides: http://www.slideshare.net/Dmitry.Baranovskiy/raphal-js-conf

Douglas Crockford – “Really, JavaScript?”
?

Tobias Schneider – “Flash is dead, long live Flash!”
GitHub: http://github.com/tobeytailor/gordon
Slides: http://www.slideshare.net/ConfEcho/flash-is-dead-long-live-flash

Makinde Adeagbo – “Primer: Facebook’s 2k of JavaScript to power (almost) all interactions”
Slides: http://www.slideshare.net/makinde/javascript-primer

Steve Souders – “The Best of Steve”
Slides: http://www.slideshare.net/souders/jsconf-us-2010

Jenn Lukas – “JavaScript and Web Standards Sitting in a Tree”
Slides: http://www.slideshare.net/JennLukas/javascript-and-web-standards-sitting-in-a-tree

Ryan Dahl – “Less is More in Node.js”
Slides: http://nodejs.org/jsconf2010.pdf

Billy Hoffman – “JavaScript’s Evil Side”
Slides: ?

John David Dalton – “All you can leet”
Slides: http://www.slideshare.net/johndaviddalton/jsconf-all-you-can-leet

Aaron Quint – “Making Bacon / Making Code”
GitHub: http://github.com/quirkey/sammy
Post: http://www.quirkey.com/blog/2010/04/20/making-baconmaking-code-jsconf-2010/
Slides: http://swinger.quirkey.com/#/preso/aq-jsconf/display/1
Video: http://bit.ly/9j7u3L

Dion Almaer, Ben Galbraith, and Matt McNulty – “The mobile web”
Slides: http://www.slideshare.net/dion/the-mobile-web-2010-jsconf

With code as simple as this:

socket = new io.Socket('localhost');
socket.connect();
socket.send('some data');
socket.addEvent('message', function(data){
    alert('got some data' + data);
});

you’ll be leveraging:

• WebSocket
• Adobe Flash Socket
• ActiveX HTMLFile (IE)
• Server-Sent Events (Opera)
• XHR with multipart encoding
• XHR with long-polling

And on the server side, things are equally simple. This is a chat application written in Socket.IO-node, the Node.JS backend implementation:

var buffer = [], json = JSON.stringify;

io.listen(server, {

	onClientConnect: function(client){
		client.send(json({ buffer: buffer }));
		client.broadcast(json({ announcement: client.sessionId + ' connected' }));
	},

	onClientDisconnect: function(client){
		client.broadcast(json({ announcement: client.sessionId + ' disconnected' }));
	},

	onClientMessage: function(message, client){
		var msg = { message: [client.sessionId, message] };
		buffer.push(msg);
		if (buffer.length > 15) buffer.shift();
		client.broadcast(json(msg));
	}

});

As usual, head to GitHub to experiment with the code.

• [FEATURE] Autocompletion with on-demand server querying

• [ENHANCEMENT] All classes moved to $. to avoid global namespace pollution. Please make sure to prepend $. to TextboxList if you are upgrading from an older version:

     new $.TextboxList('#element');
  

• [FEATURE] Easier jQuery-friendly initialization like this:

     $('#element').textboxlist({options});
  

  However, if you still need to access the TextboxList instance to call additional methods (like add), you’ll have to continue to use new $.TextboxList

• [BUGFIX] GrowingInput now works in noConflict mode

• [BUGFIX] Fix for GrowingInput to handle special characters and correctly calculate the input length.
• [BUGFIX] Fix for support of multiple addKeys
• [BUGFIX] Fix for focus problem when TextboxList gains focus through focusing an editable input
• [BUGFIX] Autocomplete search term is now trimmed (thanks Mike Feng)
• [BUGFIX] Fix for when the max option is used
• [BUGFIX] Fix for unique = true and autocomplete.

As usual, head to the project page for download.

• check option, which can allow you to specify a function to filter out new boxes that do not meet a requirement
• encode now receives the complete values, not only the id or string of the bit. This gives you full control of what you want to send to the server.

• Autocomplete now works with on-demand suggestions. As easy as this:

  new TextboxList('form_tags_input_4', {unique: true, plugins: {autocomplete: {
  	minLength: 3,
  	queryRemote: true,
  	remote: {url: 'autocomplete2.php'}
  }}});
  

And some bugfixes:

• Fixed missing index when unique: false and autocomplete were used, which resulted in an error
• Fixed problems with items with id 0, which incorrectly evaluated as false.

Head to the demo to see the new autocomplete in action, and as usual, report any bugs you might encounter.
Update: 0.5 is out already, which fixes a bug with the traditional use of Autocomplete. Sorry for the trouble!

This ambivalence is what still drives people, like myself, to keep writing about the infamous browser.

The tradeoff

The first premise we have to take into account is best summarized by this little website. There’s only two scenarios in which you can go to great lengths to make your website look (almost) exactly the same on IE6 and the rest:

• You have a very big budget, and a potentially huge IE6 audience. This is the case of websites like Facebook. If you read the Javascript and CSS of their widgets, you’ll know what I mean. The tradeoff here: money invested, poor markup and hacks all around
• Your website is just too simple. Why would you not try to fix a few CSS issues if your website is just too simple? If there’s no complex Javascript going on, and you have a nice little fixed-width website, there’s no reason why your site should look extremely different.

Mistake 1: make your site look like crap on IE6

The Universal Internet Explorer 6 CSS is the first big mistake I want to talk about. The idea here is that instead of wasting time on IE6 hacks, you just use a premade stylesheet, instead of disabling styling altogether. This is what A List Apart would look like if it was implemented.

This approach is flawed for a wide range of reasons:

• The idea behind this universal stylesheet is that disabling style would make your website look broken. However, your sites will look broken.
  • If you use a logo with a dark background, it’ll definitely not fit the white background the stylesheet imposes. The same goes for menus and any other graphical item that might not be ready for a white contrast.
  • If a prior version of your website or brand did work on IE6, and after a redesign you implement this, again, people will think something is really off.
  • There’s no “Universal JavaScript” solution. And as we all know, many of our scripts interact with the CSS present in the page. Disabling styling will also mean either disabling JavaScript or having to fix it for IE6 too, with the sort of hacks the universal stylesheet wanted to avoid in the first place (for example, conditional styling).
• It shouldn’t be black and white, there’s gray. At this time, most IE6 quirks have been perfectly documented. Most have very easy solutions: it’s almost a second-nature for me to add zoom: 1 to clear floats. Of course, making border-radius work on IE6 can be painful, but that’s exactly what you should be doing. Don’t go for all the small details: shadows, rounded corners, transparency. Or do it if the budget and time allows it. The key here is that you can still deliver your brand identity to IE6 without major efforts.

Developers strive to deliver an identity to all possible mediums. If they design custom iPhone versions, why can’t they streamline their stylesheet to make it look fairly good on IE? As an example, my website worked almost perfectly on IE6 with little work. However, when I triggered the rain in my clouds, it just crashed. As a result, I just disabled that particular effect.

Mistake 2: not explaining the user why IE6 is bad

As I was reading the comments on Jeffrey Zeldman’s post, I couldn’t help but be reminded of how condescending developers can be towards their users. The key here is that people will switch if they understand why.

Let’s look at some of the proposed solutions to make users switch.

• IE 6 Blocker overlay. Blocks content, doesn’t explain why the switch is encouraged
• Push up the web. Doesn’t block content, but doesn’t explain why the switch is encouraged and to top it off, it presents itself as sort of a deceiving “operating system important notice”.
• IE6Update takes the cake. Not only does it completely imitate a Microsoft warning in a deceptive way, but chances a very high that the user itself closed a similar message box a long time ago! Remember that Microsoft itself pushed the upgrade to IE7, even through the system automated updates. To top it off, this message doesn’t remotely explain how your website is better in a modern browser, so it’s an “easy close” for your average IE6 visitor.

The correct approach

1. Deliver the content
2. Make your website look OK on IE6, and somewhat similar.
3. Encourage the switch. If you’re looking for a universal solution for this, I would suggest placing a prominent link to PPK upgrade page. He presents the information in a very concise and reasonable way, that everyone can understand. The best idea, however, is to customize the message for your visitors. Explain why your website would be better in another browser. What they’re missing. How easier some tasks would become with better JavaScript widgets or how nicer the navigation could be.

• HTML for bits not showing properly fixed
• highlightSelector not working (due to a typo) fixed
• GrowingInput missing pad function added (only affected if you customized growing.mini option)
• Improved clicking the whole widget behavior
• Other tiny enhancements / cleanup

Secondly, in the best interest of the JavaScript community, I’ve ported TextboxList to jQuery. The API changes slightly due to the different OOP approach, but all the functionality is intact. Head to jQuery TextboxList project page for more.

Update: 0.2 is out for jQuery. Bugs in autocompleter and IE have been addressed.

A regular expression looks for text outside HTML tags. It uses a callback function to perform replacements to simulate native lookahead support.

When is this sort of replacement suitable ?

• Remote HTML responses (ajax) highlighting
• Autocompleters suggestion highlighting
• User-typed HTML, WYSIWIGs, etc.

Generally speaking, the only downside of this method, since it deals with the innerHTML, is that all attached events and properties are lost when the replacement is performed.

Note: this code is designed to match only beginning of words. If you want to match anywhere, remove \\b from the regular expression. And if you expect <script> tags, definitely don’t use it.

MooTools version (demo)

Element.implement({

	highlight: function(search, insensitive, klass){
		var regex = new RegExp('(<[^>]*>)|(\\b'+ search.escapeRegExp() +')', insensitive ? 'ig' : 'g');
		return this.set('html', this.get('html').replace(regex, function(a, b, c){
			return (a.charAt(0) == '<') ? a : '' + c + '';
		}));
	}

});

jQuery version (demo)

jQuery.fn.extend({

	highlight: function(search, insensitive, klass){
		var regex = new RegExp('(<[^>]*>)|(\\b'+ search.replace(/([-.*+?^${}()|[\]\/\\])/g,"\\$1") +')', insensitive ? 'ig' : 'g');
		return this.html(this.html().replace(regex, function(a, b, c){
			return (a.charAt(0) == '<') ? a : '' + c + '';
		}));
	}

});

Check out Devthought’s latest release, APNG 0.1

You wanted more, we give you More. Today the new MooTools More RC1 is being released, with an outstanding number of new plugins. More functionality, but with the quality you come to expect from the MooTools framework.

Most of the new components come from the excellent Aaron’s Clientcide library. I contributed to the improvement, refining and testing of some of his vast code, which brings More to its present state.

The goal here is to provide more great, simple and extensible tools to make developers’ lives easier. I suggest you head to the Docs or Builder page right away to start trying out the new stuff. As always, head to Lighthouse to report the bugs you encounter, or even to suggest new additions or features.