Почему не Assets Pipeline?

Вступление

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

Это значит, что, начиная с rails 4.2 механизм asset pipeline больше не является частью ядра rails и может не использоваться в процессе разработки приложения. Данный gem подключается по-умолчанию. Действительно, в простых приложениях (сайт-визитка, блог) данный подход вполне оправдан и позволяет не заботится о написании сложных, зависимых друг от друга frontend компонентов. В профессиональной разработке больших сайтов роль frontend заметно возрастает, как и сложность работы с ним. Итак, выдвинем свои предположения по поводу того, почему разработчики Rails уже не навязывают сценарий использования sprockets.

Модульность

Немного теории. Модульный подход разработки web-приложений с использованием Javascript AMD предполагает проектировать большие JavaScript приложения на основе отдельных модулей. Модуль имеет следующие характеристики:

1. Выполнять поставленную перед ним задачу и не более того
2. Не знать о том, что есть другие модули, а тем более о их функциональности
3. Если модуль выдаст непредвиденную ошибку, другие модули должны продолжать выполнять свою работу без ошибок
4. Модули могут иметь зависимости от других модулей для использования их функциональности. Управление зависимостями является простым и понятным инструментом разработчика
5. Модули, которые не используются не должны загружаться на страницу

Rails позволяет строить сложные вложенные деревья зависимостей, но на практике это может стать кошмаром. Обычно разработчики не заботятся о разделении и зависимостях модулей и идут простым путем – просто добавляют ссылку на файл в конце общего манифеста (app/assets/javascripts/application.js, app/assets/javascripts/application.css), который загружает на страницу все, не зависимо от того, нужны ли ресурсы или нет.

Несколько точек входа

Еще раз повторюсь, что отдельная подсистема должна иметь свою точку входа в виде подключаемого модуля. Rails позволяет это сделать, но настолько сложно и не элегантно, что этим мало кто пользуется. Типичное описание зависимости в Rails выглядит так:

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

Последняя строка описывает включение всех модулей из папки подсистемы subsystem1 в манифест и такую нотацию обычно используют в реальной жизни. Согласитесь, что сложно держать в актуальном состоянии такой код:

//= 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

Файлы модуля subsystem1 могут быть не связанными между собой или существовать лишь для обратной совместимости, но они все равно будут грузиться на страницу. Типичная ситуация. Подрядчик разработал портал и ушёл с проекта, оставив гигантский манифест. Уже сложно разобрать какой модуль зависит от какого. Проект диктует свою, заранее неправильную парадигму. Хотя, конечно, на свете существует подрядчик, который когда-то держал в голове схему взаимодействия модулей…

Очень часто, манифест разрастается до таких размеров, что отслеживать зависимости становится просто невозможным. Тем более в условиях командной разработки. Слияние этого файла в системе управления версиями также очень неудобно при больших его размерах.

JS и CSS также зависят друг от друга

Это значит лишь то, что java script модуль может быть зависеть от css модуля. Например, элемент выбора даты содержит стили, которые загружаются на страницу только, если элемент присутствует на форме. К сожалению, rails данной функциональности не поддерживает. Как не поддерживает bundling html шаблонов.

Итог

Из-за всех этих особенностей использования assets pipeline самым простым решением управления зависимостями становится их включение в один файл манифеста. Со временем он разрастается до огромных размеров, становится неуправляемым. В итоге все ресурсы грузятся на страницу. Наверное, поэтому assets pipeline перешел из обязательных в рекомендуемые функции разработки на Rails.

Вместо заключения

Уважаемое сообщество, данный пост был написан по двум причинам:

1. Желание присоединиться к Хабру
2. Жаркий спор между разработчиком, использующим assets pipeline, и разработчиком, использующим requirejs в повседневной жизни. Хотелось бы услышать ваше мнение по данному вопросу в комментариях

Заранее благодарен!

Используемая литература

» Rails Guides. The Asset Pipeline

Автор: agorinenko

Источник