Ruby Video | Rails - past, present and the future

Talks

Rails - past, present and the future

Piotr Sarnacki

Rails - past, present and the future

by Piotr Sarnacki

The video titled "Rails - past, present and the future" features Piotr Sarnacki discussing the evolution of the Rails framework during the wroc_love.rb 2012 event. The talk addresses Rails' history, recent changes with Rails 3.x, and the future trajectory of the framework.

Key points discussed include:

- Historical Context: Before Rails 3.0, the framework provided a flexible approach with convention over configuration, but suffered from significant architectural issues such as chaotic code quality and difficulties with upgrading.
- Merb and the Big Rewrite: The merge of Rails and Merb led to a significant rewrite of the framework, focusing on modularity and improved architecture. Yehuda Katz was acknowledged for his contributions to this initiative.
- Modularity in Rails 3.x: The introduction of modularity allowed developers to reuse components efficiently, making it easier to build applications and plugins. AbstractController was highlighted as a key example of this modularity feature.
- Performance Improvements: Compared to Rails 2.3, Rails 3.2 showed considerable enhancements in rendering speeds, processing over 700 requests per second, and better boot time, emphasizing ongoing performance optimization.
- Future Development: Talks of Rails 4 indicate a focus on enhancing performance, improved documentation, and better integration for client-side applications, especially concerning JavaScript technologies.
- Constructive Criticism: The speaker encouraged developers to engage actively in the community by creating plugins and providing constructive feedback rather than simply criticizing the framework.

In conclusion, while Rails has areas that require ongoing attention, its modular architecture and commitment to continuous improvement suggest a positive outlook for the future. The community's role in evolving Rails, coupled with a growing collaboration with the JavaScript ecosystem, demonstrates potential for further innovation and adoption in modern web development.

00:00:12.559 Hello everyone, today I’m going to talk about Rails.

00:00:21.779 Thank you, good morning! How are you all?

00:00:28.019 I’m Piotr Sarnacki, and I’m available on the internet. You can follow me on Twitter or GitHub.

00:00:33.719 Today, I will discuss the past, present, and future of Rails. I won’t include any jokes about drunk people or those eating, so perhaps it won’t be as entertaining as Nick’s talk.

00:00:41.219 However, I’ll be touching on some topics that relate a bit to his presentation. First, let's start with the past of Rails—specifically, how it was before version 3.0.

00:01:07.080 Before Rails 3.0, it was a nice framework that embraced convention over configuration, allowing developers to avoid making unnecessary choices before starting to write their applications.

00:01:14.460 It had some cool APIs and concepts, like routers, and of course, the highly praised feature assignments.

00:01:20.159 However, the code quality in that framework often left much to be desired.

00:01:26.759 It was complete chaos—lacking architecture, with monkey patches flying around the entire codebase.

00:01:32.280 The ActionMailer was duplicating many components from controllers, such as rendering partials and helpers. This led to considerable code duplication across different parts of the application.

00:01:50.280 And don't even get me started on Active Record, which made ActionMailer look good by comparison. I'm exaggerating a bit, but you get the point.

00:02:09.420 A significant downside to all of this was that as we extensively used Rails and incorporated many plugins, upgrading to a new Rails version often resulted in everything breaking.

00:02:22.200 This was especially apparent in the 2.x series when there was no clear public API.

00:02:34.500 Let’s leave that aside for a moment and discuss something that was an answer to these issues: Merb. It was architecturally superior, faster, and offered a public plugins API, among many other advantages.

00:02:46.739 The key point is that eventually, Rails and Merb merged, creating something that resembled Rails but was significantly different.

00:03:00.780 I think calling it a ’merge’ isn't entirely accurate; it was more of a rewrite or refactoring.

00:03:08.519 Recently, numerous posts have emerged discussing this refactoring and rewriting, along with many misconceptions about whether it was beneficial.

00:03:22.379 I wanted to say a few words about it, particularly acknowledging Yehuda Katz, who was pivotal in this initiative.

00:03:36.959 He discussed several goals he wanted to achieve with Rails 3, the first of which was modularity.

00:03:47.640 Can you all see the slides okay?

00:03:53.580 The focus on modularity meant that both application developers and plugin developers could benefit.

00:04:07.860 As a plugin developer, you could reuse components of Rails, and as an application developer, you'd have access to the same benefits.

00:04:20.820 Moreover, Rails introduced better support for rack and various features from Merb that weren’t previously highlighted.

