Archive

Archive for the ‘Javascript’ Category

Bizarro dojo with a slice of cujo.js [updated]

August 19th, 2010
Comments Off on Bizarro dojo with a slice of cujo.js [updated]

Here is the slideshow from my presentation at the Bocoup Loft on August 15th. For some reason, slideshare barfed on it even after I removed all of the video and audio. Srsly, I tried five different variations.
dojo is bizarro jQuery (bocoup)
This presentation is in the QuickTime Presentation format. You must use the space bar or arrow keys to navigate. (I seem to have to click and hit the arrow keys about a dozen times before the presentation starts.)

[update]
I finally got slideshare to accept the slides! Here’s the sideshow.

cujo.js, dijit, dojo, Javascript

Firefox’s proposed Resource Packages spec blows!

August 3rd, 2010

It’s no secret that one of the keys to a decent user experience is a responsive (fast) user interface. And the most critical component to a fast web app is minimizing the HTTP requests. So it’s no mystery that people are working on ways to solve this problem.

Firefox, of course, is one of the leaders in this area. Their proposal started out fine. Here’s a sample of what it would look like (if you didn’t read the article):

<link rel="resource-package" 
      type="application/zip" 
      href="/static/site-resources.zip"
      content="javascript/jquery.js;
               css/reset.css;
               css/grid.css;
               css/main.css;
               images/save.png;
               images/info.png" />

You specify that the file, /static/site-resources.zip”, contains the listed resources. JavaScript, CSS, and images. (I imagine SWFs and videos would also be options.)

But for some reason, this concise, nearly-valid implementation was trashed in favor of a terse, unfamiliar, and nearly unusable alternative. Here’s what the spec looks like now:

<html packages='[pkg1.zip img1.png script.js styles/style.css]
                [static/pkg2.zip]'>
</html>

In this bastardization, the packages are specified as an attribute on the document element (<html> tag). Package definitions in the packages attribute are delimited by square brackets, and the resources within them are delimited by spaces.

WTF? Not only is this ugly and non-standard, but it also has some serious drawbacks. Here’s why:

Read more…

CSS, cujo.js, dojo, HTML / DHTML, In-browser MVC

It’s official: the Cujo Project is underway

June 9th, 2010

I’ve teased.

I’ve threatened.

I’ve promised.

The Cujo Project is finally underway.
Read more…

CSS, cujo.js, Javascript

Deduplicate any array in Javascript

December 8th, 2009

I’ve neglected this blog lately. My only excuse is that I am very, very busy! Not only have I been lucky enough to land a great opportunity working with some very bright jQuery Interactive Developers at Molecular, but I’ve also been working on something really big. (More on that later!)

But despite being busy, I felt compelled to post this one. As part of the something really big project, I had to deduplicate a potentially large array of nodes. Dojo doesn’t have a built-in function for deduplication (a.k.a “deduping”). How could it not? Doesn’t everybody have to do this once in a while?

I guess I’ll have to write one. How hard could it be?
Read more…

dojo, Javascript, jQuery, performance

Javascript for Java Stoics, a Twitter series

May 14th, 2009
Comments Off on Javascript for Java Stoics, a Twitter series


Javascript for Java Stoics: Guess what. 10 years experience with Struts and JSP does not qualify you as a Web 2.0 tech lead! (true story)



Javascript for Java Stoics: Think recursion is overrated and convoluted? Try it in Javascript: it was designed for recursion!



Javascript for Java Stoics: Yes, the app must still work if users crank up the text size w/ Ctrl+/Cmd+ Bonus pts if it still looks good too!



Read more…

Java, Javascript ,

A Better Javascript Un-memoizer. Part 1: Epic FAIL!

May 7th, 2009

In my previous post, A Better Javascript Memoizer, some of you left some great feedback. (Thanks to all of you!) I think it’s because each of us has a different definition of “better”. That makes sense.

Actually, I just wrote that title quickly when I got inspired to start writing. Just before publication, I was going to change it to remove the word “better”. But as an experiment, I decided to keep it to see if it would elicit more feedback. Success! 🙂

Two people wanted to investigate cache invalidation, a.k.a. “unmemoization”, some more. Scratch that. Make that three people: I wanted to try it, too.

