As the release of Coherent looms nearer, I’ve been encouraged to start writing some documentation. My first effort is up: Writing a Widget. This tutorial takes you through creating a widget using Coherent starting with raw mark up and ending with a functional (if simple) widget. Thanks to some great feedback (and encouragement) from Neil Mix of Pandora, this tutorial doesn’t suck.
I’ve written a little bit about an exciting new feature in the Coherent library: automatic change notifications. In short, this reduces the amount of code you need to write and if your application only needs to support a Class A browser (like Safari 3 or Firefox), you can rely on JavaScript’s support for property getter/setter methods to further reduce your work.
So I’ve been thinking about JavaScript performance, because I’m hoping to make my animations run smoother. The actual animation steps (changing position, opacity, or size of a node) can’t be improved by anyone other than the browser vendor. So what can I do to optimise my code and allow me to get more raw horsepower out of the same browser?
A little while ago, I wrote about a simple animation package I was working on. I made the following wondrous claim:
You may have been wondering why the animation functions are structured like they are. All animation functions follow the same structure:
The other day, I posted the following to the Prototype Core mailing list:
Has anyone taken the time to verify that the numerous warnings
generated by running JavaScript Lint against Prototype are innocuous?Prototype 1.5.1 generates 160 warnings. For example:
prototype.js:2300: WARNING: undeclared identifier: node