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.
