QuirkeyBlog » Sammy

Sammy 0.7: Boy Meets Girl

AQ — Mon, 01 Aug 2011 13:00:07 +0000

Another long time in the making, Sammy 0.7 is here and its sexy. Check out the HISTORY and the full Changes to get the full details. The Boy of “Boy meets Girl” is Sammy, and the Girl is HTML5.

Download it!

It’s probably seemed like Sammy development had stopped a while ago. With all the other similar frameworks bouncing around these days, I’ll admit there were some dark days of doubt leading up to this release. In fact, most of the code that comprises Sammy 0.7 has been in the master branch for over 4 months. However, development and my belief in this project hasn’t wained, its more just that I’ve been completely consumed by my work at Paperless Post (and in a very good way). One of the benefits of leading the team there has been the ability to push the boundaries of what we can do with our code and our libraries. We use Sammy extensively at PP and I was super excited to have a use case and a way to develop and test this latest version and all its power. The big addition of HTML5 History support has made the big new app we’ve been working on for the past 6 months seamlessly deep-link between full urls and hash urls between multiple browsers. We’re pretty psyched about it.

History is History

Despite which side you fell in on in the Great hashchange debacle of '11 you can’t argue with the pure fact that regular URI paths are just better than hash (#) paths. The makers of the great browsers of the world and the HTML5 History spec have a solution that attempts to appeal to everyone. The premise is simple – create a JS API for manipulating the full path of the current browsers location without forcing a page reload. Meaning, you can tell the url to change from http://www.example.org/one to http://www.example.org/two without having to reload the window, and allowing you to then manipulate the state of the page. Seems sort of like a dream, doesn’t it? Not only that but it really is a perfect fit for the way Sammy manages state and how Sammy applications are already built around routes and paths. I knew this was the case the first time I saw it, but I was unsure how to mix it with the existing hash based routing that works (and would have to persist) across every browser, not just the latest and greatest.

I believe Sammy 0.7 presents a pretty solid solution. Now, instead of routing on paths that look like #/mypath you just route on paths that look like a server side path /mypath

var Sammy('#container', function() {

  this.use('Mustache');



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

    this.partial('templates/index.mustache'); 

  });



  this.get('/:user', function() {

    this.load('users/'  this.params.user  '.json')

        .partial('user.mustache');

  });



});

The beauty and magic of above is a those routes will match both quirkey.com/#!/aq and quirkey.com/aq and execute the user route as expected. I’ve created a simple working example for you to play with at http://pushstate.quirkey.com/ (source here). We’ve been using and testing this for the past months and I can say its pretty solid (and pretty awesome).

There are some known caveats:

