Alex Sexton

Third Party Front-end Performance

2012-04-11T14:36:00-05:00

I work for a company called Bazaarvoice. Our core products (Ratings and Reviews is our biggest) are all implemented as third party javascript applications. We are white-label, so you don’t see a ton of our brand around, but we power the User Generated Content (UGC) behind Walmart, Samsung, Best Buy, Proctor & Gamble, etc, etc. Needless to say, we have one of the highest volume third party applications on the internet. Fun stuff. There are other massively successful and smart companies doing similar things (take a look at Disqus or even peek into the Google or Facebook button code).

Performance Matters

Our core applications were built nearly 7 years ago, and gained features everyday over that period of time. As you can imagine, performance started to suffer. Since we’re on the product page of major retailers, we knew that this wouldn’t stand. I was tasked with re-thinking our solution with performance at the forefront of our architectural and deployment strategies. I attacked three different types of performance at varying levels of depth.

Network
Injection/Rendering
Application

Bazaarvoice has a developer blog that I sometimes write for, so I wrote an article on Third Party Front-end Performance. Normally I don’t just link across, but I think this information is actually fairly applicable to a large chunk of developers. So check it out. Feel free to comment either place. Part 2 and 3 to come.

The UX of Language

2012-03-28T00:13:00-05:00

I once read a tweet ~~that I haven’t been able to attribute back to its original source~~ (Paul Irish has sleuthed and found the original source to be a Greg Brockman tweet), but said something along the lines of

Web development is the art of finding more complex ways to concatenate strings together.

I think that there’s a good reason for this.

As we turn to the next chapter of the web and start building more web applications, rather than just web documents, we begin to need to mix language with data. This presents an extremely difficult challenge if you only have to consider a single language. Often times we have to support many.

While the data density in language increases on our sites and apps, we must consider the user who has to read those sentences. The goal is to offer interesting data to the user without just generating a table and without sounding like Borat writes the copy. You can spend as much time as you’d like on the interaction and visual design, but if your app doesn’t have a good flow, you’re leaving the most important cards on the table: the content.

Let’s Focus on English for a Second

Number of Results: 15

in Number of Categories: 3

This is the type of language that we’ve all come to expect out of the web. It gets the point across, but I’d argue that it’s not very personal or natural. That may not matter in this particular example, but consider building anything social. Identity is becoming a huge part of the next wave of apps. If you want to have any chance at personalization or identity, then the following isn’t going to cut it:

Alex added 5 friend(s) to their group on March 19, 2012

This is in stark contrast to some of the more popular social networks.

Not only does this correctly address the correct pluralization for ‘people’, it also takes into consideration the offset from the total count of the 3 people that are listed explicitly. This attention to detail doesn’t stop at decent pluralization, but also gender.

Remember the old days when Facebook used to refer to everyone as a ‘their’? That was weird. Don’t fall into that trap. When it comes to good user experience, you can’t ignore the text. If you can go through your app and find any sentence that you’d write differently if it wasn’t generated by a computer, you are reducing the effectiveness of that text and degrading the overall experience.

Iteration

Assuming you’re sold on the idea of a proper language treatment of your app, let’s try to solve the problem using some of the examples we’ve already seen.

There are X result(s)

In JavaScript, the naïve solution would be to do something like the following:

if ( X === 1 ) {
  return "There is one result";
}
else {
  return "There are " + X + " results";
}

This results in a proper english sentence in all cases. That’s great, but let’s get a touch more complex. Now we want to support another language. The pluralization rules for English are different than the rules for French. If we want to support French, our solution starts looking more like this:

if ( lang === "en" ) {
  if ( X === 1 ) {
    return "There is one result";
  }
  else {
    return "There are " + X + " results";
  }
}
else if ( lang === "fr" ) {
  if ( X > 1 ) {
    return "Le, there are " + X + " results";
  }
  else {
    return "Le, there is " + X + " result";
  }
}

This quickly becomes an unscalable solution. You might be thinking “Well, Alex, I never plan on internationalizing my app, so the rest of this article doesn’t apply to me.” - I’d encourage you to consider the original example as a more pleasant English-only sentence:

There are 8 results in 2 categories.

Even when ignoring locale, we still have some combinatoric debts to pay. Let’s check out the code for handling this naïvely:

if ( ResCount !== 1 && CatCount !== 1 ) {
  return "There are " + ResCount + " results in " + CatCount + " categories.";
}
else if ( ResCount === 1 && CatCount !== 1 ) {
  return "There is one result in " + CatCount + " categories.";
}
else if ( ResCount !== 1 && CatCount === 1 ) {
  return "There are " + ResCount + " results in one category.";
}
else if ( ResCount === 1 && CatCount === 1 ) {
  return "There is one result in one category.";
}

This is pretty painstaking even without the chore of translating it into other languages. You cannot split up the halves of the sentences safely (especially if you want multiple languages), because the two halves may not match. You can imagine that when gender is added to this sentence, things explode even further.

Alex searched for an image. He found 5 results in one category.

Now we have to multiply that logic times the number of gender choices. Most specs have 3 gender choices: “male”, “female”, and “other”. “Other” specifically is treated “as if you cannot determine the gender of someone who is far away from you.” In the case of this simple sentence, we’d need twelve copies of the sentence - one for each combination of gender and plural form of the nouns.

Gettext (jed)

I recently released a library, Jed, for using Gettext style messages in JavaScript. Gettext is a GNU spec that’s been around for ages. I had been exposed to a little bit of Gettext from my python days, and considered it to be the most popular solution to many of these problems. The main feature of Gettext is that you can decouple the messages from the plural-forms of a given language.

var pluralForms = {
  "en" : function ( x ) {
    if ( x === 1 ) {
      return 0;
    }
    return 1;
  },
  "fr" : function ( x ) {
    if ( x > 1 ) {
      return 1;
    }
    return 0;
  }
};

We now get back an index of sorts. “Gettext” refers to the lookup/loading/encoding mechanism more than anything, but with these plural forms we could do a lookup for the correct string, stored as data.

var translations = {
  "en" : {
    "somekey" : [ "There is one result.", "There are %s results." ]
  }
  "fr" : {
    "somekey" : [ "Le, there is %s result.", "Le, there are %s results." ]
  }
}

var lang = "en";
var msg = sprintf( translations[ lang ][ "somekey" ][ pluralForms[ lang ]( X ) ], X );

In this case we’re using sprintf style replacement after we do the key lookup. That tends to be the most common way to do substitution with Gettext. Now we have a solution that relies on data instead of one-off code blocks for each message. Also, if your sprintf supports positional variables, you can now solve the problem that different languages order sentences differently than english does.

