It’s a couple months in the making, but I’m happy to say that Sammy.js 0.6 is finally here. Check out the HISTORY and the Changes. I’m calling this release the California Suite in honor of my move to the West Coast and the fact that I did most of this coding on the plane back and forth. There are some awesome big new features that I’ve been using for a little while now and I can say are a big improvement over previous releases.

Download it!

Before I get to that, I want to mention that work is in full swing on a new Sammy.js website with more documentation and other great stuff. I even have a real logo which I hope to share soon (stickers, anyone?). Before the site launches, though, I set up a new GitHub wiki so that sammy.js users and developers can share projects and code that they’ve been working on.

On to the features!

Context! Context! Context!

The biggest complaint and frustration that I heard from people working with Sammy was about dealing with rendering complex views on the client. If you’re doing full client side applications or any amount of client side templating you’ve felt the pain of deeply nested callbacks and complex workarounds for interpolating data in an asynchronous environment. It’s all like, render this template, wait, first I need the data, hold up, I cant even render that yet I need to get this other template first. Here’s a common example of what I’m talking about:

this.get('#/', function() {

  this.partial('index.mustache', function(html) {

    $('#main').html(html);

    $.getJSON('items.json', function(items) {

      this.partial('item.mustache', items, function(item, i) {

        $('#main ul').append(item);

      });

    });

  ));

});

It’s not just nested callback’s that are the pain – its the knowing (or not knowing) when a template will be there or not. It’s also trying to deal with fetching data and fetching templates within the same context without a unified API. After kind of examining how other people are doing this, I took some queues from jQuery’s API as well as ‘promise’ style programming and Sexy.js. The result is Sammy.RenderContext. You create a RenderContext by calling one of three methods within a route/EventContext – load() render() or partial(). Once you have a every method you chain to it is guaranteed to execute in the order that you chain it regardless of it synchronicity. This means that you can put an appendTo() after a load() and the content won’t be appended until its fetched asynchronously from a remote location. The content from the previous method in the chain is also passed along so you don’t have to constantly pull out references. The code above, translated to the new way looks like:

this.get('#/', function() {

  this.render('index.mustache')

      .replace('#main')

      .render('items.json')

      .renderEach('item.mustache')

      .appendTo('#main ul');

});

A wee bit nicer. Not only does it improve readability but it makes it much easier to do longer more involved client side templating without getting lost in a mire of order and context passing. RenderContext’s can also be invoked side by side in a single route for parallel execution of chains. Each chain is its own object and keeps its own state. I tried to keep the API concise but with just a few methods, I think most situations are covered:

then(function(content, previous) {})

next(content);

wait();

// Loading local or remote content

load('item.template')

load($('.item'))

// rendering templates

interpolate('item.template', {})

interpolate($('.item'), {})

render('item.template', {})

partial('item.template', {})

collect(items, function(item, i) {})

renderEach('item.template', items)

// DOM Manipulation

swap()

appendTo($(element))

prependTo($(element))

replace($(element))

// Events

trigger('name', {})

Along with the readability improvements, the RenderContext (specifically load()) allows for DOM style or pre-embedded templating. Meaning, templates don’t have to come from files, they can be DOM elements and embedded into <script> or hidden tags. This goes along with the two new templating engines added as well . . .

Alchemy

I thought I had this really novel idea. Why not use classes or other attributes of DOM elements to define how they’re tied to a JSON object? I worked on some prototypes and finally found a name and wrote some real code. It turns out, it was a pretty good idea, but also one that had been done before. 0.6 includes plugins for my own Sammy.Meld and the existing and by default more popular pure.js.

The basic idea of both of these engines is that you take some data like this:

{

  "post": {

    "title": "My Post",

    "body": "Lorem ipsum dolor sit amet.",

    "tags": ["one", "two", "three"],

    "meta": {

      "comments": 5,

      "time": "Yesterday"

    }

  }

}

And some HTML like this:

<div class="post">

  <h2 class="title"></h2>

  <div class="body"></div>

  <span class="tags"></span>

  <ul class="meta">

    <li>Comments Count: <span class="comments"></span></li>

    <li>Posted: <span class="time"></span></li>

  </ul>

</div>

Meld them together and you should get something like:

