Create a gist now

Instantly share code, notes, and snippets.

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?

Complexity

  • 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

Speed

  • 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?

Takeaways

  • There's no excuse for re-requesting assets
  • It'd help if the JS frameworks were more polished
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment