// Update the values for the next time a gesture happens
width *= e.scale;
height *= e.scale;
rotation = (rotation + e.rotation) % 360;
}
Some readers might have noticed that a gesture is just a prettier way of looking at touch events. It’s completely true, and if you don’t handle things properly, you can end up with some odd behavior. Remember to keep track of what’s currently happening in a page, as you’ll probably want to let one of these two operations “win†when they come in conflict.
We see the birth of the second baby when it comes to building and running apps on the iPhone. People have already spent almost $100k in the first few hours of the AppStore not being open, so tomorrow is likely to be a great day for Apple, and developers, as people run around clicking on buy without thinking of the price.
I spent some time running the applications, and thinking about how different they are to Web versions. For example, when I launch Twitterific vs. a web based Twitter it actually was faster for the Web page to load Safari up with everything. Twitterific also had a strange feature for loading images. As I moved up and down the list the images looked like they were being pushed out of cache which made for a weird experience.
What if the iPhone offered the ability to aggressively cache "applications". When you open the application it opens its own instance of Safari instead of just linking over to Safari. What if it had access to local storage APIs in WebKit?
The native applications do have benefits. They have access to the camera, addressbook, ... well wait, those could be JavaScript APIs too.
There is the tool chain. You can have fine grained performance knowledge of your application with the Objective-C tools, but with SquirrelFish Apple is getting better and better there too. Other nice tooling could work well when constraining the Web interfaces to the iPhone form factor.
What about games? You couldn't do super monkey ball, or could you if you had a really solid Flash, or feature complete canvas.
The native apps are great, but I am still betting on the Web as a great platform for mobile applications too.
Kent Johnson has released YPulse a simple open source wrapper for the YUI Animation library that makes creating highlight fades and pulsing button glows a bit easier.
As we all know, null not only does not have any properties, but their existence also can not be tested. So null.property retuns error instead of undefined.
James Coglan has updated Ojay, the chaining wrapper for YUI that we posted on a few months back.
The new release features really simple keyboard and form scripting and couple of new UI widgets, a new event system and a stack of other improvements:
Ojay.Forms. By far the biggest new package, Ojay.Forms sorts out a real pain point for me in terms of app development. It does two things: it provides unobtrusive replacements for the YAHOO.widget.Button family of classes, and it provides a DSL for handling form validation and Ajax submission.
Ojay.Keyboard. The new keyboard package is an abstraction over YAHOO.util.KeyListener that lets you say what mean without worrying about character codes, for example:
It lets you group sets of keyboard commands together so you can make context-sensitive keyboard controls, and gives you easy access to enable/disable key events and their default browser responses. Not much more to say except that you should check out the documentation.
We have two new UI packages, Ojay.Overlay and Ojay.Paginator. Overlay gives you a bunch of classes for positioning content on top of the document, producing lightbox effects and the like, and Paginator implements the content slider effect that’s got a lot of attention recently, including the ability to lazy-load pages of content via Ajax, and easy integration with Ojay.History. Both packages come with a collection of events to allow your code to react to changes to the components, just like you would for DOM elements.
Speaking of events, this release introduces Ojay.Observable, a JS.Class module that allows any class to support the on() method used for listening to events. This module underlies the custom events published by all the Ojay components. More information and examples are in the documentation.
A technique is presented (in terms of examples) which can give performance boosts in certain situations. The technique relies on higher-order functions, and sharing variables in closures.
Namespacing has been generally accepted (in one form or another) as a good thing. In this posting, a pair of functions: 'namespace' and 'using' are presented. The former ensures the existence of a namespace, similar to what is offered in common JavaScript libraries. However, it accepts more general forms of namespace declarations:
The object function advocated by Crockford in his work on parasitic inheritance makes a new object which has the input object as it's prototype. However 'instanceof' doesn't work with this function. A technique for combining these two is presented.
Dan Morrill doesn't like JavaScript 2. His reasoning is a little like the folks who don't want Java.Next to try to copy features from every other language, but to just be the best static language, and let other languages like Scala, Groovy, JRuby (and the hundreds of others like Fan) go in different directions on the same Java platform.
You could argue the same for the browser platform. Why push JavaScript 2 further than cleaning it up, and instead allow other languages to augment it.
This is where technology such as IronMonkey come in, as well as the work that Scott Peterson is doing, written up here:
Scott Petersen from Adobe gave a talk at Mozilla on a toolchain he’s been creating—soon to be open-sourced—that allows C code to be targeted to the Tamarin virtual machine. Aside from being a really interesting piece of technology, I thought its implications for the web were pretty impressive.
If I followed his presentation right, Petersen’s toolchain works something like this:
The LLVM instructions are converted into opcodes for a custom Virtual Machine that runs in ActionScript, a variant of ECMAScript and sibling of JavaScript.
The ActionScript is automatically compiled into Tamarin bytecode by Adobe Flash, which may be further compiled into native machine language by Tamarin’s Just-in-Time (JIT) compiler.
The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there’s some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM’s “emulation†of memory to have only a minor overhead over the real thing.
The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music.
When you think about plugins in many environments, you have strict contracts through interfaces that you have to implement. With jQuery, you can just add on to the jQuery prototype, normally seen through the alias $.fn.
I read this as the power of the simplicity, but John Resig, again in his three parter saw it a little different, I think by thinking too much about the title :)
I will contend that such a thing as plugins exist and are logically distinct from "random JavaScript code that manipulates other JavaScript code" as long as the following points are met:
There have to be explicit points upon which a plugin can attach. James notes the most common one in jQuery (jQuery.fn) but we have tons more - events, animations, selectors - all over the board for developers to snap in to.
Even more importantly: Those points have to be documented or, at the very least, be under some sort of agreement that they will be treated like a normal piece of the user-facing API. In jQuery we treat all plugin extension points as "user-facing API" and only ever change them in major releases (if at all) and always provide an alternative for authors to use.
Finally, there has to be some sort of repository for navigating these plugins. This is a huge differentiator. Simply referring to "code in the wild" as plugins doesn't really cut it if there's no commitment to hosting them and keeping their documentation and examples alive.
MooCirclePack is another stunning visualization library that brings circle packing to JavaScript. It is great for data that can be represented by size (eg: an alternative to a bar graph), or data that can be represented amorphously.
ShiftZoom 1.0 is the latest tool from Christian Effenberger that allows you to add zoom and pan functionality to oversized images on your webpages. It uses unobtrusive javascript to keep your code clean. Requires no plugin/extension or any other external resource!
It works in all the major browsers - Mozilla Firefox 1.5+, Opera 9+, IE 6+ and Safari. Works also on older browsers supporting images & createElement & getElementById, else it'll degrade and your visitors won't notice a thing.
Over the past several years, Stuart Langridge’s sorttable Javascript library has found widespread use. It’s easy to see why. Just add class=sortable to a table tag and its column headers automatically support click to sort. Pretty slick.
But sometimes sorting just isn’t enough. What if you want to focus on just one or two of the columns in a table? In a client-side application you could drag the columns you care about next to each other. Why not in a web application?
Enter dragtable. Like sorttable, it teaches HTML tables a new trick through a simple class attribute.
Once you have the JavaScript in place, you can simply add a class="draggable", and you can even work with both via class="draggable sortable"
, Showcase
