Просто Ваш заголовок и статья намекают, что у Вас готовый к использованию продукт — качай (покупай), ставь и работай. А получается, что это не так, взять и развернуть просто так не получится.
Документация очень важна, хотя бы базовая, и особенно по серверной части (системные требования и требования к окружению, javadoc и пр.).
Представьте себе, в Ember тоже есть data-binding, и реализован он в тысячу раз лучше, чем в Angular, как с точки зрения производительности, так и удобства.
А что касается декларативности, то JS-код в Ember пишется декларативно благодаря в ленивым, кэшируемым вычисляемым свойствам (computed properties). В Angular сплошная императивщина, на которую после Ember смотреть противно.
Сравнить не могу, потому что Ember не использовал. С удовольствием прочитаю Вашу статью на эту тему.
А чем кстати «императивщина» вдруг стала хуже декларативного подхода? По моему просто два разных подхода, со своими плюсами и минусами.
Это самый большой п#@дёж, который можно услышать в пользу Angular.
В реальных проектах вы сталкиваетесь с HTML-элементами, имеющих десятки атрибутов.
Если у Вас десятки атрибутов на одном html-элементе, это сигнал о том, что пора бы эту директиву разбить или изменить интерфейс доступа к ней. Никогда честно говоря не испытывал с этим сложности.
Вот за что приходится платить, так это за Angular'овский dirty-checking. Сделать на Angular тяжелый, сложный вэб-интерфейс просто невозможно. Чтобы справиться с тормозами, приходится отказываться от data-binding'а и обновлять DOM по-старинке.
Не соглашусь, эта задача вполне Ангуляру по силам.
А можете привести пример такой логики? Не встречал такой, если честно…
Наследования как такового конечно же нет, но есть очень полезная штука require. С ее помощью можно логически объединять директивы, зависящие друг от друга. Например, если Вы захотели сделать собственный dropdown, то можно директиву разбить на две части. Одна часть будет связана с логикой «навешивания» на элемент (и таких директив может быть несколько, в зависимости от элемента, например), а вторая часть будет реализовывать показ непосредственно панели со списком.
Такой подход позволит использовать общую часть (панель со списком) с разными элементами и директивами (меню или инпут с селектом).
В целом такой подход (анонимные функции) объявления модулей вообще не рекоммендуется.
А почему не рекомендуется? Не встречал такого мнения…
В моем случае все моудли разбиты на отдельные файлы и линкуются через browserify, именем модуля является имя функции, довольно удобно.
У Вас в одном файле собраны все сервисы, контроллеры и директивы, связанные с модулем?
Мы разбивали каждую отдельную сущность на отдельный файл. Структура слегка «пухла», но в целом было удобнее вносить точечные правки и рефакторить файл, было меньше конфликтов.
Да, Вы правы, эти проблемы напрямую не относятся к AngularJS. Не могу сказать, что фреймворк накладывал какие-то ограничения на использование в мобильных браузерах конкретно у нас.
Сложновато отделить проблемы с производительностью двойного связывания от наведенных проблем другими компонентами. У нас показывалось примерно до 200 «плиток» на странице (может быть и больше удавалось показывать за счет бесконечной прокрутки, сложно сказать) и на каждой порядка 15 элементов были с двойным связыванием. Хуже всех себя показывал нативный Android браузер. Chrome, Safari и Firefox были примерно на одном уровне. Были небольшие тормоза при прокрутке и «затыки» при добавлении новых элементов, вероятно связанные в большей степени из-за манипуляций с расчетом позиций этих «плиток».
В целом, не могу сказать что производительность страдала конкретно из-за AngularJS. При разумном применении (не на синтетическом примере в 2000 $watch), я думаю скорость не сильно упадет.
По совместимости, могу сказать, что не сталкивался с проблемами. Во всех браузерах логический код отрабатывал ожидаемо.
Наше приложение работало также и в мобильных браузерах, и надо отметить это было нашей ошибкой. Вкратце:
Производительность раза в 2-3 (субъективно) хуже, чем на десктопе. У нас использовалась masonry-плитки с картинками.
Пришлось в одном приложении адаптировать пользовательский интерфейс одновременно и для мобильных устройств, и для десктопа. Это вылилось в большую кучу «костылей» и ветвлений в коде, «резиновая» верстка полностью не покрывала все случаи. Чудес, увы, не бывает.
Было очень много багов, связанных с конкретными браузерами на устройствах. Поддерживать их все было очень сложно. Бывали даже случаи, когда один и тот же баг в одной и той же версии браузера повторялся на устройствах Samsung, но упорно не хотел на устройствах LG (Nexus)
Сейчас, мы бы разделили эти приложения на два разных с точки зрения UI части, но объединили бы логическую часть (сервисы) через Ionic. Это было бы правильнее, на мой взгляд.
Под капотом у prerender'a находится PhantomJS. Он в real-time сходит на страницу и на выходите даст сформированный html с выполненным javascript'ом.
Во втором случае мы просто сделали, как Вы и упомянули, второй комплект шаблонов, который формировали на сервере из данных БД. На этом и остановились, потому как других путей найти не удалось.
Можно немного расширить второй путь и формировать html'ки заранее, складывая их в какой-нибудь кеш. Но тут все зависит от объема данных и насколько актуальными их надо держать. Нам это не подошло, данные могли меняться быстро, а объем позволял их формировать «на лету» без потери производительности.
Генерить статические странички «на лету» или складировать их заранее в кеш.
Мы пытались пойти по первому пути и долго бились, чтобы все заработало как надо. Мы использовали обертку на node.js, но, к сожалению, сам сервер постоянно падал после нескольких десятков обращений. Поэтому мы переключились на второй вариант, на котором и остановились.
Документация очень важна, хотя бы базовая, и особенно по серверной части (системные требования и требования к окружению, javadoc и пр.).
Сравнить не могу, потому что Ember не использовал. С удовольствием прочитаю Вашу статью на эту тему.
А чем кстати «императивщина» вдруг стала хуже декларативного подхода? По моему просто два разных подхода, со своими плюсами и минусами.
Если у Вас десятки атрибутов на одном html-элементе, это сигнал о том, что пора бы эту директиву разбить или изменить интерфейс доступа к ней. Никогда честно говоря не испытывал с этим сложности.
Не соглашусь, эта задача вполне Ангуляру по силам.
Наследования как такового конечно же нет, но есть очень полезная штука require. С ее помощью можно логически объединять директивы, зависящие друг от друга. Например, если Вы захотели сделать собственный dropdown, то можно директиву разбить на две части. Одна часть будет связана с логикой «навешивания» на элемент (и таких директив может быть несколько, в зависимости от элемента, например), а вторая часть будет реализовывать показ непосредственно панели со списком.
Такой подход позволит использовать общую часть (панель со списком) с разными элементами и директивами (меню или инпут с селектом).
А почему не рекомендуется? Не встречал такого мнения…
У Вас в одном файле собраны все сервисы, контроллеры и директивы, связанные с модулем?
Мы разбивали каждую отдельную сущность на отдельный файл. Структура слегка «пухла», но в целом было удобнее вносить точечные правки и рефакторить файл, было меньше конфликтов.
Сложновато отделить проблемы с производительностью двойного связывания от наведенных проблем другими компонентами. У нас показывалось примерно до 200 «плиток» на странице (может быть и больше удавалось показывать за счет бесконечной прокрутки, сложно сказать) и на каждой порядка 15 элементов были с двойным связыванием. Хуже всех себя показывал нативный Android браузер. Chrome, Safari и Firefox были примерно на одном уровне. Были небольшие тормоза при прокрутке и «затыки» при добавлении новых элементов, вероятно связанные в большей степени из-за манипуляций с расчетом позиций этих «плиток».
В целом, не могу сказать что производительность страдала конкретно из-за AngularJS. При разумном применении (не на синтетическом примере в 2000 $watch), я думаю скорость не сильно упадет.
По совместимости, могу сказать, что не сталкивался с проблемами. Во всех браузерах логический код отрабатывал ожидаемо.
Сейчас, мы бы разделили эти приложения на два разных с точки зрения UI части, но объединили бы логическую часть (сервисы) через Ionic. Это было бы правильнее, на мой взгляд.
Добавлю в полезные инструменты.
Во втором случае мы просто сделали, как Вы и упомянули, второй комплект шаблонов, который формировали на сервере из данных БД. На этом и остановились, потому как других путей найти не удалось.
Можно немного расширить второй путь и формировать html'ки заранее, складывая их в какой-нибудь кеш. Но тут все зависит от объема данных и насколько актуальными их надо держать. Нам это не подошло, данные могли меняться быстро, а объем позволял их формировать «на лету» без потери производительности.
Для подготовки шаблонов можно использовать любой язык и шаблонизатор на Ваш вкус.
Если имелось в виду рендеринг для поисковиков, то тут есть два пути:
Мы пытались пойти по первому пути и долго бились, чтобы все заработало как надо. Мы использовали обертку на node.js, но, к сожалению, сам сервер постоянно падал после нескольких десятков обращений. Поэтому мы переключились на второй вариант, на котором и остановились.