Author Archive

2007 Ajax Tools Usage Survey Results

Ajaxian’s annual framework survey is out. Being a Mootools developer, of course my primary interest is in seeing how it stands up.

Looking at the chart on the right here, you can see that it’s #5 on the list, although I’d argue that Scriptaculous isn’t a framework so much as an add-on to Prototype. If you’re using Prototype, you’re likely to use Scriptaculous as your effects interface.

So by that logic, Mootools is doing quite well and growing since last year (it was a write-in candidate not listed as a choice in the survey in 2006, yet still garnered 11% of the vote).

There’s more to this survey if you’re interested. Head over to the Ajaxian post on the topic.

Mootools vs. other frameworks

I started working on the update for the Mootorial for Mootools 1.2 today and one of the new pages I’ve added attempts to answer the question: why should I choose Mootools over some other framework?

The page itself is a wiki, so for anyone reading this that represents one of these other frameworks, I invite you to tweak it if I am representing these others poorly. I hope I’m not.

So. Why should you choose Mootools vs. some other framework?

Javascirpt Shortcuts Tutorial

As you know, I’m all about the tutorials. Here’s one via Ajaxian that seems useful if you’re new to the js language:

I have to say that at one point, I truly thought that JavaScript was using some type of “black magic”. Things such as closures really threw me for a loop and I was fortunate to have some good folks to walk me through some of the tougher concepts. Not everyone is as lucky and thankfully, we have developers like Christian Heilmann who continue to put out great postings that cover a broad range of topics and experience levels.

In his latest posting, Christian outlines certain JavaScript shortcut notations which make understanding specific JS techniques a whole lot easier. For example, when dealing with objects, there’s the involved way of defining objects:


var links = new Object();
links[’Cute Overload’] = ‘http://cuteoverload.com’;
links[’I can has cheeseburger’] = ‘http://icanhascheezburger.com’;
links[’Pencils at dawn’] = ‘http://pencilsatdawn.wordpress.com’;
links[’Hobotopia’] = ‘http://apelad.blogspot.com’;

and then there’s the easier way using object literals:

var links = {
‘Cute Overload’ : ‘http://cuteoverload.com’,
‘I can has cheeseburger’ : ‘http://icanhascheezburger.com’,
‘Pencils at dawn’ : ‘http://pencilsatdawn.wordpress.com’,
‘Hobotopia’ : ‘http://apelad.blogspot.com’ // < -- again, no comma!
}

Christian provides plenty of great examples that should substantially help new JavaScript developers.

JavaScript Beautify

On numerous occasions I’ve found myself with some javascript that’s been compressed or just poorly organized and before I could dig my hands into it I had to spend half an hour putting all the line breaks and tabs in place so I could make sense of it.

Less often is it the case that I am looking at someone else’s work and want to understand the source, but it happens. Enter Javascript Beautify. Ajaxian has a post up on it today and I gotta tell you, I love this stuff. Awesome, awesome, awesome. Now, if only there was a CSS Beautify…

We often talk about the latest scheme for compressing and minimizing our JavaScript. The JavaScript Beautify script aims to do the opposite.

Often, you find a site that is doing something interesting and you want to learn how it works. You check out the source and it is cryptic gibberish. This is where the beautifier comes in to make it a touch more readable.

As a test, I took one of our compressed libraries and dumped it in there and what came out was probably better organized than the source we compressed it from…

Contextual Precaching

Precaching isn’t anything new; we were cramming 1×1 pixel versions of our graphics into the footer of our home page back in the day so that after the user clicked through from our splash screen the home page would load quickly. Ahhh, the good ole’ days.

Anyway, Ajaxian has a post up today on a new twist: anticipating what your user is about to do based on what they are doing on the current page. In this case, it’s Yahoo anticipating that if, hey, you’re typing something my search boxen, then you’re probably gonna end up on my search results page. So why not go ahead and load some of those dependencies now?

Yahoo! Search does an interesting bit of caching. To see it in action, go to the main search page with Firebug enabled and ready (or any tool that lets you see network traffic). Then type any character into the search input box and you will see some traffic kick off to download items such as:

http://us.js2.yimg.com/us.js.yimg.com/lib/s3/ysch_srp_clean_200711061918.css
http://us.js2.yimg.com/us.yimg.com/i/us/sch/el/att_hdspr_1.6t.png
http://us.js2.yimg.com/us.js.yimg.com/lib/s3/ysch_srp_clean_200711051714.js
http://us.js2.yimg.com/us.yimg.com/i/us/sch/gr2/sprt_srp_core_6.gif
http://us.js2.yimg.com/us.yimg.com/i/us/sch/el/ng_bg.png

What are these files? They are artifacts for the results page. So, Yahoo! groks that you obviously are going to do a search once you start to type something in, so why not go ahead and preload the files that are needed as part of the results page? Nicely done.

Yahoo! Search Caching

GWT Conference: December 3-6, 2007

via Ajaxian:

Addison-Wesley and Prentice Hall are putting on a conference dedicated to GWT on December 3-6 in San Francisco.

Much more detail in the blog post there.

Mootools 1.2 beta. woot.

