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

Но сначала… немного предыстории

Checkmate не начинался как многоканальный общий почтовый ящик в режиме реального времени для отелей, чтобы общаться со своими гостями. Мы начинали как приложение для iOS, позволяющее гостям регистрироваться онлайн для бронирования отеля так же, как вы можете сделать это для бронирования авиабилетов. Вначале не было особой сложности со стороны пользовательского интерфейса продукта. Мы даже недолго использовали Турболинки (хотя я слышал, что сейчас он намного лучше и, вероятно, попробовал бы его снова при правильном наборе требований).

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

Используйте как можно меньше Javascript. Джаваскрипт ужасен. Rails должен выполнять большую часть работы. Давайте рендерим Javascript из Rails, когда нам нужно, почему бы и нет. — Сообщество Rails

Некоторые в сообществе Rails до сих пор придерживаются этих взглядов. Теперь я вижу обе стороны медали и знаю, что ответ более многогранен, чем вы могли бы подумать. Некоторые приложения хорошо обслуживаются благодаря большому количеству динамических манипуляций с DOM Javascript, другие прекрасно справляются с рендерингом на стороне сервера. Вы делаете вы.

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

И какое-то время было нормально.

Пока не было.

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

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

Нам нужен был каркас…

Поиск

Несмотря на то, что в то время я был в своем пузыре Rails, я не был слеп к появлению полнофункциональных клиентских сред MVC и эволюции одностраничных приложений (SPA). Я стараюсь как можно больше быть в курсе новых технологий, особенно в том, что касается веб-разработки, поэтому я был мимоходом знаком с игроками того времени… но мне нужно было сделать домашнее задание, прежде чем я смог принять обоснованное решение.

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

В то время было два основных варианта: Ember.js или Angular. Был ряд других фреймворков и библиотек, пытавшихся стать фреймворками, но большинство из них не выглядело многообещающим или не соответствовало нашим потребностям.

Вооружившись вариантами, мне нужно было их оценить…

Оценка

Как вы оцениваете новые технологии? Что касается меня, я копаюсь и использую это в реалистичном сценарии. Я имею в виду, что это круто, что вы все создали клоны одного и того же простого приложения ToDo, чтобы показать свои вещи, но для меня это не очень полезно.

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

В итоге я сделал небольшой прототип в каждом фреймворке, чтобы лучше понять их. Они оба чувствовали благоразумие. Честно говоря, ни один из вариантов мне не понравился. Я все еще не был фанатом Javascript. Мне нужно было посмотреть на что-то большее, чем просто синтаксис и структуру…

Ключевыми решающими факторами для меня оказались:

  • Качество документации.Работа в новой среде может быть сложной, и я хотел быть уверен, что у нас есть высококачественная документация.
  • Опыт адаптации.Никто в моей команде в то время не был хорошо знаком ни с Ember, ни с Angular, у нас был лишь небольшой опыт работы с Backbone. Нам нужно было быстро встать на ноги.
  • Руководство проектом. В то время оба этих проекта были еще относительно молоды. Мне нужно было быть уверенным, что проект не станет заброшенным, как это происходит со многими проектами OSS.

Это была близкая гонка, но я уже сильно склонялся к Эмберу. Их документация опережала Angular на световые годы, а их туториалы не имели себе равных. Angular был поддержан Google, что, очевидно, придало уверенности в долгосрочной безопасности проекта, но Ember возглавлял член основной команды Rails в Yehuda Katz… Мне нравится Rails…

Я с большим уважением отношусь к прошлой работе Yehuda Katz над Merb и его вкладу в Rails, а также к тому, как он управляет своими проектами OSS. Я справедливо предположил, что, учитывая его сильный опыт работы с Ruby/Rails, Ember будет «хорошо работать» с Rails, чего не может сделать Angular.

Чтобы, так сказать, заключить сделку, я отправился на первый в истории EmberConf. Находясь там, я смог получить больше информации о состоянии сообщества и о том, куда идут дела. Это была замечательная конференция с замечательными людьми (хотя большую часть времени я был болен). Я просто чувствовал, что там назревает что-то хорошее.

Я вернулся уверенный в своем решении и не оглядывался назад с тех пор…