Ну видимо вам больше нечего сказать и пошло обычное бла бла, "ты это не ты и вместо тебя отвечает нейросеть")) Если бы вы умели спорить по теме, в чем я очень сильно сомневаюсь, я бы продолжил дискуссию с удовольствием. Но вы же нити не улавливаете, от слова совсем, статья про одно, а вы мне приводите в комментариях тезисы, которые в статье не затрагивались абсолютно.
Матчасти следует учиться вам и выдать желаемое за действительное пытались как раз таки вы. Не вышло! Сели в лужу, от сюда и оскорбления пошли "Клоун" )) Клоун - это вы! Выздоравливайте
Меня реально нейронка троллит, причем не самая умная ее модель видимо)) Задеть за живое точно не получится даже бенчмарками)) Это еще раз подтверждает что статью вы не прочитали либо прочитали вскользь бегло, там ведь черным по белому написано
"Чтобы понять Virtual DOM по-настоящему, нужно выйти из плоскости “как сделать быстрее” и перейти в плоскость “как управлять системой”.
Теперь к вашим тезисам: - "Virtual DOM изначально создавался как раз для скорости, для обновления только части страницы, потому что обновления обычного DOM было дорогостоящими операциями."
Отвечаю: Vurtual DOM изначально создавался как архитектурная прослойка между состоянием приложения и реальным DOM и улучшение скорости это следствие, а не первопричина. Если бы вопрос стоял именно в миллисекундах, никто бы не вводил промежуточное представление дерева в памяти — потому что любая дополнительная абстракция имеет накладные расходы и об этом тоже указано в моей статье.
Так же в статье указано, что браузеры достаточно оптимизированы и умеют оптимально работать с DOM, не приводя к лишним перерасчетам когда в этом нет необходимости, то есть работают точечно и это тоже очевидное подтверждение того, что существующий прогресс браузеров не игнорится в статье.
Ссылаться на бенчмарк как на доказательство ненужности VDOM в корне неверно. Он показывает, что compile-time или fine-grained решения могут быть быстрее VDOM в синтетических сценариях. Но это не означает, что они работают "без промежуточной модели" или что DOM вдруг стал быстрее JS.
Разница в том, где и как устроена прослойка, а не в том, есть она или нет. Выигрыш в бенчмарке связан с отсутствием универсального runtime-diff'а, а не с тем, что можно просто работать с DOM напрямую и всё будет быстрее.
Статья разъясняет, что такое Virtual DOM как архитектурная модель, зачем он появился и какой принцип лежит в его основе. В ней не утверждается, что альтернатив не существует. В ней объясняется конкретная модель — её логика и её место в архитектуре.
Поэтому спорить с ней аргументами из бенчмарка, который измеряет скорость других реализаций, — это просто обсуждать другой вопрос.
Я понимаю ваше состояние) Хочется поумничать в комментариях, как вам кажется "аргументированно", а по факту все ваши аргументы мимо)) Выздоравливайте
Потому что статья про другое умник) Кто сказал что ты прав?)) Походу это наверное нейронка троллит меня)) Если есть что по существу сказать, если статья вводит в заблуждение и виртуальный дом работает как - то иначе и предназначен для другого, то аргументы в студию. Если нет, то до свидания!
))) Да мы уже обсуждаем ваш пример кода)) Который ну просто плоский и не учитывает кучи факторов, раз уж решили знаниями своими блеснуть, то уж будьте добры не после моих комментариев по вашему коду, а сразу описывайте нюансы. Пример кода который я привел с кнопокой - это сильное упрощение, ну и даже тут ваши советы и примеры просто не выдерживают критики) Ненужно все сводить к состоянию одной кнопки, состояний чего угодно может быть тысячи. И за тик может прилететь еще как и 10 и 20 апдейтов)) Вы предлагаете реализовать очередь обновлений собственноручно?) Вы случайно не из тех кто не использует ничего стороннего потому что "Я сделаю лучше"?)) Окей очередь вы реализовали, затем встанет вопрос оптимизации патчинга DOM, то есть по факту вы начнете пилить свой VirtualDOM)) Или что - то отдаленно напоминающее, при этом судя по вашим комментариям, отстрелите себе обе ноги.
Ваш ответ очень сильно тянет на ГПТшный, причем беслатной версии) И в вашей помощи уж точно нужды нет) Скорее наоборот.
))) Очень наивно все выглядит конечно) Тут если за тик прилетит 10 изменений булева, ваш код 10 раз пойдет в DOM менять что - то, это во - первых. Во - вторых, вы предлагаете выносить состояние кнопок в некий глобальный стейт?) Не жирно ли?) В - третьих, повторюсь столкнетесь с рассинхроном, потому что мы чаще работаем с асинхронным исполнением кода и состояние погони никто не отменял
Видимо говно ваши знания по работе с реальным DOM без прослойки, изввиняюсь за выражение, cделай ты isDisabled хоть свойством хоть параметром тебе всеравно придется сопоставлять/синхронизировать состояние флага с реальным состоянием элемента DOM, особенно если учитывать что проект не маленький и состояние может меняться не из одного кокретного места. Думаю собеседование вы бы провалили)
Почему устаревшая? VDom по сей дееь существует и отказываться от него вроде и не собираются. А альтернатива была всегда, тот же Angular работает без Vdom, так что это не что -то новое, а инструменты без VDom существуют давно. Да во vue появился vapor mode, но он не пришел на замену VDom, это альтернатива для желающих. Но вот что то подсказывает мне что желающих будет немного.
Спасибо за ап. Ну видимо не все со мною согласны и это нормально) да и я не мастер пера, вполне допускаю что где - то мне не удалось донести свою мысль верно.
потому что одного булевого флага недостаточно, когда у тебя есть вложенные effect’ы и многократные проходы трекинга в одном стеке вызовов. Плюс есть дополнительная оптимизация завязанная на битовую маску, с помощью которой vue помечает эффекты вызванные текущим прогоном dep.w и dep.n (was tracked, new tracked) и соответственно при отсутствии новой маски dep.n vue снимает подписку эффекта
Я вообще решил изучить как второй яп go, основной у меня js. Но в ходе изучения мне все больше кажется что js как раз таки и станет вторым) Мне в go реально нравится все, начиная с синтаксиса и заканчивая возможностями языка, ну а компиляция - так это вообще вишенка на торте.
Ссылаться на популярность — это не технический довод.
Вы хоть сами понимаете что пишите?) По вашему что nuxtjs - это сериал какой - то и что он популярен среди домохозяек и простых обывателей?) Он популярен в среде разработчиков и свою популярность он заслужил не статейками "а ля крутое решение" , а получил заслуженное признание в среде специалистов, которые годами тестили на деле этот инструмент, я извиняюсь за выражение, и в хвост и в гриву. И я более чем уверен что разработкой nuxtjs заняты далеко не глупые люди которые не меньше вашего заботятся об оптимизации и производительности данного инструмента. Говорю это со всей ответственностью, так как не мало времени провел изучая исходники на гитхаб. Я уже молчу про комьюнити которое достаточно активно и реагирует на все входящие замечания.
Я не увидел от вас аргументов в поддержку ваших советов. Было бы интересно услышать конкретные причины, почему именно Nuxt.js лучше подходит в обсуждаемом контексте
Вы предлагаете мне за вас сделать вашу работу?) Нет уж, это вам наверное следует подкрепить ваши статьи конкретными бенчмарками, тестами, сравнениями в профилировании, можно даже наверное для убедительности пару ссылок на репы хотя бы средних по масштабу проектов, которые будут являться хоть каким - то подтверждением того, что с интсрументом можно работать на +- больших проектах и не наткнуться на грабли которые заблочат его дальнейшее развитие.
Если делать выводы по вашим словам, то люди, которые разрабатывали тот же Nuxt.js, тоже не являются хорошими специалистами, потому что они тоже когда-то свернули с протоптанной тропинки.
Ну просто выводы надо делать правильные) Я не говорил что создавать что - то новое это плохо, наоборот - это хорошо. Но создавать что - то новое, полезное и лучшее, можно только после того, когда вы досканально изучили какой - то инструмент, провели с ним скажем так не мало времени, и знаете все его слабые и сильные стороны.
Если обратить внимание на рейтинг open-wc.org, можно увидеть, что Symbiote.js сейчас на седьмом месте среди гигантов
)) Кол - во скачиваний - это не то же самое что кол-во серьезных проектов в проде.
От себя добавлю что не имею ничего против симбиота, только посоветую не вести столь агрессивную агитацию в комментариях не подкрепляя ее ничем. Это точно даст обратный эффект ожидаемому. Плюс порекомендовал бы точно существенно переработать сайт с документацией. Успехов.
Ну во - первых а с чего вы взяли что я против нового? Я вообще никого не трогал) Проходя мимо просто ответил человеку на вопрос, что для задач с ssr я рекомендую nuxt, можно посмотреть выше. Во - вторых на счет сопротивления и не желания вникать в новое) Если вникать во все новое что появляется каждый день у тебя жизни не хватит что бы во всем разбраться, тут ключевое слово РАЗОБРАТЬСЯ. Тут хорошо бы еще понять в чем вы лично хорошо разбираетесь Mr_FatCat? Причислили себя к тем кто идет в ногу со временем, а того кто решил немного поспорить с тем кто как раз таки пытался сказать что существующий инструмент плох - вы отвели к категории людей которые не хотят ни в чем разбираться?) В-третьих - на счет хорошего разработчика - я как раз об этом и говорил, что хороший программист возьмет интсрумент и решит задачу. Понятно что задачу можно решить разными способами и с помощью разных инструментов. Но как показывает опыт, разработчик который в своей работе постоянно меняют тех стэк - не являются хорошим специалистом ни в одном из выбранных им инструментов. Собственно поэтому на рынке больше ценятся специалисты узкой направленности.
Ну видимо вам больше нечего сказать и пошло обычное бла бла, "ты это не ты и вместо тебя отвечает нейросеть")) Если бы вы умели спорить по теме, в чем я очень сильно сомневаюсь, я бы продолжил дискуссию с удовольствием. Но вы же нити не улавливаете, от слова совсем, статья про одно, а вы мне приводите в комментариях тезисы, которые в статье не затрагивались абсолютно.
Матчасти следует учиться вам и выдать желаемое за действительное пытались как раз таки вы. Не вышло! Сели в лужу, от сюда и оскорбления пошли "Клоун" )) Клоун - это вы! Выздоравливайте
Меня реально нейронка троллит, причем не самая умная ее модель видимо)) Задеть за живое точно не получится даже бенчмарками))
Это еще раз подтверждает что статью вы не прочитали либо прочитали вскользь бегло, там ведь черным по белому написано
"Чтобы понять Virtual DOM по-настоящему, нужно выйти из плоскости “как сделать быстрее” и перейти в плоскость “как управлять системой”.
Теперь к вашим тезисам:
- "Virtual DOM изначально создавался как раз для скорости, для обновления только части страницы, потому что обновления обычного DOM было дорогостоящими операциями."
Отвечаю:
Vurtual DOM изначально создавался как архитектурная прослойка между состоянием приложения и реальным DOM и улучшение скорости это следствие, а не первопричина. Если бы вопрос стоял именно в миллисекундах, никто бы не вводил промежуточное представление дерева в памяти — потому что любая дополнительная абстракция имеет накладные расходы и об этом тоже указано в моей статье.
Так же в статье указано, что браузеры достаточно оптимизированы и умеют оптимально работать с DOM, не приводя к лишним перерасчетам когда в этом нет необходимости, то есть работают точечно и это тоже очевидное подтверждение того, что существующий прогресс браузеров не игнорится в статье.
Ссылаться на бенчмарк как на доказательство ненужности VDOM в корне неверно. Он показывает, что compile-time или fine-grained решения могут быть быстрее VDOM в синтетических сценариях. Но это не означает, что они работают "без промежуточной модели" или что DOM вдруг стал быстрее JS.
Разница в том, где и как устроена прослойка, а не в том, есть она или нет. Выигрыш в бенчмарке связан с отсутствием универсального runtime-diff'а, а не с тем, что можно просто работать с DOM напрямую и всё будет быстрее.
Статья разъясняет, что такое Virtual DOM как архитектурная модель, зачем он появился и какой принцип лежит в его основе. В ней не утверждается, что альтернатив не существует. В ней объясняется конкретная модель — её логика и её место в архитектуре.
Поэтому спорить с ней аргументами из бенчмарка, который измеряет скорость других реализаций, — это просто обсуждать другой вопрос.
Я понимаю ваше состояние) Хочется поумничать в комментариях, как вам кажется "аргументированно", а по факту все ваши аргументы мимо)) Выздоравливайте
Потому что статья про другое умник) Кто сказал что ты прав?)) Походу это наверное нейронка троллит меня)) Если есть что по существу сказать, если статья вводит в заблуждение и виртуальный дом работает как - то иначе и предназначен для другого, то аргументы в студию. Если нет, то до свидания!
Вы лишь пытались повыделываться, но не вышло))
Не прочитав статью пришел тут нагадить в комментариях) Статья не дает рекомендаций, а только разъясняет как работает этот механизм.
Ваши комментарии были просто не в тему. Выздоравливайте
))) Да мы уже обсуждаем ваш пример кода)) Который ну просто плоский и не учитывает кучи факторов, раз уж решили знаниями своими блеснуть, то уж будьте добры не после моих комментариев по вашему коду, а сразу описывайте нюансы. Пример кода который я привел с кнопокой - это сильное упрощение, ну и даже тут ваши советы и примеры просто не выдерживают критики) Ненужно все сводить к состоянию одной кнопки, состояний чего угодно может быть тысячи. И за тик может прилететь еще как и 10 и 20 апдейтов)) Вы предлагаете реализовать очередь обновлений собственноручно?) Вы случайно не из тех кто не использует ничего стороннего потому что "Я сделаю лучше"?)) Окей очередь вы реализовали, затем встанет вопрос оптимизации патчинга DOM, то есть по факту вы начнете пилить свой VirtualDOM)) Или что - то отдаленно напоминающее, при этом судя по вашим комментариям, отстрелите себе обе ноги.
Ваш ответ очень сильно тянет на ГПТшный, причем беслатной версии) И в вашей помощи уж точно нужды нет) Скорее наоборот.
))) Очень наивно все выглядит конечно) Тут если за тик прилетит 10 изменений булева, ваш код 10 раз пойдет в DOM менять что - то, это во - первых. Во - вторых, вы предлагаете выносить состояние кнопок в некий глобальный стейт?) Не жирно ли?) В - третьих, повторюсь столкнетесь с рассинхроном, потому что мы чаще работаем с асинхронным исполнением кода и состояние погони никто не отменял
Видимо говно ваши знания по работе с реальным DOM без прослойки, изввиняюсь за выражение, cделай ты isDisabled хоть свойством хоть параметром тебе всеравно придется сопоставлять/синхронизировать состояние флага с реальным состоянием элемента DOM, особенно если учитывать что проект не маленький и состояние может меняться не из одного кокретного места. Думаю собеседование вы бы провалили)
Почему устаревшая? VDom по сей дееь существует и отказываться от него вроде и не собираются. А альтернатива была всегда, тот же Angular работает без Vdom, так что это не что -то новое, а инструменты без VDom существуют давно. Да во vue появился vapor mode, но он не пришел на замену VDom, это альтернатива для желающих. Но вот что то подсказывает мне что желающих будет немного.
Ну смотря кто и чем гордится)
Можно, а зачем?)
Даже процентовку вывел?) Почему не 70?
Так зачем ты залогинился?
Очень может быть)
Спасибо за ап. Ну видимо не все со мною согласны и это нормально) да и я не мастер пера, вполне допускаю что где - то мне не удалось донести свою мысль верно.
Спасибо
потому что одного булевого флага недостаточно, когда у тебя есть вложенные effect’ы и многократные проходы трекинга в одном стеке вызовов. Плюс есть дополнительная оптимизация завязанная на битовую маску, с помощью которой vue помечает эффекты вызванные текущим прогоном dep.w и dep.n (was tracked, new tracked) и соответственно при отсутствии новой маски dep.n vue снимает подписку эффекта
Я вообще решил изучить как второй яп go, основной у меня js. Но в ходе изучения мне все больше кажется что js как раз таки и станет вторым) Мне в go реально нравится все, начиная с синтаксиса и заканчивая возможностями языка, ну а компиляция - так это вообще вишенка на торте.
21? Не многовато ли?)
Вы хоть сами понимаете что пишите?) По вашему что nuxtjs - это сериал какой - то и что он популярен среди домохозяек и простых обывателей?) Он популярен в среде разработчиков и свою популярность он заслужил не статейками "а ля крутое решение" , а получил заслуженное признание в среде специалистов, которые годами тестили на деле этот инструмент, я извиняюсь за выражение, и в хвост и в гриву. И я более чем уверен что разработкой nuxtjs заняты далеко не глупые люди которые не меньше вашего заботятся об оптимизации и производительности данного инструмента. Говорю это со всей ответственностью, так как не мало времени провел изучая исходники на гитхаб. Я уже молчу про комьюнити которое достаточно активно и реагирует на все входящие замечания.
Вы предлагаете мне за вас сделать вашу работу?) Нет уж, это вам наверное следует подкрепить ваши статьи конкретными бенчмарками, тестами, сравнениями в профилировании, можно даже наверное для убедительности пару ссылок на репы хотя бы средних по масштабу проектов, которые будут являться хоть каким - то подтверждением того, что с интсрументом можно работать на +- больших проектах и не наткнуться на грабли которые заблочат его дальнейшее развитие.
Ну просто выводы надо делать правильные) Я не говорил что создавать что - то новое это плохо, наоборот - это хорошо. Но создавать что - то новое, полезное и лучшее, можно только после того, когда вы досканально изучили какой - то инструмент, провели с ним скажем так не мало времени, и знаете все его слабые и сильные стороны.
)) Кол - во скачиваний - это не то же самое что кол-во серьезных проектов в проде.
От себя добавлю что не имею ничего против симбиота, только посоветую не вести столь агрессивную агитацию в комментариях не подкрепляя ее ничем. Это точно даст обратный эффект ожидаемому. Плюс порекомендовал бы точно существенно переработать сайт с документацией. Успехов.
Ну во - первых а с чего вы взяли что я против нового? Я вообще никого не трогал) Проходя мимо просто ответил человеку на вопрос, что для задач с ssr я рекомендую nuxt, можно посмотреть выше.
Во - вторых на счет сопротивления и не желания вникать в новое) Если вникать во все новое что появляется каждый день у тебя жизни не хватит что бы во всем разбраться, тут ключевое слово РАЗОБРАТЬСЯ. Тут хорошо бы еще понять в чем вы лично хорошо разбираетесь Mr_FatCat? Причислили себя к тем кто идет в ногу со временем, а того кто решил немного поспорить с тем кто как раз таки пытался сказать что существующий инструмент плох - вы отвели к категории людей которые не хотят ни в чем разбираться?)
В-третьих - на счет хорошего разработчика - я как раз об этом и говорил, что хороший программист возьмет интсрумент и решит задачу. Понятно что задачу можно решить разными способами и с помощью разных инструментов. Но как показывает опыт, разработчик который в своей работе постоянно меняют тех стэк - не являются хорошим специалистом ни в одном из выбранных им инструментов. Собственно поэтому на рынке больше ценятся специалисты узкой направленности.