Почему TypeScript, а не Dart?

Потому, Михаил, что так захотели разработчики Angular. Пока еще крепостное право в гугле не ввели, и работники делают опенсорц как им удобней. Дарт популяризирует другая команда, так что все довольны.

Пойди спроси у них.
/thread

Потому что TS соединяется с JS без геморроя. А Dart нет.

Google для Angular взяла JS, прежде всего. И взяла она его потому, что Dart при создании Angular не было. Когда у тебя уже есть проект на JS, то для переноса на Dart его нужно переписывать, и это уже получится иной проект. Потому, вопрос должен звучать, как «почему гугл не переписала Angular на Dart?». На этот вопрос уже можно ответить: потому что большинство готовых решений написано на JS, и никто не хочет от них отказываться, ровно как и от индусов, которые кое-как умеют JS, но в жизни ничего больше не выучат.

язабан

язабан

Потому что это статически типизированное надмножество основного языка Angular.

В чём был смысл популяризировать не свой ЯП, а ЯП конкурента?

Собственно Google особо Angular не продвигает, их основной инструмент фронтенд-разработки – Polymer и веб-компоненты, см. GMail и Youtube.

ты не поверишь, но https://github.com/dart-lang/angular возраст примерно тот же.

Потому что это статически типизированное надмножество основного языка Angular.

не ангулярщик, но думается что его использование в чистом JS такая боль, что TS можно считать основным языком Angular.

Там классы и интерфейсы. Естественно, в чистом Js, особенно времён es5, это невыносимая боль.

А кто-то в курсе. почему все-таик гугл отказался от Angular в пользу полимеров? Я не знаком ни с одним, ни с другим, а 95% блогов по теме — просто мусор.

Почему Google для разработки Angular взяла TypeScript, а не Dart?

Спроси у гугла

В чём был смысл популяризировать не свой ЯП, а ЯП конкурента?

Дарт не взлетел. Причина проста - он давал мало(рядовому адепту), был не особо совместимым с жс и был слишком радикален.

К тому же он попал в банальную ловушку. Веб-адепты привыкли к множеству всяких фичей динамичности, которых дарт не давал. Там была маня-рефлексия «как в жабке», но это капля в море. Это слишком сложно, слишком заморочно. Когда как обычный манки-патчинг прост и понятен.

К тому же там не просто ts. И не просто js. Прикрутили зоны, прикрутили свои сервисы к компилятору ТС. Дарт оттуда никуда не уходил. Но, повторюсь, ангуляр никак не мог протащить дарт. А сам дарт не смог. И в таких условиях с никакущей репутацией после angularjs насаждать ещё и дарт крайне сомнительно.

А кто-то в курсе. почему все-таик гугл отказался от Angular в пользу полимеров?

Он его никогда особо не выбирал, что-бы отказываться. А в целом у ангуляра множество проблем. Слишком переусложнён и уже давно упёрся в проблемы скриптухи. Работать сам по себе нормально не может. Там настолько идиотский механизм поиска изменений, что он в принципе не может работать для чего-то сложного и динамического.

Если максимально просто. Что-то уровня ютуба можно сделать, конечно, но в основном вопреки ангуляру, а не благодаря.

Ну и самое важное. Всё это очень тесно интегрировано с броузерными api, когда как ангуляр и прочая херня - максимально сильно пытается от всего этого уйти. Хотя не так сильно как что-либо ещё.

Если кратко. Тормозит, сложный, ненужный, скрывает то, что скрывать в данном случае не следует.

Слишком переусложнён и уже давно упёрся в проблемы скриптухи. Работать сам по себе нормально не может. Там настолько идиотский механизм поиска изменений, что он в принципе не может работать для чего-то сложного и динамического

Фух, потратил на поиск ответа часа три, и еще час на написание ответа, а ведь мог бы потратить их на более полезные вещи (сыграть в доту). И нет, ты не угадал — дело не в неработающем механизме поиска изменений.

Давайте начнем с азов: на кой черт вообще все эти фреймворки создавались? Почему нельзя по изменению переменной просто менять интерфейс, и всё? А потому, что браузеры перегружены сложной логикой отрисовки страницы, где размер дочерних узлов влияет на родительские, размер родительских — на дочерные, а также дочерние двигают друг друга (переносы строк и float-ы), из-за чего инструменты разработки в Firefox и Chromium сами не могут понять и показать, откуда берутся свойства тех или иных узлов, если эти свойства не заданы прямо, вроде «width: 150px». Да. и вся эта развлекуха разделена на структуру и стили, которые нужно связать при создании макета. Введение flexbox-ов заметно облегчило алгоритм просчета макетов — я могу предположить, что этот инструмент слизали с Qt, и он действительно весьма удобен для «десктопных» GUI, то есть одностраничных приложений. В противовес картинково-текстовому GUI браузеров, которое отвратительно налязит на одностраничные приложения.

