Чому не 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/javascript/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
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.