History only works in latest and greatest browsers (Chrome, FF5, Safari 4) but support for it is growing. Ben Cherry and the team at twitter also found some issues with certain versions of webkit and URLs getting out of sync (though its been resolved
Your server side needs to be able to handle whatever urls you’re changing to. This means that if you route/redirect to something like /path/one/two in Sammy, the server better be able to handle that url as well and point you in the right direction. Otherwise, refreshing the browser will lead users to a 404 or worse. The sammy-pushstate example has a pretty clever way of dealing with this in couchapps. It uses CouchDB rewrite rules to route any url request (minus the key files) to the index.html page (and hence allows sammy to handle the routing).
Currently, mobile webkit (aka Mobile Safari and the Android browser) report support for pushState/History when in fact they don’t have it. Since I’ve tried to keep browser sniffing out of the core Sammy repo, it currently doesn’t detect for this. You can manually disable push state per application, though, and do the browser sniff yourself if you plan to use your app on mobile.
This causes some possible breaking changes for upgrading Sammy apps. If you previously did any routing (or path checking) the path reported in a route (EventContext.prototype.path) is now the full path starting at / not just the path beyond the hash. Also HashLocationProxy was renamed to DefaultLocationProxy.

That being said, its a pretty awesome feature and it makes writing Sammy apps really powerful when exposed to the full path. Theres more information in the API docs here.

Templating engines are so 2010

One thing thats frustrated a number of Sammy users is that previously all the template plugins (aka Sammy.Mustache, Sammy.Handlebars, etc) included the source for the engine in the plugin. In the beginning, I thought this was a great idea because it reduced the number of potential headaches and complaints of ‘Mustache isn’t working (because I didn’t include the source)’. However, what turned out to be a bigger issue was keeping up with all the plugins and their individual rapid development cycles. Because of this, all templating plugins (with the exception of Sammy.Template and Sammy.Meld) are now just simple wrappers and expect you to include the respective templating library in your own source. This also makes the case of using Mustache outside of Sammy in the same source/app as a Sammy.Mustache application a lot easier. For the sake of making the transition easier, the latest version of all of the engines is included in the repo (in vendor/templating).

More!

Those are certainly the biggest things with this release but its also not the whole deal. There were 12 other changes, bug fixes, and new plugins written by 10 different contributors! I can’t thank the people who use and contribute patches and ideas back to Sammy, enough. You guys rock.

Get your Sammy.js Stickers

AQ — Thu, 17 Mar 2011 23:47:15 +0000

Thanks to the awesome folks at stickermule I now have a big stack of Sammy.js stickers I want to share with all you fine folks. There are a couple ways to get them:

I’ll be at JSConf (duh) and a bunch of other meetups and get togethers until then, so just harass me for one when you see me.
If you live outside of NYC or the Bay Area, just send a self-addressed stamped envelope (MAIL – I KNOW CRAZY) to:

Sammy.js Stickers
c/o Paperless Post
3130 24th St, Unit C
San Francisco, CA 94110

I’ll send you more than one, and you can sport it on your laptop like yours truly:

#-ish

AQ — Thu, 10 Feb 2011 23:19:15 +0000

I’ve been sitting back and watching from the sidelines this week as a lot of smart people [de]ride the hash (or more specifically the #!). Most of this has come from the recent switchover of the gawker media properties to using a new URL structure based on the !# and a JavaScript app to load content. As someone who’s invested a lot of time into the # I want to make something clear – as with many things in life, the hash is no different: It’s not broken, its how you use it.

Deep Linking

Let’s take a little trip down memory lane, shall we? My first interaction with the ‘#’ as a method for getting at specific content (not as an anchor tag) was working in the ad/interactive space and with a lot of Flash developers. On every proposal or statement of work was a line about ‘Deep Linking’. In this case it meant plugging in swfaddress and wiring it up to your fancy Flash slideshow or fashion showcase. The point of this all was that when you clicked on the 8pt text in the menu that said ‘MENS BLOUSES’ you would be taken to the photo of a puffy shirt and the url would change to ‘#/items/puffy-shirt’. When you refreshed the page, or sent the link to your friend you would be taken immediately to the puffy shirt and be able to bask in its frilly glory without navigating through the 8pt menu again.

This was a big thing! Big, as in exciting and awesome, because it meant you could build relatively complex Flash applications, felt ‘stateful’ somehow. You would navigate somewhere and you’d be there, not in the middle of nowhere.

An important thing to note here is that this was not for Google. It was Flash. Google can’t crawl Flash. The point was allowing people to ‘Skip intro’ and have them feeling that this crazy interactive experience wasn’t all that different from there normal browsing. For crawling and SEO there were a host of other strategies – META tags, ‘ghost’ static HTML sites, etc. – and these were deployed alongside ‘Deep Linking’ as two different strategies trying to accomplish different things.

AJAX FOR THE PEOPLE

We’ve moved on (sort of) from the days of 8pt menus and pixel fonts. The old problem is new all over again. Now we’ve built these applications that rely on JavaScript being enabled to construct our site and fetch our data and animate our menus. Awesome! Its HTML5-tastic. At some point, we discovered the same problems that we had with Flash. Namely, when you’re loading all your content with AJAX and loading it onto the page based on clicks, you get lost in a sea of asynchronicity. What state are you in? Clearly, there’s an easy way to solve this – use the ‘#’ to route URLs without reloading the page and Deep Linking directly into content. I created and continue to work on Sammy.js, partly, as a solution to this problem. You want your application to feel interactive and fluid, you want to avoid page reloads, but when the user does reload, or copy the link, they should be taken back to the same place.

Then, confusion sets in. In a world where the only way people get to Facebook is by Googling Facebook you want your site to be ‘googleable’. This presents a problem: your application is dependent on javascript and ‘#’ and google don’t know about those. Well then, brotha, Google’s got your back. All you have to do is put a little ! after your # and tell google where to fetch your content and it’s like BLAM: SEO.

Except, no.

This is the part where I want to shake everyone. Like physically shake and be like “YOU! YOU’RE MISSING THE POINT”.

There are two different things. Crawlability and Deep Linking are two different things. For different reasons and different goals, and conflating them not only makes it hard on users, but also makes it hard on developers. You end up doing neither of them right.

I’ve been asked about a million times now, “How do you do SEO with Sammy?”. The answer is never simple, because its the wrong question. The question should really be – “If I’m really concerned about SEO, the crawlability of my site, and the persitance of my links should I use Sammy?”. The answer without a doubt is No. I’ll be the first one to say that Sammy and other similar frameworks are not for every site. Period. Theres no reason that your blog or your news site needs to load all its content with AJAX or needs to use ‘#’ to route for state. An important disctinction in what I’m trying to say is that its “you shouldnt have to” not “you never should”. If you’re building a site like Gizmodo you should pretty much always at least START with good ol’ semi-static pages that dont require JavaScript and load at old-fashioned URLs. This is not to say that you can’t build an application on top of these static pages that is more dynamic and interactive and relies on JavaScript.

Sammy and the ‘#’ are for applications. It provides a way to maintain state in a world where you can require JavaScript and even require the presence of certain browsers. If you’re an application, that requires login/signup you can make a number of demands of your users. You also probably dont even want the crawlability. You’re using ‘#’ to maintain state for a specific user in a specific session.

Outside of the world of the ‘application’ you really, really shouldn’t rely on JavaScript being there for your site to work (at least at a basic level). Jen Lukas has already talked really eloquently about why thats the case. I believe that this is where a lot of the recent frustration has come from, and really it should be directed at the use case, not the overall usage of ‘#’ for state. There have been some fingers pointed at Google for making this conflation possible, and I tend to agree.

How to do this right

I’m not going to go into detail about what framework you should use or how to lay out your app. Those are fairly complicated and my opinions could take up a couple blog posts. However, the basics are straightforward.

First, you need to determine some things about the structure of what you’re building and what your content is. Are you building an ‘application’ or a site? Does your content need to be searchable and reachable by the entire web? Do your links require true permanance and will changing them in the future “break” traffic to your site?

If you need searchability and permancance and you’re not building an application, the real best way to approach is to build your site as if JavaScript doesn’t exist. The fact is that there’s still a chunk of users for which that will be true. Not only because they’re using old browsers, but they’re on phones, or they’re on assistive devices or they just turn JavaScript off for ‘security’ reasons. If your site works this way and looks pretty decent (meaning its readable and the content is accessible) then basically you’re good. Golden. Your site works as expected, but maybe not all AJAAAAZZAY. It’s at this point that it’s acceptable to build a layer on top of your existing site, sprinkle the magic dust.

Twitter is an interesting example here because they took what was at its core really an information site, not all that different from a blog and turned it into an application. The questions of URL permanence are really gray here but I dont find myself hating it at all.

Web standards are at the core of this debate. Many make a strong argument that concept of the URL and HTTP is here for a reason, that URLs have worked and continue to work. I think instead of fueling FUD, we should get back to the work of building a better standard and a better web.

A brief epilogue on pushState/HTML5 History

A lot of people are pointing to the new HTML5 History API as a much better solution to this problem. I agree with reservations. First, the browser support for this currently isn’t very wide, and certain browsers that do support it have buggy/broken implementations. The bottom line is that it will work in some places, but not most, and this will probably be the case for years to come. That said, it is really exciting and I’m working on built in support for it in the next version of Sammy.js. I have other reservations, too – namely I think that not all hashes are created equal and in some cases the state you want to represent is really the state of a specific page not a seperate page that really requires a fully seperate URL.

SammyJS.org

AQ — Thu, 27 Jan 2011 19:50:12 +0000

Sammy.js is finally official because now we have a real dedicated website: http://sammyjs.org. It only took two years.

Along with the website the logo I designed before JSConf.eu last year now has an official place to proudly be displayed. Since we’re a REAL project now, we’re also starting up the SWAG train, so logo stickers are on their way.

The biggest change with the new site is the API documentation has been significantly cleaned up. The text is still being generated from the code itself, but now we have easier navigation, the ability to keep multiple versions of the docs (generated per release) and probably the most fun – method level comments powered by Sammy users and contributors, DISQUS. I’ve made good use of the method level comments featured in sites like apidock so I’m very excited to see if the community participates here.

Sammy.js is growing up and its been so much fun to see how and where people use it. I don’t see that many big changes in the future for it before we push a real 1.0 (See a brief roadmap on the mailing list) and a big goal is to get push the big one oh before this year’s JSConf in Portland.

Getting to know Sammy.js: Helpers

AQ — Thu, 04 Nov 2010 12:07:08 +0000

For part of this month’s writing I’m going to write focused posts about features of Sammy.js that people may not know about or have used. In the end I hope to compile these into part of the new Sammy.js site.

A question came up on the mailing list recently about overriding previously defined routes after struggling thinking of how to do this with the current codebase, the answer was simple: Use helpers!

Coming from Sinatra or Rails the idea of helpers might be associated with just “view helpers” – methods added to the controller which are passed down to the view to help refactor/encapsulate common view logic. In Sammy.js helpers are really a way of refactoring common logic out of routes and into a reusable named method.

Refactorin’

In any app you’ll have startup code or code that needs to be run for every or multiple pages (routes). In Sammy this might looks like:

$.sammy(function() {

  

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

    if (this.params.grid) {

      this.$element().addClass('grid');

    } else {

      this.$element().removeClass('grid');

    }

    this.partial('index.html');

  });

  

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

    if (this.params.grid) {

      this.$element().addClass('grid');

    } else {

      this.$element().removeClass('grid');

    }

    this.partial('user.html');

  });

  

})

