Начали использовать Ангуляр 2 когда он еще был в бете, потом перевели на одну из первых релизных версий и с тех пор не трогали, ибо и так работает :), да и каких-то особых новых возможностей в версии 4 и 5 я не вижу. В то время все примеры, включая Quick Start, были сделаны с использованием System JS загрузчика, который мы до сих пор используем в режиме разработки. И только для подакшена собираем бандлы с помощью Web Pack (которые, однако, тоже загружаются через SystemJS в runtime).
Недавно посмотрел на последний Quick start и слегка удивился. SystemJS убрали совсем и все делают через Web Pack, что слегка, обескураживает, поскольку при малейшем изменении в коде приходится пересобрать проект, что бы увидеть его на экране. У нас же достаточно сохранить .ts файл и нажать F5 в браузере. Typescript автоматом пересоздаст .js (compile on save = true), System JS его автоматом подхватит. Очень удобно и nodejs постоянно в разработке не нужен поскольку Typescript у нас компилируется через Visual Studio.
Может я не понял нового подхода, предлагаемого как в Angular Quick start, так и в этой статье? На первый взгляд это кажется очень неудобно.
Если у вас маппинг 1:1 то все хорошо и ORM уместен. Иначе приходится делегировать маппинг SQL запросам или делать это на уровне приложения получая риск проблем с производительностью.
Не совсем понимаю, что вы подразумеваете под маппингом 1:N. Можете привести пример? Могу лишь предположить, что вы получаете от ORM «N» промежуточных объектов и агрегируете их в один объект бизнес модели
ORM очень удобен в тех случаях когда модель базы совпадает с моделью бизнесс логики. Такая ситуация встречается довольно часто, например CRUD админки. Однако, если данные хранятся не так как обрабатываются, то использование ORM, скорее всего, будет неуместно.
Сам 10 лет назад делал веб приложения на XSLT – вполне работоспособный вариант (сайт до сих пор работает :) ). Там правда была задача уменьшить размер загружаемых на клиента данных, поскольку интернет в те времена не был так быстр.
Реальные кейсы где Angular 2 выигрывает это скорее экономические и политические, нежели чисто технические.
Например, поиск новых разработчиков: если человек знает Angular 2, то можно сразу в бой, поскольку все проекты на Ангуляре 2 похожи, но если он знает React, то далеко не факт, что он сможет сходу начать работу (на проекте с React разумеется).
Кроме того, надежда на то, что создатели Ангуляра не бросят разработку (поддержку) в среднем выше чем для многих других решений. Первый ангуляр до сих пор обновляют.
Ангуляр 2 это действительно непростой инструмент, но для сложных задач должен быть выбран советующий инструмент. Тут можно привести аналогию – лопата и экскаватор. Лопату освоить просто, экскаватор сложнее. Но сколько можно выкопать лопатой, а сколько экскаватором за один и тот же отрезок времени? Другое дело, что если нужна одна небольшая ямка в труднодоступном месте и при ограниченном бюджете, то экскаватор вообще не вариант. Я использую второй ангуляр в достаточно крупном проекте (те самые тысячи страниц =) ) уже в течении года + до этого пол года на “Proof of concept” (начинали еще с альфы), и могу сказать, что этот фреймворк просто великолепен как комплексное решение, но я вполне понимаю недоумение людей впервые смотрящих на “Hello World” – тут действительно ангуляр 2 кажется переусложненным.
По поводу вашего примера на alight хочу выразить вам благодарность – действительно интересно как одни и те же задачи решаются с использованием разных инструментов. К сожалению, я не знаком с alight поэтому не могу оценить простоту, но по поводу использования innerHTML у меня есть подозрение, что будет сложно добавить интерактив к шаблону будет непросто (могу ошибаться).
Вот вариант на Ангуляр 2 с кнопкой “Archive” клик на которую обрабатывается родительской страницей. Потребовался лишь минимум изменений.
Недавно посмотрел на последний Quick start и слегка удивился. SystemJS убрали совсем и все делают через Web Pack, что слегка, обескураживает, поскольку при малейшем изменении в коде приходится пересобрать проект, что бы увидеть его на экране. У нас же достаточно сохранить .ts файл и нажать F5 в браузере. Typescript автоматом пересоздаст .js (compile on save = true), System JS его автоматом подхватит. Очень удобно и nodejs постоянно в разработке не нужен поскольку Typescript у нас компилируется через Visual Studio.
Может я не понял нового подхода, предлагаемого как в Angular Quick start, так и в этой статье? На первый взгляд это кажется очень неудобно.
ORM очень удобен в тех случаях когда модель базы совпадает с моделью бизнесс логики. Такая ситуация встречается довольно часто, например CRUD админки. Однако, если данные хранятся не так как обрабатываются, то использование ORM, скорее всего, будет неуместно.
Ну так с web assembly можно (теоретически) использовать любой язык компилируемый для llvm, со строгой типизацией или без.
Идея внедрить Web Assembly кажется более удачной
А можно ли будет применять функции map reduce filter и пр. над асинхронными итераторами? Получилась бы хорошая замена observable.
В MVC уже есть (были?) так называемые Areas, которые и служат для решения описанных в статье проблем.
В ангуляре мы тоже, по сути, передаём «функцию» в компонент:
<template> компилируется в TemplateRef у которого есть метод createEmbeddedView(context: C)
Хотя соглашусь, в React это выглядит изящнее
Все ждал когда про Реакт вспомнят =)
Реальные кейсы где Angular 2 выигрывает это скорее экономические и политические, нежели чисто технические.
Например, поиск новых разработчиков: если человек знает Angular 2, то можно сразу в бой, поскольку все проекты на Ангуляре 2 похожи, но если он знает React, то далеко не факт, что он сможет сходу начать работу (на проекте с React разумеется).
Кроме того, надежда на то, что создатели Ангуляра не бросят разработку (поддержку) в среднем выше чем для многих других решений. Первый ангуляр до сих пор обновляют.
а пока можете создать полифил ;)
Ангуляр 2 это действительно непростой инструмент, но для сложных задач должен быть выбран советующий инструмент. Тут можно привести аналогию – лопата и экскаватор. Лопату освоить просто, экскаватор сложнее. Но сколько можно выкопать лопатой, а сколько экскаватором за один и тот же отрезок времени? Другое дело, что если нужна одна небольшая ямка в труднодоступном месте и при ограниченном бюджете, то экскаватор вообще не вариант. Я использую второй ангуляр в достаточно крупном проекте (те самые тысячи страниц =) ) уже в течении года + до этого пол года на “Proof of concept” (начинали еще с альфы), и могу сказать, что этот фреймворк просто великолепен как комплексное решение, но я вполне понимаю недоумение людей впервые смотрящих на “Hello World” – тут действительно ангуляр 2 кажется переусложненным.
По поводу вашего примера на alight хочу выразить вам благодарность – действительно интересно как одни и те же задачи решаются с использованием разных инструментов. К сожалению, я не знаком с alight поэтому не могу оценить простоту, но по поводу использования innerHTML у меня есть подозрение, что будет сложно добавить интерактив к шаблону будет непросто (могу ошибаться).
Вот вариант на Ангуляр 2 с кнопкой “Archive” клик на которую обрабатывается родительской страницей. Потребовался лишь минимум изменений.