00:04:39.060 So, let’s review how things look at present, particularly in Rails 3.x, starting with modularity. This is a significant improvement resulting from the rewrite.

00:05:04.560 I find this aspect of Rails the most interesting because it brings significant benefits.

00:05:11.520 Take the AbstractController, for instance. It serves as a superclass for both ActionMailer and controllers, abstracting some basic functionalities that are primarily focused on action processing.

00:05:32.100 However, on its own, the AbstractController doesn’t do much. For example, you can create a new controller that inherits from it and processes some action, but it’s not really effective.

00:05:46.199 The beauty here lies in the modularity—by including different modules, AbstractController can be extended. For instance, we can have a controller that inherits from AbstractController and includes features like rendering.

00:06:04.020 What you can create with just a few lines of code used to take a considerable amount of work before Rails 3. After this, you can add more capabilities, like layouts, by including another module in just a line or two.

00:06:51.060 Then we can also include helpers, which enable you to define methods and render them easily. With a controller that extends AbstractController and includes the necessary modules, you can render layouts and views seamlessly, allowing for cleaner and more maintainable code.

00:08:00.860 Additionally, this modular approach means you can leverage various functionalities without being tied down to Rails itself. This also opens up a chance for more plugin development that can interact with Rails in a smoother manner.

00:08:38.820 For plugin developers, this makes it much easier to build upon the Rails framework without needing extensive changes or hacks.

00:09:02.760 As you begin to see, these improvements cater to both application and plugin developers.

00:09:08.220 This also means that new developers jumping into Rails will find it considerably easier to grasp the concepts and start building out their applications.

00:09:24.260 To summarize, with Rails 3 and beyond, developers now have access to a far more modular and extensible system, enabling them to build richer applications with less overhead and complexity.

00:09:46.440 Moving forward, there will be discussions about Rails 4 and how it aims to further improve upon the milestones achieved in Rails 3.

00:10:06.480 One of the key areas that need development is performance and how we can make applications faster while improving the overall experience for developers.

00:10:21.000 I did some informal benchmarks between Rails 2.3 and Rails 3.2, which displayed a considerable improvement in rendering speeds.

00:10:40.440 In simple view rendering tests, Rails 2.3 processed about 260 requests per second, whereas Rails 3.2 soared to over 700 requests per second, which is a remarkable increase.

00:10:57.740 Of course, it's still not comparable to lightweight frameworks like Sinatra. However, those numbers illustrate that Rails has already made strides in performance.

00:11:24.780 Along with performance improvements, the boot time has also significantly optimised.

00:11:36.120 This is an important aspect of development efficiency and user experience.

00:11:51.300 The public API for plugins has also seen improvements, allowing third-party developers to create addons with more confidence.

00:12:07.740 Developers now have a clearer distinction between internal and public APIs, resulting in less breakage between updates.

00:12:23.880 Furthermore, starting with a smaller core version enables teams to add other functionalities as needed, reducing bloat and keeping the initial footprint minimal.

00:12:48.060 Additionally, better support for middlewares encourages modularity across different applications.

00:13:00.300 However, was the ‘big rewrite’ worthwhile? Many feel that while it was undoubtedly a necessary adjustment, developers must adapt to changes and embrace the new way of coding.

00:13:36.480 Now, let’s touch upon some criticisms that people have raised regarding Rails and its future. Some voices claim that Rails is no longer leading in web development.

00:14:05.640 I want to stress the need for constructive criticism rather than quick judgments. If you think changes could improve Rails, then create plugins or present ideas.

00:14:36.899 In summary, while there are areas that need attention, the shift to a modular architecture and continuous improvement of the Rails framework offers a bright future.

00:15:03.819 There is, however, a pressing need for better documentation and support for new developers.

00:15:28.980 As we move into an era dominated by heavily client-side applications, Rails must evolve to accommodate this shift and improve integration for JavaScript-heavy applications.

00:15:56.460 In Rails 3.2, there is improved support for asset pipelines, which is crucial for applications leveraging client-side technologies.

00:16:17.880 Additionally, Rails also aims to clean up and enhance the API experience to make it easier for developers to create API-only applications.

00:16:38.879 Now, partnerships with the JavaScript community will further enhance offerings, providing developers with tools to bridge the gap between Rails and modern frontend frameworks.

00:17:11.639 In conclusion, it’s important to approach discussions with respect and to remember that many developers invest countless hours into improving Rails. We should all work together to advance this framework and support community efforts.

wroc_love.rb 2012