Why not Assets Pipeline?

Introduction

The asset pipeline is technically no longer a core feature of Rails 4, it has been extracted out of the framework into the sprockets-rails gem.

Rails Guides. The Asset Pipeline

This means that starting with rails 4.2, the asset pipeline mechanism is no longer part of the rails kernel and may not be used in the application development process. This gem is connected by default. Indeed, in simple applications (business card website, blog) this approach is fully justified and allows you to not worry about writing complex, frontend components that are dependent on each other. In the professional development of large sites, the role of frontend is noticeably increasing, as is the complexity of working with it. So, let's put forward our assumptions about why Rails developers no longer impose a script for using sprockets.

Modularity

A bit of theory. AMD's modular approach to developing web applications using Javascript involves designing large JavaScript applications based on separate modules. The module has the following characteristics:

1. Perform the task assigned to him and no more
2. Not to know that there are other modules, and especially about their functionality
3. If a module generates an unexpected error, other modules should continue to do their job without error.
4. Modules may have dependencies on other modules to use their functionality. Dependency management is a simple and intuitive developer tool
5. Unused modules should not be loaded onto the page.

Rails allows you to build complex nested dependency trees, but in practice this can be a nightmare. Typically, developers do not care about the separation and dependencies of the modules and go the simple way - just add a link to the file at the end of the general manifest (app / assets / javascripts / application.js, app / assets / javascripts / application.css), which loads everything on the page , regardless of whether resources are needed or not.

Multiple Entry Points

I repeat once again that a separate subsystem must have its entry point in the form of a plug-in. Rails allows you to do this, but it is so complex and not elegant that few people use it. A typical dependency description in Rails looks like this:

//= require jquery
//= require jquery_ujs
//= require_tree ./subsystem1/*
…и ещё куча описаний зависимостей, оставшихся от прежних команд

The last line describes the inclusion of all modules from the folder of the subsystem subsystem1 in the manifest and this notation is usually used in real life. Agree that it is difficult to keep this code up to date:

//= require jquery
//= require jquery_ujs
//= require_tree ./subsystem1/module1
//= require_tree ./subsystem1/module2
//= require_tree ./subsystem1/module3_old
//= require_tree ./subsystem1/module4
//= require_tree ./subsystem1/module5
…
//= require_tree ./subsystem1/module_n

Files of the subsystem1 module may not be interconnected or exist only for backward compatibility, but they will still be loaded onto the page. A typical situation. The contractor developed the portal and left the project, leaving a giant manifesto. It is already difficult to make out which module depends on which one. The project dictates its previously wrong paradigm. Although, of course, there is a contractor in the world who once kept in mind a module interaction scheme ...

Very often, a manifest grows to such a size that it becomes simply impossible to track dependencies. Especially in a team development environment. Merging this file in version control system is also very inconvenient for its large sizes.

JS and CSS are also dependent on each other

It only means that the java script module can be dependent on the css module. For example, a date picker contains styles that are loaded on the page only if the item is present on the form. Unfortunately, rails does not support this functionality. As does not support bundling html templates.

Total

Due to all these features of using assets pipeline, the easiest way to manage dependencies is to include them in a single manifest file. Over time, it grows to a huge size, becomes uncontrollable. As a result, all resources are loaded on the page. This is probably why the assets pipeline has moved from mandatory to recommended Rails development features.

Instead of a conclusion

Dear community, this post was written for two reasons:

1. Desire to join Habr
2. A heated debate between a developer using assets pipeline and a developer using requirejs in everyday life. I would like to hear your opinion on this issue in the comments

Thanks in advance!

Used Books

» The Rails Guides. The asset pipeline