<div class="post">

  <h2 class="title">My Post</h2>

  <div class="body">Lorem ipsum dolor sit amet.</div>

  <span class="tags">one</span>

  <span class="tags">two</span>

  <span class="tags">three</span>

  <ul class="meta">

    <li>Comments Count: <span class="comments">5</span></li>

    <li>Posted: <span class="time">Yesterday</span></li>

  </ul>

</div>

There are some clear benefits to this over traditional tag style (mustache, ejs) style templating. Namely, its just HTML. This means that you can include it in the DOM on the initial render and not have to go fetch it from the server. It also means that a designer can just design it and even use lorem ipsum if you want, and you don’t have to go through and add the templating language. There are some downsides, too. DOM manipulation even with jQuery’s speed is pretty much always going to be slower then just text interpolation. I’m working on improving the speed of Meld though caching and faster manipulations, but it ain’t easy. The other big downside is that complicated iteration or template logic is pretty hard to do in this style. Pure tries to get around this by using a third element called directives which are further instructions on how to meld the data and the markup. I forgo this extra ability to configure in Meld in favor of very simple transformations (ul,ol = lists) and a much smaller file size (uncompressed meld is only 4K). I’ve been using Meld on some personal projects and hope to test its worth in a real production environment very soon. You can see more examples of it’s power in the tests

What’s next?

I’m still pushing to get Sammy.js to 1.0 in the very near future. I really don’t think theres that much between here and there. I’ll mention that I’ve finally been seriously coding with node and server side js and I’m not that happy with the current state of routing libs there. Server side sammy? Maybe.

More

There were a lot of smaller bug fixes and improvements beyond Meld and the RenderContext so I definitely encourage checking out the full list and making the upgrade soon. Big thanks as always to everyone who helped with the release. Go out and make some apps!

More interesting, I was interviewed by The Changelog Show. Wynn and Adam are awesome hosts, and we talked about a lot of fun things including a good deal about Sammy and JSConf. Since I didnt really get to talk too much about Sammy at JSConf, it was a great way to share my current thoughts and some stories of the origins of Sammy.js. This also lead into a nice mention on The Dev Show yesterday.

I haven’t mentioned it here either, but I’ve also been making some major upgrades to my Sammy presentation app, Swinger. I added slide sorting, incremental lists, and a ton more. This also includes having a fully useable hosted version for people to play with at http://swinger.quirkey.com/

I’m very excited about where Sammy is going and even more excited as I’m using it almost every day and getting to contribute back to the project and think about the stumbling blocks as I use it.

I already have a basic plan laid out for the next release which is mainly focused on re-writing the partial() and template handling to make chaining multiple templates much much easier. You can follow the work I’m doing on it on github. The current status is that it works and passes the basic tests, but theres still a bit to go in terms of API and usability. I’m going to write a more detailed post about it very soon.

I’m pleased to announce the next major release of Sammy.js, 0.5.0. I’ll go over what I think are the most import changes, but you can check out the HISTORY or just cut to the chase and download it.

jQuery 1.4.1

One of the big events I was waiting for in order to release this new version was the release of jQuery 1.4.1. Besides being a good leap and jump faster then previous versions, the latest jQuery added support for cross-browser bubbling of the submit event. This might not sound like a big deal, but Sammy handles post/put/delete routes by binding to forms and their submit events. In previous versions of Sammy, if a form was dynamically added to the page (i.e. by a partial or get route), you (or the app) would fire a changed event, which would tell the app to search for all newly added forms and bind to their submit events. Using the power of jQuery 1.4.1, Sammy can now just listen for submit events that will bubble up to the applications element and from their dispatch the route. In general this is a lot cleaner and will make it easier for beginners as it just works.

Chain of fools

From user requests, and to fulfill my own desires, I’ve tried make Sammy more adaptable to different styles of coding/app creation. The first thing I realized why not make Sammy app definitions chain-able? It’s a style of development that jQuery developers are already used to, and it looks pretty swanky, too. With 0.5, all the app modifying methods are now chain-able:

  



// classic style:

$.sammy(function() {

  this.use(Sammy.Mustache);

  this.use(Sammy.Session);

  

  this.before(function() {

    // …

  });

  

  this.get('#/', function() {

    // …

  });

  

  this.bind('run', function() {

    // …

  });

  

})



