Лишь отчасти соглашусь с некоторыми суждениями, но СЛИШКОМ МНОГО BOLD'оВОГО КАПСА НИКОГДА НЕ БЫВАЕТ МНОГО.
Во многом согласен с комментариями о дилетантстве — все описанные проблемы достаточно просто решаются при наличии желания и гугла.
Ограничения $digest цикла можно легко преодолеть, об этом уже было написано тут и о результатах в 1200ms -> 35ms тут.
DI не работает после минификации — в офф доках ангуляра прямо говорят (раздел Note on minification): используйте $inject, или аннотации. Опять же, не стоит ныть по поводу «мне влом написать 5-6 слов со знаком $ — этого не должно быть, это проблема фреймворка !». Указать минификатору наличие сторонних глобальных переменных не составляет особого труда, и это никак не относится к дизайну самого фреймворка.
По поводу «нетестированности» самого фреймворка, а автор пробовал Protractor с ngMock'ом? Есть $exceptionHandler и им вполне так удобно перехватывать любые ошибки. Хватит ныть — читайте документацию.
Наследование скоупов не имеет прямого отношения к ангуляру непосредтсвенного — это просто заморочка прототипного наследования в JS'e. Немного гугломагии подтверждает, и такого уже было написано очень много. Опять же, сами ангуляровцы в доках советуют не использовать глубокое вложение объектов внутри $scope потому что там будут глюки с $watch'ерами и $digest циклом. Использование нескольких уровней вложения в рамках одной директивы не поощряется, по тем же причинам что и указанны в статье… и это не является проблемой — ничего не мешает писать $scope.btnCaption вместо $scope.btn.caption.
Синтаксис
ng-controller="SomeController as OtherName"
не более чем синтаксический сахар для избежания путаницы в описаниях контроллеров, и никакого отношения к проблеме не имеет.
Понимание или непонимание работы директив зависит от каждого конкретного разработчика — проще чем есть сделать не получится. Если для вас это сложно — это ваши проблемы.
По сравнению с тем же backbone или ember — Angular совсем не сложный, и в нём ничего не протекает. Конечно после jQuery у людей странное выражение лица, но качественный богатый фронтенд не подразумевает место для поиска «плагина завоевания мира нажатием одной кнопки». Учитесь, и не нойте!
Невозможность серверной шаблонизации… хм, ну это зависит как посмотреть на проблему — берём prerender.io, прикручиваем рендер страниц при изменении моделей, кэшируем нормально в Nginx'e и отдаём поисковым роботам. Не то что бы это было изящно, но и писать серверный рендер ангуляра под каждую платформу бессмысленно. Тем более такой подход при небольших нагрузках на запись вполне нормально работает. Для прозрачной клиент-серверной шаблонизации нужна трансляция OT-патчей в CQRS-ES'e — это довольно сложные подходы которые используются в корпоративных приложениях с незапамятных времён (привет vaadin, привет gwt, давно не виделись).
А кто сказал что гугол не использует у себя Angular?
В общем все проблемы которые описанны в статье — вполне решаемы.
Было бы желание погуглить, и не постить на хабр всякую ерунду из-за собственной лени.
Я не говорю что React плох, но сравнивать React с Angular'ом НЕЛЬЗЯ. React это лишь View и View-Model из MVVM, а Angular — чистое MVC. У ангуляра рендер реально слоупочный, и появляются такие странные вещи как ngReact (чую запах жареных мозгов). Я и сам спокойно гоняю React + rx.js в браузере, и на node.js, и вполне так доволен производительностью для средних проектов.
Я надеюсь что во втором ангуляре исправят косяки рендера и начнут напрямую оперировать DOM деревом, без лишних перерисовок и перекомпоновок чего-попало.
Нужно понимать, что React хранит и предполагает получение View-Model состояния с сторонних источников, с последующим вызовом обработчиков для перестройки VirtualDom дерева, и по другому это просто нереализуемо. Другие шаблонизаторы будут тупо оперерировать пустым HTML — создавать бешеный overhead на перерисовки и его разбор, и Angular тоже не исключение. Поэтому появляются такие странные вещи как ngReact :x Вьюхи не генерятся кусками — они формируют дерево компонент со своими состояниями, это может быть и непривычно и я сам не поощряю такой дизайн, но сделано чисто для реюзабельности и простоты работы с DOM деревом.
Человек имеет ввиду: как сборка фронтенда относится непосредственно к реализации бэкенда. Ответ — никак. Просто в ноде больше всего инструментов для этого было разработано.
Большая часть всяких шаблонизаторов, препроцессоров и систем сборки фронтенда была реализована на node.js и ruby. Так просто исторически сложилось. Я тоже хотел бы прикрутить сборку к своему Play2 или golang'у (python не годится для масштабируемых реактивных приложений с push-нотификациями, и без костылей типа celery или микросервисных архитектур, а «прости-Господи» РНР вообще ужасен), к сожалению сущесвтующие решения на ноде очень сильно обгоняют всё остальное по функционалу. Вот мой немного кривой gulp-seed для примера. В случае с ангуляром так ещё есть перепаковка всех шаблонов в один большой js файлик который сразу ложится в кэш браузера при загрузке приложения, и другие довольно полезные вещи. А ещё я люблю писать шаблоны под Angular на jade, а вёрстку в Stylus, и получается целая вязка бубликов. В принципе фронтэнд, есть фронтенд — он просто кушает RESTful API и на сервере ничего не рендерится, и абсолютно всеравно на чём этот сервер будет написан — сборка фронта нам просто отдаст кучу больших файликов с ещё большей кучи мелких, и спрайты упакует, и векторные иконочные шрифты соберёт, и вектор под каждую плотность экрана растерезирует. Для того что бы не было проблем с SEO — просто прикручивают prerender.io, но я не поощряю такого подхода. Гораздо проще гонять тот же react прямо в node.js без каких либо заморочек с webkit'ом. Также gulp асинхронен без лишних побочных эффектов если его правильно готовить, и в нём есть возможность LiveReload'a.
Я не пытаюсь помочь всем подряд. Хочу чтобы проблемы людей, которые ничего не собираются с ними делать, были более ясны тем, кто пытается что-либо осознавать — «тыкаю в мозоли» специально чтобы всплывало наружу и было очевидным. Я и не отрицаю наличия невротизации — у меня было достаточно тяжёлое детство. Прекрасно понимаю что означает позиция помощника (по Берну), но я не играю роль «благородного рыцаря бегущего на помощь». Эта статья также является инструментом решения моих проблем связанных с прокрастинацией, пытаюсь перестраивать свои поведенческие шаблоны. Пока что по моим субъективным — выходит достаточно неплохо.
Сейчас после совка, почти никто не знает чем занимаются психологи. Отчасти я хотел показать что есть проблемы, и их нужно решать — некоторые самостоятельно, а некоторые с помощью сторонних специалистов, которых ещё и нужно поискать. У меня было не так много удачных примеров терапии, а вообще обычно даже дальше консультаций дело не доходит — часто смотришь на психолога и думаешь: где там психология, а где эзотерика. Да и методы сейчас довольно «попсовые» — сплошные гештальты, возрастная психология и расстановки, позиционируются прям как «пилюля от всех болезней». Приходится довольствоваться тем что есть.
Впарить под видом «навыкового» тренинга могут всё что угодно. Это манипуляции на подсознательном уровне которые не зависят непосредственно от темы или задач повествования, часто их результатом является отрицание наличия какой-то проблемы, не подавление, а именно отрицание. У нас тут невротическое общество, в котором проблемы передаются с поколения в поколение, и часто используются для простоты манипуляции. Нужно каждый конкретный тренинг анализировать — там часто всплывают довольно интересные вещи.
Я не могу сейчас подробно объяснять почему Flappy Bird такой успешный, могу лишь сказать что он полностью оперирует животными инстинктами «размножения и поиска пропитания», и любой виральный продукт будет оперировать этим же. Нотч разрабатывал игру которая способна компенсировать подавленную потребность самореализации, в том числе и его собственную. Джобс всячески преследовал задачи личного развития, а не посещал тренинги. Коллективные тренинги сейчас вообще ведут для того что бы у людей была краткосрочная компенсация из-за вытеснения каких-либо личных проблем — у него всё становится отлично, так как «проблем нет». Подобное осуществляется достаточно примитивными манипуляциями, и когда человек приходит в себя, он часто бывает ещё более подавленным чем был ранее. В итоге, имеем толпы людей которые всячески «верят» и полностью «зависимы». В Европе это называют психокультом, у нас это понятие ещё не очень прижилось. На правах рекламы.
Я сказал что он подходит, не надо лишний раз придираться.
Для вменяемой фрагментации контента между двумя взаимозаменяемыми ресурсами нужен контроль извне — ТМ ничего для этого не реализовало и имеем то что имеем.
Человек не высказывал своё мнение относительно причин происходящего, просто что они имеют место быть, и это сложно. А вот «жест» в конце видео всё же можно было вырезать…
С детства думал что ёмкости автомобильных аккумуляторов не хватит для работы мелкой бытовой техники. Рад что есть умельцы способные решить подобные проблемы с ограниченными ресурсами. Надеюсь это скоро прекратится.
Есть понятие Scaffolding'a — это процесс который генерирует для всех табличек в базе по контроллеру, шаблону и тесту для MVC приложения.
Понятное дело что это всё нужно будет потом переписывать под себя, в том числе и часть шаблонов генератора. Как показывает моя практика, scaffolding в lionframe, или Grails, допилить достаточно просто.
В этом комментарии описываются абстрактные генераторы в вакууме — напишите конкретно о решениях которые имеются ввиду, иначе это просто ваше субъективное суждение не обоснованное практикой.
Это отличное DDD проектирование с возможностью выделения сервисов для SOA, но ничего не мешает загрузить схему БД и написать RESTful сервис самому, что бы было понятнее, с такими маршрутами. Tastypie и DRF прекрасно справляется с этой задачей, но вот нормально выделить ААА сервисы бывает довольно сложно.
Когда существуюет 100+ табличек БД — 100+ различных контролллеров с 10-20 сервисами и сложной бизнесс-логикой, поддерживать генерируемый код очень сложно и без хорошего покрытия тестами это приводит к различным побочным эффектам. Это anti-DDD проектирование.
Гораздо проще загрузить схему БД и создать контроллер в с маршрутами
GET /{entityname}/{id}
GET /plural({entityname})
POST /new/{entityname}/
PUT /edit/{entityname}/{id}
DELETE /remove/{entityname}/{id}
OPTIONS /{entityname}/schema
OPTIONS /{entityname}/caching
OPTIONS /{entityname}/rights
OPTIONS /{entityname}/{id}/subscribe
OPTIONS /{entityname}/{id}/changed
C него можно реализовать полноценный RESTful сервис, который будет загружать правила авторизации (c Authorization сервиса) по принципу «запрещено всё, что не разрешено явно», и даст возможность загружать схему данных (типа JSON-Schema) в форнтенд для автоматизческой генерации основных правил валидации, предоставит интерфейсы для реализации сервиса учёта (Accounting) и аутентификации (Authentication).
OPTIONS методы subscribe и changed используются для оповещения об изменениях (JSON-patch, можно и по comet'у, можно и по вэбсокетах) и блокировке сущностей.
Имхо главной главным приемуществом b*-tree является возможность использования более толерантных к кэшу операций с памятью, а недостатком является относительно длительный простой конвееров в процессоре — операцию сравнения нельзя быстро предсказать, и простой возникает уже на каждой второй-третей операции.
Мне в этом плане больше импонируют ART-деревья — с ними достаточно просто реализовать вертикальное масштабирование key-value хранилищ.
Ну да, точно… нужно просто выпускать продукты что бы все были довольны их наличием, и получали прибыль.
Мне это просто не интересно — я не хочу быть «экспертом».
Критика касалась того что у кого-то «аукнулось», а я должен был быть «мягче», и того что тут людям нужно картинки глядеть, а не структурированный текст читать… «нежные» все такие. Всё остальное — ваше личное мнение, которое я не разделяю, можете при нём и остаться.
p.s. читать не смешно, а влом… так что точно не получится.
Во многом согласен с комментариями о дилетантстве — все описанные проблемы достаточно просто решаются при наличии желания и гугла.
Ограничения $digest цикла можно легко преодолеть, об этом уже было написано тут и о результатах в 1200ms -> 35ms тут.
DI не работает после минификации — в офф доках ангуляра прямо говорят (раздел Note on minification): используйте $inject, или аннотации. Опять же, не стоит ныть по поводу «мне влом написать 5-6 слов со знаком $ — этого не должно быть, это проблема фреймворка !». Указать минификатору наличие сторонних глобальных переменных не составляет особого труда, и это никак не относится к дизайну самого фреймворка.
По поводу «нетестированности» самого фреймворка, а автор пробовал Protractor с ngMock'ом? Есть $exceptionHandler и им вполне так удобно перехватывать любые ошибки. Хватит ныть — читайте документацию.
Наследование скоупов не имеет прямого отношения к ангуляру непосредтсвенного — это просто заморочка прототипного наследования в JS'e. Немного гугломагии подтверждает, и такого уже было написано очень много. Опять же, сами ангуляровцы в доках советуют не использовать глубокое вложение объектов внутри $scope потому что там будут глюки с $watch'ерами и $digest циклом. Использование нескольких уровней вложения в рамках одной директивы не поощряется, по тем же причинам что и указанны в статье… и это не является проблемой — ничего не мешает писать $scope.btnCaption вместо $scope.btn.caption.
Синтаксис не более чем синтаксический сахар для избежания путаницы в описаниях контроллеров, и никакого отношения к проблеме не имеет.
Понимание или непонимание работы директив зависит от каждого конкретного разработчика — проще чем есть сделать не получится. Если для вас это сложно — это ваши проблемы.
По сравнению с тем же backbone или ember — Angular совсем не сложный, и в нём ничего не протекает. Конечно после jQuery у людей странное выражение лица, но качественный богатый фронтенд не подразумевает место для поиска «плагина завоевания мира нажатием одной кнопки». Учитесь, и не нойте!
Невозможность серверной шаблонизации… хм, ну это зависит как посмотреть на проблему — берём prerender.io, прикручиваем рендер страниц при изменении моделей, кэшируем нормально в Nginx'e и отдаём поисковым роботам. Не то что бы это было изящно, но и писать серверный рендер ангуляра под каждую платформу бессмысленно. Тем более такой подход при небольших нагрузках на запись вполне нормально работает. Для прозрачной клиент-серверной шаблонизации нужна трансляция OT-патчей в CQRS-ES'e — это довольно сложные подходы которые используются в корпоративных приложениях с незапамятных времён (привет vaadin, привет gwt, давно не виделись).
А кто сказал что гугол не использует у себя Angular?
В общем все проблемы которые описанны в статье — вполне решаемы.
Было бы желание погуглить, и не постить на хабр всякую ерунду из-за собственной лени.
Я не говорю что React плох, но сравнивать React с Angular'ом НЕЛЬЗЯ. React это лишь View и View-Model из MVVM, а Angular — чистое MVC. У ангуляра рендер реально слоупочный, и появляются такие странные вещи как ngReact (чую запах жареных мозгов). Я и сам спокойно гоняю React + rx.js в браузере, и на node.js, и вполне так доволен производительностью для средних проектов.
Я надеюсь что во втором ангуляре исправят косяки рендера и начнут напрямую оперировать DOM деревом, без лишних перерисовок и перекомпоновок чего-попало.
Сейчас после совка, почти никто не знает чем занимаются психологи. Отчасти я хотел показать что есть проблемы, и их нужно решать — некоторые самостоятельно, а некоторые с помощью сторонних специалистов, которых ещё и нужно поискать. У меня было не так много удачных примеров терапии, а вообще обычно даже дальше консультаций дело не доходит — часто смотришь на психолога и думаешь: где там психология, а где эзотерика. Да и методы сейчас довольно «попсовые» — сплошные гештальты, возрастная психология и расстановки, позиционируются прям как «пилюля от всех болезней». Приходится довольствоваться тем что есть.
Для вменяемой фрагментации контента между двумя взаимозаменяемыми ресурсами нужен контроль извне — ТМ ничего для этого не реализовало и имеем то что имеем.
С детства думал что ёмкости автомобильных аккумуляторов не хватит для работы мелкой бытовой техники. Рад что есть умельцы способные решить подобные проблемы с ограниченными ресурсами. Надеюсь это скоро прекратится.
Спасибо, было интересно.
Понятное дело что это всё нужно будет потом переписывать под себя, в том числе и часть шаблонов генератора. Как показывает моя практика, scaffolding в lionframe, или Grails, допилить достаточно просто.
В этом комментарии описываются абстрактные генераторы в вакууме — напишите конкретно о решениях которые имеются ввиду, иначе это просто ваше субъективное суждение не обоснованное практикой.
POST /add/plural({entityname})/[to|for]/{entityname}/id DELETE /remove/plural({entityname})/from/{entityname}/idp.s. Это тема для отдельной статьи, которую мне уже не хочется писать после комментариев к предыдущей.
Гораздо проще загрузить схему БД и создать контроллер в с маршрутами
GET /{entityname}/{id} GET /plural({entityname}) POST /new/{entityname}/ PUT /edit/{entityname}/{id} DELETE /remove/{entityname}/{id} OPTIONS /{entityname}/schema OPTIONS /{entityname}/caching OPTIONS /{entityname}/rights OPTIONS /{entityname}/{id}/subscribe OPTIONS /{entityname}/{id}/changedC него можно реализовать полноценный RESTful сервис, который будет загружать правила авторизации (c Authorization сервиса) по принципу «запрещено всё, что не разрешено явно», и даст возможность загружать схему данных (типа JSON-Schema) в форнтенд для автоматизческой генерации основных правил валидации, предоставит интерфейсы для реализации сервиса учёта (Accounting) и аутентификации (Authentication).
OPTIONS методы subscribe и changed используются для оповещения об изменениях (JSON-patch, можно и по comet'у, можно и по вэбсокетах) и блокировке сущностей.
Это SOA по DDD, без генерации тонны копи-пасты.
Мне в этом плане больше импонируют ART-деревья — с ними достаточно просто реализовать вертикальное масштабирование key-value хранилищ.
Мне это просто не интересно — я не хочу быть «экспертом».
p.s. читать не смешно, а влом… так что точно не получится.