К слову, Delphi в 2020 году до сих пор при смене раб стола (например, с разработки в отладку) отдельно меняет и сразу отрисовывает каждый компонент, из-за чего при этой смене происходит веселая цветомузыка, радующая глаз эпилептиков. Они могут себе это позволить, потому что родной машинный код выполняется достаточно быстро, чтобы эпилептический приступ не успел наступить.

Короче говоря, все фреймворки фронтендов JS создаются только для одной цели — обеспечить оптимизацию обновления DOM по некой нетривиальной модели, скрыв сложность этого алгоритма от пользователя. То есть, в них кроме механизма отслеживания изменений ничего нет — они вокруг него одного и созданы, все остальные фичи призваны описывать модели, связи моделей, пути отрисовки моделей для механизма отслеживания изменений.

В чем же проблема Angular? Основная его беда заключается в том, что он не умеет отслеживать изменения частично — только сразу по всему дереву компонентов. Вы жмете кнопку, изменяете в обработчике значение поля компонента — Angular проходит по всему дереву, вычисляя свойства всех компонентов, находит расхождения нового и старого свойства, метит компонент грязью, а потом и синхронизирует для него DOM. Именно это и является его главным недостатком Angular: для большого дерева вычисления всех свойств может занимать много ресурсов, особенно если изменения происходят часто, например, по движению мышки. Для решения этой проблемы придумали OnPush, через который можно временно выкинуть отдельные ветки из отслеживания изменений. Правда, этот механизм требует много ручной работы и по сути разрушает исходную идею — сокрытие сложности синхронизации DOM по модели.

Я продолжу по хронологии и перейду к React. Этот зверь частично решает проблемы массового пересчета, позволяя пересчитывать только отдельные ветки, однако, при этом заставляет вручную оповещать фреймворк об изменениях через setState. Функционал OnPush от Angular повторен в виде shouldComponentUpdate. В остальном он точно так же ходит по всему поддереву, вычисляя свойства заново и синхронизируя DOM при расхождениях, разве что форма описания связи «модель->DOM» в React все-таки выглядит попроще.

Читая доки Polymers у меня возникло де жа вю — это же Vue. Проверка дат показала, что есть смысл называть это два фреймворка братьями близнецами, поскольку оба возникли примерно в одно время и происходили из гугла, хоть Vue уже давно потерял всякую связь с гуглом. Идея этих близнецов такова: мы пересчитываем отдельный компонент только по изменению его состояния-модели-полей. Polymers разрабатывается для нужд гугла, потому поддерживает только современные браузеры и ориентирован на производительность. В частности, из-за этого в шаблонах в качестве выражений можно использовать только булево отрицание и вызов метода — фреймворк при компиляции производит быстродействующий код для этих простых связей.

Лично я нынче пишу морды на Vue, и я вполне прочувствовал всю его тормознутость, которая особенно становится заметной на сложных компонентах, вроде продвинутого текстового редактора, которым я сейчас занимаюсь. Vue, к том же, не предоставляет каких-то эффективных средств для того, чтобы перейти от автоматического обновления к ручному, или хотя бы ограничить автоматическое обновление там, где оно не нужно. А это требование логично возникает для сложных приложений со сложными структурами данных. Вообще, у меня складывается ощущение, что Vue разрабатывают люди, которые не задаются вопросом «как это будет работать?». И это я пишу не только про производительность, но еще и про лютую геморность отладки, когда проблема возникает уже на этапе «чей это div у меня в дереве?». Если вы такие умные и скажете «дык добавь атрибут data-*», то поспешите мне рассказать, как я буду с такой же легкостью находить обработчики событий — поскольку из отладчика все ссылки ведут на единый диспетчер событий Vue.

Ах да, сам ответ:

Слишком переусложнён и уже давно упёрся в проблемы скриптухи. Работать сам по себе нормально не может. Там настолько идиотский механизм поиска изменений, что он в принципе не может работать для чего-то сложного и динамического

Отслеживание изменений в Angular может быть очень простым. Вопрос в том, насколько этот простой механизм будет быстро работать для сложного приложения. Очевидно, отсюда возникает усложнение этого механизма через OnPush и другие, но никак не из-за какой-то фундаментально неустранимой сложности.

Всё это очень тесно интегрировано с броузерными api, когда как ангуляр и прочая херня - максимально сильно пытается от всего этого уйти. Хотя не так сильно как что-либо ещё

Это к слову о Polymers vs Vue. Конкретно ориентированность Polymers на новые браузеры (на Google Chrome, что уж тут думать) вызвана политикой гугла, и не связана с какой-то потребностью от чего-то абстрагироваться или не абстрагироваться. А вот насильное ограничение сложности связей данных в Polymers вызвано уже требованиями производительности, которые вполне ощутимо влияют на степень тормознутости SPA — они начинают тормозить на любом фреймворке по мере роста сложности приложения, но Polymers все-таки тормозит чуть меньше.