// New chain style:

$.sammy()

  .use(Sammy.Mustache)

  .use(Sammy.Session)

  .before(function() { 

    // .

  })

  .get('#/', function() {

    // …

  })

  .bind('run', function() {

    // …

  });

    

Sammy()

Once just a namespace, Sammy() is now a function (and its aliased to $.sammy). The Sammy() method provides access to the new Sammy.apps object and hence allows you to access the different Sammy applications you’ve added to the page without having to define additional global vars. Finding and extending is all based on @element_selector@s so those should be unique per-application. It also provides a quicker syntax for defining an app bound to an element_selector.

// Old way

// we're forced to make app a global so we can access it 

// outside of this closure

app = $.sammy(function() {

  this.element_selector = '#myapp';

  //…

})

// equivalent to

app = new Sammy.Application(function() {

  this.element_selector = '#myapp';

  //…

});



// NEW WAY

$.sammy('#myapp', function() {

  //…

});

// equivalent to Sammy('#myapp', function() {})



// No need to assign it, the app can be looked up by element selector

$.sammy('#myapp') //=> Sammy.Application

There are some cool use-cases for this, including being able to iterate over all the Sammy apps in play and extend them.

any way you want it

Sammy 0.5 adds the new any pseudo-verb which allows you to easily add a route that will match against any verb:

  

$.sammy(function() {

  

  this.any('#/', function() {

    this.log("I'm up for anything");

  });

  

  // also equivalent

  this.route('#/', function() {});

  

});

This was actually the first step of another way to define Sammy applications. The new mapRoutes() method allows you to define any number of routes as 2D Array.

$.sammy(function() {

  

  this.runIndex = function() {

    this.partial('index.template');

  };

  

  this.mapRoutes([

    // each element in the array represents the arguments sent to route()

    ['get', '#/user', function() {

      this.partial('user.template');

    }],

    // leaving out the verb assumes the verb is 'any'

    [/\/alert$/, function() {

      alert(this.params['alert']);

    }],

    // passing a string instead of a callback assigns the method with that

    // name from the application.

    ['get', '#/', 'runIndex']

  ]);

  

});

I personally like the method syntax better, but there are some cool uses for this – You could even load your routes from multiple files and add them to the application using JSON.

Filters

before filters are very useful for extracting common functionality out of your routes. However, I’ve found myself writing this pretty often:

$.sammy(function() {

  

  this.before(function() {

    // only run if the path is not the index

    if (this.path != '#/') {

      //… do something

    }

  })

  

});

Taking some hints from Rails, I’ve added options to before filters. The above example could be rewritten:

$.sammy(function() {

  

  this.before({except: '#/'}, function() {

    //… do something

  })

  

});

The filters can match against path (as a string or RegExp) and verb and you can define them in the positive (only) or negative (except). The method that does the matching is exposed as contextMatchesOptions so you can use it outside of before()

I’ve also found myself doing a lot of wrapping entire route callbacks in an asynchronous check for something (usually a login). The new around filters make this easy. around takes a single argument which is a neatly packed function that contains the full execution path of the route being accessed. This includes additional filters and the route callback itself. This also means you can entirely halt the execution by never running the passed callback.

$.sammy(function() {

  

  this.around(function(callback) {

    // `this` here is the Sammy.EventContext

    // just like before, etc

    $.get('/session', function() {

      callback();

    });

  });



})

Lots more

Theres actually a fair amount more to cover in Sammy 0.5, but I think I’ll be doing more short ‘Whats new’ posts soon. Check the HISTORY for a full rundown of changes.

Thanks

Special thanks goes out to everyone who helped with ideas, commits and testing for this release including Lena Herrmann, Jinzhu, dpree, Jeff O’Connell, Todd Willey, Tim Caswell, and Frank Prößdorf (endor).

I’ll swing through some of the biggest changes and new hotness – see the HISTORY or the Commits for a full list and more detail.

LocationProxy

