Rails Asset Pipeline: Defunct or Da Funk

RubyConf AU 2014

by Samuel Cochran

In the video titled Rails Asset Pipeline: Defunct or Da Funk, Samuel Cochran presents at RubyConf AU 2014, discussing the relevance of the Rails asset pipeline in modern web development, particularly in the context of JavaScript frameworks. The presentation revolves around how the asset pipeline still enhances front-end development despite the emergence of newer tools like Grunt and Gulp.

Key points discussed include:

Introduction of the Rails Asset Pipeline: Cochran emphasizes the importance of the Rails asset pipeline as a tool for efficiently managing assets, particularly JavaScript and CSS.
Importance of Dependency Management: He highlights the value of maintaining organized code through an application.js file to avoid code bloat in the application.
Use of Modern Frameworks: The talk explores integrating various JavaScript frameworks, including Backbone and Angular, with Rails.
Modularity in Development: Cochran advocates for creating smaller, modular JavaScript files for each component, which helps maintain clarity and efficiency in the codebase.
Dynamic User Experience: Techniques such as pjax or turbo links are suggested for improving interactivity without full page reloads, promoting a smoother user experience.
Integration Challenges: Addressing common hurdles in integrating Angular with Rails, the use of gems like ng-min is proposed for compatibility, ensuring a seamless development process.
Pre-processing Templates: He points out how using pre-compiled templates in Angular aligns with Rails practices, making it easier for Ruby developers to adapt.

Cochran concludes that the Rails asset pipeline remains a powerful tool, particularly for developers looking to create modern applications while avoiding excess code and managing dependencies effectively. He encourages attendees to embrace the asset pipeline's capabilities while keeping applications lean and informed by best practices in modern JavaScript development. The session ends with an invitation for further discussion, underscoring the value of collaboration and inquiry in the tech community.

00:00:07.040 Hello, everyone. My name is Samuel Cochran, and I’ll be speaking in place of Alex Coles today. Unfortunately, Alex couldn’t make it due to illness. He was going to give a talk on Rails front ends, covering topics like Ember, Angular, Backbone, and how to effectively utilize these frameworks within Rails. So, at the last minute, I was asked if I would step up to the plate. Since I’m passionate about the Rails asset pipeline, I agreed to give it a go. Please bear with me; I know this presentation has been a bit rushed. I hope you find something valuable in it.

00:00:40.800 As I mentioned, I'm often known as sa26 online. I describe myself as a Ruby, JS, and Go polyglot creative, a title I’m borrowing from a talk I heard earlier today. The name ‘sa26’ was a random assemblage of letters and numbers from my Hotmail account when I was about six years old, so it doesn't mean anything significant. Depending on who you talk to, I might be recognized for my resemblance to a British author or even a very grumpy Irishman. However, in the Ruby community, I'm best known for creating MailCatcher, a tool that helps developers manage email while building applications without spamming customers.

00:01:12.640 Today, we're here to discuss front ends. I thought it would be beneficial to have an example to illustrate our discussion. Unfortunately, I didn’t have time to create a specific example, so I’ll be borrowing one most of you are likely familiar with, especially since I'm the MailCatcher guy. We will be looking at email, specifically web mail. In fact, it took me quite a while to get the screenshot ready; have any of you tried running Windows 95 lately?

00:01:39.360 So, let's create a mail application using Rails. As a developer, I admit I can’t draw very well at all, so I’m using a visual representation from my girlfriend, who kindly created a nicer version for this talk. We also need some test data for this application. I decided to reach back into the 90s for this, considering the nostalgia of that era. One particular company from back then is depicted in the Tron movie. Unfortunately, the company’s fate was steeped in tragedy due to a major court case, which made all their emails public. Subsequently, some computational linguists compiled all that data into an archive and made it available on the internet.

00:02:09.960 For those of you interested in experimenting with email, there’s a great data set available for you to play with. We are going to conceptually discuss building webmail because it’s an application that everyone is familiar with, and we’ll consider doing it the Rails way first. You would typically start by creating a Rails application and doing some modeling. For instance, your application would include accounts, mailboxes, and messages, which might look something like this. This particular layout is derived from a library called Pure, developed by the Yahoo UI team.

00:02:54.320 One of the first things you’d likely do is break up your application into partials. For example, you’d have a list of mailboxes on the left, which relates to the account, and a list of messages next to the actual email. Initially, we won't worry about JavaScript; let's imagine every link on this page requires a new request to the server, which re-renders the whole thing and sends it back. Once we have the partials, our main goal will be to make the interface visually appealing.

