Меня зовут Итай Корен. Я разработчик программного обеспечения последние 15 лет, в настоящее время работаю в команде фронтенд-фреймворков в LivePerson.

Итак, настала очередь BackboneJS, и, как и в предыдущем посте Мой собственный взгляд на AngularJS — плюсы и минусы я хотел бы поделиться с вами некоторыми своими мыслями о плюсах, минусах и мифах вокруг BackboneJS.

Опять же, это не пост о AngularJS и BackboneJS, и я даже не предлагаю никакого сравнения между ними.

Я собираюсь только рассмотреть свое собственное мнение (за и против) об этой широко используемой структуре (кстати, я не думаю, что эти две следует сравнивать — если вы хотите провести какое-либо сравнение, это должно быть выполнено между Backbone + Marionette/Chaplin и AngularJS).

Как я уже говорил в своем сообщении об AngularJS, у меня гораздо больше часов работы с BackboneJS, чем с AngularJS, и я думаю, что достаточно хорошо изучил BackboneJS со всеми его плюсами и минусами.

BackboneJS — плюсы:

  • Нет никаких сомнений в том, что BackboneJS заслуживает большой похвалы за внедрение MV* в массовую разработку JavaScript на стороне клиента. Да, еще до появления BackboneJS существовал JavascriptMVC (с которым у меня была возможность поработать), но он никогда не привлекал к себе такого внимания, как BackboneJS.
  • Одна из вещей, которые мне больше всего нравятся в BackboneJS, это то, что он дает вам пространство для принятия собственных решений по разработке и архитектуре (возможно, даже слишком много). Вы можете смешивать и сочетать части, которые вы считаете наиболее подходящими для нужд вашего приложения, и BackboneJS прекрасно сочетается с любыми дополнениями, которые вы для него выберете, что позволит вам адаптировать его к потребностям вашего проекта. Это, конечно, не может существовать без затрат, поскольку BackboneJS превосходит максимальную гибкость над удобством для разработчиков, и поэтому, на мой взгляд, одного BackboneJS никогда не бывает достаточно. Я имею в виду, что выбор BackboneJS заставляет вас принимать некоторые другие решения, чтобы создать управляемую и удобную среду разработки (хотя мне нравится принимать такие решения, и поэтому я вижу в этом преимущество).
  • BackboneJS прост и гибок, и для его запуска требуется всего несколько минут, даже при использовании дополнительных библиотек более высокого уровня, таких как MarionetteJS или Chaplin.
  • Сообщество и экосистема BackboneJS огромны, и существует множество плагинов и расширений. Документация также хороша, и существуют решения практически для любой проблемы, что упрощает поиск помощи или поддержки.
  • Еще одна вещь, которая мне очень нравится в BackboneJS, это его простая, но мощная модель наследования, основанная на полезном методе расширения. Однако здесь есть небольшая оговорка. Метод extend на самом деле определяет прототип для вновь созданных объектов, поэтому, когда вы начнете создавать экземпляры этого объекта, все они будут иметь общие свойства (но это можно легко решить).

BackboneJS — миф:

  • BackboneJS очень маленький и компактный — что ж, это один из плюсов, который можно найти почти в любом споре о преимуществах BackboneJS, и хотя это буквально правда, это удручающая иллюзия. Сама магистраль имеет размер около 20 КБ. Теперь добавьте в его зависимости Underscore (уменьшение 15 КБ) и JQuery (уменьшение 91 КБ), и вы получите 126 КБ. И это еще до добавления фреймворка более высокого уровня, такого как MarionetteJS. Например, AngularJS занимает всего около 98 КБ (без jQuery) и может работать без наличия jQuery на странице.

BackboneJS — минусы:

  • Я думаю, что больше всего меня беспокоит в BackboneJS определение моделей. Хотя с ним довольно легко и гибко работать, мне не очень нравится тот факт, что модель данных также представляет собой API. Я думаю, что во многих случаях возложение на модели данных ответственности за сохранение данных и синхронизацию с сервером является проблематичным дизайнерским решением, которое может вызвать путаницу у разработчиков в определенных сценариях (какая часть кода должна быть расположена где). Модели BackboneJS плоские по определению. Нет встроенной поддержки более глубоких моделей. Вероятно, это один из моментов, по поводу которых BackboneJS очень самоуверенно, и как утверждает Джерми Ашкенас, создатель BackboneJS:

«Мы хотим отдать предпочтение нормализованному, реляционному подходу к моделированию данных на стороне клиента, а не гигантскому единому глобальному блобу глубоко вложенного подхода JSON».

Несмотря на то, что я согласен с этим основным наблюдением, я все же считаю, что на практике большинство сценариев реального мира находятся где-то между плоской структурой и гигантской глубоко вложенной структурой, и BackboneJS должен оставить это архитектурное решение открытым.

  • Еще одна вещь, которая меня раздражает в BackboneJS, это то, что очень легко сделать множество небольших обновлений DOM для одного взаимодействия с пользователем. Для больших структур данных это может привести к плохому взаимодействию с пользователем.
  • Еще одна вещь, о которой BackboneJS думает, — это API RESTful, работа с бэкэндом API без RESTful или поддержка различных схем URI, что иногда может быть затруднено с BackboneJS.
  • Модели BackboneJS достаточно просты для модульного тестирования. С другой стороны, модульное тестирование Backbone Views очень сложно. Покрыть достаточно, чтобы тесты были осмысленными, без написания смехотворного количества фиктивного кода — довольно сложная задача при использовании BackboneJS.
  • BackboneJS создает пустой элемент div для каждого представления Backbone. Это может привести к большому количеству избыточных DIV в сгенерированном HTML.
  • И наконец, отсутствие строительного блока контроллера также беспокоит меня, и я ожидал, что BackboneJS, естественно, будет иметь его.

Обзор:

Когда вы принимаете решение о структуре, важно понимать, что BackboneJS, AngularJS и любой другой MV*-фреймворк предназначены для определенной цели (SoC), но если у вас нет четко определенной модели, большинство MV * рамки вам все равно не помогут.

Вы также должны помнить, что, поскольку фреймворк более самоуверен, он по дизайну более ограничивающий, но меньше нагружает разработчика, который должен самостоятельно выяснять, как все должно работать.

Так что же выбрать?

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

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

Вообще говоря, я бы, вероятно, выбрал AngularJS в следующих случаях:

  • Я не использую REST API
  • Мое приложение представляет собой небольшое или среднее приложение для управления со множеством форм и полей.
  • Разработчики в моей команде в основном разработчики серверной части с низким/отсутствующим знанием JavaScript.
  • Мне не нужно или я не хочу делать слишком много выборов и определять слишком много правил самостоятельно
  • Мое приложение должно легко тестироваться
  • Дай мне всю магию

Я бы, наверное, выбрал BackboneJS (+ Marionette || Chaplin || Thorax || Aura) в следующих случаях:

  • Мне нужно внедрить (полностью или поэтапно) MV* в существующее приложение
  • Мое приложение будет выполнять много тяжелых манипуляций с DOM.
  • Я хочу, чтобы гибкость и архитектурный выбор оставались за мной
  • В моей команде много опытных разработчиков JavaScript.
  • Мне нужно создать более специализированное решение, которое также требует интеграции с некоторыми другими сторонними библиотеками.
  • Я не хочу никакой магии

Мир фреймворков на стороне клиента действительно захватывающий, и мне еще предстоит испытать множество фреймворков.

Я надеюсь вскоре создать еще один подобный пост, посвященный Facebook React и/или EmberJS.

Ваше здоровье,

@itkoren