I’m a big fan of the new asset pipeline features in Rails 3.1. I’ve spent way too much time building my own JavaScript and CSS precompilers or forcing Sprockets 1.0 to do things it wasn’t intended to do. When I started using Sprockets 2.0 with Sass and Compass, there were some gotchas I didn’t anticipate and I was surprised not to see bug reports about them. As it turns out I was thinking about it all wrong. Here’s a quick explanation in case other people have the same problem.

I’m used to using Sass with one master stylesheet and several partials, like so:

In Rails 3.1 and Sprockets, this doesn’t work for two reasons:

1. Sprockets isn’t aware of @import statements in Sass, so it doesn’t invalidate the cached master stylesheet when one of them changes. You can use the *= depend_on directive to handle this, but then you have to list your partial files twice.
2. If you reference images in assets/images, the Rails precompiler rewrites those files names with an md5 hash, like assets/bg-9c0a079bdd7701d7e729bd956823d153.png (as described in this post on Rails 3.1 in production.) Sass can’t preprocess files with ERB, so you can’t use asset_path.

Being able to use ERB is pretty huge, so I realized I had to use Sprockets require directives to get that preprocessing. But you can’t just require "compass" at the top (it’s not in the load path) or be able to share variables and mixins with a single require.

The trick is to think of Sass files like Ruby files: if you depend on functionality in another file, you have to explicitly include it each time. So my example above becomes:

I still had to add a depend_on directive for the partial so that application.css updates when that file changes, but otherwise this solution solves all my problems and I have maximum flexibility.

Let me know if I’m overlooking something simple! And this post will probably be out-of-date soon as the Sprockets guys starting adding documentation.

UPDATE: Came across another gotcha today. You can’t use asset_path inside partial Sass files included with @import, so any shared styles can’t reference image files. Arg.

PS: This is how you get Compass in the Sass load path (I forgot where I stole this from):

Bindings keep UI elements in sync with data with minimal code. In Cairngorm, all application data lives in a ModelLocator singleton, so UI elements have a single point of reference for application data.

I’m sure there are many ways to implement binding in JavaScript, but I started with my ideal API:

Where object is the bound object. This creates a cascade of calls setting the appropriate values on properties of other bound objects.

I avoided recursion by creating a unique transaction id every time Binding.trigger is called. The set method passes this id along internally so no object is changed twice in the same transaction.

So far I only support text and checkbox inputs, textareas, and select dropdowns. The selected option in a select dropdown doesn’t amount to a single property, but instead to element.options[element.selectedIndex].value. It was easy to override the get and set methods to allow Binding.trigger(element, "value").

See the example and check out the code. I used the Flow JavaScript library to normalize the DOM API (really just for addEventListener), but it doesn’t rely on any particular library.

My appreciation and respect for JavaScript increased tremendously while developing Silverlight projects. Not at all because of how easy it was to work with. But its flexibility and power made it interesting and fun to tackle challenges like optimization and application architecture.

Optimization

In Silverlight 1.0, the plugin is only a rendering and animation engine. All of the logic and much of the processing still resides in the browser’s JavaScript interpreter. All web applications need to make optimization a priority, but this is especially true for Silverlight 1.0 applications.

Doing a lot of small things can add up to make a big difference. Swap myArray.push(obj) with myArray[myArray.length] = obj. Avoid string concatenation when possible to give Internet Explorer a little boost.

I made two significant changes to my code between the WWE project and the last Library of Congress project that I believe made a big difference.

Avoid Function.bind

I usually resorted to a Function.bind method (usually the version in prototype.js) to manipulate function scope. This really comes in handy for event listeners:

I really like this syntax, even though in an ideal world it wouldn’t be necessary. (Actionscript 3 is an ECMAScript implementation that fixes this). I’ve heard Mozilla might implement it natively, which would be lovely.

The problem with bind() is that it uses apply() internally, which is significantly slower than just executing the function. This makes a big difference for MouseMove or ProgressChanged event handlers.

Fortunately it is easy to avoid, and there are a number of ways to use depending on your personal preference. I usually used:

I looked around for any documentation on the effects on bind() on performance and found nothing. This isn’t a Silverlight-specific issue but something other people might run into so it’s probably worth documenting.

Using and Removing Event Listeners

This also isn’t necessarily Silverlight-specific, but it’s also worth mentioning because of a few difference from how HTML DOM event listeners are handled. The crux of the matter is still that adding event listeners is memory intensive and not disposing of them properly can cause leaks and sluggishness.

In HTML you can use event delegation to limit the number of event listeners added. Add a single click event listener to a parent object, and act upon the event based on on the target property of the event, which is usually a child of the parent object. This isn’t possible in Silverlight 1.0 because there isn’t a real event object. The sender argument sent to the listener is always the object to which the event was added.

The only way to combat the overhead from adding event listeners is to reuse objects when possible. For WWE, there is a big grid of thumbnails the user can click on. Instead of creating a whole new grid each page refresh, I just changed the data for each item.

Sometimes reuse isn’t an option, and you’re forced to create and destroy XAML objects repeatedly. Removing event listeners before destroying an object isn’t difficult.

I came up with a way to store those event tokens in a simple, behind-the-scenes manner, which made this easier to do than not do. I’ll describe this in the next section on JavaScript/Silverlight Architecture.

• Intro
• Part 1: Xaml
• Part 2: JavaScript Optimization
• Part 3: JavaScript Architecture

A lot of ajax-y web pages involve hiding and showing content. My current project has a tons of content related to a video in dynamic reveals that the user can open and close. Of course, accessibility is important, so for users without JavaScript enabled, all of this hidden content should be visible.

Typically, JavaScript would explicitly hide this content as soon as it is available. Something like:

I chose prototype.js because of its notorious file size, and I know a lot of you still don’t compress and gzip their JavaScript! If you’re loading a lot of JavaScript, HTML, and CSS, chances are pretty likely that the #revealContent element will display before that that function has a chance to run.

So how do we hide that element before it has a chance to load? The technique I’m using adds a CSS rule to a new stylesheet as soon as possible, i.e. when the JavaScript is interpreted.

// JavaScript

var CSSRules = function() {

	var headElement = document.getElementsByTagName("head")[0],
		styleElement = document.createElement(”style”);
	styleElement.type = “text/css”;
	headElement.appendChild(styleElement);

	// memoize the browser-dependent add function
	var add = function() {
		// IE doesn’t allow you to append text nodes to
 elements
		if (styleElement.styleSheet) {
			return function(selector, rule) {
				if (styleElement.styleSheet.cssText == ”) {
					styleElement.styleSheet.cssText = ”;
				}
				styleElement.styleSheet.cssText += selector + ” { ” + rule + ” }”;
			}
		} else {
			return function(selector, rule) {
				styleElement.appendChild(document.createTextNode(selector + ” { ” + rule + ” }”));
			}
		}
	}();

	return {
		add : add
	}
}();