Here’s my attempt at better unmemoization in Javascript. I’m looking forward to more great feedback! (I really, really need it this time!)
Read more…

Javascript, performance

A Better Javascript Memoizer

May 1st, 2009

Last month, I had the pleasure of meeting tons of excellent and intelligent front-end engineers at JSConf 2009 — the conference for Javascript in Washington DC. If you are a front-end engineer — or even if you write programs in Javascript for back ends, mobile devices, or desktops — you absolutely have to go to JSConf 2010. It’s apparent that Javascript is quickly becoming one of the hottest languages for all environments and applications, and JSConf is the first (and only) conference that deals with Javascript exclusively.

JSConf 2009

Track A presentations from JSConf 2009

One of the Track A speakers was Stoyan Stefanov, a really smart guy from Yahoo. His presentation was about high-performance web apps, but on one slide in particular, I was struck by his implementation of memoization (slide 79 of 87) because he used the function instance to cache the results of the function itself.

If you’re not familiar with memoization, here’s a great overview:

In computing, memoization is an optimization technique used primarily to speed up computer programs by having function calls avoid repeating the calculation of results for previously-processed inputs.

Memoization (Wikipeida)

In other words, it’s a way to cache the results of function calls so that repeated expensive computations or lengthy lookups can be avoided.

Here’s Stoyan’s example:

function myFunc(param){
    if (!myFunc.cache) {
        myFunc.cache = {};
    }
    if (!myFunc.cache[param]) {
        var result = {}; // ...
        myFunc.cache[param] = result;
    }
    return myFunc.cache[param];
}

(Use your imagination to fill in some complex or lengthy task in place of the line with the “…”!)

Again, what struck me was his use of the function instance to cache the results. In Javascript, functions are first-class objects and can be assigned properties just like any other object. But should we do this? It certainly seems like this could cause intractable problems if used widely. Imagine if everybody started decorating functions and methods with properties? (Actually, debuggers such as Drosera and Firebug now use properties on function instances to help identify them in logs and traces. It seems to me we should try not to invade on that space!)

So, of course, I set out to answer the question, “Do we really need to use the function instance to hold the result cache?”

The answer is “No”. It’s really quite easy to avoid, too.
Read more…

Javascript, performance

Hi-performance Javascript Tips #3: Less is More [Updated 2009-04-09]

April 9th, 2009
Comments Off on Hi-performance Javascript Tips #3: Less is More [Updated 2009-04-09]

This should really be Tip #1 since it’s the most critical of all. Let me just say this as clearly as possible:

Your fastest Javascript projects are the ones that have the least Javascript!

Sure, Javascript engines have matured. Safari’s Nitro, Chrome’s V8, Firefox’s TraceMonkey, and Opera’s Carackan all kick some serious butt. (IE8’s JScript, unfortunately, still sucks wind.) However, routines written in C++ still run orders of magnitude faster in most cases.

Don’t write Javascript to do something your browser already does at compiled-code speeds.
Read more…

dojo, Javascript, performance

Debouncing Javascript Methods

March 20th, 2009

Back in 2006, I was the lead front-end architect for a mission-critical Web 2.0 application. Yah-yah, aren’t they all mission-critical? Yes, but this one really was critical since it was one of those make-or-break moments for the product. What made this project really interesting were the unrealistic expectations the product managers had of web apps.

Sometimes, pressure like this can lead to creativity and innovation. On this occasion, it helped me reach back in to my electrical engineering coursework to apply a hardware concept to software programming.
Read more…

dojo, Event Handling, Javascript

Hi-performance Javascript Tips #2 «Revisited»

March 19th, 2009

In a previous post, we recreated a simple version of Java’s StringBuilder:

var StringBuilder = function (str) {
    var _stack = str ? [str] : []; // str == initial string to start, if any
 
    // append can take one or more strings as arguments
    this.append = function () {
        _stack.push.apply(_stack, arguments);
        return this;
    }
 
    this.toString = function (separator) {
        return _stack.join(separator || '');
    }
}

Unlke Java’s implementation, we’ve added a separator parameter to the toString() method. This would be very helpful in creating HTML or CSV using our object.

I was thinking it would be fun to add a few more features of Java’s StringBuilder onto our decidedly simple example. Here’s how we could add a separator property and a length property (with setter and getter):
Read more…

Javascript, performance