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.