As easy as Rails
summary
Claim: Rails is the wrong default for fat‑client JavaScript single‑page apps and the proof is concrete. Demonstrations include using lineman plus Node and Grunt to get fast builds and test runners, API proxying and API stubbing to develop the client independently, a rails-lineman gem for integration, measured file I/O speedups (about 20–30×), CI and deploy outputs as single concatenated minified assets, and a real case where splitting a monolith cuts test time from ~30 minutes to ~10.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:11Cupcake analogy and Rails workflow
- 3:58Ruby devs overusing Rails client-side
- 5:41JavaScript tooling evolution
- 8:12Rails extracted from Basecamp
- 10:36HTML vs JS user interfaces
- 12:44Monolithic Rails problems
- 14:31Late extraction costs more
- 15:53Making JavaScript development easier with Lineman
- 19:43Lineman workflow and feedback
- 21:51Lineman deployment and starter
- 24:18Grunt build tool and ecosystem
- 25:19Breaking monoliths client-server
- 26:45API proxying and stubbing
- 28:29Faster test builds split apps
- 30:14Rails Lineman plugin and conclusion
related talks
34mThe "Rails of JavaScript" Won't be a Framework
36mRails is Obsolete (But So's Everything Else)
34mRails: Still the Best Framework for Bootstrapping
40mMaking a Rails App with 140 Characters (or less)
56mFireside Chat
01h 09mRails 3 ...and the real secret to high productivity
23mRails Frontend Evolution: It Was a Setup All Along
57mFuture of Developer Acceleration with Rails