Soon after I released Jed it was shared on es-discuss. Immediately Norbert Lindenberg stepped up to tell me that I was making a mistake by choosing Gettext. How right he was. The best example of my oversight is actually one that we’ve already seen:

There are 8 results in 2 categories

How would we represent this in Gettext’s PO format? The plural-form functions can only take a single number to decide the plural form. This sentence would need to be split up again, which won’t work across languages and often won’t work well even in English. Gender can be added in by utlizing Gettext’s context feature, but it only goes one level deep. What if I needed an actual context AND a gender selection?

Norbert was kind enough to point me in the direction of the ICU MessageFormat spec. I could quickly see that some smart people had thought about this a lot longer than I had. Using Jed for Gettext can still be nice if you already have invested in using Gettext in other parts of your stack, but I’d generally suggest against it in favor of MessageFormat.

ICU MessageFormat

MessageFormat is actually just a few specs pasted together, but they look similar. They may seem vaguely familiar to those who have ever used Java’s ChoiceFormat utility. They are different in a few ways, but the important part is that they more or less solve multiple plurals and gender specificity without as much of the combinatorics game.

The MessageFormat spec contains PluralFormat and SelectFormat in the most common cases. Using the syntax in PluralFormat we can address multiple plurals in the same sentence. All the pluralization data is standardized and pulled from CLDR and not needed as user input. There are keywords that come back as a result for any given input number: “zero”, “one”, “two”, “few”, “many”, “other”. All languages can be roughly mapped to these keywords, and it is the basis for some of the keywords in the message.

I won’t go in to much detail about the syntax, as that’s not the point of this post.

PluralFormat

