Search
Ruby on Rails
Rails: The Next Five Years
Edit
#ruby-on-rails
#rest-api
#javascript
#client-side-rendering
Summarized using AI

Rails: The Next Five Years

Yehuda Katz • August 22, 2012 • Austin, TX

In the talk titled "Rails: The Next Five Years," Yehuda Katz discusses the evolution and future challenges facing Ruby on Rails, particularly in light of the increasing shift towards client-side development. Katz begins by emphasizing that Rails, which gained popularity for its convention-over-configuration approach, must continue to adapt to current trends or risk becoming obsolete. He highlights key developments in Rails over the past five years, noting its embrace of RESTful conventions in 2007, which streamlined API development.

Katz outlines several critical points:

  • Adoption of New Technologies: As modern web applications increasingly shift focus to the client-side using JavaScript-heavy frameworks, Rails faces competition in justifying its relevance in such projects.
  • Convention Over Configuration: This principle helps developers avoid trivial decisions, allowing them to focus on more significant aspects of application development. Katz elaborates that a well-defined convention provides a solid foundation, making the framework more robust and efficient.
  • Security and Complexity Reduction: He uses Cross-Site Request Forgery (CSRF) protection as an example of how Rails simplifies complex problems through conventions, reducing cognitive load on developers.
  • Standardization of JSON APIs: Katz argues that the lack of standardized approaches to JSON APIs results in repeated trivial decisions that could be streamlined through Rails’ existing conventions.
  • Technological Debt: Discussing the balance between immediate feature implementation and long-term maintainability, he cautions against accumulating further technical debt during rapid development phases.
  • Proposed Solutions: Katz introduces a proposal for using Active Model Serializers, which he believes could help standardize JSON API structures while reducing redundancy and inconsistency in client-server interactions.

Katz concludes by urging the Rails community to take proactive steps to maintain relevance in the evolving landscape of web development, emphasizing that Rails must leverage its historical strengths in creating conventions to effectively address challenges brought by client-side frameworks. He asserts that frameworks should provide solutions for common problems rather than leaving developers with trivial choices, ensuring Rails remains an attractive option for modern web applications.

Rails: The Next Five Years
Yehuda Katz • August 22, 2012 • Austin, TX

When Ruby on Rails burst onto the scene in 2004, it excited web developers by showing that you could build next generation apps quickly and efficiently. Rails was one of the first frameworks to embrace Ajax, giving everyone the power to do partial page updates and whiz-bang effects in a conventional, effortless way.

In 2007, the Rails team embraced RESTful conventions, making API development a no-brainer for new applications. Because RESTful JSON is so easy in Rails, Rails applications tend to implement APIs on balance.

Then it was time to polish. Both the 2.0 and 3.0 releases cleaned up the code-base and found ways to take emerging conventions and make them easier to use.

But now, like in 2004, another revolution is brewing. Increasingly, developers are moving their view layer from the server into the client, using RESTful JSON and client-side templating to increase responsiveness and bring applicable aspects of desktop applications to the web.

Like last time, not every application needs to jump head-first into this new world. But just as in 2004, Rails has an opportunity to embrace the future, and bring its ruthless insistence on convention over configuration to bear on this problem.

Rails already has the plumbing to be a fantastic conventional JSON server. The question is: will we take the challenge, or will we desperately cling to the past, hoping that the future will never come?

Help us caption & translate this video!

http://amara.org/v/FGkY/

RailsConf 2012

