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