Каковы реальные сильные и слабые стороны многих фреймворков, основанных на backbone.js? [закрыто]

Надеюсь, что кто-то может поделиться своим опытом с некоторыми из новейших вариантов backbone.js. У меня есть хороший опыт работы с основой / подчеркиванием / требованием в нескольких проектах, и я хотел бы сделать следующий шаг в направлении более совершенных решений для сложной структуры приложения.

Я знаю, что доступны следующие фреймворки:

• марионетка
• Джеппетто (на основе марионеток)
• Чаплин , Чаплин - чаплин-котел
• позвонки
• LayoutManager
• торакс
• аура
• Лука
• Singool
• backstack
• Базовый интерфейс

• килектор

• Кстати - отличная отправная точка для масштабного проекта

И, наверное, я пропустил несколько.

Здесь есть краткое введение о различиях:

• Speakerdeck поговорить

но это очень общее. Мне было интересно, если кто-то может поделиться своим опытом с реальными приложениями, использующими эти платформы.

В чем преимущество выбора одного над другим? Когда марионетка станет лучшим решением по сравнению с Чаплином, или почему ветераны лучше для определенных применений, например.

Конечно, очевидным ответом будет « использовать то, что лучше для ваших нужд », но мне не хватает опыта работы с этими структурами, чтобы знать их силу / цель / преимущества или предпочтительные сценарии.

Спасибо!

Редактировать 1: найдено это сообщение: Backbone.Marionette vs Backbone-Boilerplate

Изменить 2: Ответ Матиас Шефер (Чаплин) по почте:

Короче говоря, текущая структура близка к версии 1.0, поскольку она уже используется в производстве. Мы не планируем добавлять новые функции или вносить изменения в API до версии 1.0.

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

Напротив, Чаплин фокусируется на довольно небольшом, но очень важном аспекте приложений Backbone, а именно на общей структуре приложения и жизненном цикле модуля. В этом отношении Чаплин очень популярен и больше похож на фреймворк, чем на библиотеку (например, «ваш код вызывает библиотеку, а фреймворк - ваш код»). Чаплин предоставляет несколько центральных классов, которые расположены над отдельными модулями приложения и контролируют общее состояние приложения. Это дает вашему приложению традиционную структуру, как, например, Ruby on Rails.

В Чаплине вы объявляете некоторые маршруты, которые отображаются на контроллеры, и Чаплин запускает контроллер, когда маршрут совпадает. Он также заботится об удалении старых контроллеров, а также об отображении и скрытии основных видов, которые должен создать контроллер. Это основная идея, но Чаплин позаботится об уродливых деталях, чтобы все прошло гладко.

С этой структурой связаны два принципа: - модульность, развязка и песочница; - межмодульное взаимодействие с использованием публикации / подписки и посредников.

Конечно, эти шаблоны не новы в мире разработки программного обеспечения, и Chaplin не единственная библиотека, которая применяет их к приложениям Backbone.js.

Chaplin также предоставляет улучшения для слоя View, например, очень сложный CollectionView, но в целом не так много, как Marionette с его регионами и макетами. Но писать такие мета-классы относительно легко, используя средства, предоставляемые Chaplin Views.

Большинство (всех?) Платформ, на которые вы смотрите, решают одни и те же проблемы, но они делают это немного по-другому с немного другими целями.

Я думаю, что будет справедливо сказать, что все эти проекты решат проблемы в следующих категориях:

• Обеспечить разумный набор значений по умолчанию
• Уменьшить шаблон кода
• Обеспечить структуру приложения поверх строительных блоков BackboneJS
• Извлекать шаблоны, которые авторы используют в своих приложениях

Марионетка, которую я строю с декабря 2011 года, также имеет в виду несколько совершенно разных целей и идеалов:

• Архитектура составного приложения
• Влияние корпоративного обмена сообщениями
• Варианты модуляции
• Инкрементальное использование (без требования «все или ничего»)
• Нет блокировки сервера
• Сделать это легко изменить эти значения по умолчанию
• Код как конфигурация / сверх конфигурации

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

Композитная прикладная архитектура

Я провел более 5 лет, работая в распределенных программных системах с толстыми клиентами, используя WinForms и C #. Я создавал приложения для настольных компьютеров, ноутбуков (смарт-клиентов), мобильных устройств и веб-приложений, все из которых имели общий функциональный набор и много раз работали с одним и тем же сервером. За это время я понял ценность модульности и очень быстро пошел по пути разработки составных приложений.

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

Я немного написал об этом в своем блоге, представляя Marionette в качестве архитектуры составного приложения для Backbone:

• http://lostechies.com/derickbailey/2011/11/17/introduction-to-composite-javascript-apps/
• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/

Очереди сообщений / Шаблоны

Такие же крупномасштабные распределенные системы также использовали преимущества очереди сообщений, корпоративных схем интеграции (шаблонов обмена сообщениями) и служебных шин для обработки сообщений. Это, больше всего на свете, оказало огромное влияние на мой подход к развязке разработки программного обеспечения. С этой точки зрения я начал видеть однопроцессные приложения WinForms в памяти, и вскоре моя серверная сторона и разработка веб-приложений повлияли на это.

Это напрямую переросло в то, как я смотрю на дизайн приложений Backbone. Я предоставляю агрегатор событий в Marionette как для объекта приложения высокого уровня, так и для каждого модуля, который вы создаете в приложении.

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

• http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/
• http://lostechies.com/derickbailey/2012/04/03/revisiting-the-backbone-event-aggregator-lessons-learned/
• http://lostechies.com/derickbailey/2009/12/23/understanding-the-application-controller-through-object-messaging-patterns/ (код WinForms, но все еще применимый)

Модульность

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

Марионетка обеспечивает модульность непосредственно через свои moduleопределения. Но я также признаю, что некоторые люди любят RequireJS и хотят использовать это. Поэтому я предоставляю как стандартную сборку, так и совместимую с RequireJS сборку.

MyApp = new Backbone.Marionette.Application();

MyApp.module("MyModule", function(MyModule, MyApp, Backbone, Marionette, $, _){

  // your module code goes here

});

(Пока нет сообщений в блоге)

Инкрементное использование

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

Сама система Backbone использует очень инкрементный и модульный подход со всеми объектами строительных блоков. Вы можете выбирать, какие из них вы хотите использовать, когда. Я твердо верю в этот принцип и стараюсь, чтобы Марионетка работала так же.

С этой целью большинство частей, которые я встроил в Marionette, созданы для того, чтобы работать в одиночку, работать с основными компонентами Backbone и работать вместе еще лучше.

Например, почти каждое приложение Backbone должно динамически отображать представление Backbone в определенном месте на экране. Приложения также должны обрабатывать закрытие старых представлений и очистку памяти при установке новых. Это где Марионетт Regionвходит, чтобы играть. Регион обрабатывает стандартный код для создания представления, вызова для него рендера и помещения результата в DOM для вас. Затем закроете это представление и очистите его для вас, при условии, что ваше представление имеет метод close.

MyApp.addRegions({
  someRegion: "#some-div"
});

MyApp.someRegion.show(new MyView());

Но вы не обязаны использовать взгляды Марионеток, чтобы использовать регион. Единственное требование заключается в том, что вы расширяетесь из Backbone.View в некоторый момент в цепочке прототипов объекта. Если вы решите предоставить closeметод, onShowметод или другой метод, регион Marionette будет вызывать его для вас в нужное время.

• http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/
• http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/

Нет блокировки сервера

Я создаю приложения Backbone / Marionette на основе самых разнообразных серверных технологий:

• ASP.NET MVC
• Рубин на рельсах
• Рубин / Синатра
• NodeJS / ExpressJS
• PHP / Slim
• Ява
• Erlang
• ... и больше

JavaScript это JavaScript, когда дело доходит до запуска в браузере. Серверный JavaScript тоже потрясающий, но он никак не влияет на то, как я пишу свой браузерный JavaScript.

Из-за разнообразия проектов, которые я создавал, и внутренних технологий, которые используют мои клиенты, я не могу и не буду привязывать Marionette к одному стеку технологий на стороне сервера по любой причине. Я не буду предоставлять шаблонный проект. Я не буду предоставлять рубиновый камень или пакет npm. Я хочу, чтобы люди поняли, что Marionette не требует определенного внутреннего сервера. Это JavaScript на основе браузера, и бэкэнд не имеет значения.

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

• https://github.com/derickbailey/backbone.marionette/wiki/Available-packages

Легко изменить настройки по умолчанию

В моих усилиях по сокращению стандартного кода и предоставлению разумных значений по умолчанию (это идея, которую я непосредственно «позаимствовал» из LayoutManager Тима Браньена), я признаю необходимость для других разработчиков использовать немного отличающиеся реализации, чем я.

Я предоставляю рендеринг на основе встроенных <script>тегов для шаблонов, используя шаблон Underscore.js по умолчанию. Но вы можете заменить это, изменив объекты Rendererи / или TempalteCacheобъекты в Marionette. Эти два объекта обеспечивают ядро ​​возможностей рендеринга, и есть вики-страницы, на которых показано, как это изменить для конкретных шаблонизаторов и различных способов загрузки шаблонов.

С v0.9 от Marionette это становится еще проще. Например, если вы хотите заменить использование встроенных блоков сценариев шаблонов предварительно скомпилированными шаблонами, вам нужно заменить только один метод в Renderer:

Backbone.Marionette.Renderer.render = function(template, data){
  return template(data);
};

и теперь все приложение будет использовать предварительно скомпилированные шаблоны, которые вы прикрепляете к templateатрибуту вашего представления .

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

Код как конфигурация

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

Это сделано с целью и намерением.

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

Для этого я использую подход «код как конфигурация» к марионеткам. Я не предоставляю много API "конфигурации", где вы можете предоставить литерал объекта со статическими значениями, которые изменяют диапазон поведения. Вместо этого я документирую методы, которыми обладает каждый объект - как с помощью аннотированного исходного кода, так и с помощью фактической документации API - с целью рассказать вам, как изменить Marionette для работы так, как вы хотите.

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

Вы не найдете API "configure" или "options" в Marionette. Но вы найдете большое количество методов, каждый из которых служит определенной цели, с чистыми подписями, которые позволяют легко изменить работу Marionette.

В настоящее время я использую магистраль с модулем менеджера компоновки и рулями в качестве движка шаблонов, и я обнаружил, что очень легко настроить небольшое приложение с использованием уже существующего бэкэнда Grails. Перед тем, как начать использовать менеджер раскладок, я прочитал о Марионетке и Чаплине, и оба мне показались действительно мощными, но сложными. Тогда я вспомнил, почему я изначально выбрал backbone.js: простота. Все эти фреймворки добавляют то, что опущено в дизайне. Я не говорю, что фреймворк плох, но если мне нужно что-то более сложное, я попробую другие проекты, такие как ember.js или sproutcore, так как они имеют уникальную кодовую базу, написанную с целью в глазах их разработчиков. Здесь у нас есть рамки поверх другого. Конечно, Backbone является основой не только для создания приложений, но и для написания более мощной библиотеки, но единственное, что я считаю действительно плохим - это слой представления, так как отсутствует менеджер макета и возможность вложения представлений. С менеджером по расположению этот пробел заполнен довольно хорошо.

Итак, мой ответ на ваш вопрос: начните с использования магистрали как есть, и спросите себя, чего не хватает и каковы были ваши ожидания от фреймворка. Если вы обнаружите, что магистраль оставляет слишком много вещей, то найдите их в других системах и выберите ту, которая наиболее соответствует вашим потребностям. И если вы все еще не уверены в выборе, возможно, магистраль не для вас, и вам нужно искать какое-то другое решение (ember.js, sproutcore, ExtJs, JavaScript MVC - все хорошо). Если у вас есть опыт написания клиентских приложений, вам не обязательно иметь опыт работы со всеми фреймворками, чтобы выбрать правильное (для вас, конечно)

Я изучил различные фреймворки, созданные с помощью Backbone.js, и собрал Vertebrae для проекта в HauteLook. Цели проекта включали: динамическую загрузку сценариев, формат модуля AMD, управление зависимостями, сборку с использованием в основном библиотек с открытым исходным кодом, организацию кода в пакеты, оптимизацию и сборку для одного или нескольких одностраничных приложений, размещение на полностью кэшированном сервере, например, без сервера Сценарии на стороне пользователя, использующие только API для данных, и самое забавное для меня - использовать разработку проекта на основе поведения. Описание проекта можно найти по адресу: http://www.hautelooktech.com/2012/05/24/vertebrae-front-end-framework-built-with-backbone-js-and-requirejs-using-amd/

Наша проблема:

Отдельные библиотеки (jQuery, Underscore.js, Backbone.js, RequireJS, Mustache) обеспечивают загрузку модулей, управление зависимостями, структуру приложения (для моделей, коллекций, представлений и маршрутов), асинхронные взаимодействия с API, различные утилиты и объекты для управления асинхронным поведением. Например, (Обещания) Отложенные, Обратные вызовы. Оставшаяся логика, необходимая для завершения структуры, включает в себя:

• объект (модель) для управления состоянием одностраничного приложения;
• менеджер компоновки для представления, упорядочивания / перехода и четких представлений, и
• контроллеры, которые отвечают на маршруты, получают / устанавливают состояние приложения и передают работу диспетчеру компоновки.

Наши решения (реализованы в позвонках):

Диспетчер состояния приложения -

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

Менеджер по раскладке -

