О «критически важных» обновлениях Angular 17
Хочу высказать непопулярное мнение относительно обновлений в библиотеках и фреймворках. Иногда новшества вместе с новизной и удобствами несут дополнительное усложнение и побочные эффекты, которые придется учитывать, а возможно и устранять самостоятельно. В последнее время тенденция выпускать новые версии связана больше не с реальной необходимостью, а именно с желанием выпустить новую версию. Покажу на примере последних заявленных обновлений Angular 17.
Здесь мы видим новый синтаксис призванный упростить запись
Angular теперь поддерживает специальные декораторы в HTML на замену *ngIf и прочих «устаревших» структурных директив.
Так выглядит «устаревший» метод записи
Прирост читаемости конечно есть, но он весьма символический, действительно избавляемся от лишних слов ng-container и ng-template (но учить новичку их все равно придется), конструкция выглядит чуть короче, это плюс. По количеству строчек, однако, то же самое. Но лучше бы о таком думали в первых версиях, а не когда уже треть приложений в мире на Angular написана. Самое время подумать о новичках. А ведь новичок который придет на любой проект все равно увидит там *ngIf и прочие конструкции и их ему также придется выучить.
В реальной жизни конечно большинство напишет конструкцию ниже, потому что в 99 процентах случаев ухудшение производительности приложения будет неизмеримо, а код будет заметно короче
Пример того, как это зачастую пишут в реальных проектах в жизни
При этом у этого решения есть побочный эффект, который теперь придется учитывать всем разработчикам. С появлением нового синтаксиса в HTML, разработчики потеряют право использовать некоторые символы напрямую, а вместо них вставлять сигнатуры компьютерной кодировки текстов.
Как давно мы ждали такого счастья, правда?
Приведу выдуманный пример который отражает суть моих мыслей.
Мы привыкли пользоваться некоторыми инструментами, например плоскогубцами и бокорезами.
А Angular нам такой говорит: «Наконец‑то свершилось! Вам больше не нужно пользоваться старыми и неудобными инструментами, потому что специально для вас сегодня мы представляем вам новые инструменты: плоскорезы и бокогубцы! Плоскорезы делают тоже самое что бокорезы, но внешне и по названию похожи на привычные всем плоскогубцы! А бокогубцы делают тоже что и плоскогубцы, но теперь они наконец‑то выглядят единообразно с бокорезами! И отныне для того чтобы пользоваться инструментами, в том числе и старыми, нужно будет использовать перчатки, а все что ранее было сделано без них придется переделать и все это ради чистоты и техники безопасности на рабочем месте!
И теперь, интерполируя этот гипотетический пример на код, у нас вместо 2 уже 4 инструмента которые надо знать, использовать и думать в каком сценарии какие из них лучше применять. А на проекте есть код написанный старыми методами и теперь надо думать еще и о том, чтобы мигрировать или переписывать их на новые, либо закрыть глаза на принцип единообразности и позволить на одном проекте существовать как старому, так и новому способу записи одного и того же. А потом еще старые методы сделают deprecated, сиди и выпиливай их. А завтра под соусом стремления к сферическому чистому и читаемому коду, они придумают еще один способ записи условий в HTML. Дай бог чтобы об обратной совместимости кто-то думал и не выпиливал в будущих версиях старые методы. По сути это мелочь, одна из тысячи, но из таких мелочей складывается весь рабочий процесс.
Может конечно этот взгляд не очень популярен, но я считаю что:
1. Код, написанный в первых версиях фреймворка, должен быть полностью совместим и без каких-либо проблем работать без миграций даже когда мы обновляемся до последней версии фреймворка.
2. Новые версии как минимум не должны влечь за собой побочные эффекты требующие обязательного анализа и необходимости их учитывать либо устранять привлекая дополнительные часы разработчиков.
Конечно же это капля в море и таких примеров можно привести сотни. Неужели это не очевидно тем кто разрабатывает фреймворки? Первая и главная заповедь разработчика инструмента, которым пользуются сотни тысяч людей по всему миру должна быть «Не навреди. Не создай побочных эффектов, которые всем придется расхлебывать». Надеюсь дойдет, хотя бы до кого-нибудь из мира разработки. Самый отказоустойчивый модуль в ракете, это тот, которого не существует, который удалось убрать на этапе проектирования. Илон Маск говорил так. Наверное что-нибудь да понимает.