00:03:20.640 As a developer, creating an aesthetically pleasing interface is not my strong suit, so I would typically grab a UI library to help. There are many libraries available, providing frameworks for grids, typography, code tables, forms, dropdowns, button groups, navigation, etc. While these libraries can be incredibly powerful, oftentimes they end up delivering a colossal bundle of CSS to every client that visits your website.

00:03:43.680 Although it looks good initially since you can customize colors and such, you might find that you're overwhelmed when needing to add an extra component or adjusting the design slightly. In this case, you would return to that massive library page, which might provide a URL that includes all your customization options. When you make changes, however, you might end up with a disorganized history, leading to some unnecessary complexity. I believe most of you are reasonably familiar with the Rails asset pipeline.

00:04:06.960 The main takeaway here is that the power of the asset pipeline is its dependency management. The correct approach is to create an application.js file for your JavaScript, where you maintain a manageable, organized code base. For example, if you have a messages controller, creating an index.js for managing messages will help keep things tidy. If this is done correctly, when you clean up your controllers, the bundling process will only include the necessary components. If you remove an element that is no longer needed, it will fall out of the bundle as well.

00:04:48.509 The beauty of this granular dependency approach is that you won't deliver unnecessary code to your users, and your bundles will remain slim and efficient. The same principles apply when you're working with webmail; if you have an automated dependency graph, it'll ensure that your application does not bloat unnecessarily. Now, let’s return to our example regarding the webmail interface. We’ll introduce techniques like pjax or turbo links for dynamically refreshing without having to fully reload the page.

00:05:11.200 This way, your HTML is rendered server-side, yet updates happen dynamically, providing a more fluid user experience. Essentially, we’re adapting the Rails way to this modern dynamic approach. A brief side note: I must say that content-aware fill is one of my new top choices, as it can do amazing things with meme images. I also believe we now have the opportunity to enhance our webmail further by implementing richer features like auto-completion for user inputs or advanced model manipulations using a client-side framework.

00:06:25.120 For such features, leveraging a framework like Backbone would allow us to structure our code through models, collections, and views, with each piece fitting together nicely. The traditional practice would often lead developers to organizing everything inside a single application.js file, which can bloat and complicate the overall architecture. However, what I suggest is creating smaller files for each component that require corresponding dependencies for better maintainability.

00:06:50.560 By managing granular files, when you remove an outdated view or any unnecessary JavaScript, only the related dependencies remain intact. As you can imagine, this lowers the chance of bloating and enhances the speed of your web application. With Backbone, developing views and associating them with the DOM can ultimately make your webmail interactively dynamic without adding additional load to each request.

00:07:40.560 The same principles apply to modern frameworks like Angular, which have gained immense popularity in recent years. While there are differences in implementation within Angular, the core concepts remain aligned with the ideas previously mentioned. Modularity is critical; by creating separated JavaScript files for each component, organizing views and dependencies, and referencing them explicitly, you’ll ensure that each bundle remains slim and efficient.

00:08:10.200 I acknowledge there may be some hiccups while integrating Angular with Rails, but rest assured various solutions exist to streamline that process. For instance, using the ng-min gem allows the compatibility required for Angular's dependency injection system within the Rails asset pipeline. Moreover, the way you can preprocess templates in Angular aligns with familiar Rails concepts, allowing us to use pre-compiled templates directly, a seamless approach for experienced Ruby developers.

00:09:20.679 Ultimately, building applications with Angular or any other JavaScript framework in conjunction with Rails can be straightforward and maintainable. Continuous integration of granular dependency management will ensure you’re only bundling the necessary code required to deliver your application to your clients effectively. In closing, while setting up these frameworks can be overwhelming initially, the Rails asset pipeline simplifies these processes, making it a valuable asset for modern web development.

00:10:42.599 I apologize for overwhelming you with a lot of information today—but I aimed to highlight some key points regarding the synergy of the asset pipeline and modern JavaScript frameworks. I encourage you to explore these elements further as you work with asset management in your projects. Should you have questions, feel free to reach out to me on Twitter or find me after the talk for further discussion.

00:11:23.919 Thank you very much for your attention! I hope you got a better understanding of how the Rails asset pipeline can still be incredibly useful in facilitating modern front-end development. Let’s embrace the power of this asset pipeline while keeping our applications lean and efficient, and I look forward to discussing more of these ideas with you in the future.

RubyConf AU 2014