Valerio posted over on the Mootools blog today about the release of Mootools 1.2 beta. I argued with him that this should be Mootools 2.0 because, once again, nearly every single method and class has been tweaked or rewritten wholesale.

Mootools 1.11 was released just over five months ago and since then the development team has been hard at work (I’ve been slacking, mostly reading code commits and giving feedback; you won’t see my name in the commit log very much on this release) and the product is something I’ve been eagerly awaiting. The list of what’s new is daunting and will take you a few minutes to read and many more to grok.

I especially look forward to Fx.Tween and Fx.Morph, the awesome test suite integration, the new and improved Hash, and the new Sortables (which I’ve already been using in a version I ported back to 1.11 for myself). But that’s not all! Call now and you get like a bazillion other new methods and shortcuts and browser fixes (oh, I forgot the new Iframe class).

SRSLY, this release is awesome. Congrats all around to the Mootools dev team, myself excluded.

A note on our stuff: The Mootorial will be a few weeks in the updating but it’ll catch up eventually. Our code base is a different story. It’s going to take a while to migrate all our stuff to 1.2 as we haven’t started yet (I learned my lesson previously; don’t start migrating for a Mootools release until the release is done or else you’re chasing a moving target, and Valerio and team are far more productive than I am). It should continue to work with the compatibility script for 1.2 installed, but we haven’t tested for that. Stay tuned as we start on this process.

The first beta for MooTools 1.2 is finally here!

After months in the making, we can confidently say that MooTools 1.2 is now feature complete. However, there are still some bugs left to squash.

Head over to MooTools download page to start playing with it right away.

read about all the new stuff in this release >

Javascript shorthand @ d’bug

The d'bug blog has a nice little post on javascript shorthand that's worth looking at if you don't know these tricks. Stuff like declaring variable defaults with the logical OR or using ternary , etc. One thing to be careful of is type coercion. Basically if you say "if (x) ..." you can get a false evaluation if x is an empty string, null, zero, or false. Check out the mootools functions $chk, $pick, and $defined for easy ways to avoid these kinds of things. You can also express conditionals using === and !== to ensure you are evaluating for the right condition.

JavaScript:
/*

    -----------------------------------------------
    Conditional Shorthand 1
    -----------------------------------------------

    If "a" is not defined, or is not equal to true,
    then "a" is equal to "b".

    Longhand:

        var a, b;
        if ( !a ) {
            a = b;
        }

    Shorthand:

*/

var a, b;
a = a || b;

/*

    -----------------------------------------------
    Conditional Shorthand 2
    -----------------------------------------------

    If some condition is equal to true,
    then "a" is equal to "b", or else
    "a" is equal to "c".

    Longhand:

        var a, b, c;
        if ( true ) {
            a = b;
        } else {
            a = c;
        }

    Shorthand:

*/

var a, b, c;
a = ( true ) ? b : c;

drag to resize


Check out the whole article »

d’bug blog on choosing a js framework, mastering javascript

This post over on ajaxian today led me over to d'bug, a blog by Brian & Stephanie Reindel. The Ajaxian post points to their recent post "How to Choose a Javascript Framework" which is a brief overview of what to look for in choosing. They don't endorse a particular framework but rather clue you in on what to look for.

But this article led me to "Mastering Javascript - concept and resource guide". Holy guacamole. This article is great. It's very direct and to the point and lists out the main things that you really need to grok to be a javascript bad ass:

  • Access Control
  • Accessible Javascript
  • Closures
  • Classical OOP
  • Concepts in AJAX
  • Memory Leaks
  • Namespaces and Self-invoking Functions
  • JSON and Object Literal Notation
  • Security

Each item has a quick one or two sentence description followed by 3-5 links to deeper resources on each topic. Then, after all this, there's sections of links to JS articles, tutorials, and publications, Javascript tools, and finally frameworks.
This is going on my list of links for developers getting start with javascript and even if you think you have these bases covered its worth bookmarking it. Terrific stuff!

Fireclipse: Debug from FF straight into Eclipse

I use Eclipse at home (I run Ubuntu), but I can't say that this plugin excites me terribly. I use the debugging in firebug for a lot of different things (with our own debugging wrapper: dbug.js) and I don't know that I want all that stuff diverted into my editor... Still, it's cool and I'll probably install it just to see if it's more useful than firebug on its own. I don't really get all the mileage out of Eclipse that I could, so maybe this is just another instance of me not getting it entirely. To you Eclipse users out there, what do you think?

Note: the comments on ajaxian imply that this plugin isn't quite ready for prime time as of this posting.
via ajaxian, via Dean Edwards...

John J. Barton has released a new open source framework named Fireclipse that enables nice coupling of Firefox and Eclipse for debugging purposes, working on top of Firebug.

  • Fireclipse routes error messages from Firefox’s
    Javascript Console to Eclipse’s console.
  • Fireclipse positions an Eclipse editor on the source line reported by Firefox.
  • Calls to dump() end up on the Eclipse console
  • Fireclipse adds an Eclipse panel to Firebug
  • Extensions to Firebug include:
  • debug eval() code.
  • debug event handlers
  • route error messages to eclipse
  • executable line numbers marked

Take a peak at the page of screenshots to see it setup in Firefox and Eclipse.

( via Dean Edwards )

Categories

Archives

Links and whatnot