Chalice - The Holy Grail
A small framework on top of CoffeeScript Backbone and Node to render
apps on the client and server.
Installation
If you haven't already done so, install grunt-init and grunt-cli
.
npm install -g grunt-init grunt-cli
Once grunt-init is installed, place this template in your ~/.grunt-init/
directory. It's recommended that you use git to clone this template into that directory, as follows:
git clone git@github.com:shanejonas/grunt-init-chalice.git ~/.grunt-init/chalice
(Windows users, see the documentation for the correct destination directory path)
mkdir myproject
cd myproject
grunt-init chalice
Note that this template will generate files in the current directory, so be sure to change to a new directory first if you don't want to overwrite existing files.
Then you can run
npm install .
grunt
And you it will build/serve/watch for you. You can go to
http://localhost:3000
in your browser to view the page.
What is the holy grail of web development?
I'm sure everyone has a different view but heres mine:
- Share code across the client/server seamlessly
- Boot application on the server to generate the html
- Boot application on client to progressively enhance
- Dont block the critical rendering path to break the 1s time to glass barrier
- Snappy Jank Free Applications
- 100/100 page speed
And for development:
- CoffeeScript + SourceMap debugging
commonJS
modules and npm
for package management- Rebuild on file change (selectively rebuild js or css when source files change)
live-reload
out of the box- All
node.js
tool chain - Not implemented yet: Stylus Source Maps
for debugging in chrome dev tools.
Thin Libraries
This documentation site and the libraries (backbone + chalice + handlebars + zepto) are only 29kb gzip/compressed.

String Concatenation and Dom Creation Speed
Dom creation libraries are getting faster. But the clear winner is still concatenating strings. This also makes it easier to work with views on the server.
Don't block rendering path and Progressive Enhancement Speed Gains
By having the markup served on the server and loading javascript asynchronously you take it out of the critical
rendering path, this gives you 5x faster perceived loading time. From the twitter
blog
There are a variety of options for improving the performance of our JavaScript, but we wanted to do even better. We took the execution of JavaScript completely out of our render path. By rendering our page content on the server and deferring all JavaScript execution until well after that content has been rendered, we've dropped the time to first Tweet to one-fifth of what it was.
The Approach
I'm pretty opinionated with my CommonJS dependencies here but it just makes sense
if the end goal is to get Backbone running on the server. My approach is
to provide a thin layer on top of Backbone that allows it to run fast
and seamless inside node.js
. The templates are handlebars and the
language is coffeescript. This approach differs from rendr in
that I'm not rewriting the routing layer. Simply overwriting
Backbone.Router::route
to make an express route and call the same
route on the server. Something like:
Backbone.Router::route = (route, name) ->
app.get '/' + route, (req, res) =>
@[name] _.values(req.params)
This leaves the MV*
implementation up to the developer.
The backbone docs say it best:
References between Models and Views can be handled several ways. Some people like to have direct pointers, where views correspond 1:1 with models (model.view and view.model). Others prefer to have intermediate "controller" objects that orchestrate the creation and organization of views into a hierarchy. Others still prefer the evented approach, and always fire events instead of calling methods directly. All of these styles work well.
How The View Works
The View
overrides _ensureElement
to try to first get the element
out of the DOM. Calling super wont create anything if @el
is defined but when
it isn't it will create the element using jQuery. This method does nothing on
the server.
_ensureElement: ->
if Backbone.$?
@el = @getElFromDom()
super
When calling render on the view, on the server it will return a wrapped
string, and on the client side it will return this
as usual.
render: ->
unless @$el?.html @toHTML(no)
return @toHTML(yes)
@afterRender()
this
Usage:
View = require 'chalice-view'
view = new View
# client side
view.render()
=> view object
# server side
view.render()
=> '<div class=\'view\' data-cid=\'view1\' ></div>'
The Grunt Build System
Grunt is becoming a popular build tool, and for good reason. If you
haven't seen grunt before, check the getting started guide. Running
grunt
out of the box will give you a dev server on localhost:3000
that will selectively rebuild and livereload in the browser when .coffee
or
.styl
files change.
grunt
- Alias for "default" taskgrunt default
- Alias for "clean", "stylus:dev", "browserify2:dev", "express:app", "livereload-start", "regarde" tasks.grunt build
- Alias for "clean", "stylus:build", "browserify2:build".grunt serve
- Alias for "express:app", "express-keepalive" tasks.grunt clean
- Clean files and folders.grunt devtools
- A GUI For grunt in chrome devtools

Generators
You can use the following grunt tasks to generate new views/models/routers:
grunt generate:view --name=MyView
grunt generate:model --name=MyModel
grunt generate:router --name=MyRouter
grunt delete:view --name=MyView
grunt delete:model --name=MyModel
grunt delete:router --name=MyRouter
Sample output:
$ grunt generate:router --name=MyRouter
Running "generate:router" (generate) task
File written to: ./src/routers/myrouter.coffee
File written to: ./test/routers/myrouter.coffee
Done, without errors.
$ grunt delete:router --name=MyRouter
Running "delete:router" (delete) task
File deleted: ./src/routers/myrouter.coffee
File deleted: ./test/routers/myrouter.coffee
Done, without errors.
You can get a list of all the tasks by running grunt --help
.
Examples Applications:
(Note that these examples may still be pointing to older npm packages for Chalice libs)
Contributing
Add unit tests for any new or changed functionality and Follow the
CoffeeScript style guide
Running the tests:
npm test