The Front-End Future
summary
Argues that choosing thick client (Backbone/Ember) buys faster, more responsive UX at the cost of more complex development, harder integration tests (Selenium), and a painful first-page bootstrapping penalty that caused Twitter to roll back some pages; highlights crawlability problems with Google’s hashbang approach. Recommends REST APIs for decoupling, parallelized JSON requests, caching, and optimistic updates. Notes Meteor’s client-centric claim is risky, Rails API + active_model_serializers exist, and JavaScript jobs are growing versus Ruby.
AI-written summary · about
chapters (9)
- 0:00Thick client web dev
- 2:12Thick client challenges
- 8:30REST and thick client
- 13:46Speed and UX in thick apps
- 17:16Future-proofing considerations
- 21:52Ruby/Rails career impact
- 25:47Debunking thick client myths
- 31:24JavaScript values and community
- 37:01Final thoughts
related talks
40mFRONTEND CHOICES
38mEmbrace the frontend revolution
21mFrontend-centered Development: the Future of Web Development
29mThe Front-end Takeover
34mYour Front End Framework is Overkill - Server Side Javascript w/ Rails
36mRails Vs. The Client Side
34mWe need to talk about the front web
23mRails Frontend Evolution: It Was a Setup All Along
