Rails Vs. The Client Side
summary
Compares the Russian Doll server-rendered HTML approach (aggressive cache keys, Turbolinks, occasional JS) with a Rails API that returns JSON to a client MVC, shows code-level differences, and measures tradeoffs in speed, duplication, and complexity. Demonstrates an Ember map app where client-side state and interactions keep round trips low and work well, and a hybrid using ActiveModelSerializers that sends JSON but keeps server logic. Recommends choosing by representation stability, client interaction patterns, team skills, and caching needs.
AI-written summary · about
chapters (21)
- 0:00Start
- 0:59I want my users to have a "rich client experience"
- 2:56The locus of innovation is in the client
- 4:32Hybrid JS App
- 10:53Avoiding Complex MVC Structures
- 11:57your application live?
- 14:49How can you best manage complexity?
- 15:35Simplicity is using simple structures
- 18:03Server-side uses simpler JavaScript structures
- 18:15distinct output modes
- 18:48But, business logic can be duplicated
- 20:58proportional to user clicks
- 21:22proportional to new data requirements
- 23:17Server style is optimized for least disruption to Rails
- 24:02Client style is optimized for simplicity of Server logic
- 25:07Is the representation of your data stable?
- 27:37components interact?
- 28:29What do you already have?
- 30:01Will a hybrid approach work?
- 31:38There's no excuse for re- downloading assets
- 32:12It'd help if the JS frameworks were more polished
related talks
34mYour Front End Framework is Overkill - Server Side Javascript w/ Rails
36mRails is Obsolete (But So's Everything Else)
38mThe Front-End Future
35mCrossing the Bridge: Connecting Rails and Your Front-End Framework
32mWhere did the OO go? Views Should be Objects Too!
40mUsing Backbone.js with Rails: Patterns from the Wild
40mFRONTEND CHOICES
48mClientside templates for reactive UI