Comments 32
запускается сборка, пока она длится, я ввожу следующий код и сохраняю — в результате получается устаревший бандл, без последних правок
В Webpack 2 это починили
Была статья на эту тему How it feels to learn JavaScript in 2016: ))
lazy loading and pre-rendering
Как раз следующая тема, с которой хотел разробраться — это серверный рендеринг. Lazy loading без code splitting смысла особо не имеет к сожалению. Кстати, как у webpack получается сплиттить, кто-нибудь пробовал? Гугл говорит вроде умеет, но интересно как это на практике.
Сборка Angular 2 приложения — это боль и страдания. Продакшн билд приложения с компиляцией шаблонов и использованием ДевЭкстрим занимает… 8.5 минут!!!
Да, можно использовать watch, так что при сохранении изменений сборка будет запускаться автоматически. Но это не решает проблемы. 1. На практике все выглядит так: я ввожу часть кода, сохраняю, запускается сборка, пока она длится, я ввожу следующий код и сохраняю — в результате получается устаревший бандл, без последних правок. Кто-нибудь сталкивался с такой проблемой? Как вы ее решаете?
Постигая дзен двухсекундными ожиданиями после полусекундных правок.
Существует опция вебпака watchOptions.aggregateTimeout и watchOptions.poll, которая теоретические добавляет задержку перед запуском билда после изменений.
О какой IDE речь? Из коробки кажется только VS поддерживает, в остальных нужно ставить плагины. Без compile-on-save вся идея dev-окружения теряет смысл. Проще тогда взять тот же Angular CLI и не париться.
Browsersync у меня как-то не прижилось — мне кажется нерациональным гонять браузер постоянно (ноутбук относительно слабый). Сохраняю я часто, а переключаюсь на браузер гораздо реже. Да и вообще, не очень доверяю подобной автоматике — F5 надежнее, все под контролем. Впрочем, если есть интерес, с удовольствием замержу пулреквест (при условии что browsersync будет запускаться отдельной командой).
Для vim тоже есть плагин. Если нужно что-то быстро поправить без настройки рабочей среды, можно запустить из консоли gulp build-dev --color, это запустит компиляцию всего.
На крайняк можно запустить tsc --watch, но добавлять это в стартер я бы не стал по все тем же причинам — никогда не знаешь, что и как ты получишь, все зависит от порядка и скорости нажатия Ctrl+S.
Я очень хочу перейти на новый уровень, но совершенно не понимаю ради чего весь этот оверхед? Что мне даст этот бонусный мегабайт? Ведь мне нужно то не много: двусторонний биндинг и DRY. Большего от Angular, и прочих фреймворков я не жду.
Что это? Java экспансия во все языки? Или что?
Ох не возьмусь оправдывать Angular, его сложность и размеры действительно пугают. Хотя вот Ember еще больше, только там кажется даже tree-shaking не применишь. Оставлю только вот эту ссылочку в защиту Angular. Все-таки, как не крути, а есть у Ангуляра киллер-фичи. За одну изоляцию CSS я готов с ним мириться.
Так в этом же и весь смысл, SPA — это, по сути, десктопное/нативное приложение, только без проблем связанных с доставкой этого приложения всем пользователям и поддержкой актуальной версии этого приложения у всех пользователей.
Получается, победа бизнес-требований над качеством приложений.
Исторически, Angular 2 имеет очень сложную процедуру сборки проекта, заставляя разбираться во всем многообразии различных подходов и инструментов, не имеющих напрямую отношения к самому коду.
Как самый базовый предлагается использовать Angular Quickstart, однако после написания «Hello World» его возможностей резко начинает нехватать. И тут начинается тернистый путь выбора подходящего бойлерплейта.
Мой текущий выбор — Angular CLI (использует Webpack)
Плюсы:
- Самый официальный среди официальных бойлерплейтов, большинство сторонних модулей ориентируются именно на него
- Ментейнеры — разработчики ядра Angular, поэтому поддержка новых фич появляется достаточно быстро
- Инструменты CLI
- Безболезненная компиляция AoT
- Генерация бандлов Lazy Load из коробки
- Удобное обновление самой среды Angular CLI (как отдельный пакет)
- Быстрая пересборка только измененных частей (около секунды)
- Синхронизация с браузером через LiveReload (несколько проигрывает Browsersync по функционалу)
Минусы:
- Все еще бета, время от времени одна из сотен зависимостей ломает все (правда, быстро чинят)
- Работает по принципу «черного ящика» с минимумом доступных настроек
- Linter доступен только как отдельная команда
- Размер бандлов несколько больше, чем с system.js (однако в сжатом виде они могут быть и меньше)
До перехода на CLI я долгое время использовал angular-seed (использует system.js).
Плюсы:
- Полуофициальный бойлерплейт
- Главный ментейнер — уже упомянутый разработчик ядра Angular Minko Gechev, поддержка новых фич появляется достаточно быстро (часто быстрее CLI)
- Очень гибкая настройка Gulp tasks
- Агрессивный linter на этапе сборки
- Первый бойлерплейт, ставший поддерживать AoT
- Генерация кода из коробки через compodoc
- Сравнительно малый размер бандлов (см. выше)
- Синхронизация с браузером через Browsersync
Минусы:
- Частые проблемы с AoT со многими популярными сторонними модулями из-за system.js (ng2-bootstrap, например, официально не поддерживает system.js)
- Отсутствует changelog и система версий, очень неудобное обновление вручную
- Нет генерации бандлов Lazy Load
- Долгое время пересборки (2-5 секунд)
Выбор бойлерплейта в мире Angular напоминает религиозные войны дистрибутивов Linux, где каждый продвигает свою философию. На данный момент самым перспективным считается tree shaking с помощью rollup.js, однако работа ведется и на фронте Google Closure Compiler. Помимо уменьшения размеров самого бандла есть еще 2 приема оптимизации: Lazy Load и рендеринг на сервере через Angular Universal.
Seed проект Minko мне не понравился по двум причинам:
- Очень сложная система сборки. Когда мне надо было добавить стороннюю библиотеку в зависимости, и у меня ничего не заработало из коробки, я начал разбираться. У него там куча каких-то скриптов, непонятно что из них что делает, откуда все берется и куда следует. В итоге я добавил эту библиотеку в папку с исходниками и так решил проблему. Что особенно печально, на тот момент не было другого сида, который делал бы AOT и tree-shaking. Тогда-то я и начал разбираться в теме, чтобы сделать свое.
- Не работает compile-on-save. Дев сборка в его сиде (когда я с ним работал) копировала файлы в специальную папку (как у меня релизная сборка). В результате, пока ты не запустишь из консоли билд (который довольно долгий), изменения в браузере не посмотришь. Может сейчас он это уже изменил, не знаю.
В своем стартере я старался сделать максимально простую и прозрачную систему, чтобы в ней легко было разобраться. Я намеренно оставил ряд вещей не автоматизированными (например, редактирование index.html), дабы не плодить громоздких gulp-конструкций.
Решения вида "черный ящик", конечно, хорошо, но только до тех пор пока все работает. Если что-то идет не так, то ты сразу же оказываешься в безвыходной ситуации. Остается только писать ишью, на которые неизвестно когда ответят. Поэтому для продакшена мне страшновато использовать Angular CLI. Может быть когда-нибудь, когда она станет совсем стабильной (как Ember CLI)...
Куча скриптов требовала вдумчивого чтения, но после большого опыта собственного велосипедостроения на Gulp особых проблем не вызывала. Зато внедрение экзотических фич (вроде ставки кода Google Analytics только для продакшена) происходило куда легче, чем с CLI.
Искренне желаю вам успехов с вашим проектом, надеюсь вам удастся сочетать баланс легкости в использовании и функционала.
А какого рода проблемы? Можете привести случаи из жизни?
А не бывает проблем, когда нужно подключить какую-то библиотеку, или сделать что-нибудь специфичное? Как, допустим, выше приводили пример, добавить аналитику только в production сборку. Или подключить библиотеку, которой вообще нет в npm, и она есть только в виде репозитория на гитхабе.
Единственный недостаток при сборке вебпаком, а может и не только им, в том, что не работают сорсмапы для изолированных стилей. Если у кого-нибудь есть решение этой проблемы, то с радостью послушаю!
Angular — настройка среды разработки и production сборки с AOT-компиляцией и tree-shaking (Gulp, Rollup, SystemJS)