A contrived example, but you can tell we’re doing almost the exactly same thing in each of the routes. A common JS convention and something you could do pretty easily here, would just be to extract the functionality out into a closure/function and call it for each route.

$.sammy(function() {

  

  var displayGrid = function($element, display) {

    if (display) {

      $element.addClass('grid');

    } else {

      $element.removeClass('grid');

    }

  };

  

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

    displayGrid(this.$element(), this.params.grid);

    this.partial('index.html');

  });

  

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

    displayGrid(this.$element(), this.params.grid);

    this.partial('user.html');

  });

  

})

This works, it prevents global leakage by declaring it inside the app, and it gets rid of a number of lines of repetitive code. However, we’re still passing a bunch of route attributes into the closure. This is where helpers can shine.

$.sammy(function() {

  

  this.helpers({

    displayGrid: function() {

      if (this.params.grid) {

        this.$element().addClass('grid');

      } else {

        this.$element().removeClass('grid');

      }

  });

  

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

    this.displayGrid();

    this.partial('index.html');

  });

  

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

    this.displayGrid();

    this.partial('user.html');

  });

  

});

This looks a lot cleaner to me. You might not love this but it makes some things really magical. By making displayGrid a helper it automagically has access to the context of the current route. That means that just like the route’s callback, it has access to everything in the EventContext including params, redirect, render and other helpers. This is important, because it basically allows you to extract common code from routes into helpers and then refactor those helpers even further into other helpers.

