Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Rails vs. The Client - Noel Rappin (@noelrap) - RailsConf 2013

Rails vs. The Client

Noel Rappin (@noelrap)

  • Problem: Want users to have "rich client exp" (even though clients don't know what that means)
  • @dhh and @wycats offer different opinions (document vs json api)
  • But @noelrap just wants to write an e-commerce site
  • We tend to split stuff up into client stuff and server stuff between the user and data
  • @dhh says that the focus is on the server. The app lives on the server
  • @wycats says that the client is the focus, and the server just does whatever the client can't do (i.e. validation, persistence)
  • Where does the heart of your application live?


  • Various definitions of simplicity:

    • being able to deal with components separately
    • using simple structures
    • consistency
  • Server side can be simple, but has three distinct modes (HTML, JS, JSON)

  • Client side has generally one mode of interaction, but business logic can be duplicated

  • It's not clear that one side or the other requires less code


  • Both sides claim speed

  • Server side interaction is proportional to user clicks

  • Client side interaction is proportional to new data requirements

  • Server style is optimized for least disruption to Rails

  • Client style is optimized for simplicity of server logic

Questions to ask to decide where to place your emphasis:

  • Is the representation of your data stable?
  • Is interaction with the server primarily notification?
  • Do client components interact?
  • What do you already have/know?
  • Will a hybrid approach work?


  • There's no excuse for re-requesting assets
  • It'd help if the JS frameworks were more polished

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.