I’ve always thought the poller implementation that monitors the hash/location for changes was a little bit of a hack. CodeOfficer also had brought up the pain of having a poller per-app when you have multiple or many Sammy applications on a single page. As more browser’s support it I also wanted to make use of the native ‘onhashchange’ event which when bound to, completely eliminates the need for polling. I attempted to do this all in one fell swoop, by decoupling the location monitoring into an entirely separate object: Sammy.HashLocationProxy. The HashLocationProxy is setup for each app by default. It tries to make use of the ‘onhashchange’ event where available, and where it isn’t it gracefully falls back to ol’ fashioned polling. The big difference, however, is there is only a single global poller per page no matter how many apps you have.

The HashLocationProxy also defines a spec for other location proxies to be created. There’s also a DataLocationProxy which derives its location from a jQuery.data attribute.

Storage and Session

The newest and most visibly awesome part of the new release is a new suite of plugins and prototypes: Sammy.Store, Sammy.Storage and Sammy.Session. As part of 0.3 I introduced Sammy.Cache which was really a first attempt at what Sammy.Storage does. Sammy.Store is an single access point and API for all the various browser based storage methods, including HTML5 DOM Storage and Cookies. It provides a unified way of dealing with these as Key/Value stores. As an extra bonus, it also conforms to Key Value Observing, triggering jQuery events when values change. Heres a little example:

// Cookies

var cookie = new Sammy.Store({name: 'mycookie', type: 'cookie'});

cookie.set('foo', 'bar'); //=> "bar"

cookie.get('foo'); //=> "bar"

cookie.keys(); //=> ["foo"]

// HTML5 localStorage (only works in certain browsers)

var local = new Sammy.Store({name: 'mylocal', type: 'local'});

local.fetch('foo', function() {

  return 'bar';

}); //=> "bar"

// Only sets if not set.

local.fetch('foo', function() {

  return 'baz!';

}); //=> "bar"

The latest chapter of the Sammy tutorial also covers Sammy.Session

More Plugins

There are also a number of other less glamorous but new and awesome plugins.

• Sammy.Mustache Provides support for the Mustache templating framework, thanks to Mustache.js
• Sammy.JSON is a simple wrapper around json2.js
• Sammy.NestedParams: Adds full [tested!] support for Rails/Rack style nested params to Sammy form handling. (Even though this was part of the 0.3.1 release, I never mentioned it here)

Thanks

Thanks to everyone who helped with this release through testing, ideas, or putting Sammy in production and telling me what’s wrong with it.

Last week I had the pleasure of launching a big new feature set into production for one of my favorite clients, Wejetset. The excitement was greatly enhanced by the fact that City Notes Interactive makes full use of my own special framework, Sammy.js.

City Notes and the other features deployed were an almost ideal project. The design and direction was an awesome back-and-forth collaboration between myself, Tom Ran of The Scout fame, and the face and brains behind Wejetset, Taj Reid. I could probably talk forever about how much fun it is to work with those guys, but in this post I’d rather dive deeper into the challenges and takeaways in the actual code.

I knew right from the beginning that Sammy would be a good fit for this. The question was how. Sammy let me think about the construction of the app in terms of routes and instantly gave me a way to create perma-links to specific notes and even specific filters.

Templating

One of the first decisions I made was to go with server-side templating. As much as I am and have been a proponent of pushing everything client-side, for this specific app it made much less sense. Specifically, there are other places throughout the site where I’m using the same templates and the benefits of re-using them were just too strong. Also, this gives the extra bonus of making the site a little more google friendly. In fact, without JavaScript the most recent notes still display and can link to the right destinations.

Forms

One thing that I wanted to streamline as much as possible is handling forms – posting them to the server and handling the responses without leaving the page. I came up with a useful method – postFormDirectly() – that handles the post route and submits it directly to the server, handling the response and sending it back to a callback.

Heres an example call, for positing the form to create city notes.

this.postFormDirectly('/city_notes', function(response) { 

  if (response.status == 'success') {

    this.redirect('#/');

  }

});

Instantly, you can tell that a lot is abstracted and changed from a traditional route. Here we’re routing on an actual URI as opposed to just an anchor. This has the added benefit of allowing the form to work without JS. (As an aside, I’ve personally found a key to making degradable and unit testable sites is to first make the process work (albeit without any flair) without JS and then add the code to push the interactions and the single page-ness.)

To give a little more insight, heres the implementation:

this.postFormDirectly = function(path, callback) {

  var app = this;

  app.post(path, function(context) {

    var context = this,

        post_path = this.path, 

        wrapped_callback = function(response) {

          WJS.handleResponse(response, context.params, function(r) {

            if ($.isFunction(callback)) {

              callback.apply(context, [r]);

            }

          });

        };

    if (!post_path.match(/js$/)) { post_path = post_path + '?format=js'; }

    this.params['$form'].find(':input').trigger('clear-errors');

    this.params['$form'].ajaxSubmit({

      url: post_path,

      dataType: 'json',

      success: wrapped_callback,

      error: wrapped_callback

    }).trigger('show-loading');

  });

};

Lets take a little walk through. First and formost, we’re just adding a post route to our Sammy app. The contents of this route allow us to use jquery.form’s nifty ajaxSubmit to send the form to the server without reloading the page. We’re creating a response callback for the ajax request called wrapped_callback which takes the response from the server, passes it to handleResponse which then in turn calls our passed callback if it exists. handleResponse does a lot, too, but I’m not going to post the contents here (though I might make it into a plugin …). All you need to know is that the response from the server is JSON and looks something like:

{"status": "success", "message": "You're note was posted successfuly."}

handleResponse displays the little flash message and also highlights the form if there are errors. I use this pattern on a number of projects and it seems to work pretty well.

One neat Sammy tidbit you might not have known about, in post & put routes, there is always a ‘$form’ param which is a jQuery object containing the HTML form that submitted to the route. Very useful for cases like above.

Modals

If you play around with the app, you’ll notice that we make pretty good use of modal windows for actions (submit/share/email to friend). The cool thing about using Sammy for this is they’re just routes, so refreshing the page or linking jumps directly to them. I also wrote a little jQuery extension that I found extremely useful for them:

$.fn.findOrAppend = function(selector, element) {

  var $this = $(this), 

      $el = $this.find(selector);

  if ($el.length > 0) return $el; 

  // el doesnt exist so lets make it

  if (typeof element == 'undefined') {

    // figure out how to build the element from the selector

    var parts = selector.split(' ');

    $el = $("<div>");

    if (parts.length == 1) {

      // single selector so just added

      $el.addSelector(selector);

    } else {

      // selector with multiple depth so we just want the last selector

      $el.addSelector(parts.pop());

      // find this down the parts

      $this = $this.findOrAppend(parts.join(' '));

    }

  } else {

    // we provided a specific element

    $el = $(element);

  }

  // append it

  $this.append($el);

  // return it

  return $el;

};