Фух, потратил на поиск ответа часа три, и еще час на написание ответа, а ведь мог бы потратить их на более полезные вещи (сыграть в доту). И нет, ты не угадал — дело не в неработающем механизме поиска изменений.

Ну посмотрим что ты там родил.

Давайте начнем с азов: на кой черт вообще все эти фреймворки создавались?

Потому что веб говно. Изначально был создан на целиком и полностью несостоятельных концепциях, очевидно.

Почему нельзя по изменению переменной просто менять интерфейс, и всё?

Уже давно можно. Проблема не в этом. Проблема в том, что обновление данных - это даже не половина от того, для используется все эти либы/фреймворки. Данные меняют структуру dom.

А потому, что браузеры перегружены сложной логикой отрисовки страницы, где размер дочерних узлов влияет на родительские, размер родительских — на дочерные, а также дочерние двигают друг друга (переносы строк и float-ы), из-за чего инструменты разработки в Firefox и Chromium сами не могут понять и показать, откуда берутся свойства тех или иных узлов, если эти свойства не заданы прямо, вроде «width: 150px». Да. и вся эта развлекуха разделена на структуру и стили, которые нужно связать при создании макета. Введение flexbox-ов заметно облегчило алгоритм просчета макетов — я могу предположить, что этот инструмент слизали с Qt, и он действительно весьма удобен для «десктопных» GUI, то есть одностраничных приложений. В противовес картинково-текстовому GUI браузеров, которое отвратительно налязит на одностраничные приложения.

Какой-то поток ахинеи. Логика здесь не при чём. Как и её сложность, как и причём тут вообще инструменты разработки?

К слову, Delphi в 2020 году до сих пор при смене раб стола (например, с разработки в отладку) отдельно меняет и сразу отрисовывает каждый компонент, из-за чего при этой смене происходит веселая цветомузыка, радующая глаз эпилептиков. Они могут себе это позволить, потому что родной машинный код выполняется достаточно быстро, чтобы эпилептический приступ не успел наступить.

Опять шиза. То как работает бездарное говно никого не волнует. К тому же они не рисует даже 5% того, что рисует веб. Никакое говнелфи ничем нативным не является и то как это говно работает - никак не связано с ним самим.

Короче говоря, все фреймворки фронтендов JS создаются только для одной цели — обеспечить оптимизацию обновления DOM по некой нетривиальной модели, скрыв сложность этого алгоритма от пользователя.

Да тут у нас очередная жертва пропаганды, которая услышала где-то херню и побежала повторять? Нет, ты нихрена не понимаешь, а то что ты сожрал - говно.

То есть, в них кроме механизма отслеживания изменений ничего нет — они вокруг него одного и созданы, все остальные фичи призваны описывать модели, связи моделей, пути отрисовки моделей для механизма отслеживания изменений.

Нет, отслеживания изменения никак не относятся к dom. Отслеживания изменения нужны для того, чтобы понять, что изменения произошли и где они произошли. Неважно будет ли там какая-то оптимизация, либо нет.

В чем же проблема Angular? Основная его беда заключается в том, что он не умеет отслеживать изменения частично — только сразу по всему дереву компонентов.

Опять же - меньше жри пропаганды. Ты сожрал первую же ссылку в гугле и решил, что что-то понимаешь? Нет. Ты ничего не понимаешь. Никакое дерево никого не интересует, никакое «отслеживать тоже».

Вы жмете кнопку, изменяете в обработчике значение поля компонента — Angular проходит по всему дереву, вычисляя свойства всех компонентов, находит расхождения нового и старого свойства, метит компонент грязью, а потом и синхронизирует для него DOM.

Опять потоки херни. У ангуляра нет никаких «значений» и полей. Меньше жри пропаганды. Он, как и всё остальное, работает на уровне реакции на какие-то действия внутри ангуляра. Никто не знает что и где, но раз что-то произошло - оно должно что-то поменять, возможно. Никто не знает что и где.

Именно это и является его главным недостатком Angular: для большого дерева вычисления всех свойств может занимать много ресурсов, особенно если изменения происходят часто, например, по движению мышки.

Опять клоун решил повторять то, о чём ему сказали. Но даже тут он обделался. Потому как ретранслирует шаблонную херню из первой ссылки в гугле.

Никакое древо-хренево ни к чему не относится. Никакие данные свойства не относятся к ангуляру. Ты обделался. Так работает что угодно.

Для решения этой проблемы придумали OnPush, через который можно временно выкинуть отдельные ветки из отслеживания изменений. Правда, этот механизм требует много ручной работы и по сути разрушает исходную идею — сокрытие сложности синхронизации DOM по модели.

Нет, трепло. Ты где-то услышал про OnPush и решил мне сообщил? Ты опять обгадился. OnPush - это базовый механизм, который был всегда и везде. И он точно так же требуется для любой либы, потому как любая либа работает так же как ангуляр, правда говней.

Я продолжу по хронологии и перейду к React.

К чему ты можешь вообще перейти, трепло?

Этот зверь частично решает проблемы массового пересчета, позволяя пересчитывать только отдельные ветки

Нет, ты опять обгадился. Ангуляр именно что пересчитывает всё. Никаких отдельных веток там нет.

однако, при этом заставляет вручную оповещать фреймворк об изменениях через setState.

Нет, маня. Ты опять обгадился. стейт там появился уже после. Но всё это неважно - важно то, всё это есть и в ангуляре. Это ручной пердполинг. И никакой сейт никому нахрен ненужен. Он не решает необходимых проблем.

Функционал OnPush от Angular повторен в виде shouldComponentUpdate.

Нет, ты опять обгадился. Изменение сейта в реакте вызывают рендер, т.е. создают заново всё поддерево. Точно так же это работает и в ангулере - можно так же запустить детектирование изменений на поддереве с корнем в текущем компоненте.

В остальном он точно так же ходит по всему поддереву, вычисляя свойства заново и синхронизируя DOM при расхождениях, разве что форма описания связи «модель->DOM» в React все-таки выглядит попроще.

И к чему ты всё это кукарекал, чтобы после разницы не найти?

Читая доки Polymers у меня возникло де жа вю — это же Vue.

О, дак у нас тут очередная вуе-макака. Никакого отношения полимер к вую не имеет. Ты обгадился.

Проверка дат показала, что есть смысл называть это два фреймворка братьями близнецами, поскольку оба возникли примерно в одно время и происходили из гугла, хоть Vue уже давно потерял всякую связь с гуглом.

Ты опять обгадился. Никакого полимера как полимера не существует. Он напрямую связан с веб-компонентами.

Идея этих близнецов такова: мы пересчитываем отдельный компонент только по изменению его состояния-модели-полей.

Очередные нелепые потуги. Никакой идеи нет. Говновуй - это просто реакт с прикрученной сверху реактивностью. Т.е. вместо того, чтобы дёргать какие-то говнофункции - мы обвешиваем поля гетерами и ловим доступ к ним. Всё это перепаста того, что было тысячи лет в реакте-экосистеме. Но реакт сложен и от того в базе был выкинут jsx и заменён на убогие тектовые шаблоные дерьма.

Полимер же, т.е. веб-компоненты, это попытка интегрироваться в дом. И не связывать ноды с каким-то говно, с сразу из говна сделать ноду и поместить в дом. А сам полимер - это просто обёртка для упрощения работы с веб-компонентами, для проработки их будущего дизайна и для ухода от низкоуровневого бойлерплейта.

Polymers разрабатывается для нужд гугла, потому поддерживает только современные браузеры и ориентирован на производительность.

Какая-то херня нелепая. Не потому, жертва пропаганды. А потому, что использует нативные для броузера фичи, которых, очевидно, нету в древнем говне. Это никак не связано с гуглом. Точно так же никакой говновуй не будет работать на жабаскрипте без геттеров.

В частности, из-за этого в шаблонах в качестве выражений можно использовать только булево отрицание и вызов метода — фреймворк при компиляции производит быстродействующий код для этих простых связей.

Опять какие-то нелепые потоки шозофазии.

Лично я нынче пишу морды на Vue

Я не сомневался. В целом как какой-то очередной клоун несёт мне херню и ничего не знает - это адепт вуе. В целом вуе и притягивает всяких неосиляторов.

и я вполне прочувствовал всю его тормознутость, которая особенно становится заметной на сложных компонентах, вроде продвинутого текстового редактора, которым я сейчас занимаюсь.

Ты же кукарекал, что там не так как в ангуляре? А оказывается, что так же.

Vue, к том же, не предоставляет каких-то эффективных средств для того, чтобы перейти от автоматического обновления к ручному, или хотя бы ограничить автоматическое обновление там, где оно не нужно.

Вуе - это бездарное говно для птушников. Очевидно, что там ничего нет и не будет. К тому же, какие-то ручные обновления и обновления вообще в принципе не возможно в этом подходе дерьма.

К тому же, ты выше нёс херню про «оптимизацию dom», а теперь вдруг дом то оптимизирован, а тормоза есть? Как же так? Опять обгадился и нёс херню? Да, и это не удивительно.

А это требование логично возникает для сложных приложений со сложными структурами данных.

Нет, это требование логично для любых приложений. Просто существует избыток производительности, который скрывает эти проблемы.