There {ResCount, plural,
        one {is one result}
        other {are # results}
      } in {CatCount, plural,
        one {one category}
        other {# categories}
      }.

Using PluralFormat we were able to decouple the pluralization of each of the nouns.

SelectFormat

Gender is usually handled via SelectFormat which works much like a switch statement (except default becomes other).

{GENDER, select,
  male {He}
  female {She}
  other {They}
} just found {ResCount, plural,
        one {one result}
        other {# results}
      } in {CatCount, plural,
        one {one category}
        other {# categories}
      }.

At the top we are able to determine the gender to use and then reuse most of our code from above to have a multiple plural and gender-specific sentence in as few characters as possible. Exceedingly complex sentences can often still require nesting and combinatorics, but for the majority of cases, you can avoid repeating any logic.

There are also complex ‘plugins’ that can be used. The offset option will help you generate sentences like in the google plus example earlier.

NumberFormat

Technically, I don’t think NumberFormat is part of MessageFormat - but it is usually necessary to pull in. NumberFormat allows you to internationalize things that we haven’t even covered yet. Ever consider that other countries use , characters where the US uses . and visa versa? Number format is how you handle numbers, percentages, and currencies across languages.

1234.5       //Decimal number
$1234.50     //U.S. currency
1.234,57€    //German currency
123457%      //Percent

Tools

messageformat.js

Shortly after releasing Jed, I released messageformat.js. It’s a much less sexy name, but perhaps I’ll fix that soon. Google also has an implementation for people using the Google Closure library: http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/i18n/messageformat.js.

While both are likely to be sufficiently fast, I did implement messageformat.js as a compile to JS language. This means that at build time, you can ‘precompile’ your messages and ditch the majority of the library. This creates some great opportunities to be able to include MessageFormat style strings directly inside of your precompilable templates and have it all compile to a series of string concats. The readme on the project page should be quite helpful to learn the syntax as well as the integration and api.

numberformat.js

My co-worker Oliver Wong was able to do a quick port of the Google Closure NumberFormat.js to not need Google Closure (under Apache 2).

EDIT: moment.js

If anyone was wondering how I handle dates in my JS apps, I figured I’d add it here. Moment.js, by Tim Wood is a library that I lean on a lot. There are plenty of additional internationalization libraries that I could start adding (for collation and rtl, etc), but for right now, the built in localization, and friendly ago syntax of moment.js make for a great user experience around dates.

All Together Now

I plan on updating Jed to actually contain this group of tools rather than the Gettext ones. I think these tools better suit the needs of modern applications. I will certainly keep the old Jed (Gettext) code around for those that require that format. It’s not terribly difficult to integrate with these tools separately now, though.

Conclusion

Language is important. It can get complex. A lot of incredibly bright people have been looking into the constraints of same-language message generation, as well as multi-langual message generation (the spec writers, not necessarily the library creators). These tools and/or ideas should be the starting point of any application that desires to have a good UX.

It doesn’t matter how many drop-shadows or rounded-corners you have, the user shouldn’t have to decode your words. The words are often the most valuable experience.

My Thoughts on AMD

2012-03-22T23:08:00-05:00

So I know it was cool to write blog posts about AMD (A CommonJS JavaScript Module Specification) like a month ago, but I’ve recently had the desire to put my two cents into the discussion. I am likely not entirely objective - as I frequently use RequireJS and have even committed tiny little parts to the project that James likely had to rewrite. I would like to point out up front, though, that AMD !== RequireJS. RequireJS is an implementation of AMD plus a whole ecosystem of usefulness.

I recently had some in-depth discussions with Tom Dale who wrote a pretty popular article against AMD. Tom is a good friend and I respect all of his opinions. I wouldn’t say that he’s since ‘come around’ on the AMD issue, though I may have worn his desire to fight against it. I’ll take what I can get. His business partner and all-around web-tech badboy Yehuda Katz remains less convinced and sent me a few questions that he wanted answered. I won’t add them here verbatim, but I’ll try and touch on a lot of that stuff as well. I think we more or less agree these days (but he by no means necessarily endorses what I’m writing here). I’ll explain.

I’m going to opt to try and not rehash the great responses to Tom’s concerns by James, Dave, and Miller.

AMD is not a script loader

This misconception is likely propagated by the fact that RequireJS shows up on all of the script loader shootouts. I have written most of my thoughts on this already in my most popular (read: only) Quora answer: What are the use cases for RequireJS vs Yepnope vs LABjs. I’ll mostly just leave it at this: Script loading is a means in which AMD/RequireJS meets their requirements. It’s neither a focus of the project or an integral part to using AMD in production.

AMD makes async loading possible, not required

I often hear that people don’t have an interest in asynchronous modules. This is perfectly fine. There are tons of integrated systems in full stack web frameworks that do a lot of great things for preprocessing that just don’t require asynchronous script loading to be great.

AMD is also so other people can include your module asynchronously.

So if you have your app split up into modules via some preprocessor system, that’s fine, but if you’d like your code to be accessible to people who don’t run the exact same stack as you: AMD works everywhere.

So write all your code how you like it, and right before you release it on github, consider adding this:

if (typeof define === 'function' && define.amd) {
  define(function () {
    return TheModule;
  });
}
// Feel free to also leak the global and/or test for a CJS enironment.

And to take this a step further, I’d encourage the preprocessing systems to just process to AMD.

// Node style modules
var x = require('x');
var y = require('y');

var res = doSomething(x, y);

exports.module = res;

Instead of preprocessing this code to work on the web by just concatenating the globals in the correct order, why not just use AMD? It could easily be translated at preprocess time to:

define(['x','y'], function(x,y) {
  var res = doSomething(x, y);
  return res;
});

Now you have a module that anyone can pick up (and translate it into their own module format if they’d like).

The problem with using anyone else’s format is that AMD is the only format that is suited well for asynchronous loading. This is not important to one group of people, but it is important to a different group of people, and is a valid concern in web development. In this case, AMD is the inclusive module format.

As for ‘synchronous’ module loading with AMD, the api must use the asynchronous pattern, but if a module is already registered, the result is atomic. Not to mention that it’s perfectly valid to use the require('x'); syntax when you can be sure a module already exists. The syntax allows for asynchronous loading, but it doesn’t require you to load things that way.

If you don’t like parts about AMD, and prefer to preprocess, that’s fine. I would encourage you to process to AMD though. Much like JavaScript is a common compilation target, I’d like to see AMD become that as well, for modules. It won’t help when in 5 years every project handles modules with their own preprocessor format.

AMD requires preprocessing anyways, right?

Yep, but not until build time. Any sane user of RequireJS uses the amazing r.js build tool before pushing to production. So why not just preprocess on request and output “modules” in the correct order and wrap them in a big IIFE?

It would likely work, but in my opinion there is value in being able to develop directly out of a folder, with only static resources. It’s the reason that so many new developers are using LESS.js - just load the file and go. It doesn’t require you to install a watcher, or set up rails, or even learn how to install an additional whole programming language to your highly varied OS landscape. AMD works without all the stuff. It is a developer experience with immediate gratification.

Many people disagree with the sentiment that our tools should all be able to run on the client side in order to facilitate the idea that our web pages can run out of static directories. I definitely agree that there are tons of uses for preprocessors that run outside of the browser, but I don’t fundamentally agree that modules are part of the ‘just nice to have if you can figure out the watchers’ group of tools. Real modules are going into browsers soon, and I think they should be part of the first class citizen group of tools that we run in our browsers. Not to mention, if you do opt-in to using a pre-processor and you want someone else’s preprocessor to be able to understand your modules, you’ll have to agree on a standard compilation target anyways. What better than AMD?

Much of what James writes about in his posts are about how there are a few ‘meh’ things about AMD, but that it meets nearly every requirement of a module system better than any alternative. He doesn’t often mention AMD as a compilation target, but I think it solves everyone’s problems.

It’s not nearly as ‘complex’ as you think it is.

AMD is implemented by attaching a scriptloader to an object. Load something, store it in the object, if someone else asks for it, pull it back out. Much of the size in RequireJS is for other amazing features and developer tooling. You can switch out RequireJS in production with Almond - it is 857 bytes.

The other notion is that it’s a chore to write. If we ignore the fact that most modern code editors could easily store the boilerplate for you, I would argue that it’s actually less characters than not doing it. Also, (nearly) everyone who says this also complains that it forces them to nest their code an extra level, and then they turn around and immediately wrap all of their code in an IIFE.

// An IIFE for leakage. One level of nesting.
(function(){
  // require statement per dependency
  var x = require('path/x'),
        y = require('path/y'),
        z = require('path/z'),
        a = require('path/a');

  doStuff();
  exports.module = { ... }; // if you're doing more commonjs type stuff, not always
})(this);

Here’s the same AMD module:

require([
    'path/x',
    'path/y',
    'path/z',
    'path/a'
], function ( x, y, z, a ) {
  doStuff();
  return { ... };
});

~36% less to type, by my quick and dirty measure (stripping whitespace and counting chars). It can be even less if you don’t have any dependencies and just include a define at the end of your file like we did in a previous example.

Sure there’s a level of nesting, but it’s one that you’ll need to put there regardless of whether you’re using AMD or not. Sure that can be generated at request time, but so can the AMD callback function boilerplate.

Why not just polyfill ES6 Modules?

Well, first off, they’re not entirely baked. David Herman - the author of the original Module proposal - just posted a pretty delicious update for some ideas for a simpler and sweeter module syntax.

Secondly, I think it’s a great idea. As soon as the syntax settles back down I think we could all consider setting up preprocessors to allow for the syntax in the browser. This would require a request-time preprocessor because of the invalid nature of the syntax. So if you were able to run a preprocessor, then I think you should use the ES Harmony Module syntax. I think it should then compile to AMD, obviously, but you shouldn’t ever have to worry about it.

Quick RequireJS plug

I obviously like AMD a decent amount, but I also think RequireJS is a fantastic tool in my stack. The ‘plugin’ architecture is not incredibly well-documented, but it essentially acts as module middleware. My favorite application of this feature involves templates.

I use the pattern in my require-handlebars-plugin to great effect. Rather than require a precompiled template during dev mode, I simply prefix my module name, and the template compilation occurs before the callback is invoked.

// In a no template middleware world
require(['handlebars', 'text!someTemplate.hbs'], function ( Handlebars, strTemplate ) {
  var fnTemplate = Handlebars.compile( strTemplate );
  fnTemplate({"some": data});
});

This is also similar to the technique where templates are stored in type="script/tmpl" script tags and pulled in by their id. This means that if you want to compile your templates at build time, you need to fundamentally alter every location that retrieves a template.

With the hbs template plugin, this is handled for you.

// With require-handlebars-plugin
require(['hbs!someTemplate'], function ( fnTemplate ) {
  fnTemplate({"some":data});
});

During development, this loads the template in as text and precompiles it for you. At build time it automatically outputs a precompiled module that is concatenated into the build. This ability alone is like magic to me and I just wanted to tell everyone how much I like it.

Conclusion

You don’t have to like AMD more than whatever you use. It would be nice if we had a standard, compatible web module syntax though. I think AMD is the best-suited candidate for that role, and that the preprocessors should use AMD as a compilation target, rather than a direct competitor. Obviously it’s still cool if you just use it straight up, but that doesn’t need to happen for it to succeed.

Uselessware :: A Brief History (JSConf 2011 Talk)

2012-03-20T01:15:00-05:00

I felt like linking up this talk that I gave on Track B of JSConf in Portland this past year. I feel passionately about the value of writing code that serves no useful purpose other than to bring joy and skills to its implementors and users.

The talk is pretty short :D

A New Blogging Engine

2012-03-19T00:21:00-05:00

All the cool kids are staticly generating these days. I’m in.

Breaking The Cross Domain Barrier (Screencast)

2011-06-06T00:00:00-05:00

I decided to try my hand at doing a screencast. I have been told my old cross-domain talk slides have always needed a little more context, so I did that. Hopefully I’ll get in the habit of doing these, they’re not so difficult. Enjoy!

Breaking The Cross Domain Barrier from SlexAxton on Vimeo.

Breaking The Cross Domain Barrier (or half of it anyways)

2010-11-30T00:00:00-06:00

I gave a talk at TXJS and AustinJS about cross domain communication in JavaScript. Here is a video that stopped halfway through that talk.

Breaking The Cross Domain Barrier from yayQuery on Vimeo.

The slides are available here:

Breaking The Cross Domain Barrier

View more presentations from Alex Sexton.

Sorry for the half-vid, and low quality, but I figured it was worth putting out there, as I’ve had a few requests for it and I’m running out of hard drive space. Perhaps with any pressure, I’d do a screencast.

Also, this was the day that I took two green nyquil pills thinking that GREEN meant DAY (for dayquill). So I may be a little more relaxed than normal. I’m sure the beer didn’t help either. I rather liked it, if I recall.

An Accessible Way To Stop Your Content From Flashing (FOUC)

2010-09-28T00:00:00-05:00

There are a lot of different reasons why you might see content flash on your page before it’s done loading. The flash that I’m talking about usually happens when you are trying to build a JavaScript widget that gracefully degrades when JavaScript is off. You probably feel pretty cool about yourself for writing your JS in an accessible way, but you are sad that it hurts the user experience.

One of the most common examples of this situation happens with tabbed interfaces, and more specifically the jQuery UI Tab widget. You give it your group of divs and links to turn them into the tabs, but that code doesn’t run until domready. Before the dom is ready, you’re original content all shows on the page, then when the tab code runs, it gets hidden.

Please don’t set them to hidden in your CSS in order to stop this from happening. This hurts accessibility, SEO, and the laws of white-hat web development, because without JavaScrpt, this content can never be seen. Instead, try this little trick:

<style type="text/css">
/*
Obviously this is not a real class name, but here you would just
set all the elements you want to hide as display:none.
You should probably make this style whatever the JavaScript ends
up setting them to. That way you don't accidentally add weird styles.
*/
.stuffIDontWantToFlash {
  display:none;
}
</style>

<noscript>
<style type="text/css">
/*
Inside of this noscript block, show the elements, this should behow
you want it to look for people without JS - it could even be styled
totally different for them if you'd like to lay it out differently without
tabs...
*/
.stuffIDontWantToFlash {
  display:block;
}
</style>
</noscript>

So there. Now we’re using the noscript tag to conditionally override our CSS hiding of the elements. You can technically do this with link tags as well, but since you need to put the noscript version in a separate place than the original style (which can be anywhere), it’s probably not worth the extra http request. Just make sure the noscript override version runs after the initial setting. Cascading at it’s finest.

I know what 2 of you are thinking: “OMG Gross. This does not validate, because a style tag can’t be anywhere except in the head element” - well, you could put it in the head element, but that could be weird. In other words, I don’t really care. It works everywhere.

<3z

Alex

What I Learned about the Google Chrome Store

2010-09-18T00:00:00-05:00

While traveling in Europe this week, I had the pleasure of going to a Google Chrome developer event put on by Mike Mahemoff (The Moff™) and Paul Kinlan (whom Paul Irish says is a genius, so that’s a good start). I took some notes during the meeting. I didn’t know tooo much about the chrome app store, so I figured I’d post what I learned in a very digestible manner for anyone who’s googling for the right keywords next week.

A bulleted list of things I learned at the meetup (other than how strong The Moff™ is in real life):

Here were some slides for the night: http://3.ly/y2dd
No date on the official release of the store but apparently “Coming soon”
There will be a free and a pay model, but the pay model is only launching in the US (then other markets to follow)
There will be a way to do billing monthly/yearly/onetime (paypal (“harder”, not sure of the specifics)/googlecheckout)
There will be an API to see if the user really bought something
5% of your revenue is theirs, rest is yours (yay) (way better than 30% - wowy)
Apps aren’t chrome specific. They say they’d love to make stuff work cross browser, but they are going a little bit different direction from W3C widget spec…
Pay to install
You install apps directly into the browser
There will be a user-permission popup for (location, notifications, storage, etc)
Open now… I guess this means you can build stuff that works as a chrome app already (but there’s no store)

—————–Second Half——————-

Apps different than websites (even though theyre both web)
You CAN use flash/silverlight/java if you want, but they don’t auto install, so if the user doesn’t have them, you’re SOL
Google hosted (if you want)
If you go Google hosted, they are packaged (let’s get a spec for this going!), if not, just a URL and a manifest

I stopped taking notes at this point to actually build a chrome app. It was insanely easy, so I’m happy about that. Yay chrome apps. I’d love to see how these pan out. I don’t think it can work until they are cross-browser, etc, but half the fun of them is that if it’s a chrome app, it doesn’t have to work in FF, so you can use specific APIs… so it’s a tradeoff.

Aiight. Tried to keep that as informal as possible. Hope someone wanted this info!

Alex

On "Rolling Your Own" Large jQuery Apps

2010-08-16T00:00:00-05:00

As a preface, make sure you’ve read my super-smart and talented yayQuery co-host Rebecca Murphey’s blog post on this topic

here: On jQuery Large Applications and here: On Rolling Your Own.

Rebecca points out some huge holes in the jQuery-verse when it comes to large-application development, and gives her opinion on why she doesn’t think jQuery is ever a good fit for a large application. I disagree, and she’s successfully convinced me to write a post on why I think what I do, so here we are.

Also, please, no one point out that I prefer Django over Pylons, which is essentially the same argument :D . The difference, though, is that I think Pylons is awesome, and that people should totally be using it for large applications on the backend, as long as they prefer it!

First, I will start by mentioning that I have written several large applications using jQuery, and that I think that from a ‘framework’ perspective, something like Dojo (which Rebecca supports) or YUI3 serves as a much better core to a large application than jQuery. However, arguing that ‘you shouldn’t use jQuery in your large application’ is an entirely different topic. jQuery does not describe or prevent any framework of application development, so you are free to choose your own to suit your needs. I do not advocate the incorrect use of jQuery as the core of your application. I do advocate JavaScript at the core of your application, though.

jQuery is a tool (lolz)

I build large applications that use jQuery. I don’t build large applications on top of jQuery. This incredibly important distinction hasn’t been very well clarified thus far in the conversation. I think it’s a fair ambiguity, however, because while it’s possible to use jQuery in well-structured ways, it’s certainly the road less travelled. The ‘common jquery user’ tends to throw everything onto the jQuery namespace, and pull in everything as plugins, and generally very tightly couple their applications to jQuery. I think the distinction is still important for the argument, because it doesn’t rule out the fact that you can write some really nice applications using jQuery.

It’s not jQuery, it’s you.

I think the thought that people are incapable of using jQuery in this manner stems from quite a few bad consulting experiences with companies using jQuery for no reason other than the fact that it’s the cool thing to do, but using it entirely in an entirely backwards manner. This is also not a good way of making library decisions (at least in the long term). It doesn’t reflect poorly on the code in jQuery so much as it reflects poorly on either the messaging from the jQuery team, or just the general population’s inability to write good code and tendency to do what’s popular. However, if Dojo were the hip-cool-designer library, they would suffer from the exact same problem.

Any library, in the hands of people who don’t know what they’re doing (even FuseJS), will not serve the needs of the application. This is a reality for anything that becomes popular. It’s easy to like Dojo for the quality of code that comes out of it, but that’s because the significantly less amount of people who use it are really good JavaScript Developers. That’s important.

Being a good JavaScript developer before you start writing your application is the key to building good large applications. It’s not what library you use. This is why I write about inheritance in JavaScript for the majority of my large jQuery apps articles. It’s the JS people need to learn. In fact, I’d imagine there’d be some insanely backwards code from people using Dojo who didn’t know what they were doing. You have to remain level-headed, though, and try to evaluate the tools without bringing in your past experiences with other developers. You can certainly choose Dojo to get away from jQuery noobs, but recommending Dojo to jQuery noobs is just bringing your problem along with you.

Roll it.

Aiight, with all that out of the way (yikes), let me give my most objective reasoning possible for why I think it’s ok to use jQuery in a large app. Please keep in mind that I’m not advocating against Dojo or YUI3, I’m advocating against the absolute notion that ‘jQuery should never be used for large applications.’ Use what you prefer, of course.

Rebecca’s core argument against rolling your own jQuery large app is that 1) no one else knows your code-base, so supporting is harder, and 2) the solutions in a library like Dojo are built to work together by smart people who have thought long and hard about the problems, and rolling your own are more fragile and can cause issues with upgrade paths and compatibility, etc. These are valid points, but I think they are painted with a narrow frame of reference for the type of app structure you might use in a large jQuery app.

It’s common knowledge that a separation of concerns is key to any large application. Loose-coupling is something that I’ve blogged extensively about in the past. If you have a problem updating a portion of your application, it’s because you wrote it too coupled. This is not unique to jQuery. Dojo’s API stays about as backwards-compatible as they come (seriously), but that doesn’t mean your old code will just work. In fact one of the few experiences I’ve had with DojoX code is that some of the less popular DojoX modules often need changes to return the correct values, or not throw errors. The core of the library, has been significantly more impressive in regards to this, but we’re talking about code that you write, not the library core. I am a fan of Dojo’s backwards compatibility efforts over jQuery’s. Changing an API in a point release isn’t always the most friendly change for devs.

Her list of requirements for a large app is well considered. It is a comprehensive list of things that often come in handy when building a large application. All of these things have been answered by smart people, in the JavaScript community. Much like her example with templating, you can decide which pieces to use (except, directly, not with library specific code…). Instead of overriding Dojo.templated you just change out the contents of your template rendering function with the new one. If you correctly loosely-coupled your application, then ‘yay’, you switched out a part of your app in less lines of code!

Here’s the list of things that she’d expect from a framework, along with the appropriate solutions I’d consider:

DOM manipulation tools - jQuery core
Ajax tools - jQuery core
A dependency management and build system - RequireJS
Clear patterns for code organization, such as namespaced modules - The module pattern and a few object literals
An inheritance system, preferably one that offers multiple inheritance, for sharing code across modules and staying DRY - modules +$.extend
A non-DOM-centric, loosely coupled API for communication between modules - pub/sub || custom events
A widget system that makes use of the inheritance system, with lifecycle management (setup/teardown) and templating - $.fn + mustache/microtemplates
A system for maintaining templates separate from JavaScript while interning them into the build to eliminate HTTP requests - <script “text/html”> + text!requirejsdependency
A system for abstracting RESTful server communication - assumes you want REST - but $.ajax usually works anyways…
For a UI-intensive project, a rich widget system pluggable to arbitrary data sources and designed with an easily-extended API - jQuery UI or ExtJS on jQuery
For an enterprise project, a11y and i18n provisions, as well as clear patterns for file organization - jQuery UI has many of these, you can also build them in. Require dictates some directory structure.

These requests are pretty obviously skewed to someone who likes working in Dojo. They are all pretty awesome ways to do things, but to say that you needed the module pattern is to entirely overlook other very valid ways of structuring complex code. Of course Dojo offers ways to do things like event-oriented programming over object-oriented. The point here is that, if Dojo has answered every question, and jQuery and friends has also answered every question (perhaps not in the same place), it’s going to be just as hard to pick up the code base and figure out what’s going on. I could structure my Dojo app in a way that Rebecca doesn’t like, and use template overrides for template-languages that she despises, and I could tightly couple my dom elements and their attributes to my data, and it’d all be in beautiful Dojo. That Dojo has answered all the questions does not facilitate that you understood those answers or that you agree with them.

The positives

I somewhat reject the notion that using jQuery, Underscore, Require, Mustache, and the module pattern (as facilitated by Require) is “rolling your own.” Sure you piece them together, by choosing how you use them, but you do the exact same thing when you choose how you use the various parts of Dojo. I think that all of these tools are as strong as the Dojo alternatives. You can argue that you could use any of these tools with Dojo because it’s so flexible that you can put anything in, but then you can’t argue that ‘rolling your own’ is bad, because that’s what you just did. Either use Dojo, or agree that sometimes, it’s not that bad to pull in a different way of thinking, you can’t have it both ways.

jQuery normalizes things across browsers when you need it to, and serves as a mostly-fantastic way of doing dom-manip and ajax. If you use it according to it’s strengths, you still can choose some really strong software alongside it that was specifically designed to be awesome at what it does.

Underscore gives you a very solid utility library, much like you’d find in Dojo, and it’s extensible to boot. You can use it in two of the major paradigms natively, and it falls back to native implementations when it can. It’s hardly fragile, and it’s insanely easy to integrate into your project. It’s no worse or better than Dojo’s offering.

RequireJS is likely going to be used in Dojo 2.0 and James Burke, who wrote Require, also wrote most of the Dojo dependency management system. Require incorporates all the sweet stuff from Dojo, plus some really awesome future stuff coming from the CommonJS peeps. Some apps, though, don’t require a ton of dependency management. Single page apps are likely not going to be terribly dependency heavy, and if you want… you can leave out the dependency management system all-together, and still use your modules, just like you always wanted. You can switch it out for LabJS if you want speed too.

Templating was the example that Rebecca used to show that she could roll her own templating style in Dojo. She used mustache instead of the default Dojo offering. I can’t argue against that. I’m in favor of pulling together the correct tools for the job.

A lot of what is nice about Dojo, is it’s prescribed format for creating modules. There’s quite a bit of flexibility, but anyone who could understand the way that Dojo does this could easily understand some of the basic underlying patterns that it’s enhancing. I can use object.create and the module pattern to my hearts content to structure my app, and that’s not some ‘wild tangent’ that no one will ever be able to unravel. It’s a simple, and common pattern that you’d be required to understand to use the Dojo method. Sure there’s no prescribed way to exactly structure this, but that’s the case with the ‘extremely flexible’ Dojo offering as well.

I’m not advocating creating super complex alternatives to Dojo’s module structure. I think JavaScript offers a simple and flexible interface to creating and manipulating objects. I can choose which ever way I’d like. The module pattern is 2 pages of of text and code examples in The Good Parts. Just go read that.

TL;DR

Dojo is a fantastic library that I would encourage you to pick up and add to your skillset. jQuery can be a fantastic tool to use as well. “Rolling Your Own” application with good tools alongside jQuery is no harder to understand than a Dojo app, nor is it harder to support, and it’s likely more specific to your needs. The fragile part of your code isn’t in the tools you use, it’s in the code that you write around them.

I wish we’d focus less on whether jQuery or LibX was a good or bad choice for large applications, and focus on the fact that people who don’t know JavaScript are never going to write well-structured apps. Anyone who does understand the fundamental concepts behind JavaScript would be able to do it well with or without Dojo. Your language should provide your structure, and your toolkits should dictate your tools on top of that structure.

Learn JavaScript first. Then care about large apps. Then make a smart decision, according to your preferences, on which, if any, library you want to use.

-Slex

TXJS and ScriptJunkie

2010-06-10T00:00:00-05:00

I have been pretty neglectful of my blog since I started at Bazaarvoice, but I think I’m going to try to pick up a little bit. That being said, here’s a short update.

I am now a featured author on ScriptJunkie - a new website from Microsoft about front end development. Check out my post “Building and Maintaining Large JavaScript Applications”

I’ll likely cover a few more topics concerning large application structure in the future, both on my blog and on yayQuery and ScriptJunkie.

Also, TXJS happened. I’d suggest going to the totally awesome webpage and catching the slides and the speakerrate pages for all the talks to get caught up on how much awesomeness happened. Also, my fridge is still full of left over beer, so if you’re in town… beer.js at my place.

Superclassy Inheritance with JavaScript Video

2010-03-10T00:00:00-06:00

Here is the uncut director’s edition of my talk given on February 20th, 2010 concerning Inheritance patterns in Javascript. Please forgive the rambling, and the bit of extra footage on either end of the talk.

Superclassy Inheritance with Javascript - Alex Sexton - NCJS 02/20/10 from yayQuery on Vimeo.

<3z

Using Inheritance Patterns to Organize Large jQuery Applications

2010-02-25T01:27:00-06:00

I want to introduce/reinforce a pattern for developing large applications with jQuery. I did not invent any of this, but I find that the resources that describe this technique are few and far-between.- so I’m taking a shot at it.

By and large, when using jQuery, developers seem to forget the paradigms they learned for well structured code in other languages. This is likely due to the fact that jQuery is effectively neutral when it comes to your structural methodology or inheritance patterns, and therefore doesn’t push someone in any one direction. Many times in other libraries (See Dojo Declare/Provide/Require, or MooTools Class, etc.), a paradigm is used and exclusively offered, and then code generally ends up more uniform than the oh-so-common-massive-jquery-indented-chains that I’m sure you’ve seen .

I’m not going to necessarily suggest that you use any single inheritance pattern, as there are many options, and each makes sense for different people and different situations. I do however suggest that you know your options. There are a few good reads on the topic of Inheritance in javascript, and I would strongly suggest people read at least a bit of the following:

Javascript: The Good Parts (Chapter 5) -Douglas Crockford
Prototypal Inheritance in Javascript) -Douglas Crockford
Object-Oriented Javascript -Stoyan Stefanov
Javascript Override Patterns -Andrea Giammarchi
Simple JavaScript Inheritance -John Resig

Choosing your form of modularity is an important step. If you come from a background of highly-classical inheritance (I learned Java in school, so…I know that world) then perhaps starting with a classical implementation is going to be your best choice. If you are trying to stay slim and do the things a little more in the “JavaScript way” (a term that means essentially nothing), then you might try to use prototypal inheritance. For my examples, any form of inheritance will at least work on most accounts.

I’ll jump straight to a code example of this technique in use, and then describe it’s setup and structure:

<!-- Just an empty div to begin with -->
<div id="mySpeaker"></div>

Then we’ll run our javascript:

$(function(){
  // Call a custom plugin for your object on a dom element
  $('#mySpeaker').speaker({'name': 'Alex'});

  // Have quick access to the actual speaker object
  var mySpeaker = $('#mySpeaker').data('speaker');

  // The interface of the object that you build can
  // wrap more complex dom manipulations that are
  // separated from actual program logic.
  mySpeaker.speak('I am a speaker.'); // Results in a dom update

  // This shows automatic access to correct element in the dom
});

And the html now looks more like this:

<div id="mySpeaker">
  <h1>Alex</h1>
  <p>I am a speaker.</p>
</div>

The key here is that we didn’t have to call something like $elem.append(‘Alex’) nor did we even have to consider what would happen when a speaker object was called with the speak() function. I consider this to be the key to modular development. This level of abstraction helps keep the how and the what separated (or “loosely coupled” - if you like buzzwords). The other thing that was important to note is that after we instantiate the plugin, we have a clear two-way path between our Object and our Dom Element - both have an easy way to immediately access the other. This is important, because we often have different points of entry to jump-start a routine, so being able to access the part that you need quickly and easily is important.

Implementing this technique is pretty simple, and should actually take less brain power to set up than traversing through the dom in your head to figure out a crazy chain.

Let’s start with the Speaker object.

/**
 * Object Speaker
 * An object representing a person who speaks.
 */
var Speaker = {
  init: function(options, elem) {
    // Mix in the passed in options with the default options
    this.options = $.extend({},this.options,options);

    // Save the element reference, both as a jQuery
    // reference and a normal reference
    this.elem  = elem;
    this.$elem = $(elem);

    // Build the dom initial structure
    this._build();

    // return this so we can chain/use the bridge with less code.
    return this;
  },
  options: {
    name: "No name"
  },
  _build: function(){
    this.$elem.html('<h1>'+this.options.name+'</h1>');
  },
  speak: function(msg){
    // You have direct access to the associated and cached jQuery element
    this.$elem.append('<p>'+msg+'</p>');
  }
};

I use an object literal here which puts me in the Prototypal Inheritance camp, I believe, but this is just an easily digestible pattern.

As you can see, there are easy-to-read, small functions, that have a clear purpose. In our use of this pattern, we call api type methods like speak() but not necessarily an internal method (like _build). You can hide your internal functions either by naming convention (not really hiding them), or by using something like the module pattern. In our simple example, I have just added an underscore to the beginning of the function to indicate that it’s private.

Code that is organized like this is much easier to test and to change/read. This also allows you to change the way things function without changing the way that the Object api is used. For instance, we could change the speak method to alert the string instead of append it to the related element. We would have to change the internals of the speak function, but we could keep our call to it the same.

The bridge that we build is probably the most interesting part of this pattern. It’s a different approach than many of the popular plugins take (slightly different than jquery ui), but it has a few really great benefits.

The most simple way to do this is by hand:

// Make sure Object.create is available in the browser (for our prototypal inheritance)
// Courtesy of Papa Crockford
// Note this is not entirely equal to native Object.create, but compatible with our use-case
if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {} // optionally move this outside the declaration and into a closure if you need more speed.
        F.prototype = o;
        return new F();
    };
}
(function($){
  // Start a plugin
  $.fn.speaker = function(options) {
    // Don't act on absent elements -via Paul Irish's advice
    if ( this.length ) {
      return this.each(function(){
        // Create a new speaker object via the Prototypal Object.create
        var mySpeaker = Object.create(Speaker);

        // Run the initialization function of the speaker
        mySpeaker.init(options, this); // `this` refers to the element

        // Save the instance of the speaker object in the element's data store
        $.data(this, 'speaker', mySpeaker);
      };
    }
  };
})(jQuery);

And that’s it!

Now you have separated the creation of the plugin from the actual code itself. You are using the plugin to attach objects (with any inheritance patten) to dom elements and visa versa, but the plugin itself is just the connection and initialization code. This means that we could generalize this process further. I first saw this from Scott Gonzalez (of the jQuery UI team) and his code later became the ‘widget factory’ in jQuery UI. I prefer to not pass strings into my plugins in order to call functions, but it’s a valid approach as some people would take issue with having to pull out the object each time they started with a dom element.

Here is some code that might get you started writing/using a ‘bridge’ function (bridge is what’s found now in jQuery UI 1.8) that can help you attach your general code with a given plugin (since writing that same initialization plugin code multiple times would get old and defeat the whole DRY principle that our inheritance model has hopefully provided). This code is mostly courtesy of Scott Gonzalez because I couldn’t think of a more stripped down elegant approach to this. I changed it to accept Objects instead of Constructor Functions because that works a little better with my example (prototypal inheritance). I also force it to call my init function in order to save myself an extra call. (This example shows Scott’s use of this method along with John Resig’s Simple-Inheritance implementation - also very cool.)

$.plugin = function(name, object) {
  $.fn[name] = function(options) {
                // optionally, you could test if options was a string
                // and use it to call a method name on the plugin instance.
      return this.each(function() {
          if ( ! $.data(this, name) ) {
              $.data(this, name, Object.create(object).init(options, this));
          }
      });
  };
};

// With the Speaker object, we could essentially do this:
$.plugin('speaker', Speaker);

// At this point we could do the following
$('#myDiv').speaker({name: "Alex"});

That’s about all there is to it. I’d encourage you to pick some pattern for your development that isn’t just inline chaining of jQuery function calls. This way of breaking up and organizing functionality in your code serves as a quick and easy jumping-off point for testing and modularity. It’s much easier to test the individual functions of a modular object than it is to write tests for a single-line chain of jQuery calls.

Also, I do get some feedback along the lines of “well, my code is not a plugin” - “this isn’t applicable to my code” - but I usually tend to disagree. The stigma that a jQuery plugin has to be for general consumption is flawed. I encourage you to use the plugin architecture if you are creating functionality based on a dom element selection. For instance, if you are adding an error notification system, it would be very easy to create a notification object that attaches to a div and has the methods required for notification directly attached to it, rather than having a function that merely hides and shows random dom elements.

I am doing a round up of performance on a lot of this inheritance usage and I should get to writing another entry on that soon, but from my early tests, using reasonable inheritance is generally not that expensive. If you are pushing the limits of CPUs and browser rendering, you might have to make some sacrifices, but for the general case, the instantiation hit of inherited objects is probably well worth your while.

I’d love to hear about the way you approach this problem.

Superclassy Inheritance in JavaScript Developer Day Talk Slides

2010-01-31T00:00:00-06:00

I thought I would make a quick post for anyone coming here for my slides from Developer-Day here in Austin.

Superclassy Inheritance In Javascript

View more presentations from Alex Sexton.

I plan on giving a screencast of sorts a try, and perhaps even breaking up some of the sections into a few blog posts on the subject. Encapsulation, modularity and code reuse is an interesting topic in any language, but especially when it comes to applying those ideas to real life applications and web sites.

The demo pages can be found at A Totally Realistic Demo Page for applying Inheritance in Javascript or whatever.

Thanks to Viget for having me out to speak today, it was a blast.

Invalid JSON in jQuery 1.4 and beyond

2010-01-25T00:00:00-06:00

I’m pretty happy about jQuery’s move to only supporting valid JSON, as well as it’s standardization across browsers to enforce that rule, even if native JSON parsing isn’t being used. I think it’s silly for people to expect things to work when they are passing invalid data back and forth. Much like no one would dare write invalid xml documents for data transfer, the same should be applied to the JSON data format. Simply put, if you aren’t conforming to the JSON Standards as defined on http://json.org/ - then you aren’t using JSON. You are just passing Javascript source-code back and forth. I wouldn’t suggest it.

Now, I understand there are a variety of libraries and services that currently break the standard. I would strongly suggest you write to them and demand that they follow the spec. Nothing should break for their users, so it’s not much too ask. Until then I wrote this little lovely plugin so you could consume criminal data sources until they get their acts together:

jQuery.getInvalidJSON = function(url, data, callback) {
  return jQuery.get(url, data, function(d){
    callback.call(this, (new Function('return ' + d))());
  }, "text");
};

This is just an unsafe eval of Javascript source that is unwisely used as a data exchange format. I don’t think it belongs in jQuery, but if you are of the unlucky few that are forced to receive invalid JSON don’t let it stop you from upgrading to 1.4.

<3z

Don't let document ready slow you down.

2010-01-08T00:00:00-06:00

I just wanted to quickly post about a common performance hit that I see in pages (including a bit of my old stuff), especially ones that load data on page load.

A common pattern for application development loads a page template with the application code included and then makes an asynchronous data request to load all the relevant data.

One example might be something like:

<html>
  <head>
    <script type="text/javascript" src="jquery.js" />
    <script type="text/javascript">
      $(document).ready(function(){
        // make an ajax request once the dom is ready
        $.ajax({
          url: 'ajax.php',
            success: function(data) {
              for(var i in data) {
                $('.app-container').append('<div>'+data[i]+'</div>');
              }
            }
        });
      });
  </script>
</head>
<body class="app-container">
  // Perhaps a very large dom - which makes the page load slower
</body>
</html>

The problem with this is that the request for the page content isn’t made until the dom is ready, but that request doesn’t require the dom at all.

Instead of wrapping the $.ajax() call in a dom ready function, try just wrapping your success callback function in one instead. This will allow the request to fire off as soon as possible, but will ensure the handling of the data doesn’t happen until your domready event has fired.

<html>
  <head>
    <script type="text/javascript" src="jquery.js" />
    <script type="text/javascript">
      // make an ajax request right away
      $.ajax({
        url: 'ajax.php',
          success: function(data) {
            $(document).ready(function(){  //<-- Hey Guys check this out!
              for(var i in data) {
                $('.app-container').append('<div>'+data[i]+'</div>');
              };
            });
          }
        });
  </script>
</head>
<body class="app-container">
  // Perhaps a very large dom - which makes the page load slower
</body>
</html>

This should speed up the load time of your page. From my testing, there doesn’t seem to be any issues with this, so I believe it’s safe to use. The function will fire immediately if your domready event has already fired, and it will wait to fire if the dom isn’t ready yet. You can have as many document ready calls as you want on your page without overwriting old ones, so don’t worry about only defining it in one place. I would also imagine that you wouldn’t need too many more than two or three if you structured your code in an intelligent way.

As a footnote, this is only one of many things you can do outside of dom ready to help speed up the execution of your code. If you are binding events with ‘live’ or if you are just defining functions, I’d suggest that you do it inside of a closure instead of inside of a dom ready function. Then put just the stuff you need to run with the dom into the dom ready function.

The reason for this is essentially the same as before. You can allocate all the function definitions and variables while the page is building, rather than afterwards. Anything that you can do asynchronously right away is going to generally be better than waiting until the document is ready. There are a few ways to make this a little better organized, but organization isn’t the topic, so here is a simple example of code you might write with minimal code execution in the dom ready function. The closure that I have surrounding the entire block of code serves to make the variables have a similar scope affect as it would inside of a document ready function, though it’s not absolutely necessary.

  // This runs immediately
  $('a').live('click', function(e){
    alert('OKBYE!');
    return true;
  });

 // define functions outside of the dom ready
 function doSomething(input) {
    $('div.something').do(input);
    // you can even use functions that require the
    // dom inside of a defined function as long
    // as you don't call it until the dom is ready
    $('div.somethingelse').click(function(){
      console.log("I don't need no dom ready");
     });
  }

  // dom ready
  $(document).ready(function(){
    // Do stuff that requires the dom, and
    // use your functions from outside
    $('a.special').click(function(e){
      doSomething('special');
    });
    // yay!
  });
})(jQuery);

