Comments 74
Документация — говно,
Devtools — говно, вернее нормальных нет(кроме как Redux DevTools), Augury — ущербная, бажная.
Обновление angular cli это позор — так как она обновляет лучше бы ее и не было.
live reload — просто жесть.
Размер приложения после сборки — ужас
Режимы компиляции — ад(в дев режиме может все работать а в билде нет).
и т.д.
ЗЫ: У меня вопрос к фанатам angular — за что вы так любите этот «филиал ада»? Хотелось бы услышать аргументированные четкие ответы.
Почему дока говно — потому как в ней не все описано, и не для людей.
Почему devtools говно — потому как кроме state ничего нормально нельзя отследить, хотя Augury и позволяет некоторые вещи отслеживать но пользоваться им крайне сложно.(Хотелось бы отслеживать, видеть — состояние компонентов, событий, роутинга, стэйта(хоть тут нет проблем))
Обновление angular cli это позор — тут 2 вещи
1. обновление приложения — при переходе на новую версию angular возникают проблемы(хотя само cli помогает) приходиться дописывать\править ручками где не справился cli
2. обновление пакетов, cli обновляет зависимости фреймворка и не затрагивает сторонние пакеты, но при этом при обновлении сторонних пакетов(npm up) обновляются зависимости фреймворка, что приводит к не работоспособности приложения(как пример зависимость typescript для angular 8 должна быть 3.4 а на текущий момент 3.5)
live reload — просто жесть. Потому как он каждый раз перезагружает страницу и состояние теряется после изменения и это сильно напрягает — пример хорошего live reload у vue.
Размер приложения после сборки — ужас — где вы видели 200кб? просто по дефолту сгенерированного приложения измеряется в MB
Режимы компиляции — ад(в дев режиме может все работать а в билде нет).
Дело не в tslint а в самом типе компиляции, по умолчанию dev режим и product режим работают в различных режимах jit и aot в этом весь косяк, и без разруливание не поймешь.
Не надо говорить про пороги входа, и большого набора компонентов и плагинов, этого добра полно и для других фреймворков.
записывать в плюсы роутинг angular'овский я бы на вашем месте не стал, это просто убожество, хотя просто взгляните на другие решения в других фреймворках.
можно конечно самому по крупицам собрать на вью или риакте все это, но пока я буду выбирать из сотни посредственных плагинов — за это время можно набросать прототип на ангуляре,…
Тут вы не правы, или просто не владеете информацией.
PS: Прежде чем минусовать — аргумент в студию
Почему дока говно — потому как в ней не все описано, и не для людей.Это субъективно. На мой взгляд там все вполне хорошо. Вы сравниваете ее с докой Vue, но Vue в принципе проще, потому, вероятно, дока вам кажется лучше.
состояние компонентов, событий, роутингая скинул в предыдущем комменте ссылку на хром экстеншен, который прекрасно показывает состояние компонентов. С событиями роутинга вполне справляется enableTracing: true.
По поводу Cli — сталкивался с подобными проблемами до 8 версии. С 7 на 8 лично у меня все проходило на ура.
Live reload на Vue — прекрасен, до тех пор, пока не столкнулся с ситуацией, когда он обновляет не полностью. По запаре убиваешь из-за этого кучу времени, пока не допрешь в чем дело. Я сталкивался неоднократно.
По поводу размера бандла на вашем скрине — вы неправильно билдите, других вариантов для HelloWorld быть не может.
С режимами компиляции не возникает никаких проблем, если все делать по доке. Если нет, хотелось бы увидеть примеры =)
Это субъективно. На мой взгляд там все вполне хорошо. Вы сравниваете ее с докой Vue, но Vue в принципе проще, потому, вероятно, дока вам кажется лучше.
Я сравниваю не только со vue. Но дока должна отвечать на вопросы программиста и не вызывать вопросов и гуглинья сторонних ресурсов.
я скинул в предыдущем комменте ссылку на хром экстеншен, который прекрасно показывает состояние компонентов. С событиями роутинга вполне справляется enableTracing: true.
Я посмотрю предложенное расширение — но что то оно не внушает доверия, но поглядим.
Live reload на Vue — прекрасен, до тех пор, пока не столкнулся с ситуацией, когда он обновляет не полностью. По запаре убиваешь из-за этого кучу времени, пока не допрешь в чем дело. Я сталкивался неоднократно.
Так прелесть в том что обновляется не все, а только часть.
По поводу размера бандла на вашем скрине — вы неправильно билдите, других вариантов для HelloWorld быть не может.
что значит я не правильно билдю, есть какие то правильные способы которые не описаны в доке. Можно пошаманить с настройками и размер уменьшиться но кардинально 200кб он не станет.
С режимами компиляции не возникает никаких проблем, если все делать по доке. Если нет, хотелось бы увидеть примеры =)
=) то есть вы не встречали проблем, а статьи в интернетах по этому поводу вы не читали видимо.
Так прелесть в том что обновляется не все, а только часть.
Я понял, что вы имели в виду. Объясню суть.
По долгу службы я вынужден периодически ковыряться в нескольких однотипных вьюшных проектах. И не раз сталкивался с ситуацией, когда ты ожидаешь, что без перезагрузки страницы у тебя обновится как раз таки нужный компонент/часть логики, следишь, когда в консоли появится надпись "Hot module reload все обновил" (не помню, как там оно точно сформулировано), но на деле то, что ожидалось не обновлено. Я не спец по Vue, но тот факт, что мне не удалось найти никакой закономерности в таком поведении вроде как намекает на то, что дело не в кривых руках.
то есть вы не встречали проблем, а статьи в интернетах по этому поводу вы не читали видимо
Читал, в хейтерских комментариях =)
Я понимаю, что для полноценного пруфа проект маловат, но все же. Весь процесс обновления с 7 на 8 https://github.com/gothinkster/angular-realworld-example-app на двух скриншотах:
- https://monosnap.com/direct/3gIvAZ1mXR2kYurcE7EBRncCrCGLg8
- https://monosnap.com/direct/UzjLm0VOqfb6y8db93eWtcIFYglKx8
Обратите внимание на размер бандла, пожалуйста.
по поводу размера бандла, сборка делается с настройками по дефолту, я кажется выше указал.
Я же правильно понимаю, что HelloWorld — это просто пустой ангуляровский проект?
1. monosnap.com/direct/yISJygtXM0MKv4CCSOZ2zSAezK0sY1
2. monosnap.com/direct/0NsGq8EkDCpnPfdNiTHhAe4JpSPR3z
250kb.
Я не понимаю, как вы билдите, и где вы берете эти дефолтные настройки?
$ng new app
$ng build
Я же правильно понимаю, что HelloWorld — это просто пустой ангуляровский проект?
да
фото с результатом вы видели
$ng buildВот выдержка из «говняной» доки angular.io/cli/build
A «production» configuration is created by default when you use the CLI to create the project, and you can use that configuration by specifying the --configuration=«production» or the --prod=«true» option.
$ ng new appЭто еще раз доказывает мой довод что у angular есть проблемы, так как нужно как то, где то, помнить, догадаться о том что нужно где то что то дописать|изменить
А как же довод того что просто взял и работаешь?!
Но если вы работаете над проектами даже чуть-чуть больше todo, то, наверное, вы должны знать, что при билде вы должны указать конфигурацию.
К примеру локально вы делаете -c dev, на альфе -c alpha. Вполне логично, что для продакшена вы тоже должны указать конфигурацию (и да, за вас ее подготовил cli при создании проекта).
Я правда не могу понять, к чему тут претензия. Вы хотите, чтобы cli читал ваши мысли, и понимал, какую конфигурацию вы хотите сбилдить?
ng buildng build --prod
я выше написал, что cli помогает но не решает проблемы и нужно руками делать, и там описаны 2 типа обновления.
А с чем вы в данном случае сравниваете cli?
просто по дефолту сгенерированного приложения измеряется в MBВы бы хоть в названия файлов вчитались…
Во-первых — половина файлов — это отладочные sourcemap-ы
Во-вторых — все фалы в 2-х вариантах, для нормально JS и для старого
В-третьих — дефолтный билд делается на быстрых настройках, без оптимизаций, закидывая используемые пакеты целиком
Как уже выше советовали, прочитайте доки чуть дальше 1-й страницы, сделайте билд в production-режиме, можно даже без AOT, и будет вам счастье.
Во-первых — половина файлов — это отладочные sourcemap-ы
какие половина это sourcemap'ы глаза раскройте, говорилось о 200кб размера бандла, там vendor весит больше МБ.
Во-вторых — все фалы в 2-х вариантах, для нормально JS и для старого
Да какая мля разница — для нормального или нет размер больше 200кб
В-третьих — дефолтный билд делается на быстрых настройках, без оптимизаций, закидывая используемые пакеты целиком
что это меняет? Выше было сказано другим оратором, что ты просто берешь и делаешь, все настроено и готово. Я вам говорю что это не нормально, что чтобы сбилдить нормально приложения я должен пойти отыскать в доки что нужно поставить флаг. Хотя мне фреймворк из коробки предлагает подготовленные команды, но их еще нужно довести до ума, так же как и настройки(так как с дефолтными работать нельзя). Я в среднем делаю 1 проект в 3 месяца и каждый раз мне нужно помнить что нужно добавить вот сюда вот это а вот тут подкрутить чтобы было это — классное решение из коробки!!!..
ЗЫ: мы говорим не о том что мне лень что то делать или я что то не знаю, а о том как обстоять дела в реальности. и выше перечисленные проблемы это ерунда по сравнению то как работает фреймворк.
И хватит уже этих упреков — ты мля не умеешь готовить его, почитай доку… читали, читаем(и вы читайте коменты выше) есть что сказать говори но по делу
Я вам говорю что это не нормально, что чтобы сбилдить нормально приложения я должен пойти отыскать в доки что нужно поставить флаг.
А как фреймиворк должен без флага догадаться, что вы хотите билдить именно продакшн, а не дев сборку? По дефолту-то все билдят именно дев. С-но, он и есть без аргументов.
Если бы дефолтной сборкой был прод, то вы бы сейчас, наверное, кричали, что: "почему я должен для дев сборки дописывать какие-то аргументы, чтобы мне нормальный бандл сделало, с соурсмапами и прочим"?
В webpack, кстати, по умолчанию запускается именно production сборка. Так что это уже angular-cli внутри себя решил установить свои порядки.
Так что это уже angular-cli внутри себя решил установить свои порядки.
angular-cli, вообще говоря, отвязан от вебпака, по-этому нет причин на вебпак оглядываться.
Я привел это как пример инструмента в котором production режим включен по умолчанию. Можно еще привести react-scripts, где дефолтный react-scripts build тоже собирает продакшен вариант, со всеми оптимизациями.
Попробовал еще и vue-cli, там тоже команда build собирает продакшен вариант по умолчанию. Получается, это в angular-cli какая-то левая резьба.
Я привел это как пример инструмента в котором production режим включен по умолчанию. Можно еще привести react-scripts, где дефолтный react-scripts build тоже собирает продакшен вариант, со всеми оптимизациями.
Если что-то везде сделано нелогично, это не повод делать в новом инструменте столь же нелогично. Можно как раз сделать правильно.
Кстати, а не подскажете — как мне в react-scripts запустить дев билд? И со ссылкой на доки, желательно.
Судя по треду выше, есть люди, которые считают, что логично – это как раз запускать продакшен билд по дефолту.
Для девелопмента есть отдельная команда start – https://facebook.github.io/create-react-app/docs/getting-started#npm-start-or-yarn-start
Для девелопмента есть отдельная команда start –
Это не то, это аналог ng serve. А как сделать аналог ng build (без --prod)? Сбилдить в дев моде?
Судя по треду выше, есть люди, которые считают, что логично – это как раз запускать продакшен билд по дефолту.
Ну то есть это дискуссионный вопрос, с-но разработчики могут выбирать любой вариант.
Как обычно строится разработка:
- запускаем локальный сервер с dev-сборкой, которая пересобирается при сохранении
- собираем оптимизированные файлы для прода
Где в этом процессе требуется dev-сборка, но без сервера?
Где в этом процессе требуется dev-сборка, но без сервера?
Много где, на самом деле. Но это нерелевантно теме разговора. На мой вопрос вы можете ответить? Как в react-scripts сделать дев-билд, и где можно увидеть описание этого процесса в документации?
Нет, собрать в dev-режиме без запуска сервера не получится. Только если eject сделать.
Вопрос где это используется как раз очень релевантен теме разговора. Нужно же понять сценарии использования этой фичи.
Нет, собрать в dev-режиме без запуска сервера не получится.
Ок, то есть, CLI:
автоматически делаются дев/прод билды, которые легко выбираются и запускаются одной командой, поведение четко прописано в доках в ожидаемом месте
react-scripts:
делается только прод билд, дев билд сделать нельзя без костылей, в документации костыли не прописаны
Но проблемы, почему-то, у CLI.
Можно посмотреть на ситуацию с другой стороны:
angular-cli дает пользователю возможность выстрелить в ногу, причем еще и делает это по умолчанию, если пользователь явно не откажется
react-scripts стрелять в ногу не дает. А если по каким-то причинам вам все-таки нужно выстрелить в ногу, то вы настраиваете webpack или другой сборщик самостоятельно, и стреляете куда хотите.
ngular-cli дает пользователю возможность выстрелить в ногу
Эм. Не дает. В чем стрельба в ногу заключается? Сборка дев билда — это обычный вариант использования, а не стрельба в ногу. Стрельба в ногу — это когда делается что-то ошибочное.
А если по каким-то причинам вам все-таки нужно выстрелить в ногу, то вы настраиваете webpack или другой сборщик самостоятельно, и стреляете куда хотите.
Замечательный инструмент, шаг вправо/влево — настраивайте все сами.
И правильно там dev по дефолту стоит.
- ng serve – запускает локальный сервер для разработки, с dev-environment, все хорошо
- ng build – собирает файлы для деплоя, зачем здесь dev-environment по умолчанию?
Вот именно, а в angular смешали эти две концепции и теперь огребают. Env-переменные не имеют никакой связи с режимом сборки.
Я могу представить ситуацию, когда вам надо локально подключиться к preprod-версии бекенда вместо dev чтобы продебажить какой-то сценарий. Но подебажить не получится, потому что флаг --configuration еще и минификацией управляет
Env-переменные не имеют никакой связи с режимом сборки.
Как это не имеют? env-переменные входят в режим сборки. Как часть режима сборки может не иметь связи с режимом сборки?
Env-переменные – это переменные окружения. Можно собрать одну сборку и раскатить ее на разные окружения. В бекенде параметры сборки и окружения четко отделены, это во фронтенде они слиплись, к сожалению.
P.S. то что в Реакте продакшен режим включается через NODE_ENV я тоже считаю ошибкой. По хорошему это должно задаваться директивами препроцессора вроде #ifdef в C, но фронтенд тулинг на это не способен, к сожалению.
Можно конечно читать env'ы и по ним выставлять конфиг при запуске билда, но это же немного другое.
Env-переменные – это переменные окружения.
env-переменные — это часть конфигурации билда. Так что они там, где надо.
По хорошему это должно задаваться директивами препроцессора вроде #ifdef в C
Это как раз ужас-ужасный, пришедший из дедовских времен. К счастью, сейчас от этого уже отошли (в том числе и на беке, конечно) и используют конфигурации, которые позволят настраивать все, что хочется — от di-контейнера до параметров билда.
ng build – собирает файлы для деплоя, зачем здесь dev-environment по умолчанию?
Затем, что сперва деплой идет на девсервер, для которого нужен отдельный environment и которому не нужны оптимизации от --prod ключа.
Тут по моему все доступно описано. У меня были проекты, где принято было использовать не serve, а build --watch.
Более того, serve тоже можно запустить с --prod. Да и вообще добавить еще конфигураций (--prod это алиас к установке build -> configurations, там можно своих добавить).
Просто так сделали что dev везде по дефолту, он чаще используется разработчиком.
Не думаю что это важно вообще, никогда не вызывало проблем.
Я ниже приводил примеры, где разработчики наступали на эти грабли. Использование более подходящих дефолтов предотвратит новичков от стрельбы в ногу, а для тех кому нужно что-то другое, есть возможность перенастроить.
Энивей, это вообще мелочи.
Использование более подходящих дефолтов предотвратит новичков от стрельбы в ногу, а для тех кому нужно что-то другое, есть возможность перенастроить.
Выбор дефолтов тут не важен. Если у вас есть дефолты — то всегда найдутся избранные, которые будут ожидать другого дефолта и, не прочитав доки, выстрелят себе в ногу.
Чтобы исключить выстрелы в ногу есть всего два варианта — либо убрать дефолты в принципе (с-но, билдить только ng build --dev или ng build --prod, но не просто ng build), либо вообще лишить пользователя права выбора. один билд есть? Ну и хорош (с-но, в react-scripts как раз и пошли по этому сценарию). оба варианта, конечно, только ухудшают ситуацию.
Касательно всего треда в целом, я почитал документацию и узнал про ng build --prod.
Очень странная это ситуация. На домашней страничке angular-cli написано:
ng new
The Angular CLI makes it easy to create an application that already works, right out of the box. It already follows our best practices!
А теперь внезапно выясняется, что проект после генерации нужно дорабатывать напильником, дополнительные флаги подкидывать. Врет, получается, страница, не следует их шаблон best practices.
В package.json в секции scripts собирают все необходимые команды для работы с проектом. Чтобы не приходилось каждый раз вспоминать, что там в этом конкретном проекте используется, а просто запустить npm run build и получить результат.
А в этом случае angular-cli генерирует проект, в котором нет команды сборки продакшена. Вот именно это и приходится руками допиливать.
Хороший инструмент обладает «защитой от дурака» и предотвращает типичные ошибки, типа нечаянного деплоя дев-сборки в продакшен.
Можно, конечно, во всем винить «тупых пользователей», а можно сделать нормальные дефолты
Можно, конечно, во всем винить «тупых пользователей», а можно сделать нормальные дефолты
Так и есть нормальные дефолты. Если кто-то что-то собирает, то почти всегда нужна именно дев сборка. А прод сборка нужна, с-но, в исключительных случаях — на прод, либо для специфических тестов.
И то, что где-то в фреймворке Х это сделано через Ж, и в силу лени разработчиков дефолтная сборка с продом — не повод повторять плохие практики.
Можно, конечно, во всем винить «тупых пользователей»
А вы наблюдали в реальности этих "тупых пользователей"? А то пока что все выглядит так, будто они существуют только в фантазиях.
И то, что где-то в фреймворке Х это сделано через Ж, и в силу лени разработчиков дефолтная сборка с продом — не повод повторять плохие практики.
В angular-cli тоже не против поменять дефолтное значение. Так что ничего плохого в этой практике нет.
А вы наблюдали в реальности этих "тупых пользователей"? А то пока что все выглядит так, будто они существуют только в фантазиях
- Выше в комментариях человек запутался с конфигурацией.
- https://github.com/angular/angular-cli/issues/9016
- https://stackoverflow.com/questions/41432673/angular2-cli-huge-vendor-bundle-how-to-improve-size-for-prod
Документация — говноА это точно объективная оценка?
Devtools — говноAugury действительно глючная, но есть как минимум два-три других тула, вполне достойных. К примеру Angular State Inspector
live reload просто жестьА с ним что не так?
Размер приложения после сборки — ужасА с чем вы сравниваете? Может с реактом? Тогда спешу вас расстроить, вы и тут не правы.
Режимы компиляции — адЧто с ним не так?
Я бы предложил вам сначала попробовать написать что-нибудь крупнее todo-mvc на Angular, в идеале версии выше 2.0 beta, и потом уже задавать вопросы, на которые вам так нужны аргументированные и четкие ответы.
Документация — говносредне, дока нормально описывает что есть, но она неполная. Например недавно не нашел в оф доке как сделать CVA компонент со встроенной валидацией, описано только для директив.
Devtools — говно, вернее нормальных нет(кроме как Redux DevTools), Augury — ущербная, бажная.нету, факт. Не представляю как их можно сделать, ибо все на rxjs-потоках.
Обновление angular cli это позор — так как она обновляет лучше бы ее и не было.Не встречался с проблемами
live reload — просто жесть.Точно такой же, как и везде
Размер приложения после сборки — ужасСейчас десяток страниц, два десятка компонентов, Материал, Акита, что-то еще по мелочи — 1.1мб.
Режимы компиляции — ад(в дев режиме может все работать а в билде нет).
Есть такое, в дев моде плохо проверяет сигнатуры в шаблонах.
По последним двум пунктам ожидаются кардинальные улучшения в Angular 9. Посмотрим.
множество проектов находится в процессе перехода с Angular 1.X на более свежие версии фреймворка
И фреймворк этот – Vue или React :)
Самое забавное все зацепились именно за то ставим мы параметр prod или нет, конечно же ставим. Посыл был в том что почему это не делается по умолчанию.
Это конечно ерунда. Но больше удивляет, что по тругим претензиям не возникли вопросов.
Вы же пишете на нем, неужели все устраивает и вы считаете это нормальным?
На этом все спасибо за внимание.
Мы выяснили, чтением доки вы сильно не заморачивались, но считаете ее плохой.
Экстеншены для дебага вы не искали, но считаете, что их нет.
Проблемы с компиляцией у вас были, но примеров нет.
С размером бандла все понятно.
По поводу проблем с cli вы тоже ничего толком не сказали.
Единственный имеющий отношение к реальности ваш аргумент — то, что во Vue чуть более продвинутый хот-релоад.
Если я начну приводить примеры, это не размер комннта, а размер серии постов.
Сейчас подготовлено ессе на 14 страниц.
И почему вы считаете что доку никто ничитал? Читали, делали исследования.
И можно с уверенностью сказать проблем много. От разворачивания проекта до работы шаблонов, от прощета переменных до роутинга, от типа компиляции до многословности
И можно с уверенностью сказать проблем много. От разворачивания проекта до работы шаблонов, от прощета переменных до роутинга, от типа компиляции до многословности
Проблем везде много. В том же реакте, например, банальный PureComponent уже который год пофиксить не могут, и ничего — все браво едят кактус, походу обсуждая, следует ли иголки разжевывать, или лучше глотать так.
Очевидно, что любой фреймворк проигрывает некоторому сферическому в вакууме идеальному фреймворку (который имеет лишь один недостаток — этого фреймворка не существует), так что абсолютная оценка бесполезна, следует сравнивать с альтернативами.
Angular: состояние дел в 2019 году