Вообще, у меня складывается ощущение, что Vue разрабатывают люди, которые не задаются вопросом «как это будет работать?».

Вуе - бездарная поделка говна для тех, кто не осилил реакт(либо, хотя бы, ангуляр). Смысла существования не имеет. Она лучше только реакта с говнуксом, но говнукс тебя использовать никто не заставляет.

И это я пишу не только про производительность, но еще и про лютую геморность отладки, когда проблема возникает уже на этапе «чей это div у меня в дереве?». Если вы такие умные и скажете «дык добавь атрибут data-*», то поспешите мне рассказать, как я буду с такой же легкостью находить обработчики событий — поскольку из отладчика все ссылки ведут на единый диспетчер событий Vue.

Это проблема не vue, а подхода дерьма. Такие же проблемы есть везде, потому как логические дом-ноды никак не связаны с твоими маня-нодами, а маня-ноды в свою очередь никак не связаны с твоими данными.

Отслеживание изменений в Angular может быть очень простым. Вопрос в том, насколько этот простой механизм будет быстро работать для сложного приложения. Очевидно, отсюда возникает усложнение этого механизма через OnPush и другие, но никак не из-за какой-то фундаментально неустранимой сложности.

Нет, ты опять обгадился. Ангуляр изначально задизайнен таким образом, чтобы об этом не думать. Любые костыли - нарушают целостность подхода.

Это к слову о Polymers vs Vue. Конкретно ориентированность Polymers на новые браузеры (на Google Chrome, что уж тут думать) вызвана политикой гугла, и не связана с какой-то потребностью от чего-то абстрагироваться или не абстрагироваться.

В школу сходи и меньше жри бездарной пропаганды. Во-первых ориентация не на новые броузеры делает тебя идиотом по умолчанию. Потому как никто в здравом уме не использует протухшее говно. И никто в здравом уме не желает жрать говно и ориентироваться на какое-то бездарное протухшее дерьмо. Во-вторых полимер ориентируется не на хром, а на броузер. А броузеров, кроме хроме, нету. И это не проблема гугла, не проблема хром и полимера. А на броузер он ориентируется потому, что использует определённые api.

А вот насильное ограничение сложности связей данных в Polymers вызвано уже требованиями производительности, которые вполне ощутимо влияют на степень тормознутости SPA — они начинают тормозить на любом фреймворке по мере роста сложности приложения, но Polymers все-таки тормозит чуть меньше.

Дело не в связях данных. Дело в том, что полимер по большей части нативный и он базируется на прозрачности связей между данными и домом, между домом и компонентами. Когда как и в реакте и в ангулере и в говновуе всё это не прозрачно.

И чем менее оно прозрачно - тем хуже оно тюнится и чем больше тюнинг снижает привычный уровень dx"а.

Царь ударился в веб? Это что-то новое. Не вижу, на что можно ответить — сплошная стена отрицаний. Выделю вот это, как 4.2:

Ты опять обгадился. стейт там появился уже после. Но всё это неважно - важно то, всё это есть и в ангуляре. Это ручной пердполинг. И никакой сейт никому нахрен ненужен. Он не решает необходимых проблем

«v0.14.7
Fixed bug with calling setState in componentWillMount when using shallow rendering
v0.13.0
Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
v0.11.1
setState can be called inside componentWillMount in non-DOM environments
v0.4.1
setState callbacks are now executed in the scope of your component.»

То есть, он там был всегда. shallowRenderer появился позже, но это уже кривоватый костыль, который не составляет базу React-а.

Точно так же это работает и в ангулере - можно так же запустить детектирование изменений на поддереве с корнем в текущем компоненте

Нет, по умолчанию все компоненты суются в общий автопоиск изменений. Чтобы ручками обновлять отдельное поддерево, нужно убрать его из автоматического обновления через ChangeDetectorRef.detach(), а потом дергать ChangeDetectorRef.detectChanges()

https://angular.io/api/core/ChangeDetectorRef

Говновуй - это просто реакт с прикрученной сверху реактивностью. Т.е. вместо того, чтобы дёргать какие-то говнофункции - мы обвешиваем поля гетерами и ловим доступ к ним. Всё это перепаста того, что было тысячи лет в реакте-экосистеме

Опять 4.2. Ничего подобного в реакте нет до сих пор, для связи компонентов из разных веток применяют костыли в виде Flux/Redux. При этом Vuex, сделанный в рамках карго культа, само по себе практически ничего не делает, а только создает экземпляр Vue и сует в него состояние — всё отслеживание изменений Vue делает само из коробки.

Полимер же, т.е. веб-компоненты, это попытка интегрироваться в дом. И не связывать ноды с каким-то говно, с сразу из говна сделать ноду и поместить в дом

