Challenges

End user-facing challenges

Slow initial page render
Performance issues/quirks between maintaing two apps in one.

Maintenance/dev happiness challenges

Duplicating logic on client/server
Client-side code is a second-class citizen
Testing client-side code sucks

Why not other existing solutions?

Derby.js & Meteor

Takes control of the full stack
Tied to real-time
Meteor doesn't render on the server
Very large frameworks still well in beta
We've never used anything like it before

Rendr

Self-proclaimed experimental prototype with lacking documentation
Abstracts away server/client environments which feels leaky
- What is a Backbone view on the server?
- Beyond simple route & fetch* logic there isn't much shared "controller/glue" code, more work to learn Rendr conventions.
Unnecessary kitchen sinks

*simple route & fetch logic example

route '/artwork/:id', ->
  new Artwork(id: 'foo').fetch success: -> 
    renderTemplate('templates/artwork_initial_tmpl.jade')

Martsy's approach

Sharing code

Doesn't abstract away the server/client glue
Focuses on modules that can sanely be shared in both environments
Overrides Backbone.sync to have a server-side HTTP adapter
Shares data between environments by bootstrapping it with sharify

Example of shared code flow

1. An express route instantiates a Backbone model and calls fetch

2. A server-side only template bootstraps the model.toJSON()

3. Client uses the same Backbone model and populates it with the bootstrapped data

4. A partial template that can be used on the server and client is required with jadify and re-renders a portion of the page.

Modularization is king

Organizes assets into /components and /apps instead of all in /stylesheets /scripts
- Components: Logical groupings of stylesheets, client-side js, and templates
- Apps: A page or a logical group of pages (e.g. the "Fair" app)
Requires all around
- Group assets into smaller packages
- Use npm to manage 3rd party modules client/server or both

Challenge accepted!

Initial page rendering

Renders on the server an API request or two first then lets the client-side take over.

Client-side performance and quirks

Client-side code is actually rather light-weight and split up so it can be loaded piece-meal
Separate from Gravity means all that baggage is left behind

Client-side second class citizen

Components and Apps modularize code for easy re-use and refactor
Browserify and npm make a package manager and module definition for server & client
Asset compilation times can be optimized via smaller packages and simple middleware

CSS spagetti

Microgravity avoids a lot of pain in managing CSS by following two simple rules (thanks @gib):

1. ALWAYS namespace class names (e.g. by component or app name)

2. If you don't namespace, scope by a name-spaced selector

e.g.

.artwork-app-suggested-artworks
  li
    border-bottom 1px solid #ccc
  img
    width 100%
  h3
    avant-garde()

Super slow integration suite

Headless browser using zombie.js
Stubbed Gravity server using antigravity

Unit testing client-side code

Unit test client-side code in node.js using benv
Browserify and Backbone ensure modularity in code and less dependence on globals
Sinon makes it easy to stub things like Backbone.sync for ajax calls

What's next?

Open source modules and projects

backbone-super-sync - Server-side Backbone.sync adapter using super agent.
benv - Library of helpers to test client-side code in node.js
bucket-assets - Small utility that uploads a folder of assets to S3
sharify - Tiny module that formalizes bootstrapping data and sharing it server/client in browserify
artsy-node-boilerplate - Generic stripped down version of these patterns and module to easily get started
flare - Open source iphone.artsy.net inspired off Microgravity

craigspaeth/gist:7031917