findOrAppend() takes a selector (I used it mostly with #ids) and creates a series of nested divs (if needed) that matches that selector.

For example, given HTML:

<div id="container">

  <div id="main"></div>

</div>

And we wanted to replace the contents of an element #submit_modal inside of it:

var $modal = $('body').findOrAppend('#main #submit_modal');

The first time its called, it actually creates the neccesary #submit_modal div and returns it. However, if it exists already, it will just find it using $.fn.find() and return it.

For modals, this allows me to ensure that the container exists first, then replace it with the contents of the modal that I’m fetching from the server.

this.helpers({

  // …

  showModal: function(path, selector, callback) {

    var context = this;

    this.showLoading();

    this.loadNotesInBackground();

    this.partial(path, function(form) {

      var $el = context.$element()

                .findOrAppend(selector);

      var $close = $('<img src="/images/button_remove.gif" alt="close" class="close_modal" />');                    

      $el.hide().html(form);

      $close.prependTo($el).click(function() {

        $el.slideUp(200);

        context.redirect('#', context.conditionsToURL());

      });

      if (callback) { callback.apply(context, [$el]); }

      // bind error handlers

      context.bindFormErrorHandlers();

      context.hideLoading();

      $el.slideDown();

      $('#main').slideTo();

    });

  }

  //…

});

Here I have a helper that fetches the view/template from the server using partial() and then situates its content using findOrAppend(). It also does me the favor of adding the little close icon in the upper right corner. A typical use is for the login screen:

this.get('#/login', function(context) {

 this.showModal('/account/login', '#main #login_signup.modal')

});

Analytics

It has to be said as well that I’m really excited about the burgeoning Sammy.js community. I’m lucky enough to have some other really smart individuals working on Sammy projects and sharing some of their code through plugins. Thanks to Brit Gardner and his Sammy.GoogleAnalytics plugin, adding analytics to the app was as easy as dropping in the file and adding one line to my app. That felt really really good. I hope more people will start sharing some plugins soon.

A lot more

There were a lot more discoveries over the months building this app then I can really share in a little blog post but needless to say, I’m going to try to bring the usefull and reusable stuff back into Sammy and plugins for everyone to use. If you want to hear more about it or have specific questions, dont hesitate to ping me on IRC or twitter or email the Sammy mailing list.

Highlights included:

• Going to RubyConf without actually going.
• Eating and drinking fine food and wine in Napa/Sonoma for 4 days non-stop. (Full list of vineyards and restaurants with menus on request).
• Spending time with my lovely wife.
• Seeing friends I don’t get to see enough.

Though this blog may tell a different story, I actually have been writing a lot of code as well:

• Most notably, the production, public-facing Sammy.js application I’ve been working so diligently on finally launched: Wejetset City Notes Interactive. I learned a ton writing and deploying it, and I promise to share a bunch of those lessons, soon.
• With the help of the amazing rvm I’ve started getting all my gems tested and working on Ruby 1.9. I think everyone should be doing the same, so if people are interested in my approach, maybe I’ll write a tutorial.
• I’ve even been porting other peoples gems to 1.9. Specifically I have a fork of the oauth gem that works on Ruby 1.9.1 without any dependencies. It should be merged and released to the master oauth gem shortly.
• It’s been a long time coming, but I’ve been working on a big rewrite of qadmin thats being used in production in a couple places. Its a lot easier to configure and extend and really just needs to have its documentation thoroughly updated before I can do a real release.
• I’ve also updated my portfolio to include links to my talks and some other new projects.

I’m hoping to get some more blogging done and OSS releases out in the next couple of days so stay tuned!

Quick note, I decided to use github pages instead of this here blog to post the tutorials. In the end, its just easier to post lots of inline code AND it will be easier to maintain with updates as the Sammy API changes.

I hope you enjoy it! I’m always appreciative of feedback and constructive criticism, so fire away.

I’m very happy to announce the next major release of Sammy.js. I’ve been working on this for over a month and the result has been a lot more changes then I expected but over all a smaller, cleaner core code base. Here’s a quick run through of the biggest changes. See HISTORY or the Commits for a full list and more detail.

Plugins

The biggest change, that resulted in a lot of little changes is Sammy.Application#use() which allows you to package and resuse application level code into ‘Plugins’. See the documentation on plugins for more detail. This also marks the start of an official selection of plugins, with two as part of this release and more on the way.

The default template system that used $.srender internally has been extracted out into a plugin. To enable almost the exact same functionality:

// somewhere in your HTML (after sammy.js): 
// <script src="plugins/sammy.template.js" type="text/javascript"></script>
$.sammy(function() {
  // include the Sammy.Template plugin
  this.use(Sammy.Template);
  
});

Events

Sammy.Application’s bind() and trigger() methods now use jQuery’s namespacing to bind to Events. This means that Sammy.Application can now easily catch events that bubble to it like ‘click’ or ‘focus’. The big awesomeness is that the callbacks for these bind() methods are always evaluated within a Sammy.EventContext so that even events triggered from outside the app can be handled in the same way as internal events.

var app = $.sammy(function() {

    this.bind('custom-event', function() {
      // this == Sammy.EventContext
      alert('Custom Event' + this.params['wha']);
    });

  });

  // the app is by default bound to 'body'
  $('body').trigger('custom-event', {wha: 'ZUH?!'});
  //=> system alert ZUH?!
  

Cleanup

With the advent of plugins, Sammy Core is now even smaller (8.9k minified). This is also possible because I’ve removed the former ‘classical’ inheritence code in favor of prototypal inheritence, which is a big win in terms of cleanlieness and global scope leakage.

See Also

I mentioned this on twitter, but I’m working on some new tutorials and screencasts about Sammy. If you have ideas/suggestions, dont hesitate to let me know. The first one should be up next week. I’m going to try to do them bi-weekly, we’ll see how that goes

Again, I’ve tried to be as thorough with inline API docs as I could so any changes should be in the clear. Thanks again to everyone who helped with this release and has supported Sammy recently!

I’ll be honest. When I created Sammy.js, It was more of an academic exercise then a means to an end. I had ideas for how it could be useful, and had some immediate uses for it, but the initial thought was ‘recreating Sinatra’s API in JavaScript’. Little did I know – with a little introduction and the work of some clever individuals, its real value would be revealed.

We’re at the dawn of a new age on the web, or maybe or horizon, or a precipice; the metaphor doesn’t matter, the point is, things are changing. Specifically, as browsers become more and more powerful, as developers we’re given new opportunities to rethink how we architect web applications. Whether or not some of the predictions of ‘the death of the traditional desktop’ are correct – whether or not the near future desktop is just the browser – we now have the power, without proprietary technologies (flash, etc) to create truly desktop like experiences on the web. Thats nothing mind-blowing, we’ve seen it coming for a little while now.

Ok, then: let me blow your mind.

Because of the great power that modern browsers provide us as Javascript developers a new paradigm of web development is arising. Lets take a look at the current/traditional model:

Here we have a traditional stack. The ‘power’ of the application lies on the server: our development platform of choice (Rails, PHP, etc) sits on top of our database of choice (probably relational, probably SQL). This server platform renders finished HTML and maybe decorates those pages with the use of our JS library and our application specific code (Your $(hit)). In this model we’re using probably at least 3 different programming languages and almost fully on the speed and reliability of our servers for getting data to the user. There’s probably also at least 3 steps in either direction between data and the user:

• User clicks a link on a page or follows a URL
• The request is sent to the server
• App receives request passes it on to Model/ORM layer
• ORM requests the data from the Database
• Database returns the data to the ORM
• ORM returns the data in a parse-able form to the App
• App converts it into user-readable format and displays it to user

Obviously, Rails and most other languages frameworks abstract a lot of this away, so we don’t really have to think in all these steps. They’re there, though.

Welcome to the new world. HTTP Databases and JSON Storage. The simple act of making the database and the browser more powerful on either end has destroyed the need for the middle tier. In the new architecture, Our database (JSON/HTTP based: CouchDB, Cloudkit) serves data as JSON directly to the browser. On the browser side we create a much smaller/tighter ‘controller’ layer with JavaScript. This handles the directing of the user to the right place, the displaying of the data to the user, and the conversion of user interaction into state + data. This middle piece is jQuery + Sammy.js.

In my presentation at jQuery Conf this past weekend (slides available here) I demonstrated this concept in a rather meta-tastic way. The presentation tool I used was called Swinger and it was written using CouchDB, CouchApp, and Sammy.js. The application logic was contained in a single JS file that used a Sammy application to do all the routing, getting data in and out of CouchDB and displaying it in a particularly pretty way. The coolest part about this whole thing is that even beyond taking out the middle layer, this implementation removes the traditional static file serving model, too. With the power of CouchApp and _attachments, the javascript and HTML files needed to serve the application are served directly out of the database. Its like CouchDB and Sammy.js were made for each other. Think about the new steps for this architecture:

• User clicks a link on the page or follows a URL
• Data is requested via AJAX from the server
• The server proxies to the database or processes the request directly
• The data is returned to Sammy.js as JSON
• Sammy.js uses the data it needs and displays it to the user

There are a number really amazing and exciting things to note here. First, notice how the application is written in JavaScript AND the data is JavaScript. The JSON store might actually be written in another language (CouchDB is Erlang, Cloudkit is Ruby) but we don’t really ever have to touch those. Personally, I really like JavaScript. Sure, I miss some of Ruby’s syntax and niceties, but I’ll give that up pretty quickly for something that still shares some of the similar good features (closures, loose typing) and has a ubiquitous deployment environment (the browser). Second, the end result is probably similar if not better to the end user, as we eliminate the need to reload the page at every request, resulting in a better perceived speed.

One of the provisions I gave for my talk is that “I’m less concerned with speed than awesomeness”. That rings pretty true here. I don’t have an architecture like this running in production and getting hit like twitter. I can’t really speak yet to how well it ‘scales’ or how it preforms under load. I CAN tell you about how awesome it is and how easy and fun it was to develop swinger with Sammy. That’s really all I need to know right now.

• Sinatra-Sammy: Inspired half by potential usefulness and half by a dare from binary42 at the first meeting of NYC.js, sinatra-sammy is a sinatra module/plugin that includes sammy.js makes multi-page apps appear to be single page (with deep-linking etc) while maintaining the SEO and other benefits of a multi-paged, normal app. Make sense? No? Yeah, OK. I’m working on putting up a good example, for now you can clone the repo and checkout the included test app.
• Speaking of NYC.js, I was honored to be the first speaker and did a little presentation about Sammy. Slides are viewable here
• Vegas + Gembox are now windows friendly. It took a bunch of hacking, specifically around the daemon-ization (Kernel.fork is not natively implemented on win32) but windows users can now use Gembox just like their Unix based brethren. Windows users can now also, and should, make use of Vegas for creating Rack based executables.
• I’m giving an updated version of the talk I gave at GoGaRuCo “Sinatra: The Framework Within” at Ruby Kaigi. I’ve been hacking on a secret and useful project and hopefully I can wrap it up on the plane and present it at the conference.
• I got a new camera. I’ll be posting a lot of drool worthy food photography on flickr.

For anybody attending RubyKaigi, please come find me and lets hack/talk/eat ramen.

My favorite feature from this update might be the simplest.

Rendering partials now uses a special swap() method on Sammy.Application. By default it just uses jQuery's html() method to swap out the old content of $element with the new content. The power though, is you easily override this to provide a cool transition when a new partial is rendered.

var app = $.sammy(function() {
  
  this.swap = function(content) {
    var width = $(window).width();
    this.$element()
      .wrapInner('<div class="inner"></div>')
      .children('.inner')
        .animate({queue: false, left: "-" + width}, 400)
        .remove()
        .end()
      .html(content)
      .css({left: width})
      .animate({left: '0px', width: width}, 400);
  };
  
  this.get('#/user/:name', function() {
    this.partial('name.erb', {name: this.params['name']});
  });
  
  //...
});

Now, when you go to '#/user/aq' or similar, it will use the swap method to do a nifty transition, instead of ye old html().

Theres more examples and Sammy on the way. Come join the mailing list or hang out in irc to learn or contribute.

• Two weeks ago I released Sammy and since then its been getting a lot of great feedback. It was mentioned in a github rebase and Nick Plante wrote a great post on DDJ. I’m really impressed with what people have done with it so far. Alex Lang, especially, has fulfilled a vision I had by embedding Sammy as the client controller for a couch app. Also make sure to check out his Boom Amazing presentation tool using Sammy as the proxy for controlling a slideshow contained in a massive SVG. I’m crossing my fingers that they’ll be a video of his RailsWayCon presentation. Sammy also has a mailing list now and (hopefully) soon a dedicated IRC room.

• Gembox was featured as a great tool for viewing RDocs on RubyInside. This inspired a little flurry of activity and commits with more to come. Thanks to Samuel Elliot Gembox works in passenger pane.

• EngineYard finally posted the videos from Scotland on Rails and you can view my talk in full quicktime glory. Really you should just take the whole weekend and watch all the videos. LOTS of fantastic talks.

• Goruco is tomorrow! If you’re attending and reading this, please come find me. I’ll probably be milling around with a bearded dude (@mrb_bk).

Get Started

• Watch a Screencast (iPhone)
• Read the Introduction
• Read the Docs
• Follow @sammy_js
• Join the mailing list

The Story

About three months ago, when I was knee deep in hacking and playing with Sinatra I had this weird moment as I woke up one morning: “What if I could build Sinatra in JavaScript?” At that point it was just a challenge – I had just started doing almost full-time JS for a client and it seemed like a fun project.

As I started to actually implement it (slowly in short spurts on the weekends), I realized that using the power of JavaScript’s closures and jQuery’s powerful event system, this could be something more then just a ‘clone’. It could actually be . . . useful!

With that in mind, I set out to actually make is usable. I cleaned up the code, I wrote some example implementations, and most importantly – I documented the shit out of it.

I’m pretty excited about it (can’t you tell?) especially about its possible uses for structuring applications on the front-end for RESTful Databases and services. Embed it in a CouchApp to build an entire application in JavaScript while having access to a full range of documents/querying abilities.

The Future

I’m going to continue refining and adding examples. Please feel free to email me or contact me through github with questions/feedback.

Happy Friday!