Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Two completely different ways have emerged for using Rails as the back end to a rich client-side JavaScript application. * The 37Signals "Russian Doll" approach, where the server generally returns HTML to the client. This approach uses aggressive caching and a little bit of JavaScript glue to keep the application fast. * The "Rails API" approach, where the server generally returns JSON to the client, and a JavaScript MVC framework handles the actual display. Which of these will work for you? We will look at code to see the structural difference between these two approaches and see what the speed, extensibility, and maintainability trade-offs are. At the end of the talk, you will be better equipped to chose a structure for your next rich-client application. Help us caption & translate this video! http://amara.org/v/FGa5/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
The video titled "Rails Vs. The Client Side" presented by Noel Rappin at Rails Conf 2013 explores two distinct approaches for utilizing Rails in combination with rich client-side JavaScript applications. The speaker addresses the increasing demand for rich client experiences, highlighting two popular methodologies: 37Signals' "Russian Doll" approach and the "Rails API" approach. **Key Points Discussed:** - **Introduction to Rich Client Experiences:** - Rappin notes the desire for fast and feature-rich applications among clients who often lack understanding of their technical requirements. - **Comparison of Approaches:** - The **Russian Doll** approach: - Server returns HTML with aggressive caching and some JavaScript. - Best for document-centric applications where response speeds and caching matter. - The **Rails API** approach: - Server returns JSON to be handled by JavaScript MVC frameworks like Ember. - Allows for dynamic client-side interactions with reduced server requests. - **Technical Insights:** - Discusses the evolution of JavaScript and how it has developed into a fundamental language for client-side coding, contrasting it with Rails' traditional server-side strengths. - Emphasizes how client-side frameworks allow for more sophisticated user interactions by minimizing server dependency. - **Decision Making Criteria:** - Rappin advises on various criteria to determine the suitable approach for new projects: - Stability of data representation, interaction styles (notification vs. retrieval), and the need for simultaneous component interaction. - Importance of developers’ proficiency in JavaScript and existing systems during planning. - **Conclusions and Future Perspectives:** - Rappin posits that both methods have their merits and that complexity can vary based on the application framework chosen. - As JavaScript tools improve, the divide between these approaches might lessen, making client-side frameworks even more viable for future projects. Ultimately, Rappin encourages balance and thoughtful decision-making based on the specifics of the application and team capabilities, providing a framework for evaluating the suitable architecture for developing rich client applications.
Suggest modifications
Cancel
