плюс люди со стороны заказчика, члены групп которые могут смотреть код/пользоваться стэшом, несколько служебных аккаунтов (админ/бамбу/etc), итого около 70 юзеров.
ну человек жалуется на то что у него стэк-трейс режется до digest-loop'а. Но он всегда будет резаться, потому что колбеки всегда будут, даже при использовании promise'ов, которые их по сути всего лишь прячут. На ответ от сервера, на банальный setTimeout чтобы отдать управление браузеру, и т.д. Пример, где «не печально» — async/await шарповые
1. Data-binding и его возможные тормоза. Простой ответ — за удобство приходится платить. Нефиг всю логику на него завязывать. Понятно, что watchCollection на тысячи элементов будет тормозить. Поэтому никого не должно удивлять, что особо критические места, возможно, придется оптимизировать ручками и без байндинга (гриды/чарты/etc). Вообще напоминает недавний пост про сборщик мусора в C#, который якобы течет и тормозит — а у автора просто-напросто объекты во второе поколение и LOH попадали очень быстро
2. DI. В JS невозможно его реализовать с использованием типов аргументов, как в нормальных языках, поэтому приходится использовать алиасы. Есть три возможных варианта использования, один из которых не дружит с минификацией или, например, с неймспейсами. Проблем с двумя другими нет. Автору только считает синтаксис уродливым. Срочно всем перестать использовать ангуляр! По поводу 5 «новых» сущностей и мучающихся людей. Тут просто сказать нечего, у некоторых этих сущностей вообще-то даже разный жизненный цикл
3. Дебагинг. Не самое приятное дело, да. Но дебагинг в среде, построенной на асинхронных событиях от браузера, вообще штука печальная
4. Наследование scope'ов. Нужно. Все в сервисы не понапихаешь, хотя бы потому, что они синглтоны. И да, 'Controller As' синтаксис. Хотфикс примера на fiddle — jsfiddle.net/1op3L9yo/253/. Вообще пример хороший, заберу в качестве задачки на собеседования с вопросом «почему так?» :)
5. Синтаксис директивы довольно сложный, да. Но как правило сокращается до scope, restrict и link. Остальное иногда пригождается. Пункт аналогичен — не пишите на Java, там стопиццот различных ключей в командной строке.
6. Проблемы с людьми — так на любой технологии эти проблемы, сильные разработчики работу долго не ищут :) Адекватные разработчики основы понимают довольно быстро, а структурированность ангуляра сильно помогает, особенно тем кто имеет опыт в бэкенде. Если лабать визитки на JQuery последние лет 5, то да, есть опасность разрыва шаблона. Но черт возьми, это же не C++!
7. Серверная шаблонизация — наверное единственный стоящий пункт здесь. Никто не мешает генерить HTML template на сервере тем же .NET'ом или каким-нибудь шаблонизатором, но мне кажется имелось в виду нечто типа isomorphic js раз уже SEO помянут. Мы эту проблему не решаем, у нас немного иной класс приложений :)
8. Документации достаточно. Если есть проблемы с тем, как и почему использовать — это не в документацию, а на амазон за литературой
Остальное по 10 раз объяснено в других комментариях.
Собственно народ и накинулся, потому что единственная реальная проблема (шаблонизация?) в статье затронута так, что приходится гадать, а что собственно имелось в виду? Все остальное из разряда — тут синтаксис плох, там слишком сложно, это ниасилил.
А как вы предлагаете сделать так, чтобы все работало без «плагинов»?
Если не хочется наследования — существует «controller as» синтаксис. А плюсом является доступ из контроллера к scope парентовых контроллеров без директив и всяческих $parent
По поводу сложности — допустим сектор круга (d3'шный arc). Вопрос не про единовременную отрисовку, к ней вопросов нет, вопрос был про анимацию. Я не знаю с каким фпс-ом работает transition в d3, но вот requestAnimationFrame это по дефолту 60 фпс. В анимации, допустим, меняются радиусы у этих элементов. Профайлер у меня вообще на изменение атрибута у DOM-элемента ругался больше всего. Снижение фпс, замена честных секторов на полигоны и тому подобное да, помогает. Просто мне не понравился тезис
поэтому анимация почти любой сложности с огромным числом элементов (c 0:30) рисуется и двигается плавно.
Ну и не надо забывать что есть например IE, в котором SVG работает не в пример хуже чем в хроме. Если я где-то не прав, поправьте пожалуйста, скорее всего я и впрямь чего-то не знаю.
Пардон, под точками я имел в виду элемент path. Ну в общем либо я не умею его готовить, либо еще что, но аналог вот такой штуки bl.ocks.org/mbostock/4063423 (это иерархический кластеринг) при около 10 тысячах элементов заставляла меня очень печалится…
Про прямый коммит (кстати, вот issue — jira.atlassian.com/browse/STASH-2910): в branch permissions можно запретить всем запись в бранч, но тогда никто и на merge нажать не сможет, то есть все-равно нужен один генерал с большими правами.
2. DI. В JS невозможно его реализовать с использованием типов аргументов, как в нормальных языках, поэтому приходится использовать алиасы. Есть три возможных варианта использования, один из которых не дружит с минификацией или, например, с неймспейсами. Проблем с двумя другими нет. Автору только считает синтаксис уродливым. Срочно всем перестать использовать ангуляр! По поводу 5 «новых» сущностей и мучающихся людей. Тут просто сказать нечего, у некоторых этих сущностей вообще-то даже разный жизненный цикл
3. Дебагинг. Не самое приятное дело, да. Но дебагинг в среде, построенной на асинхронных событиях от браузера, вообще штука печальная
4. Наследование scope'ов. Нужно. Все в сервисы не понапихаешь, хотя бы потому, что они синглтоны. И да, 'Controller As' синтаксис. Хотфикс примера на fiddle — jsfiddle.net/1op3L9yo/253/. Вообще пример хороший, заберу в качестве задачки на собеседования с вопросом «почему так?» :)
5. Синтаксис директивы довольно сложный, да. Но как правило сокращается до scope, restrict и link. Остальное иногда пригождается. Пункт аналогичен — не пишите на Java, там стопиццот различных ключей в командной строке.
6. Проблемы с людьми — так на любой технологии эти проблемы, сильные разработчики работу долго не ищут :) Адекватные разработчики основы понимают довольно быстро, а структурированность ангуляра сильно помогает, особенно тем кто имеет опыт в бэкенде. Если лабать визитки на JQuery последние лет 5, то да, есть опасность разрыва шаблона. Но черт возьми, это же не C++!
7. Серверная шаблонизация — наверное единственный стоящий пункт здесь. Никто не мешает генерить HTML template на сервере тем же .NET'ом или каким-нибудь шаблонизатором, но мне кажется имелось в виду нечто типа isomorphic js раз уже SEO помянут. Мы эту проблему не решаем, у нас немного иной класс приложений :)
8. Документации достаточно. Если есть проблемы с тем, как и почему использовать — это не в документацию, а на амазон за литературой
Остальное по 10 раз объяснено в других комментариях.
Собственно народ и накинулся, потому что единственная реальная проблема (шаблонизация?) в статье затронута так, что приходится гадать, а что собственно имелось в виду? Все остальное из разряда — тут синтаксис плох, там слишком сложно, это ниасилил.
Если не хочется наследования — существует «controller as» синтаксис. А плюсом является доступ из контроллера к scope парентовых контроллеров без директив и всяческих $parent
родной студийный модуль для гита не работает с SSH
в общем, сравнивали стек Atlassian и TFS — предсказуемо выбрали первое
Ну и не надо забывать что есть например IE, в котором SVG работает не в пример хуже чем в хроме. Если я где-то не прав, поправьте пожалуйста, скорее всего я и впрямь чего-то не знаю.