Comments 31
Код, написанный в первых версиях фреймворка, должен быть полностью совместим и без каких-либо проблем работать без миграций даже когда мы обновляемся до последней версии фреймворка.
Давайте говорить «в ранних» и это с определенного момента. Иначе, давайте сами напишите такое, чтобы всегда работало без напильника.
Есть стратегия, основанная на «deprecated» предупреждениях, скажем в течение 2х версий, а потом выпиливании.
Да и вообще, как мне кажется в мире Javascript говорить об обратной совместимости - это очень смелое заявление, с учетом объема кривого кода в зависимостях любого проекта…
В мире Javascript говорить об обратной совместимости вполне справедливо, как и в мире других языков. Кривого кода быть не должно нигде. А больше всего его не должно быть в фреймворках мирового уровня. Там никаких высоких материй нет. Все что нужно можно писать с первого раза если временами хорошенько думать о будущем и не подгонять кнутом выпустить версию ради версии
Да в жс относятся к обратной совместимости как мало где) Даже баг typeof null оставили в угоду Ей. Видите ли слишком много сайтов в интернете написано с расчетом на это недоразумение.
Код, написанный в первых версиях фреймворка, должен быть полностью совместим и без каких-либо проблем работать без миграций даже когда мы обновляемся до последней версии фреймворка.
А я вот несогласен, да, с точки зрения бизнеса этот тезис верен, но с точки зрения инструмента, это ведет к раздуванию и к торможению в развитии.
В ангуляре тонны всего, что давно пора выбросить, за 7 лет появились крутые идеи и решения в мире фронта, до которых не додумались на старте, и за это же время пришло осознание о многих ошибочных решениях. И вот это вот требование полной обратной совместимости, сковывает авторов, и от этого страдают и разработчики и теряет популярность сам фреймворк.
В этот раз они хотя бы не обрывают концы, как при выходе NG2, сколько помоев тогда на них вылили, а пытаются сделать миграцию менее шокирующей.
Как по мне, раз в 3-5 версий стоит обрывать совместимость, чтоб развязывать себе руки.
Просто не надо завязывать руки, дабы потом не приходилось развязывать. Ели фреймворк меняется за несколько лет до неузнаваемости, значит надо выпускать новый. Любители всего новенького все равно не поленятся переписать, благо на это у них времени всегда хватает
Например? Что надо выбросить и что включить?
Тоже интересно было бы послушать
Выбросить: rxjs, свои модули, дайджест
Добавить: сигналы, нативные модули, onpush по дефолту.
Почему? А то выглядит как просто мнение;)
Ну дык:
Сигналы в разработке
Со standalone components можно и не использовать ангуляровские модули
С сигналами, насколько я понял, станет уже пофиг на пуш/дефолт, да и вообще зону можно будет выкинуть с её дайджестом
rxjs как будто бы не лишним будет как средство комбинации потоков, исключительно для сложных случаев, когда альтернативой будет накручивание страшных вещей вокруг сигналов. Зачем самому рожать и поддерживать, если можно rxjs воспользоваться?
Про нативные модули только не понял чего именно хочется
А зачем нужны сигналы если rxjs намного удобнее и с запасом перекрывает их функцицонал?
Есть короткий ответ, а есть и длинный.
imho:
change detection, zone, раз уж есть AOT, rxjs и сигналы
кастомный неоднозначный синтаксис шаблонов, или и дальше двигаться в сторону Razor (asp.net), или, простихоспаде, TSX, сколько костылей с тайп-чекингом шаблонов уберет
возможно модули, как минимум не lazy
ну и еще по мелочи
Не упомянули про инструмент миграции.
На сколько он справится.
У меня были проблемы миграции, причем неоднократно. Раз были и были не только у меня, значит фигово он справляется... А если надо сразу на 5 версий вперед обновить? Есть такие инструменты? Когда иной раз и на одну без проблем не получается
если не костылесипедить и не говнокодить, то в целом справляется. страданий не вызывает. иначе - не приплетать опыт таких же страдальцев, а попытаться разобраться где был поворот не туда.
Вы говорите что проблема миграции именно в "говнокоде" тех, кто пишет на Angular, а не тех кто писал эту миграцию и что-то не учел. А я говорю проблема в том, что разработчики Angular сами создают ситуации из-за которых теперь появляются дополнительные возможности делать "повороты не туда". Проблема миграции не в том что ее может сделать говнокодер. А в том что она в принципе есть. Она материализовалась из пустоты и теперь это новый узел в цепочке поставки решения. А узел отбирает время. Его работу надо учитывать. И тестировать. И он может сбоить
Неужели это не очевидно тем кто разрабатывает фреймворки?
Так вы не используйте фреймворки от проф непригодных авторов. Вот, в $mol, как писали 8 лет назад так:
<= Syntax_example $mol_section
title \No @if, #else, &and "other" \escaping
content <= syntax_example /
<= Bid $mol_paragraph title \Use mol!
<= Use_mol $mol_check_box checked? <=> use_mol? true
<= Yes $mol_paragraph title \Yes!
<= No $mol_paragraph title \Nooooooo!@ $mol_mem
syntax_example() {
return this.use_mol() ? [
this.Use_mol(),
this.Yes(),
] : [
this.No(),
this.Use_mol(),
]
}Так до сих пор не видят причин это менять.
Это вы ещё не видели что твориться в мире Андройд разработки - там это постоянная карусель с deprecated. Такое ощущение, что там это специально делают, чтобы получать повышение за новые "прорывные" технологии
Мне кажется этот подход чужеродным, это какая-то шаблонизация поверх компонент, не очень естественная вещь.
Есть один пример обратной совместимости - HTML. Браузер должен открывать и рендерить любой сайт, сделанный на заре веба. Сейчас только ленивый не ругает за это HTML, называя древним легаси, пережитком прошлого, ошибкой и не пытается написать очередную прорывную альтернативу. Но имеем что имеем.
В итоге у нас доктайпы, чтобы включить нужный режим парсера, все старые элементы (`marquee`, frame, font, big и тд) все ещё работают, код движков все ещё содержит тонны логики по их обработке. Скоро у нас будет select и selectlist - одно и то же, но одно стилизуется, другое - нет. У нас есть b и strong, i и em, вроде одно и то же, но есть нюанс. И тд и тп.
К сожалению, сделать сразу хорошо с первого раза невозможно. Со временем приходит понимание ошибок, новые возможности и подходы. В то же время у технологии уже есть аудитория и проекты. Либо итеративно развивать и периодически делать breaking changes, либо каждые пару лет создавать новую реинкарнацию старого фреймворка. В итоге что мигрировать breaking changes, что мигрировать на новый фреймворк. Второе обычно проще.
Поддерживаю - это уже не разработка, а какая-то борьба с технологиями и обновление ради обновления... грусть
О «критически важных» обновлениях Angular 17