Диспетчер макетов имеет одно или несколько видов, а также места назначения документов (DOM) для каждого (визуализированного) вида. Страница может переходить между многими представлениями, поэтому менеджер макета отслеживает состояния просмотра, например, отображается, не отображается, отображается, не отображается. Вы можете использовать менеджер макетов для отложенной загрузки и отображения (отсоединения) представлений, которые посетитель сайта, скорее всего, запросит, например, изменения вкладок на странице. Переход между состояниями просмотра управляется этим объектом. Весь макет может быть очищен, так что объекты представления и их привязки удаляются, подготавливая эти объекты для сборки мусора (предотвращая утечки памяти). Менеджер по расположению также связывает состояние просмотра с контроллером (ами).

Контроллер -

Объект контроллера вызывается функцией обработчика маршрута и отвечает за получение соответствующего состояния (модели приложения) для генерации страницы (макета) (также отвечает за настройку состояния при изменении маршрутов). Контроллер передает зависимые данные (модели / коллекции) и построенные объекты представления для запрошенной страницы в менеджер компоновки. Как побочный эффект использование контроллеров препятствует тому, чтобы объект маршрутов стал раздутым и запутанным. Маршрут должен отображаться на контроллер, который затем начинает просмотр страницы, сохраняя функции обработки маршрута.

Приложение Todos размещено как в режиме разработки, так и оптимизировано для Heroku ...

• http://vertebrae-framework.herokuapp.com/
• http://vertebrae-optimized.herokuapp.com/

Многие концепции других структур заимствованы, например, необходимость уничтожать представления для предварительного просмотра утечек памяти, как указал Дерик Бэйли - http://lostechies.com/derickbailey/ ; менеджер по макету Тим Браньен http://tbranyen.github.com/backbone.layoutmanager/

Таким образом, Backbone.js предназначен для использования в качестве инструмента в вашем приложении. Библиотека Backbone.js не обеспечивает всю архитектуру, необходимую для создания приложения, но обеспечивает отличное взаимодействие с API и структурой твердого кода для ... Представления (также действуйте как контроллеры) и модели уровня данных и коллекции, и, наконец, маршруты. Мы создали Vertebrae для достижения целей нашего проекта и решили извлечь код в качестве основы для использования, изучения или чего-либо еще.

По моему мнению, ответ на ваш вопрос заключается в том, чтобы учиться на всех платформах и использовать то, что вам нужно для достижения ваших целей, если вы обнаружите, что цели вашего проекта тесно связаны с одной из структур, созданных с помощью Backbone, то отлично, в противном случае создайте свою собственную структуру Есть прекрасные примеры, которыми обменивается сообщество. Или, если вы немного растерялись в направлении своего приложения, тогда выберите что-то более упрямое и структурированное, возможно, Ember.js. Самое замечательное в том, что есть хороший выбор вариантов, которые помогут вам кодировать, используя MVC-подобный шаблон с JavaScript.

Я разработал фреймворк Luca , работая в BenchPrep, где мы использовали его для разработки нескольких больших одностраничных приложений поверх библиотеки backbone.js.

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

Одним из преимуществ этого подхода является возможность повторного использования компонентов в нескольких приложениях или в разных местах вашего приложения, с незначительными изменениями, использующими расширение Backbone. Также очень легко экспериментировать со многими различными макетами / презентациями компонентов, внося незначительные изменения в конфигурацию JSON.

В дополнение к широкому спектру вспомогательных / служебных функций, Luca Ships имеет много высокоуровневых производных Backbone, которые вы можете собрать любым удобным для вас способом для создания сложного пользовательского интерфейса.

Представления, компоненты, контейнеры

• Классы дополненной модели, вида, коллекции, маршрутизатора
• Параметры конфигурации, которые облегчают связь между моделями, коллекциями, представлениями, приложением и его соответствующими менеджерами.
• Контейнеры (разделение / расположение столбцов, расположение сетки, представление вкладок, представление карты / мастера)
• FormView со всеми стандартными компонентами полей и помощниками для синхронизации с Backbone.Model
• GridView, для генерации прокручиваемых элементов сетки из Luca.Collection
• CollectionView, для генерации представлений на основе коллекции
• Панели инструментов / Кнопки

Стили загрузки и разметка Twitter бесплатно

• Luca очень хорошо играет с фреймворком Twitter. Просто установив Luca.enableBootstrap = true и включив CSS, ваши компоненты (такие как представления вкладок, панели инструментов, кнопки, формы, поля, сетки и т. Д.) Автоматически будут использовать разметку, совместимую с Bootstrap Twitter, и соглашения CSS-классов.
• Использует Grid-систему для разметки и интеллектуально реагирует на большинство базовых классов CSS начальной загрузки.
• Компоненты Luca.Viewport и GridLayout настроены для работы с адаптивными, текучими или статическими сеточными системами начальной загрузки.
• Стремится обеспечить соответствие «один к одному» для компонентов начальной загрузки Twitter, чтобы представить их как настраиваемые базовые представления.