CSSRules.add(’#revealContent’, ‘display: none !important’);

// later
$(’revealContent’).addClass(’show’);
</pre>
<p>I haven’t tested this exhaustively, but it works as intended in Internet Explorer 6 and 7, Firefox 2 and 3, Safari 2 and 3, and Opera 9. I originally expected some strange behavior from adding elements to the <code>&lt;head&gt;</code> before it finished loading, but fortunately this isn’t the case.</p>
<p>You could also include a stylesheet or a <code>&lt;style&gt;</code> tag in a <code>&lt;noscript&gt;</code> tag, but I prefer to keep all of this behavior in JavaScript.</p>
<p><strong>Update:</strong> The old code:</p>
<pre lang=”javascript”>
// JavaScript
var CSSRules = function() {

    // create a stylesheet
    var stylesheet = document.createElement(”style”);
    stylesheet.setAttribute(”type”, “text/css”);
    document.getElementsByTagName(”head”)[0].appendChild(stylesheet);
    stylesheet = document.styleSheets[document.styleSheets.length - 1];

    return {
        add: function(selector, rule) {
            // the Microsoft method
            if (stylesheet.addRule) {
                stylesheet.addRule(selector, rule, 0);

            // the standard method
            } else if (stylesheet.insertRule) {
                // safari 2 apparently ignores this
                stylesheet.insertRule(selector.concat(’{’ + rule + ‘}’), 0);
            }
        }
    };
}();

CSSRules.add(’#revealContent’, ‘display: none !important’);

// later
$(’revealContent’).addClass(’show’);
</pre>

First, XAML is an awkward language to work with. From a business perspective, this makes sense because Microsoft can push their Expression suite on developers and designers. But this is unacceptable for a client-side developer who wants to write markup by hand and is a Mac user.

XML is a terrible vehicle for describing anything more complicated than nested boxes. It is especially terrible with vectors. This is XAML generated by Blend to describe a tiny arrow pointing left:

Opening up 2000 line XAML files full of markup like this is headache inducing.

Second, XAML in SL 1.0 is the Anti-DRY language. It lacks concepts like cascading styles and class names, so if you want all your TextBlock elements to be red, you have to specify Foreground="#FFFF0000" for each one.

It gets worse for repeating elements programmatically. Say you have XAML for a button with a TextBlock label, and you want to create four of them to make a menu:

Of course, you’ll want programmatic access to that TextBlock so that you can change the label text. But because there is only one namespace for x:Names (x:Name="buttonLabel" can only be used once), adding more than one to the XAML hierarchy will throw an exception. Also, there are no utilities like .getElementsByTagName. Solutions like button.children.getItem[0].children.getItem[0] are brittle and don’t scale.

There is a solution to this, but it was nearly impossible to find in the Silverlight 1.0 documentation. The createFromXaml method takes a second boolean argument that can create a new, separate namespace for x:Names. This allows you to create multiple XAML objects from the same source and add them to the XAML hierarchy without x:Name collisions.

A caveat to this technique is that findName won’t find elements created in a new namespace, so you have to save a representation of each new element in JavaScript.

My methodology for using XAML tries to tackle these two big challenges. It breaks down to these steps:

• Use images instead of XAML vectors when the file size overhead allows it.
• If Blend is used, only create small, isolated pieces of XAML so each is easier to digest and manipulate.
• Zip up every XAML file and download it all at the beginning. XAML files are usually light enough that it shouldn’t noticeably delay the start of your application.
• Create XAML elements dynamically from the files in the zip file. Use createFromXaml(text, true) for repeated elements and always save a representation of the elements in JavaScript to manipulate later.

I built a number of utility functions to make this methodology very easy to use. Here is an example:

My XamlDownloader utility is a simple wrapper for the Downloader class that passes back an instance of a ZipHandler class. The save method grabs a XAML file out of the zip file and returns a XAML creation function that can be run as many times as necessary.

Because the XamlDownloader utility creates a closure around a Downloader instance, you have to destroy that instance or you’ll create a massive memory leak. The WWE project would bring down a fresh instance of Firefox 2 in half an hour easily.

• Intro
• Part 1: Xaml
• Part 2: JavaScript Optimization
• Part 3: JavaScript Architecture

I’ve worked on four SL 1.0 projects:

• myHSN, which I can no longer find online — September, 2007.
• Reading Pre-Columbian Artifacts and Waldseemüller Maps for the Library of Congress, developed concurrently — November-December, 2007.
• WWE’s Silveright Video Player, up but with features pulled — December, 2007-January, 2008.
• Creating the US Declaration, Constitution, and Bill of Rights for the LOC — April, 2008.

All of these projects were developed under extremely tight deadlines and generally had ad-hoc development processes. HSN was a mess because the plugin was released after development had started. The first LOC projects had a lot of UX, creative, and project management complications. WWE actually followed our architecture and development processes very well but it was an overly ambitious project for a technology this immature.

For the last LOC project, I was finally able to piece together techniques developed over the last six months. It was still a very tight deadline and inevitably a bit ad-hoc, but I am still proud of it.

Challenges in Silverlight 1.0 Development

Silverlight 1.0 development is difficult by its reliance on two technologies:

1. XAML
2. JavaScript

Of course, that’s all there is to Silverlight 1.0! On top of that, it’s a buggy plugin, but there’s not much we can do about that. Instead, I’ll focus on ways to address the challenges presented by SL 1.0’s core technologies.

• Part 1: Xaml
• Part 2: JavaScript Optimization
• Part 3: JavaScript Architecture

I’m not sure how much I would have gotten out of Google’s I/O conference at the end of May, because so many of the sessions seemed to center around GWT and Gears, which I have little interest in. But fortunately they posted videos of the talks on Youtube, and I really like this one byAlex Russell of the Dojo JS library. It’s not a talk about practical solutions to the larger problems facing the web, but it gives a thoughtful, articulate, big-picture summary of what brought us here, where we’re going, and who to yell at to change something.

Working with YUI helped trigger an epiphany for me this past week. Credit for laying the foundation for this moment goes to the sample chapter on Inheritance of Douglas Crawford’s new book, JavaScript: The Good Parts. I did not understand the practical usage for the techniques in the chapter at first because I learned Object Oriented design in classical OO languages like Actionscript 2, PHP5, and Ruby (which Prototype imitates as best as possible).

I’ve tried to maintain this style in JavaScript, especially in large projects like Silverlight 1.0 RIAs. I usually structured classes like this:

I eventually extracted the new Class.create function from Prototype.js 1.6.0, because it gives you an elegant syntax for inheritance, mixins, and access to overridden methods without much overhead. It basically does the same as the above with some extra magic for creating the inheritance chain.

There’s nothing inherently wrong with this approach, and I think that anyone who tells you otherwise is a bit of a zealot. But it’s reliance on the this object creates problems, especially with event listeners. YUI made this very apparent:

The scope of the event handler is the button, which I believe follows the standard. However, I usually want this to refer to the instance of the class so I can access other methods and properties. The bind method in Prototype makes this easy by creating an anonymous function that executes the function in the specified scope:

There are a few problems with this approach.

1. bind uses Function.apply which adds overhead. It’s usually negligible but with JavaScript optimization is always a top priority.
2. We’re not using Prototype! In this case, the client is a large e-commerce site and we’re only coding a small section of it. Prototype doesn’t necessarily place nice with other libraries since it defines a lot of global variables and augments the prototypes of build-in objects (like adding bind to Function).

You can specify the scope of the event handler with YUI, but it has the same effects as the first point above.

This felt very awkward to me, like I was doing something I wasn’t supposed to do. It’s perfectly valid but the awkwardness got a few gears turning in my head. I don’t think I can adequately explain my train of thought without turning this into an unreadable ramble, but here is how I’ve started writing components (using the module pattern):

And all of a sudden, Crockford’s techniques make sense! My paradigm shift is really just two ideas:

• Encapsulate code into factories, not classes.
• Functions act upon objects instead of being methods of the object that act upon itself (addEvents(that) instead of this.addEvents()).

I’ve yet to fully explore the ramifications of these techniques, but I wanted to try writing this down to see if it still makes sense. I won’t throw Class.create out of my toolbox just yet, but if I can understand an elegant way to do inheritance–or more likely, composition–I do think this will be the way to go 90% of the time. More on this topic to come.

Addendum: Curiously, Luke W posted an article while I wrote this about the exact component I was refactoring when this epiphany hit me.

The reason I’m unhappy with this so far is that it doesn’t achieve the goals I have for a blog. Of course, I can’t fully achieve my goals unless I know what they are in the first place. What are my goals?

• To have central homepage that aggregates my three outlets on the web: twitter, tumblr, and this blog. The streams should be kept separate because they have different audiences. The blog is technical, tumblr is social, and twitter is personal.
• To have URL I can use to identify myself professionally.
• To have good blog for technical writing. It must be easy to skim and allow code samples.

I could probably manufacture more if I needed to, but I think this is a good starting point.

Don’t worry, nonexistant readers! I have a few topics in mind for real posts in the near future.

… wait.

A blog design in progress

Having tried to start a blog for, I don’t know, the last 8 years or so, I know that if I try to get the design perfect I will never post it for the world to see. Hell, if I were to wait until it qualified as just “good” you would never read this. So my plan is to put something up that isn’t ugly and tweak it from here. I’ll write a post or two about my development process, or lack thereof, as well.