Там минимальная интеграция, вроде общих селекторов, при парсинге страницы компоненты выносятся в отдельную парашу, и для скрытой работы с ними есть специальный механизм Shadow DOM, отдельный от обычного DOM, пусть и повторяющий интерфейсы последнего. По сути, браузерописаки (читай «Google» https://caniuse.com/#search=web components , https://caniuse.com/#search=shadow dom ) решили просто вынести виртуальный DOM из JS в код браузера на C++. Естественно, в браузере без поддержки веб компонентов с полифилами это будет тормозить еще сильнее, чем виртуальный DOM на JS.

сам полимер - это просто обёртка для упрощения работы с веб-компонентами, для проработки их будущего дизайна и для ухода от низкоуровневого бойлерплейта

В веб компонентах нет связывания данных. Вообще. В принципе. Да, формально в состав полимеров входят также либы совместимости и некоторые готовые решения. Я писал про фундаментальный механизм полимеров — связывание данных и вида, без которого полимеры просто не нужны со своими полифилами и готовыми решениями.

К тому же, какие-то ручные обновления и обновления вообще в принципе не возможно в этом подходе дерьма

То есть, с Vue ты совсем не знаком. Окей. Каким же шоком будет для тебя когда ты узнаешь про render() во Vue.

Это проблема не vue, а подхода дерьма. Такие же проблемы есть везде, потому как логические дом-ноды никак не связаны с твоими маня-нодами, а маня-ноды в свою очередь никак не связаны с твоими данными

Тем не менее, для реакта проблема решена: https://github.com/facebook/react-devtools/issues/382

Во-вторых полимер ориентируется не на хром, а на броузер. А броузеров, кроме хроме, нету

Схоронил.

Царь ударился в веб? Это что-то новое.

А что тебя удивляет? Царь закончил пту, надо как-то жить дальше. Карьера веб-макаки самая перспективная. Так что встречайте бессмысленные и беспощадные жопэс-срачи. Будем скучать по царю-школотрону с асмом и сишкой.

Жалкая потуга унизить Царя – даже краснодипломники после вуза идут ковырять Джаву и веб-парашу.

при этом заставляет вручную оповещать фреймворк об изменениях через setState

Не совсем. Часть DOM-а может перерисоваться и без использования state.

В остальном он точно так же ходит по всему поддереву, вычисляя свойства заново и синхронизируя DOM при расхождениях

При этом перерисовка DOM-а коснётся только изменённого элемента, а не всего блока. Если, например, у тебя есть десяток li в списке и изменился только один, то перерисуется только один.

Часть DOM-а может перерисоваться и без использования state

forceUpdate никто не отменял, но мы, все-таки, ведем разговор про связи данных.

При этом перерисовка DOM-а коснётся только изменённого элемента, а не всего блока. Если, например, у тебя есть десяток li в списке и изменился только один, то перерисуется только один

Но пересчитываться будут все. Да, V8 быстрый, по ресурсоемкости-производительности сравним с жавой, но все равно эта жава ни разу не бесплатная. На родительском компонента только рамочка появилась/исчезла в результате перемещения мыши, а в итоге фреймворку приходится проходить по всему дереву только для того, чтобы узнать, что изменений больше нет. И приходится крутить-вертеть архитектуру/верстку так, чтобы отделить рамочку от корневого элемента.

Аналогичная проблема небесплатности есть и в Vue/Polymers, просто там ресурсы жрут иные алгоритмы.

Часть DOM-а может перерисоваться и без использования state

forceUpdate никто не отменял

Не-е, никаких таких хаков.

Например у нас есть чекбокс. Вешаем на него событие onChange – если чекбокс установили – функция вызвала rander() и что-то изменилось на странице. Вот кейс без стейта.

в итоге фреймворку приходится проходить по всему дереву только для того, чтобы узнать, что изменений больше нет

Почему это по всему?)) Только в контексте одного компонента где был вызван render(), ну и компоненты которые он затрагивает. А иногда компоненты дробят на такие мелочи, что жуть просто.

То есть, он там был всегда. shallowRenderer появился позже, но это уже кривоватый костыль, который не составляет базу React-а.

И что ты высрал? Это ничего не значит. К тому же, реакт не развивался в паблике. Даже если бы ты был не настолько тупым и предоставил что-нибудь получше - это бы всё равно ничего не означало. Потому как изначальных данных у тебя нет.

Нет, по умолчанию все компоненты суются в общий автопоиск изменений. Чтобы ручками обновлять отдельное поддерево, нужно убрать его из автоматического обновления через ChangeDetectorRef.detach(), а потом дергать ChangeDetectorRef.detectChanges()

О боже, почему ты трепло не перестаёшь обгаживаться. Ты увидел в первой ссылке комбинацию флажков и решил, что один зависит от другого? Нет, ты обгадился. Вызов детектера для поддерева руками никак не требует отсоединения.