Компонент приложения

• Конечный автомат на основе Backbone.Model предоставляет методы получения / установки и события изменения атрибутов как стиль потока управления приложениями.
• Компонент встроенного контроллера, который скрывает / показывает страницы приложения в ответ на события Backbone.Router или State Machine
• Интегрированный менеджер коллекций, который отслеживает созданные вами коллекции, позволяет вам охватывать их, группировать, назначать им параметры по умолчанию
• Socket Manager, который представляет собой уровень абстракции поверх сервисов websocket, который делает push простым, как Backbone.Event
• Маршрутизатор событий клавиатуры, который запускает именованные ключевые события на компонентах, которые хотят реагировать на такие события

Улучшения коллекции и моделей

• Коллекции основаны на магистральном запросе , который обеспечивает интерфейс запросов, очень похожий на mongoDb.
• включить локальное хранилище Backbone.sync просто установив collection.localStorage = true
• автоматическое заполнение коллекций, данные которых загружаются при загрузке страницы
• кэшированные методы / вычисляемые свойства. кэшировать результаты методов сбора и завершать кэш в ответ на изменения / добавления / удаления событий в коллекции или ее моделях
• вычисленные свойства на моделях. создавать атрибуты на основе сложной функции и автоматически обновлять вычисленное значение в ответ на изменения

События и крючки

Компоненты Luca более либеральны по сравнению с исходными компонентами Backbone. Они будут генерировать события, как до: инициализировать, после: инициализировать, до: рендеринга, после: рендеринга, активации, сначала: активация, деактивация, сначала: деактивация, и это позволит вам более точно настроить поведение ваших компонентов. Кроме того, определив событие в свойстве @hooks на вашем представлении, оно автоматически вызовет для вас функцию с аналогичным именем, если она существует. Это предотвращает много кода стиля обратного вызова, который улучшает удобочитаемость.

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

Рубиновый камень

Luca был разработан специально для работы с Rails и Sinatra API, и в связи с этим в настоящее время оптимизирован для конкретного стека, но он никоим образом не привязывает вас к конкретному серверу.

Luca поставляется в составе Ruby Gem, настроенного для работы с конвейером ресурсов, или в виде загружаемого файла JS.

Вы не обязаны использовать Rails или Sinatra. Но если вы делаете, я включил много полезных вещей:

• Файлы с расширением .luca обрабатываются как HAML с интерполяцией переменных в стиле JST. (эквивалентно .jst.ejs.haml) по конвейеру активов
• Тестовый комплект для браузера или безголовые модульные тесты на основе жасмина вместе со многими помощниками по тестированию Backbone и Underscore.
• Конечная точка API для набора инструментов разработки, который поставляется вместе с Luca (подробнее об этом позже)
• Конечная точка API, которая позволяет использовать Redis в качестве механизма хранения без схемы для Luca.Collection с минимальной конфигурацией

Инструменты разработки

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

• С помощью Rails Gem и редактора компонентов на основе Luca CodeMirror вы можете редактировать исходный код Luca Framework, а также компоненты приложения непосредственно в браузере, используя Coffeescript. Вы увидите немедленную обратную связь в ответ на ваши изменения, когда обновленные прототипы обновятся, и вы сможете сохранить изменения на диске.

• Component Tester - это живая песочница для игры с компонентами, которые составляют ваше приложение изолированно. Он предоставляет вам инструменты для изменения прототипа компонента, настройки его зависимостей и настройки компонента. Компонент будет визуализироваться немедленно каждый раз, когда вы делаете редактирование. Вы можете просматривать и редактировать разметку, создаваемую компонентом, а также CSS прямо в браузере и сразу же видеть ваши изменения. Это делает его очень ценным инструментом для экспериментов.

• Компонент тестер скоро будет интегрирован с Jasmine, так что вы сможете просматривать результаты своих модульных тестов в режиме реального времени, как вы редактируете их код

Luca находится в стадии разработки, но поддерживает стабильный API (пока не 1.0) и используется в нескольких крупных производственных приложениях. Это определенно очень самоуверенный фреймворк, но я работаю над тем, чтобы сделать его более модульным. Я активно работаю над документацией и образцами компонентов.

Я соавтор Chaplin, и я написал подробное сравнение между Chaplin.js и Marionette.js:

http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

Это не «перестрелка», но попытка объяснить оба подхода сбалансированным образом.