От переводчика: когда я начал разбираться с MVC-фреймворками для фронт-энда, каким-то чудом попалась на глаза эта статья Henrik Joreteg. Сейчас дошли руки перевести ее для Хабра, тем более, что об AmpersandJS на Хабре вообще не слышно. Попробую организовать цикл статей по этому инструменту ребят из &yet, мне кажется, он достоин внимания.
В рамках наших образовательных семинаров я даю краткий обзор JS фреймворков. Я не очень-то хотел публиковать большую часть моих мнений об этих инструментах в Сети, потому что такие вещи, как правило, вызывают бурление масс, обижают людей, и в отличие от разговора с глазу на глаз, в интернет-дискуссиях нет действительно хорошей двунаправленной связи с аудиторией.
Но мне не раз говорили, что мой обзор крайне полезен и помогает получить сжатое и, в то же время, хорошее понимание в вопросе «кто есть кто в JS фреймворках для создания одностраничных приложений». По этому поводу я решил материализовать его и опубликовать как Нечто, но, пожалуйста, помните, что я просто высказываю свое мнение, я не говорю вам, что делать, и вы должны использовать те инструменты, которые лучше подходят вам и вашей команде. Вы можете запросто не согласиться со мной, написать об этом в Твиттере, или, еще лучше, опубликовать отдельный пост, объясняющий вашу позицию.
Angular.js
за
- очень легко начать использовать. можно просто вставить тег script, добавить немного ng- атрибутов в ваше приложение, и вы волшебным образом получаете нужное вам поведение
- Angular хорошо поддерживается его основной командой разработчиков, многие из которых работают в Гугле на постоянной основе
- большая аудитория/сообщество
против
- Если вы выбираете Angular, то вы учите Angluar.js вместо того, чтобы узнавать как решать проблемы посредством JavaScript’а. Если бы я перевел нашу команду на написание приложений с использованием Angular, что было бы, когда {здесь название прекрасного нового JS фреймворка} захочет изменить мир фронт-энд разработки? Или если мы выясним, что в конкретных задачах Angular не может делать в точности то, что мы от него хотим и мы хотим сделать эту часть с использованием чего-то еще? Насколько актуальны в этом случае будут навыки разработки под Angular? Вместо JS-разработчиков я бы получил людей, у которых основным навыком является Angular, не обязательно собственно JavaScript.
- Нарушает разделение ответственности. Можете сказать, что у меня устаревшие взгляды, но я до сих пор думаю, что CSS нужно использовать для оформления, HTML для структуры, а JavaScript для логики приложения. Но в случае Angular вы проводите кучу времени, занимаясь описанием поведения внутри HTML вместо JS. Лично для меня это самый существенный минус в репутации Angular. Я не хочу описывать логику приложения в HTML, это просто не достаточно выразительное средство для такой задачи, потому что это язык разметки для задания структуры документа, а не для описания логики поведения. Чтобы обойти этот момент, Angular создает, по сути, еще один язык внутри HTML и приправляет это небольшим количеством JS для описания дополнительных подробностей. Опять же, вместо того, чтобы учиться создавать приложения на JavaScript, вы изучаете Angular, и все усложняется. Вот почему книга моего друга Ари по Angular толщиной аж в 600 страниц!
- Слишком много магии. За магию надо платить. Когда вы работаете с чем-то на высоком уровне абстракции, становится гораздо сложнее выяснить, что же именно не так, когда что-то начало криво работать. И, конечно, когда вы сходите с проторенного пути, вам уже мало кто сможет помочь. Я могу ошибаться, но я предполагаю, что большинство использующих Angular слабо разбираются в фреймворке до такой степени, чтобы иметь возможность изменить или хотя бы отладить Angular как таковой.
- Почти не предоставляет структуры для приложений. Я не уверен, что вообще существует некий канонический способ построения одностраничного приложения на Angular. Не поймите меня неправильно, я думаю что это хорошо, по крайней мере точно нет ничего плохого в инструментах, которые не навязывают какой-то определенный стиль работы, но это также значит, что будет тяжелее разобраться в чужом angular-приложении или кому-то еще разобраться в вашем, потому что стили написания скорее всего будут сильно отличаться.
мой субъективный (и не застрахованный от ошибок) вывод
Слишком много логики описывается с помощью псевдо-языка внутри HTML вместо JS, и все это производит впечатление слишком абстрактного и магического.
Мне бы больше хотелось, чтобы моя команда хорошо разбиралась с DOM и JS вместо того, чтобы изучать высокоуровневую абстракцию.
Ember.js
за
- Сильный акцент на том, чтобы делать все «The Ember Way» (обратите внимание на первый пункт в «против»). Это палка о двух концах. Если у вас большая команда, что потенциально может привести к куче неразберихи, наличие жесткой структуры может примирить желание иметь общий базовый код и новых разработчиков, которые хотят выкинуть все написанное ранее куда подальше. Если все они Ember-разрабы, они скорее всего быстро включатся в новый для них проект на Ember.
- Отдает большую часть сложных проблем, встречающихся при построении одностраничных приложений, неким невероятно умным людям, которые примут много непростых решений за вас (см. вотрой пункт в «против»).
- Большое отзывчивое сообщество.
- Хороший сайт с доками.
против
- Сильный акцент на том, чтобы делать все «The Ember Way» (это также есть и в «за»). В Ember очень много правил. Несмотря на то, что существует возможность свернуть со стандартного пути, мало кто действительно это делает. Например, вы не обязаны использовать хендлбары вместе с Ember, но я буду сильно удивлен, если существует много Ember-приложений в продакшене, которые этого не делают.
- Код Ember содержит в себе множество конкретных мнений о том, как решать ту или иную задачу. Если вы не согласны с этими мнениями и решаете заменить отдельные кусочки функциональности на свои собственные, в все равно отсылаете весь неиспользуемый код в браузер. Не то чтобы я люблю считать байты, но концептуально лучше иметь возможность отдавать клиенту только то, что реально используется. К тому же, если вы отдаете только то, что используете, то у вас будет меньше кода, который нужно просмотреть, чтобы обнаружить баг.
- Большие аппетиты по отношению к памяти тоже можно считать недостатком, особенно когда Ember запускается на мобильных девайсах.
- Ember намеренно не имеет структурной гибкости. Не верите мне? Тогда поверьте Иегуде (один из двух основных разработчиков Ember; остальная дискуссия также достаточно интересна).
мой субъективный вывод
Недостаток гибкости и ощущение, что при использовании Ember нужно либо принимать его целиком, либо не браться за него вообще — вот главные причины, почему я бы не очень хотел иметь с ним дело.
React
Стоит заметить, что по правде не совсем честно включать React в этот список. Это не фреймворк, а слой представления. Но он настолько активно обсуждается, что я решил включить его в этот обзор. В принципе, когда вы добавите к нему фейсбучный flux, он уже может считаться фреймворком.
за
- Возможность перестраивать DOM, не беспокоясь об его очистке. React сравнивает виртуальный DOM, который вы отрендерили, тем что есть в реальном DOM’е в настоящий момент, и делает минимальные изменения для их синхронизации
- Виртуальный DOM также позволяет легко решать проблемы, связанные с обработкой событий в разных браузерах, предоставляя браузеронезависимую и соответствующую стандартам модель появления и «всплытия» событий. В итоге вы получаете совместимую событийную модель в каком угодно браузере.
- React — это просто слой представления, не фреймворк как таковой. А значит вы можете использовать любой инструментарий при разработке приложения, который вам по душе. Он хорошо сочетается с Backbone, поскольку Backbone не предоставляет коробочного решения для привязки представления к модели, предлагая рендерить представление заново при изменении модели, и именно под этот процесс и заточен React.
против
- Синтаксис шаблонов и метод создания DOM (при помощи JSX) слегка странен для JS-разработчика, просто потому что нужно хранить незакавыченный HTML в Javascript код, как будто это валидно. Да, JSX не обязателен, но альтернатива: React.DOM.div(null, «Hello », this.props.name); — по моему, не сильно лучше.
- Если вам нужен действительно полный и явный контроль над изменениями в DOM, React вам его не предоставит. Например, вам нужно четко контролировать то, как происходят изменения в style-атрибутах, для создания интерфейсов с возможностью перетаскивания элементов. Вы не можете с легкостью установить порядок, в котором добавляются классы и так далее (хочу заметить, что я бы назвал это недостатком, но лично у меня проблем из-за этого не возникало; в то же время я общался с разработчиками, которые мучились именно с этой особенностью React; в общем, не сильно полагайтесь на мое мнение в данном вопросе)
- Несмотря на то, что существует возможность перестроить сразу всю вьюху React’а, если ее компоненты достаточно сложны, есть сильное подозрение, что в ряде случаев выяснение различий между виртуальным и реальным DOM’ом может стать достаточно трудоемким процессом. Я слышал о том, что некоторые разработчики, использующие React, реализовывали обновление только тех элементов, о которых было известно, что они поменялись, и это, по мне, дискредитирует саму идею невмешательства в процесс рендера модели. Опять же, в данном вопросе опыт у меня небольшой.
мой субъективный вывод
Небольшое замечание по поводу «FLUX» архитектуры. Для меня это не новая информация или идея, просто новое название. И, кажется, я не одинок в этом мнении.
Я понимаю концепцию FLUX как наличие слоя данных с разумно сделанной системой событий в чем-то типа Ampersand или Backbone с превращением всех операций пользователя и обновлений сервера в изменения состояния этого слоя.
Если вы хотите гарантировать, что действия пользователя никогда не приведут напрямую к обновлению DOM, вы в конечном итоге придете к тому же однонаправленной цепочке передачи событий, как и в FLUX + React. Мы намеренно не включали какого-либо двунаправленного связывания модели и представления в Ampersand по этой причине. По моему, двунаправленное связывание — это потенциальный источник опасности. Мы много лет используем архитектуру, в которой только один слой имеет дело с входящими событиями, не важно, пользовательский ли это ввод или ответ сервера.
Polymer
Этот парень для меня немного странноват. Он построен на основе стандарта, который разрабатывался для возможности определять кастомные элементы (document.registerElement для создания новых HTML тегов со встроенным поведением), делать импорт HTML ( ‹link type='html'› для того, чтобы импортировать эти кастомные элементы в другие документы), и теневой DOM (для изолирования CSS от остального документа)
Все эти штуки замечательны (кроме HTML импорта, по моему мнению).
Но, судя по описанию Polymer, возникает ощущение, что это универсальное средство для того, чтобы сделать всю веб-разработку легкой и прекрасной, и и что этот фреймворк хорош буквально для всего. Вот цитата с официального сайта:
Веб компоненты вступают в новую эру веб-разработки, в основе которой лежат инкапсулированные и взаимосовместимые кастомные элементы, которые расширяют HTML как таковой. Сделанный на базе этих стандартов, Polymer позволяет легче и быстрее создавать что угодно, начиная от простой кнопки и заканчивая целым приложением для десктопа, мобильных девайсов и всего, что вы можете себе представить.
Несмотря на то, что я считаю возможность создания кастомных элементов и инкапсулирования их поведения просто фантастической, я разочарован позиционированием фреймворка. Такое ощущение, что мы теперь должны его использовать буквально для всего.
Простой аргумент: я не знаю ни одного значимого приложения от Google, которое бы использовало polymer хоть для чего-то.
Это для меня как красный сигнал светофора. Не поймите меня неправильно, очевидно это новая штука, а изменения требуют времени. Проблема просто в том, что тескт на сайте, он же обращение от инженеров из Google, работающих над Polymer, не отражает этой новизны.
К тому же, даже если бы вы насоздавали кучу кастомных элементов, покрывающих весь ваш код для слоя представления в одностраничном приложении, должен быть организован и процесс управления создания/удаления этих элементов. Вам все также придется управлять состоянием и выбирать инструменты для построения внутренностей приложения, что приводит нас к тому, что все эти кастомные элементы по правде просто другой способ написания эквивалента Backbone-вьюхи. В мире одностраничных приложений я не вижу большого выигрыша от того, что мы просто перейдем в кодированию этих вещей внутри кастомных элементов.
за
- Чудесная возможность создавать такие штуки, как кастомные элементы форм, не дожидаясь их поддержки в браузерах.
- Polymer достаточно полифилен, так что вы можете начать использовать и экспериментировать с его функциональностью уже сейчас.
- Изоляция стилей про создании виджетов является проблемой веба на протяжении уже многих лет. Новые стандарты решают эту проблему на уровне браузера, что просто замечательно.
против
- Лично мне кажется, что одним из главных стимулов создания Гуглом такого инструмента является желание сделать встраивание их сервисов, которые включают в себя поведение, стили и функциональность, внутрь страниц настолько простым, что не потребуется даже знать собственно JS. Я могу быть полностью неправым в этом предположении, но я не могу избавиться от чувства, что маркетинговая мотивация является главной движущей силой для продвижения новых стандартов в данном случае.
- HTML-импорт кажется мне плохой идеей. По сути, это те же грабли, что и в случае с CSS import. Если вы импортируете что-то, вам нужно подождать, пока от сервера придет ответ, после чего выясняется, что это что-то импортирует еще один компонент и так далее. Таким образом, если вы реально будете придерживаться компонент-ориентированного подхода для построения страницы, который и преподносится как наилучший, вам придется иметь дело с кучей сетевых запросов. Правда, для есть «vulcanizer» для компоновки зависимостей. Но инлайновая компоновка не видится мне правильным решением. Недавно был написан объемный пост про проблемы с HTML-импортом, где обсуждается этот вопрос и некоторые другие проблемы.
- Я просто не понимаю, почему Гугл так агрессивно продвигает Polymer как будто он является панацеей для разработки, при том, что единственный пример гугловского продукта, где они используют его, который мне удалось найти, это собственно сайт Polymer. Сайт утверждает, что «Polymer позволяет легче и быстрее создавать что угодно, начиная от простой кнопки и заканчивая целым приложением для десктопа, мобильных девайсов и всего, что вы можете себе представить». Из моего опыта работы с Polymer скорее очевидно обратное, я чувствую, что меня хотят обмануть.
мой субъективный вывод
Почему-то гугл не ест то, что он сам и готовит. Спецификация на document.registerElement восхищает, я не вижу другого применения Polymer, кроме как в качестве полифила для этой функциональности, простите.
Backbone
Нет более распространенного фреймворка для построения одностраничных приложений, используемого в продакшн-версиях сайтов, чем Backbone, из тех, которых я знаю. В разделе примеров в документации Backbone приведен список большого количества известных сайтов, и он далеко не полон.
за
- Это достаточно небольшой и гибкий набор хорошо оттестированных блоков для построения приложений
- Модели
- Коллекции
- Представления (вьюхи)
- Роутер
- Он решает большинство основных проблем
- Его сфокусированная функциональность позволяет быстро в нем разобраться. Я всегда даю изучить документацию Backbone.js в качестве первого задания для всех новых фронт-энд разработчиков, приходящих в команду &yet.
против
- Backbone не предоставляет решений для всех проблем, с которыми вы столкнетесь при разработке. Поэтому, из моего опыта, каждому, кто использует backbone, приходится создавать свой собственный «фреймворк» поверх Backbone-основы.
- Скорее всего при использовании чистого Backbone вам будет не хватать следующих вещей:
- Способа создания вторичных свойств для моделей
- Способа связывания свойств, в том числе, вторичных в представлением
- Способа рендера набора представлений внутрь какого-либо элемента
- Простого способа работы с «подвьюхами», зависимыми лэйаутами и тому подобное
- Несмотря на минималистичность Backbone’а, его компоненты слишком связаны друг с другом. Например, до релиза, включающего мердж моего пулл реквеста, было невозможно использовать какой-нибудь другой тип Модели внутри Backbone’овских Коллекций без локальных изменений внутренних методов. Это может быть некритичным для некоторых приложений, но это необходимо, если, например, я хочу, чтобы модель хранила observable-данные в библиотеке, с которой должен уметь работать другой код, не обязательно зависящий от Backbone. Единственный способ использовать Backbone’овские Модели предполагает включение всего Backbone’а в проект, что кажется мне неправильным и неэффективным.
мой субъективный вывод
Backbone стал первооткрывателем многих замечательных вещей. Я использую его, начиная с версии 0.3 и мне очень импонирует его минималистичная концепция.
Он стимулировал появление нового поколения приложений, которые начали использовать браузер как среду исполнения, а не как движок для рендера документов. Но его узкая специализация приводит к тому, что разработчикам приходится писать свои решения поверх Backbone’а. Несмотря на то, что это как бы не плохо само по себе, просто становится очевидным, что при разработке придется иметь дело с большим числом проблем.
Без фреймворка
Существует подмножество разработчиков, которые считают, что фреймворки вообще не стоит использовать. Мне во многом близка эта точка зрения и я согласен с основными доводами, но такой подход элементарно не целесообразен, особенно в случае командной разработки.
Я склонен согласиться с позицией, обозначенной в посте Райанa Флоренсa, которая лучше всего изложена в этой цитате:
Когда вы решаете не использовать общедоступный фреймворк, в конце концов вы придете к тому, что вы фреймворк все же используете, только он будет ваш собственный.
Далее он говорит, что это не является плохим решением по умолчанию, но вы должны быть настроены серьезно, заниматься поддержкой вашего кода и так далее. Я крайне рекомендую прочитать этот пост, он просто отличный.
за
- Предельная гибкость
- Вы можете включить в сборку только тот код, который вы реально используете в вашем приложении
против
- Большой объем работ по изобретению велосипедов и, как следствие, высокая стоимость разработки
- Сложнее понять, какие модули использовать и какие лучше подходят в данной ситуации
- Отсутствие понятной документации и соглашений для новых разработчиков
- Сложная адаптация и переиспользование кода в новых проектах
- Вам придется учится на своих ошибках вместо использования преимуществ чужого проверенного кода
ОГРОМНАЯ пропасть
В процессе проведения наших семинаров и подготовки моей книги Human JavaScript, равно как и внутри нашей команды как таковой, мы пришли к пониманию, что есть огромная пропасть между процессом выбора инструмента, фреймворка или библиотеки, и непосредственно разработкой законченного приложения.
Я не говорю о том, что сам вопрос «как создать приложение силами команды так, чтобы не отдавить друг другу ноги и другие части тела?» сталкивает нас с рядом серьезных проблем. Ведь кроме вопроса выбора фреймворка, у нас есть еще куча способов и паттернов, которые мы можем использовать для структурирования, сборки и развертывания приложений.
Об этих вопросах пишет совсем небольшое количество людей, хотя эта кроличья нора кажется не менее глубокой, чем та, в которую мы попадаем в попытках выбора фреймворка.
Что мы на самом деле хотим
- Чтобы было понятно, с чего начать
- Понятный, но не единственно возможный, способ решения типовых задач
- Предельно очевидное разделение ответственности для легкой замены и сочетания различных частей приложения
- Легкое управление зависимостями
- Возможность использовать существующие проверенные решения, не изобретая велосипедов
- Инфраструктура разработки, при которой мы можем переключаться между dev- и prod-режимами простым изменением булевой переменной в конфиге
Что мы предлагаем по этому поводу
Итак, если вы еще не догадались, мы сделали страшную для мира JavaScript вещь. А именно «новый» фреймворк: Ampersand.js. Слегка напоминает облегченный Backbone или его ответвление.
Обратная связь пока что крайне позитивна, мы анонсировали его в середине лета, и ряд замечательных ребят уже подключились к работе по его развитию. Уже появились доклады о нем на конференциях, а Джереми Ашкеназ, создатель Backbone.js, Underscore.js, и CoffeeScript попросил меня седлать кейноут об Ampersand.js на BackboneConf 2014.
Как же мы постарались учесть все те недостатки, которые я перечислил выше по отношению к другим фреймворкам?
- Гибкость и расширяемость
- В Ampersand есть набор модулей «ядра» (см. документацию), которые примерно соответствуют набору компонентов Backbone. Но их все можно устанавливать и использовать по отдельности. Не предполашается, что вы обязательно должны использовать RESTful или вообще Ajax API. Если вам не нужны эти штуки, вы просто используете Ampersand-State, а не его декорированную версию, Ampersand-Model, которая дополняет State RESTful методами.
- В комплекте нет никакого шаблонизатора. Шаблоны могут быть задаваться элементарными строками с HTML, функциями, которые возвращают такие строки, либо функциями, возвращающими DOM-элементы. В демо-приложении есть примеры использования более сложных templatizer-шаблонов, но реально шаблонизацию можно делать чем угодно. Например, есть замечательный подход в стиле handlebars/htmlbars + Ember с объявлением привязок внутри самого шаблона, реализованный в domthing Филипом Робертсом. Есть разработчики, использующие React в связке с Ampersand-представлениями.
- В представлениях (вьюхах) можно задавать привязки к данным, не зависимо от шаблонизатора. То есть, если нужно, вы можете использовать просто HTML строки в качестве шаблонов и все равно полностью контролировать процесс связывания данных с их представлением. Отсутствие шаблонизатора в стандартном комплекте дает возможность создавать модульные/многократно используемые представления без необходимости таскать вместе с ними еще и шаблонизатор.
- Должна существовать некая очевидная стартовая точка и концептуальная схема задания структуры приложения, но эти вещи не должны превращаться в обязаловку. Мы создали CLI, который вы можете использовать для создания каркаса новых приложений. Он берет за основу ряд подобных соглашений, и может служить как для начального этапа разработки, так и просто как источник полезных знаний. Больше информации можно найти в мануале.
- Мы решили, что лучше взять за основу нечто с хорошей репутацией, чем создавать новый фреймворк, просто, чтобы создать новый фреймворк. Поэтому мы взяли за основу Backbone, а не делали все с нуля.
- Хотелось также иметь более полный мануал, который устраняет эту пропасть, о которой я говорил выше. В нем должно быть уделено внимание всем окружающим концепциям, инструментам и парадигмам. Для этого мы написали книгу Human JavaScript. Ее можно целиком бесплатно прочесть онлайн, и она также доступна в e-book формате.
- Мы хотели сделать легким использование существующих решений распространенных задач для минимизации велосипедостроения в проектах. Поэтому мы используем npm для управления всеми пакетами, и сделали каталог наших любимых clientside модулей с удобным поиском.
- Также хотелось иметь возможность безболезненного перехода из dev-окружения в продакшен. Эту проблему мы решаем использованием moonboots, который добавляет такую функциональность в browserify. У moonboots есть плагин для hapi.js и express.js, где все, что вам нужно сделать для изменения режима работы приложения с продакшен варианта (минифицированные, кешируемые статические сборки с уникальными именами) на dev (пересобираем код на каждый новый запрос, не минифицируем и не кешируем что-либо) — это изменить значение одной булевой переменной.
- Мы не хотели, чтобы этот проект принадлежал исключительно нашей &yet. У нас уже появилось порядка 40 контрибуторов с момента, когда мы рассказали всем об Ampersand.js и недавно мы добавили первого из, надеюсь, многих не-из-&yet контрибуторов в проект ядра фреймворка. Все части используют крайне лояльную лицензию MIT, а модульная слабо-связная структура фреймворка сама по себе дает возможность заменить или расширить любую его составляющую для соответствия вашим требованиям. Мы также завели отдельную организацию под этот проект на GitHub.
- Также хотелось обеспечить дополнительную поддержку и обучение при необходимости. Для этого мы сделали общедоступным IRC-канал #&yet на freenode для вопросов и поддержки. В дополнение к бесплатным ресурсам, мы сделали онлайн-курс «Human JavaScript code-along» и оффлайн-семинары с практическими занятиями и обратной связью.
Итак, вы хотите сказать, что Ampersand это однозначно лучший выбор?
Нет. У него конечно же есть свой список компромиссных решений. Вот те из них, которые мне очевидны, наверное, есть еще:
- Естественно, что у Ampersand еще несколько незрелая кодовая база по сравнению с некоторыми другими подобными инструментами. Признавая это, мы, однако, используем его во всех одностраничных приложениях, разрабатываемых нами, и все базовые модули имеют хорошее тестовое покрытие. Стоит отметить, что если вы все же столкнулись с проблемой, скорее всего, вы сможете разобраться с ней сами. Его открытая, изменяемая и достраиваемая архитектура отличает его от остальных фреймворков, и вам не придется долго изворачиваться, чтобы поправить или изменить что-то в вашем приложении. Небольшой размер модулей упрощает задачи по изолированию и исправлению багов и позволяет быстро публиковать фиксы. В реальности мы часто публикуем версию с новым патчем в npm как только смерджим пулл-реквест. Мы строго придерживаемся семантического версионирования, что позволяет нам поступать таким образом, сводя к минимуму риск поломки в существующего кода. Я думаю, это основная причина того, что мы получили так много пулл-реквестов к настоящему моменту. При этом, если вы думаете, что какая-то часть фреймворка должна работать по-другому, вы всегда можете использовать свой модуль вместо стандартного. Мы также делаем шаги для увеличения числа основных коммитеров, чтобы быть уверенными в том, что патчи добавляются в проект даже когда другие разработчики заняты.
- Пока еще вокруг Ampersand не существует развитой инфраструктуры инструментов и большого сообщества. Все это требует времени, но, как я уже говорил, нас очень вдохновляет та обратная связь, которую мы уже получаем. Включайтесь, исправляйте баги, реализовывайте ту функциональность, которую вам хочется видеть в Ampersand.
- Поддержка старых браузеров это слабое место Ampersand. Мы специально установили границу в этом вопросе, сказав, что мы не будем поддерживать IE8. Мы не одиноки в таком решении, jQuery 2.0 идет по тому же пути, Google оставил в поддерживаемых браузерах только две последние версии IE и недавно отказался от поддержки и IE9 тоже, да и сам Microsoft постепенно отказывается от поддержки старых браузеров. Почему мы так решили? В основном, потому что мы используем геттеры и сеттеры для управления состоянием. Это было непростое решение, но было ощущение, что мы больше выиграем, чем потеряем. К сожалению, поскольку это фича непосредственно языка, ее не просто эмулировать (по крайней мере, я такого метода не знаю). И понятно, что для некоторых компаний отсутствие поддержки IE8 будет решающим моментом. Возможно к этому моменту кто-то уже написал плагин для browserify transform, который может это сделать, но мне о нем пока не известно. Если у вас есть, что предложить по этому поводу, пожалуйста, напишите, я буду очень рад, если мы сможем добавить поддержку IE 7 и 8 в Ampersand-State.
В заключение
Надеюсь, мне удалось донести до вас свои мысли и они оказались для вас полезными. Если у вас есть что сказать по этому поводу или если я что-то упустил или где-то ошибся, со мной можно связаться в Твиттере.
И конечно давайте вместе делать наши инструменты лучше. Нам нравится, когда к таким проектах подключается много людей. Пишите о найденных багах или выберите себе одну из открытых задач по вкусу и помогите нам сделать нужный патч.
Автор: osharper