А то, что ты там увидел - это написано про тот кейс, когда необходимо только ручное обновление. Тебе об этом никто не говорил и в реакте подобное так же.

Опять 4.2. Ничего подобного в реакте нет до сих пор, для связи компонентов из разных веток применяют костыли в виде Flux/Redux.

Опять ты обгадилось. В говнуе точно так же нету ничего. И точно так же всё решается внешним стейт-менеджером. К тому же, к чему ты несёшь эту херню - неясно.

И да, клоун, ты опять обгадился с redux.

При этом Vuex, сделанный в рамках карго культа, само по себе практически ничего не делает, а только создает экземпляр Vue и сует в него состояние — всё отслеживание изменений Vue делает само из коробки.

О боже, ты и тут обгадился. Причём тут состояния, клоун? Тебе сообщили, что говноуе - это реакт с прикрученной реактивностью. Ворованной из реакта, которая там была тысячи лет.

Там минимальная интеграция, вроде общих селекторов, при парсинге страницы компоненты выносятся в отдельную парашу, и для скрытой работы с ними есть специальный механизм Shadow DOM, отдельный от обычного DOM, пусть и повторяющий интерфейсы последнего.

О боже, я каждый раз читаю этот нелепый высер и рожу себе расшибаю. Какой нахрен ещё Shadow DOM - ты услышал новый базворд и давай кукарекать?

Shadow DOM - это такой же дом. Никакие интерфейсы он не повторяет. Единственное чем он отличается - это созданием виртуального корня. Если проще - это dom и dom. Существует лишь для изоляции компонентов.

По сути, браузерописаки (читай «Google» https://caniuse.com/#search=web components , https://caniuse.com/#search=shadow dom ) решили просто вынести виртуальный DOM из JS в код браузера на C++.

Какой нахрен виртуальный дом. Трепло нелепое. Никакой виртуальный дом нахрен никому ненужен и это ни в каком виде виртуальным домом не является.

Естественно, в браузере без поддержки веб компонентов с полифилами это будет тормозить еще сильнее, чем виртуальный DOM на JS.

Ещё раз - в школу. Твой потолок даже в вебе - это пхп и вуе.

В веб компонентах нет связывания данных. Вообще. В принципе. Да, формально в состав полимеров входят также либы совместимости и некоторые готовые решения. Я писал про фундаментальный механизм полимеров — связывание данных и вида, без которого полимеры просто не нужны со своими полифилами и готовыми решениями.

Что следует из этой нелепой херни? Какие полимеров, какой механизм. Ты решил обгадиться и в тотальную несознанку уйти?

То есть, с Vue ты совсем не знаком. Окей. Каким же шоком будет для тебя когда ты узнаешь про render() во Vue.

Да у меня тут колхозник с помойки затриггерился. В школу.

Тем не менее, для реакта проблема решена: https://github.com/facebook/react-devtools/issues/382

И что ты высрал? Первую ссылку из гугла? Позорище нелепое. Этот высер никакого отношения к теме не имеет. Это примитивная бесполезная херня, которая ничего не показывает и не доказывает.

Царь закончил пту, надо как-то жить дальше. Карьера веб-макаки самая перспективная.

Бездарная обезьяна - ты зачем в контексте меня про себя рассказываешь?

Например у нас есть чекбокс. Вешаем на него событие onChange – если чекбокс установили – функция вызвала rander() и что-то изменилось на странице. Вот кейс без стейта

А тут render не будет взываться. Точнее, он вызовется только если ты сделаешь setState или forceUpdate в обработчике.

в итоге фреймворку приходится проходить по всему дереву только для того, чтобы узнать, что изменений больше нет

Почему это по всему?)) Только в контексте одного компонента где был вызван render(), ну и компоненты которые он затрагивает

Вот поэтому я и привел пример рамочки на родительском компоненте, которая приводит к вызову render на нем и на всём дереве дочерних компонентов.

Вызов детектера для поддерева руками никак не требует отсоединения
А то, что ты там увидел - это написано про тот кейс, когда необходимо только ручное обновление. Тебе об этом никто не говорил и в реакте подобное так же

А какой смысл вызывать детектор без отсоединения? У тебя без отсоединения детектор будет проходить сразу двумя путями: один раз общий автоматический по ApplicationRef.tick, и второй раз твой ручной по ChangeDetectorRef.detectChanges. Компонент отсоединяют именно для того, чтобы сберечь ресурсы при автоматическом поиске изменений, переводя поддерево на ручное обновление.

Тем не менее, для реакта проблема решена: https://github.com/facebook/react-devtools/issues/382

И что ты высрал? Первую ссылку из гугла? Позорище нелепое. Этот высер никакого отношения к теме не имеет. Это примитивная бесполезная херня, которая ничего не показывает и не доказывает.