It’s nothing revolutionary, but I figured I’d get it out there!

yayQuery Podcast 1.0

2009-11-06T00:00:00-06:00

A few of the ladies and fellas from the #jquery IRC (Adam J. Sontag, Paul Irish, & Rebecca Murphey) and I decided to make a podcast on the topic of jQuery. We landed on the name yayQuery!

From Paul’s blog post:

We talk about…

Underscore.js - a great utility belt (very handy for Ruby/Python folks), comes with John Resig’s microtemplating script and lots more
Thickbox - Rest in peace. Also alternatives: Colorbox, jQuery UI Dialog
jQuery on mobile. Phonegap, XUI, jQTouch, going it alone
Anti-Pattern of the week: css(key,val)
$var and Hungarian notation
… and dancing

If you’d like a download: mp3 audio (30mb), mp4 video (94mb), ogg video (61mb)

I’d love to get your feedback on what you liked or didn’t like. If people seem to enjoy it, we’d love to step up the production just a bit, but it doesn’t really make sense quite yet.

You can also follow us on twitter (@yayQuery) if you want updates for the next episodes and such. Yay!

Goto.js

2009-07-04T00:00:00-05:00

Today I launched my new site www.summerofgoto.com. It is the official new homepage for my new script Goto.js. Goto.js adds the functionality of the goto command into native javascript. It uses James Padolsey’s parseScripts as a preparser and rewrites the input code to be valid javascript. Leave it to me to write programs solely for the comedic value, but I actually did find some interest in the fact that it is challenging to implement functionality that is so basic to low level programming.