00:00:25.640 The topic of my talk is 'Rails: The Next Five Years.' I want to start with a short disclaimer: the opinions represented in this talk are not the opinions of the Rails Core team or my employer. This reflection is purely my own.
00:00:32.520 The logo on the left side is my company's new logo. I work for a company called Tilda. We have been engaging in a lot of consulting as a bootstrapping mechanism; we don't want to take venture capital. Throughout this process, we've worked on various projects, including many JavaScript-heavy projects, which we're skilled at, as well as projects that involve a server-side component.
00:00:50.320 Increasingly, we find ourselves in situations where Rails is not an obvious choice. Some clients want to use Node, Clojure, Scala, or other technologies. However, people know that we like Rails and they ask us to justify why Rails should be used in their projects.
00:01:06.280 Despite having two members from the core team and colleagues who created Bundler and contributed to the Ember core team, we often have to convince clients that Rails is a viable option. This situation – needing to justify the use of Rails when there are other alternatives – is troubling.
00:01:19.280 I enjoy using Rails and wish to see it thrive in the future. I don't want Rails to be relegated to just building human resource applications in HTML. I want us to keep pace with what other developers are doing. My experience has shown me that, especially as we shift to building rich JavaScript applications, something feels amiss with the current trajectory of Rails.
00:01:45.000 Having been involved with Rails since 2006, and primarily working on Rails applications since 2008, I keep reflecting on what might be missing. I think the first question to consider is: why did we like Rails in the first place?
00:02:05.000 Many might argue that Rails is merely a transitional technology, designed to solve HTML-based problems, but now with the focus shifting to JavaScript, tools like Node seem to be the answer. However, I want to explore deeper into why Rails remains relevant, as I mentioned in a similar talk at Ruby on Rails.
00:02:22.360 I expressed to the audience that Rails is not obsolete because the underlying principles of Rails remain contentious. In fact, many other frameworks and libraries stand in stark contrast to what Rails embodies. So why do we value Rails? Most people cite 'convention over configuration' as a significant reason, which has become the slogan of Rails.
00:02:54.200 While there's truth to this motto, it has been repeated to the point where its meaning has somewhat faded. Convention over configuration primarily refers to eliminating trivial choices. In the context of building web applications, many decisions may seem necessary but, fundamentally, can actually be trivial.
00:03:11.360 When building a web application, you face choices that, while they feel significant at the moment, do not critically impact the outcome. An example of trivial decisions might include what you name things, the testing process, or the HTTP request flow within your application.
00:03:46.480 If a problem is common, it typically leads to a proliferation of options. In contrast, within the Rails community, we adopt a different philosophy: for common problems, we should have fewer decisions, not more. Rails takes on the responsibility of addressing common issues effectively, ensuring we solve them comprehensively.
00:04:04.080 For example, CSRF (Cross-Site Request Forgery) protection is an issue many frameworks approach differently. In Rails, the solution is straightforward and embedded within the framework, which enables you to build secure applications without needing to deeply understand CSRF mechanisms.
00:04:41.400 Other frameworks may present semi-automatic solutions, requiring developers to piece together security measures. While Rails provides default behaviors that shield developers from the intricacies of security vulnerabilities, such as CSRF, it allows users to focus on building their applications without worrying about every minute security detail.
00:05:01.840 Additionally, conventions within Rails provide a solid foundation for creating other abstractions. For instance, everyone uses controllers, which allows for the development of authorization frameworks that integrate seamlessly into Rails.
00:05:33.760 Aaron, yesterday, spoke about three different types of features in Rails, which intrigued me. I must admit, I'm not particularly drawn to cosmetic changes, nor do I have much time for grand refactoring projects. However, what truly interests me is understanding why, in recent projects, we sometimes find ourselves needing to persuade others of Rails' value.
00:06:00.360 What has changed in two years? The criteria for deciding whether a course correction is necessary involves recognizing when many users are facing the same issue. We must also acknowledge that certain problems are trivial. When we face repetitious actions while addressing a concern, it's crucial to look for a shared solution.
00:06:21.720 REST, for example, eliminated several trivial decisions like HTTP structure, method naming, and URL generation. When we implemented REST, we reduced the burden of decision-making that developers had to grapple with.
00:06:54.920 Thus, the criteria for success in course corrections often include the existence of an uncomplicated, shared solution, ideally one that integrates smoothly with already established frameworks and practices.
00:07:16.760 If a problem is sufficiently common that learning about it can be considered laborious, we should work on a correction project to ensure that the solution becomes standardized and, thus, easier to apply.
00:07:39.720 When we fail to address a challenge systematically within the Rails core, we create confusion and undermine the essential clarity that Rails is renowned for. The first risk involves the emergence of multiple competing solutions that dilute focus from a unified approach.
00:08:06.680 Without critical mass, no initial implementation of a solution can improve swiftly. Rails naturally provides exposure to the features we implement. When we don't funnel a feature into Rails, we increase the chances of encountering overlapping issues among competing solutions.
00:08:23.760 When new features exist as plugins, maintainers often struggle with low adoption rates, which can hinder improvements and cause users to encounter major problems.
00:08:42.840 As noted, the integration of the asset pipeline had several hurdles, but due to its inclusion in Rails, necessary adaptations were made. Introducing features within Rails compels the community to confront underlying conceptual challenges that need clarification.
00:09:00.520 When users self-select a solution, they often overlook the broader implications of building an automated framework. Integrating functionality into Rails seeks to streamline user experiences and address inefficiencies.
00:09:15.920 Ultimately, many developers already possess understanding of various solutions that they have chosen, which can solidify their reliance on manual processes, leading to a cycle of complications.
00:09:40.960 As Aaron suggested, while resolving larger issues, we must be mindful of the technical debt we accept. I've repeatedly stated our significant burdens of maintaining legacy systems.
00:09:57.520 We face substantial technical debt, and we must prioritize paying it down to maintain Rails’ sustainability, all while being cautious about accruing additional debt as we evolve.
00:10:19.920 Focusing on constructing features with an eye towards durable architecture signifies a forward-thinking approach, enabling Rails to adapt and innovate efficiently in the long run.
00:10:40.640 When we architect solutions mindfully, it fosters an environment where future requirements can also be met with ease, ensuring an agile response when adapting to new challenges.
00:10:56.640 The asset pipeline, however, faces challenges to adapt quickly as its original design became overly complex and coupled with other processes.
00:11:18.720 Aaron proposed a formula regarding technical debt: your tolerance for debt equals features now plus features later over cost now plus overall maintenance.
00:11:39.440 Considering future features and maintenance costs often outweigh initial implementation costs. This perspective signifies the essence of sustainable design.
00:11:55.840 When addressing a course correction, we take measured risks regarding the industry’s future, ensuring our decisions align with long-term goals.
00:12:13.520 DHH’s initial implementation of REST was a lateral swing, betting on principles that extend beyond HTML-centric frameworks.
00:12:29.920 Rails enjoyed victories by actively re-evaluating its HTTP foundations, which paved the way for modern APIs to flourish.
00:12:49.720 However, we face challenges beyond just the HTTP layer. Matters involving effective data transport are crucial.
00:13:06.560 Let’s first discuss challenges Rails developers historically grappled with while setting up SQL databases—such as the decisions surrounding primary keys, timestamps, and table structures.
00:13:27.920 Active Record transforms this layout dramatically by instituting conventions instead of leaving them to individual DBAs, compelling Rails applications to adhere to these guiding principles.
00:13:54.640 This structure fosters consistency across various applications, reducing discrepancies that might exist in isolated database systems. Today, we see parallel discussions surrounding JSON APIs.
00:14:18.320 Developers often express a desire to customize their APIs extensively, much like the initial discussions with DBAs about how to configure databases.
00:14:44.480 However, the real benefit lies in recognizing the efficiency of established conventions. Standardizing how we approach JSON APIs can save developers considerable large amounts of time.
00:15:21.920 We need clarity and uniformity in defining structure, ensuring we minimize trivial decision-making across both client and server implementations.
00:15:38.720 By constructing JSON API frameworks based on clear conventions, developers can streamline processes without needing to rethink their approach each time.
00:15:54.840 In doing so, we mitigate repetitive labor and tease out effective structures that enhance productivity—including building standardized clients.
00:16:06.700 If we fail to standardize protocols between client-server communication, we risk spiraling into fragmented practices, as seen with past attempts at active resource applications.
00:16:28.320 Moreover, we should acknowledge the potential of Ember Rails to define the interface while retaining the flexibly to support diverse use cases.
00:16:42.520 Ember Rails generates models along with serializers, guiding developers on utilizing Rails effectively within the context of JavaScript frameworks.
00:16:56.920 There’s no reason we shouldn't have a framework-agnostic tool that enables seamless interaction with Rails by abstracting technical complexities.
00:17:11.320 This tool should redefine efforts by establishing conventions around JSON transport that elicit familiarity while simplifying usage.
00:17:25.880 Conventions can extend beyond serialization to address commonalities that exist at multiple points along the pathway developers navigate when interacting with the server.
00:17:39.720 Additionally, we recognize that enhanced conventions for JavaScript organization will lead to better cohesiveness across projects within Rails.
00:18:01.160 Ultimately, we want to lead developers back towards core Rails principles, focusing on centralizing decision-making while minimizing complexity.
00:18:22.120 To summarize, trivial decisions should be the enemy. Our goal as developers is to eliminate as many trivial choices as we can find.
00:18:38.680 I want to shift gears to discuss the emergence of Node.js. Some advocate for its adoption due to the JavaScript landscape's familiar framework—the thought being that developers can leverage the same language across both client and server.
00:19:05.920 Quote Paul Graham, who stated that writing software restricted to your own servers allows for any language choice. With web-based applications, the freedom extends, and it’s imperative that we harness that flexibility consciously.
00:19:31.880 As developers, we should evaluate whether to stick with JavaScript across all projects or follow conventions that make the most sense inherently.
00:19:49.560 I believe a balance can be struck. There’s a world of languages to explore, and we should have the freedom to pursue opportunities that fulfill our technical needs.
00:20:11.960 In conclusion, our path is clear: when we embrace conventions, we empower developers to focus on delivering results rather than on trivial decision-making.
00:20:28.320 If we redirect our attention to creating frameworks that foster easy implementation and unity between client and server, we will simplify our development process.
00:20:44.960 Thank you for joining me today for this exploration into the next five years of Rails.
Yehuda Katz
@wycats
Explore all talks recorded at RailsConf 2012
+65