https://reactjs.org/f57ae67cfaa1fe76880654e2eddbf71f/devtools-full.gif

Больше отвечать не на что.

Какой нормальный девелопер будет юзать язык, сделанный этой компанией? А мелкософт известен тем, что поддерживает любое говно мамонта десятилетиями.

сделанный этой компанией?

Я вот не понимаю. Претензия в том, что компания не тянет на горбу все эти две сотни проектов?

Претензия в том, что dart может присоединиться к этим двум сотням проектов в любой день.

Дарт делали для галочки: нужен свой nihjs, тяп-ляп, положили в шкафчик. Все бы уже забыли про это ненужно, но появилась тема флюттера, и стюардессу откопали. Теперь постфактум люди недоумевают: почему мол в лохматом году не выбрали дарт? Да в том году такая опция даже не рассматривалась.

А какой смысл вызывать детектор без отсоединения? У тебя без отсоединения детектор будет проходить сразу двумя путями: один раз общий автоматический по ApplicationRef.tick, и второй раз твой ручной по ChangeDetectorRef.detectChanges.

Основной смысл в том, что ты обделался, потому как не знаешь нихрена и пытаешься кому-то что-то рассказывать.

Сообщаю новость - зону можно обойти и никакого триггера не будет. Если ты попытаешься кукарекать про «а вот из другого места придёт» - ты опять обделаешься, потому что в реакте это работает так же.

Если ты руками не накостылишь блокеры обновлений - будешь получать ререндер при ререндере любого предка.

Компонент отсоединяют именно для того, чтобы сберечь ресурсы при автоматическом поиске изменений, переводя поддерево на ручное обновление.

Нет. Ты кукарекал, что «необходимо». Теперь методичку ты поменял, когда обделался. Ранее об этом ты не говорил. Про то, что зону можно обойти - тебе сказали.

https://reactjs.org/f57ae67cfaa1fe76880654e2eddbf71f/devtools-full.gif

И что ты мне показываешь, жертва пропаганды? Потолок твоего развития - рекламную агитку? Это говно меняет строку в стейте. Это никому не интересно.

Это примитивная херня, которая читает пару полей у компонентов. Которые никто в здравом уме не юзает.

Мне даже лень говорить о том, что 90% нод будут генерировать компоненты без стейта. Который, о чудо, в этом говне не показываются и показываться не могут.

И чем дальше - тем подобных компонентов больше. А там дальше реактивность, хуки-хренохуки. Тысячи врапперов вокруг компонентов. Удачи что-то найти.

В общем, в школу сходи и не позорься.

Больше отвечать не на что.

Больше осилил.

Какой нормальный девелопер будет юзать язык

Любой не с помойки.

сделанный этой компанией?

Что это за бездарная херня для мамкиных опущенцев? Что вообще должен значить этот высер бездарный? Что из него следует?

А мелкософт известен тем, что поддерживает любое говно мамонта десятилетиями.

Потекла методичка. А чего у опущенных нету такого же списка по МС? Срочно беги писать, а то как-то странно получается. Одному нельзя убивать, а другому можно. И хомячьё в интернете ничего по этому поводу не орут.

Претензия в том, что dart может присоединиться к этим двум сотням проектов в любой день.

Основания.

Сообщаю новость - зону можно обойти и никакого триггера не будет. Если ты попытаешься кукарекать про «а вот из другого места придёт» - ты опять обделаешься, потому что в реакте это работает так же

Ты писал изначально про то, что механизм сложный и неудобный. Я тебе сразу ответил: он таковой потому, что его пытаются использовать нестандартно. Обходить зоны, чтобы автоматика не срабатывала, а в другом месте не обходить, тут я дергаю руками, а тут - не дергаю, ой, что-то все равно херня получилась и непонятно почему так работает.

А чего у опущенных нету такого же списка по МС? Срочно беги писать, а то как-то странно получается

https://www.zdnet.com/pictures/in-memoriam-all-the-consumer-products-microsof...

http://techrights.org/wiki/index.php/Microsoft_-_Dead_Divisions_or_Products

Это другие сектанты, к тому же потуги явно левые и не ходовые. Не засчитано.

К тому же, сам факт их наличия автоматически делает любых заявляющих о них идиотами. Потому как если мёртвые проекты - это свойство всех(а не только корпораций), то какой смысл выделять какую-то и хаять её за это?

На самом деле мотивация тут другая. Это просто бездарные жертвы пропаганды. Всякие мамкины бездарные адепты маня-свободки, говнозилы и прочего дерьма. В общем с мочёй в черепушках, залитой туда маркетинговыми отделами конкурентов гугла. А эти бездарные жертвы пропаганды о каких-то подобных вещах не думают, да и в целом не думают. От того они и бездарные жертвы пропаганды.