stOOPid inheritance and mixins

Helpers are actually just methods on the app’s EventContext prototype, and event though there’s no classical inheritance with super’s and all that jazz we can do some fun OOP-like magic.

In the example from the mailing list, we wanted to override an application’s existing route with a new route. Though the way routes are stored and handled makes it difficult on the app level, doing it on the helper level is EZ:

// initializing a new app

var app = $.sammy(function() {

  

  this.helpers({

    // define a helper to load the index as the default behavior

    loadIndex: function() {

      this.partial('index.html');

    }

  });

  

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

    this.loadIndex();

  });

});



// override the specific helper, and hence the index route

// we can also do this by calling `helpers()`

app.helper('loadIndex', function() {

  this.partial('specialindex.html');

});

use() is how Sammy includes a plugin in an app. A plugin is really just another app function, though, that get’s evaluated at the time you use() it. In fact, when you call $.sammy() you’re just creating a new instance of Sammy.Application and then calling use() on it with the app function. This is a simple way of doing “mixin” style inheritance. A plugin can do anything an app can, including and especially helpers. So with multiple apps we be all like tag team: OOP there it is

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

  this.helpers({

    playCatchPhrase: $.noop

    // noop there it is 

    // this is sort of like an abstract method

  });

  

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

    this.playCatchPhrase();

  })

});



var atlanta = function() {

  this.helper('playCatchPhrase', function() {

    alert('whoomp there it is!');

  });

};



var la = function() {

  this.helper('playCatchPhrase', function() {

    alert('do the hump!');

  });

};



$.sammy('#hiphop').use(la);

// get '#/catchphrase' //=> 'do the hump!'

Thats still pretty simple, though combining these ideas is actually pretty powerful. Almost all of Sammy’s existing plugins are based on this simple approach. I’m hoping soon, it can get even more abstract and complex. Why not a Sammy.Auth that handles displaying/posting/and doing all the basic authentication? You could use helpers for most of the dirty work and then one could just override the defaults in their specific apps. You could even create another set of plugins that were different displays or authentication systems that override the simple base methods. Do it! ( so I dont have to )

Sammy.js Tutorial finally updated for 0.6

AQ — Tue, 02 Nov 2010 05:45:46 +0000

The title really says it all but this has been a long time coming. Since the RenderContext changes in 0.6 there were some incompatibilities between the code in the tutorial and what actually worked. It wasn’t just an easy swap of method names – I spent some actual time today rewriting some big chunks of the first tutorial and adding an introduction to the RenderContext. The example app (The JSON Store) was also updated.

I’ve been thinking about part III and beyond as well, but thats for another day. I hope at least this fixes a lot of the confusion for people delving into Sammy for the first time.

Check out the new tutorials here.

Sammy 0.6: California Suite

AQ — Thu, 02 Sep 2010 13:18:12 +0000

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 $.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!



Sammy.js, CouchDB, and the new web architecture
AQ — Tue, 15 Sep 2009 13:44:38 +0000
	UPDATE: My slides and a protected instance (will open up for play soon) or swinger, available here 

	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.