Не спорю, сам люблю Vue за two way binding, при грамотном подходе его можно нужно делать контролируемым. Просто вопрос в предсказуемости и простоте потока данных. Односторонний поток минимизирует сайд-эффекты. За удобство двусторонней связи приходится платить: чем больше компонент может менять данные извне, тем выше вероятность неожиданных сюрпризов (а нам ведь не нужны сюрпризы). Это супер важно для крупных проектов, где сотни и тысячи компонентов. Two way binding требует постоянного внимания: нужно всегда держать в голове, что этот стейт в родителе может измениться из любого дочернего компонента. А значит, остальные компоненты, которые его используют, тоже должны быть готовы к этим изменениям. Плохо ли это? нет и да, расширять такую систему не всегда просто и удобно — это и есть цена за удобство двустороннего связывания.
ИМХО, двусторонняя связь удобно, полезно, но не всегда оправдана — проблема в том, что её иногда применяют там, где она вообще не нужна. Главное делать это осознанно: одно дело, когда связь настроена прозрачно и предсказуемо, и совсем другое — когда изменения приходят непонятно откуда. И как сказал выше, во многих кейсах связь на самом деле не нужна, и вариант с событиями будет грамотнее.
Самая главная фича лично для меня это способность изменять пропсы компонента. Это то чего мне не хватало у вью и то почему я не перешел на композишн апи(не только из за того что он похож на реакт)
Если дочерний компонент может менять пропсы, то весь поток данных становится непредсказуемым — родитель не знает, что его данные внезапно изменились, и это приводит к трудноуловимым багам. Vue специально предупреждает об изменении пропсов, чтобы поддерживать порядок: данные идут сверху вниз, а события— снизу вверх.
Перед тем как писать подобное, вам стоило ознакомиться, почему вью вас ругает, вы, явный косяк в архитектуре, подчеркнули как ПЛЮС, это фатальная ошибка, и ведь дело даже не в фреймворке... хоть на сервере будете писать код, где есть иерархия данных, подобные махинации, это выстрел в себе в ногу, ничего больше.
Представьте ситуацию: у вас есть функция, которая обрабатывает объект с настройками, переданный из другого модуля. Эта функция изменяет настройки внутри себя, например, добавляя значения или модифицируя их. Но другие части программы тоже используют этот объект и ожидают, что он останется неизменным. В результате возникает конфликт: один модуль получил изменённый объект, когда ожидал его в исходном виде, и программа начинает вести себя неожиданно. Такой баг сложно отследить, потому что изменения объекта происходят «втихаря». Вам это ничего не напоминает? Ну, конечно, вы нашли какие-то плюсы там, где их нет и не должно быть :)
Какая та мутная статья и оч старая, Bun даже на ощупь заметно быстрее ноды, да и чисто физически нода не может быть быстрее Bun, ибо на ноде часть дефолтных либ написаны на самом js, тогда как в Bun они написаны на Zig.
Если нода тоже перепишет свои либки с js на C++, то возможно, разница между нодой и Bun будет незначительной. На данный момент Bun вывозит чисто подобными моментами, это вопрос времени, вон нода тоже шевелится и тоже чето там переписывают, буквально на неделях, подвезли нативный ts (пока экспериментально, но это вопрос времени)
Ни в node, ни в bun нет Web API. Потому что это API клиентской части, а bun/node - серверной.
Конечно, Web API в прямом смысле этого слова нет да и никто так не говорил, с этим можно ознакомиться тут
p.s в статье слишком много громких слов, если не предвзято смотреть на Bun, почему нет, достаточно хороший рантайм, многие js фрейморки давно уже предлагают через него создавать проекты, экосистема растет, да вон даже нода наконец пошевелилась, одни плюсы
О, не только мы об этом задумались, круто! мы на работе потихоньку переходим на такой формат, + внутренний корпоративный софт потихоньку начали верстать под наклоном, самое удивительное, судья по отчетам отдела QA, количество багов связанные с версткой сократилось на 22,44% из за наклона, ща пилим специальную CSS сетку с наклоном, скоро в опенсорс пустим.
Некоторые люди, слово "монолит" — воспринимают как что-то "плохое", но это не совсем так, некорректно сравнивать в контексте что "лучше", это больше всего зависит от бизнеса и его масштабов.
Не спорю, сам люблю Vue за two way binding, при грамотном подходе его
можнонужно делать контролируемым. Просто вопрос в предсказуемости и простоте потока данных. Односторонний поток минимизирует сайд-эффекты. За удобство двусторонней связи приходится платить: чем больше компонент может менять данные извне, тем выше вероятность неожиданных сюрпризов (а нам ведь не нужны сюрпризы). Это супер важно для крупных проектов, где сотни и тысячи компонентов. Two way binding требует постоянного внимания: нужно всегда держать в голове, что этот стейт в родителе может измениться из любого дочернего компонента. А значит, остальные компоненты, которые его используют, тоже должны быть готовы к этим изменениям. Плохо ли это? нет и да, расширять такую систему не всегда просто и удобно — это и есть цена за удобство двустороннего связывания.ИМХО, двусторонняя связь удобно, полезно, но не всегда оправдана — проблема в том, что её иногда применяют там, где она вообще не нужна. Главное делать это осознанно: одно дело, когда связь настроена прозрачно и предсказуемо, и совсем другое — когда изменения приходят непонятно откуда. И как сказал выше, во многих кейсах связь на самом деле не нужна, и вариант с событиями будет грамотнее.
Эмм... вы шагнули мимо концептуальных вещей, вам сюда https://ru.vuejs.org/guide/components/props#one-way-data-flow
Если дочерний компонент может менять пропсы, то весь поток данных становится непредсказуемым — родитель не знает, что его данные внезапно изменились, и это приводит к трудноуловимым багам. Vue специально предупреждает об изменении пропсов, чтобы поддерживать порядок: данные идут сверху вниз, а события— снизу вверх.
Перед тем как писать подобное, вам стоило ознакомиться, почему вью вас ругает, вы, явный косяк в архитектуре, подчеркнули как ПЛЮС, это фатальная ошибка, и ведь дело даже не в фреймворке... хоть на сервере будете писать код, где есть иерархия данных, подобные махинации, это выстрел в себе в ногу, ничего больше.
Представьте ситуацию: у вас есть функция, которая обрабатывает объект с настройками, переданный из другого модуля. Эта функция изменяет настройки внутри себя, например, добавляя значения или модифицируя их. Но другие части программы тоже используют этот объект и ожидают, что он останется неизменным. В результате возникает конфликт: один модуль получил изменённый объект, когда ожидал его в исходном виде, и программа начинает вести себя неожиданно. Такой баг сложно отследить, потому что изменения объекта происходят «втихаря». Вам это ничего не напоминает? Ну, конечно, вы нашли какие-то плюсы там, где их нет и не должно быть :)
Какая та мутная статья и оч старая, Bun даже на ощупь заметно быстрее ноды, да и чисто физически нода не может быть быстрее Bun, ибо на ноде часть дефолтных либ написаны на самом js, тогда как в Bun они написаны на Zig.
Если нода тоже перепишет свои либки с js на C++, то возможно, разница между нодой и Bun будет незначительной. На данный момент Bun вывозит чисто подобными моментами, это вопрос времени, вон нода тоже шевелится и тоже чето там переписывают, буквально на неделях, подвезли нативный ts (пока экспериментально, но это вопрос времени)
Конечно, Web API в прямом смысле этого слова нет да и никто так не говорил, с этим можно ознакомиться тут
p.s в статье слишком много громких слов, если не предвзято смотреть на Bun, почему нет, достаточно хороший рантайм, многие js фрейморки давно уже предлагают через него создавать проекты, экосистема растет, да вон даже нода наконец пошевелилась, одни плюсы
Вероятно, имелся в виду TypeScript
Zig не является альтернативой C++ или Rust, он скорее аналог C
Лично мне, нравится дизайн vue (в плане реактивности)
тоже возьму на вооружение
нет бэкапа - нет бэкапа.
Сделал расширение для браузера, сайты не оптимизированные для диагональных (наклонных) экранов, будут корректно отображаться под углом.
https://github.com/azabroflovski/diagonal-orientation-extension
Не благодарите.
О, не только мы об этом задумались, круто! мы на работе потихоньку переходим на такой формат, + внутренний корпоративный софт потихоньку начали верстать под наклоном, самое удивительное, судья по отчетам отдела QA, количество багов связанные с версткой сократилось на 22,44% из за наклона, ща пилим специальную CSS сетку с наклоном, скоро в опенсорс пустим.
Чат-бот в Bing больше под поиск заточен, для ваших целей ChatGPT будет показывать себя лучше.
Слово "МОБИЛЬНЫЙ" телефон в заголовке, вам ни о чем не говорит?)
Гитхаб ван лав
Смотря что за разработка…
Лично я, не вижу смысла ставить две ОС, у меня на машине винда + wsl с блекджеком и докером, живется не плохо, я бы сказал шикарно)
Некоторые люди, слово "монолит" — воспринимают как что-то "плохое", но это не совсем так, некорректно сравнивать в контексте что "лучше", это больше всего зависит от бизнеса и его масштабов.
Действительно, думаю там будет по хлеще этого.