Sexy Sliding Menu - Andrew Sellick decided to use mootools due to the smoothness of their effects, however, he developed a sliding menu using script.aculo.us
FastFind Menu Script - This script allows for nested menus, based on dynamic “AJAX” responses. The menu can also be dragged/dropped thanks to the jQuery Interface Library.
Phatfusion- Image Menu - Image menu using javascript, onClick event keeps selected item open and to close it again.
Drag and Drop ordering in a TreePanel - This example shows basic drag and drop node moving in a tree. In this implementation there are no restrictions and anything can be dropped anywhere except appending to nodes marked “leaf” (the files).
Custom Menu Events This is a combination of animation and custom events where Think Vitamin team show us how menu items sliding into view and firing off subscribable events using Yahoo! UI
Context Menu Functionality This is a combination of animation and custom events where Think Vitamin team show us how menu items sliding into view and firing off subscribable events using Yahoo! UI.
LavaLamp jQuery Sliding Menu It is a jQuery sliding nifty effect menu with light weight code and extra two more interface styles.
Slashdot Menu- Dynamic DriveThis is a stylish collapsible menu modelled after the navigational menu found on Slashdot.
CSS Dock Menu If you are a big Mac fan, you will love this CSS dock menu that Nick La designed. It is using Jquery Javascript library and Fisheye component from Interface and some of their icons.
Back in March, we posted about Ian Smith’s newest project, TaffyDB, the lightweight JavaScript library that acts as thin data layer inside Web 2.0 and Ajax applications.
Ian contacted us to let us know about a new tutorial that he posted which provides step-by-step instructions on how to best implement TaffyDB:
TaffyDB extracts the “hard part” of working with data in JavaScript. It provides methods to insert, update, remove, sort, and filter a data collection in much the same way you can with SQL. But how do you take advantage of this when building a data intensive application? How can you incorporate what TaffyDB does well to minimize and simplify your code?
In this tutorial you’ll go step by step and build a simple data grid application that uses TaffyDB as the engine. The application will render a table and expose options to customize the table to your liking.
In this tutorial, he runs you through important TaffyDB steps such as initializing a grid, adding custom columns, implenting column sorting and more.
If you’ve not checked out TaffyDB, this tutorial is a great way to get acquainted with it.
Blackbird, G. Scott Olson's JavaScript logging library, truly has a catchy slogan. The slogan "Say hello to Blackbird and 'goodbye' to alert()" definitely captures what the Blackbird library aims to do; make logging messages in JavaScript extremely easy. And setup is very easy. By incorporating the following lines of code, you've now added the ability to set checkpoints which will display specific data you're interested in:
Pastebins have become an important part of sharing code with colleagues. Sites such as Pastebin & Pastie.org are extremely popular because they're easy to use and very effective in letting people compare notes on source code, especially in a support setting.
Remy Sharp wanted to take the pastebin concept a step further, past the static posting of code. His idea, which he tossed around for 6 months, finally came to fruition in the form of JS Bin, a new pastebin site with a twist:
JS Bin is a form of paste bin, but with a twist. It allows you to also include the HTML and CSS to provide context to your pasty. As such, it means you can actually run the JavaScript and pass this on to a colleague to help to debug.
This is a great idea as it lets you troubleshoot your code while seeing immediate results. The feature list is well thought out as well.
Save private snippet
Remote Ajax debugging
Snippet URLs run entirely on their own (i.e. without the JS Bin framework around them)
Support to quickly inject major JS libraries including jQuery, jQuery UI, Prototype, Scriptaculous, Dojo, MooTools & YUI
Saves state within the open window (i.e. refresh and the code doesn't reset)
The ability to inject many of the popular JavaScript libraries is especially important and I would highly recommend individual project teams to contact Remy directly to have their libs included.
To give this a run, I'd suggest going to the JS Bin site and putting it through its paces. In addition, Remy has produced two videos which go into detail on how to leverage JS Bin:
And then he rev'd it in different ways and captured the output.
His conclusion?
What I think of these results:
I don't know what Firefox is doing in case 2, and for some reason Safari Nightlies seem to be following it. Maybe it's just beyond my understanding, but case 2 is not supposed to be different from case 1. Why does case 2 operate in global scope? If window.eval is different from eval, case 3 shouldn't all have given errors. Someone please help me understand that $hit.
Case 4 makes sense, but that's a non-standard behavior in Firefox. Understandable that no one else exhibits it.
IE baffles me in case 5, and Chrome seems to ape it. In this scenario, the anonymous function is supposed to have the global scope - so, in this case, this should point to the window. WTF is happening here!
Consistent with case 2 above, Firefox and Safari Nightlies continue to display weird behavior in case 6. For some reason, in these two cases, the eval operates in the global scope.
Now, I have no idea why, but only cases 8 and 9 seem to really work at all. This is despite Doug Crockford going on and on about not using with constructs. It's also despite being beyond (my) understanding about why the with should make any difference to the eval, since eval is part of the window object.
All in call, if you are going to be evaling JavaScript (not JSON), and you want the eval'd code to run in the global scope, you should use the with block around the JavaScript snippet. Or else, you can lose a lot of hair handling cross-browser issues.
Ars Technica has a new columnist, John Resig. His first piece is on Extreme JavaScript Performance which has started to come to us in abundance recently!
His article focuses on the latest updates to the fish, SquirrelFish Extreme:
A popular technique that is gaining traction amongst JavaScript engine implementers is that of optimizing the engine, while it's still processing the JavaScript code, to determine the "type" of the object that is being used. Since JavaScript doesn't include any sort of explicit type system JavaScript engines are frequently forced to check and re-check the values that they are handling, to insure their integrity. SFX rounds out the collection of other modern JavaScript engines, namely V8 and TraceMonkey, to provide this form of polymorphic inline caching. Interestingly, the idea for this form of caching comes from the Self programming language, the origin of many of the ideas in JavaScript (such as using prototypal inheritance instead of the more-common classical form of object inheritance seen in languages like Java).
JavaScript engines are serving as the test bed for new forms of dynamic language optimization. No other language is seeing this level of competition and rapid improvement that JavaScript is. This is optimal considering that JavaScript is one of the most widely-deployed programming languages available.
The SquirrelFish Extreme release currently stands as the fastest JavaScript engine [based on SunSpider] (although that's certain to change as healthy competition continues).
Based on its performance on the regexes it does handle, WREC (WebKit Regular Expression Compiler) is indeed an awesome design. regexp-dna.js, however, is flawed and exaggerates SFX performance.
We could use nanojit to make a regex compiler for SpiderMonkey that would perform as well as WREC. But I don’t know if it’s worthwhile yet. Regex performance is much less important for today’s web than it is for SunSpider–I hope to link to a report on that in a future post.
That was the conclusion that David Mandelin of the Tamarin project as he looked into how "SquirrelFish Extreme (SFX) is kicking our butts so badly on regexp-dna.js."
I love David's posts, as they go into the real meat of the tech:
Technical details: the design of WREC. There are two main ways to implement regular expressions: using a backtracking matching engine, or by transforming the regex to a finite automaton (NFA, aka “state machine”), which does not backtrack. Most Perl-type regex engines, including both SpiderMonkey’s and WREC, follow the backtracking design. I don’t know the exact history of that choice, but at present it is much easier to implement features like group capture and backreferences in the backtracking design. Also, although some regexes scale only if implemented as NFAs, my tests suggest that many simple regexes, including those in SunSpider, are faster with backtracking.
As of this writing, WREC’s implementation strategy is dirt simple (which is a good thing). There are no transformations or fancy optimizations on the regex. WREC simply generates native code that directly implements the backtracking search. Thus, within a single match operation, there are no function calls, no traversals of regular expression ASTs, and few option tests, so almost all of the overhead is eliminated.
WREC’s code is very easy to read, so if you want to know exactly how it works, just read it in WREC.cpp. It’s also great example code for anyone implementing a compiler for a simple language like regular expressions. The basic plan is to parse the regular expression with functions named things like parseDisjunction (the | operator). Those functions directly call functions like generateDisjunction that generate the native code using the same assembler that the call-threading interpreter uses. There’s also the oddly named “gererateParenthesesResetTrampoline”. Inexplicably preserved typo, or watermark to detect copying of WREC code?
I got to meet Aaron Newton at The Ajax Experience, and he is a thinker. He was really taking in the various talks, and interactions, and you could tell that he was trying to work out various angles on the frameworks. What makes them different? What makes them popular? Where are they going?
He wrote a really nice post on some of these thoughts that goes into detail on different patterns for JavaScript programing. The meme at the show was definitely "the frameworks all do the same thing, just with a different looking API" which makes it even harder to put your finger on differences sometimes. Aaron does a good job.
John Resig himself gave a talk comparing the frameworks. Considering that he is Mr. jQuery, I thought he was very unbiased and had some good thoughts:
Uriel Katz wrote in to tell us that he's burned his GearsORM framework to the ground to create the entirely new JStORM framework, announced in his blog. JStORM currently supports Google Gears, Aptana Jaxer, and Adobe AIR, but it's still bleeding edge: no documentation yet, just code. But the feature-set is interesting:
* define your tables as models.
* full CRUD support.
* events on(Before/After)Delete/Save/Update.
* SQL LIMIT/OFFSET support.
* order by support.
* automatic creation of tables.
* selecting and deleting over relations.
* easy iterating with each syntax like in Ruby,support for query chaining and more.
* basic introspection support.
* transaction support.
* self relations.
* support multiple backends and multiple dialects,currently MySQL (in Jaxer only) and Sqlite (Jaxer, Gears and AIR).
Here's an example of loading "Person" entities from a database using JStORM:
Mikael Bergkvist was frustrated with how effects in different browsers were far from uniform. They could run around in a modern browser, and lag on old ones. In general many effects seem to be far from smooth, and we have talked about the need to have a Timer thread that you can tie into to get the work smoother.
ZAP is a widgetplus project which boosts javascripts up to eight times the speed without having to resort to a plugin of any sort, by using a completely new approach that takes into account how the javascript engine is actually written. It’s also making sure – automatically – that the set speed remains exactly the same regardless of what browser you use.
Once set to a certain speed, it stays that way – regardless of the browser being used.
This page is a teaser of what is to come, the actual launch is next month, and developers will then have a tool that resolves a very important pain that webdevelopers will be facing now when the new age of browser wars has come to the javascript engine itself.
alert('The this keywords works (even in IE!): ' + this.id);
});
and he has some nice commentary:
So some of you may be wondering: "Why another addEvent function. Haven't we been through this?" We have, but I think you'll find that this version does more than any other addEvent function you've seen. For example:
Works in all browsers that matter
Ensures one event wire up for any given element/event/handler combination (this is mostly for IE)
Forces IE to honor the this keyword from within event handler functions
Normalizes the wire up mechanism in all browsers (no need to include the "on" prefix for IE)
Forces IE to recognize the following properties/methods on event objects: .stopPropagation(), .preventDefault(), .target, .relatedTarget
Enhances Non-IE browsers to support mouseenter and mouseleave events
Provides an extension mechanism so developers can write their own custom events that plug right in ('mousewheel' or 'DOMContentReady' for example)
Azer Koculu has released his Pi.js framework, which is a lightweight system that includes a minimal set of modules, and the ability to use and provide plugins.
By default you get:
pi.env: browser detection
pi.get: DOM access
pi.util: Extensions to JavaScript (e.g. support currying, includes, viewport config, and more)
pi.base: OO subsystem
pi.element: Create and modify the DOM
p.xhr: Remoting
Extensions to native objects such as Array, Function, Number, and String
, JavaScript