The script (which can be downloaded at the site) hinges on a single heuristic for implementing Goto. In javascript, while loops can have labels, and they can also have ‘continue’ statements that accept a label as the parameter.

e.g.

label1: while (i < 10) {
  if (!valid(i)) {
    continue label1;
  }
i++;
}

In effect, this is just a crappy goto statement that is confined to a special case. So my goal in goto.js was to extend this case to all cases. I did this by surrounding everything after a label with a while loop that only runs once by default. The only tricky part being that while loops cannot stretch across multiple functions or blocks. So each while loop ends at the end of its block scope, not the file or script. This is an interesting problem, because typically, when goto was around and actually heavily used, there weren’t a whole lot of functions being written. Even if I was somehow able to allow you to start running code from the middle of a function from the middle of a different function, I don’t think it would work, because the context of all the variables that have been passed into the new function cannot be guaranteed to exist.

The only feature that I am actively toying with currently is a way to allow goto satements to jump to labels that haven’t been declared yet. After reading a bit on the subject, different languages had different rules about this feature in the past, and some languages therefore also did/do not support forward looking goto statements.

Enjoy the Summer of Goto!

P.S. For anyone who is wondering (so far a total of zero people), Summer of Goto is a term that was popularized by Paul Irish, while discussing this script and PHP’s decision to add goto into their language.

And for those who do not immediately recognize that this entire thing is a joke, please forgive me. <–(insurance).

Class Blog:

2009-06-23T00:00:00-05:00

Hello all,

I don’t expect a terribly large readership, but hopefully I can post some things that will help some people along the way. This will be less of a personal endeavor and more of a location for me to write about some of the things that I create or think are cool in my areas of interest.