Но топить за Vite, который взлетел исключительно из-за того, что его в скафолдинг тулзы стали пихать "чуть менее чем все" дждавскриптовые фреймворки - это наше все.
Звучит как какая-то обида. Нет, Vite стал популярен, так как он обходит webpack по всем характеристикам, кроме гранулярного контроля над чанками (с переездом на rolldown и это останется в прошлом). Иначе бы все "чуть менее чем все" на него не перешли.
Вспоминаю сколько сил забирал Webpack у меня в прошлом буквально 0 желания к нему вновь прикасаться.
PS. В последний раз трогал Webpack когда надо было проект с SSR+SSG Vue2 на Vue3 пернести, мата было много. В итоге переехали компанией на Vite и все остались супер счастливы
Компоненты как раз ничего не запрашивают, а в них проталкивают значение сверху вниз. В то время как у Solid пропсы это Pull-based так как они ленивы и значение пропса вычисляется только в момент попытки обращения значению пропса.
Нужно нехилую ментальнужю гимнастику применить, чтобы хоть как-то натянуть модель реактивности React на Pull-семантику. А если с точки зрения вычисления смотреть, то это прям совсем push push
Так как это изначально не было целенаправленным функционалом Vue. Скорее случайным образом обнаруженная возможность для реализации. Просто из Vue в целом выпилили идею топорных событий (теперь они заранее регистрируются). Если так подумать то действительно смешно было наблюдать по 5-6 инстансов Vue для того чтоб сообщениями обменивались компоненты, как-то логика нарушается
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Там уже почти официально свой язык программирования SvelteScript. И код всего проекта пишется только в файлах .svelte.js. Очень ванильно) По сути 5ка несет еще больше магии и подкапотной работы по итогу. В чем ванильность решения - не ясно
Вы уж больно сильно давите на "невероятную разницу Vue 2 и Vue 3". А по факту единственное что нужно будет изучить (и что является причиной мажора): разница системы реактивности на Proxy и системы реактивности на getter/setter. Это тема 1 занятия. Там же изучается 2 ушедших метода Vue.$set / Vue.$delete. Все. никаких x1.5 или 1.3 для 90%+ случаев.
Да будут некоторые особенности но не страшнее чем изучение разницы между react 14 / 18. Выбор между вакансиями тоже синтетический. Я особо не встречал, чтобы строго разделяли знания Vue2 и Vue3. Если знаешь одно, то спокойно возьмут на другое, так как на адаптацию и недели не уйдет. Были на практике даже случаи(буквально в прошлом году), когда джуны 0 опыта проходили на Vue вакансию после изучения реакта буквально 3-4 дня потренировав Vue и уловив основные концепции.
vue сейчас, кстати, тоже активно ведет разработку над no-vdom решением на основе реактивности как в Solid: vue vapor mode. Это будет опциональный режим для работы компонентов
Да они небольшие. Но вот эту пачку утилит которую все пишут как попало. Таскают из проекта в проект накапливая устаревания, бед-практисы и тд. Часто на вопрос: а на кой эта утилита? Ответ: ну вот из проекта в проект таскаю привык уже. Так что единая точка для утилит: замечательный выбор. Они всегда протестированы, задокументированы и поддерживаются силами всего сообщества
Зависимость и зависимость. Проблем от создания велосипедов гораздо больше: неожиданные корнер-кейсы. Дополнительная точка для тестирования и потенциальная проблема (Ваш пример с useLocalStorage тоже не с первого коммита заработал корректно. Мне бы хватило взять функцию и не переживать о остальном)
Да они могут делать что-то другое что в 90%+ случаев будет более подходящим. Пример опять вышел мимо:
const breakpoints = useBreakpoints({
desktop: 1800,
notebook: 1200,
tablet: 480,
mobile: 0,
}).current()
// Так как vueuse возвращает нам все подходящие брикпоинты, то берем самый большой
const currentBreakpoint = computed(() => breakpoints.value[0])
// Тут и комментировать нечего, код нагляднее некуда
watch(currentBreakpoint, (newBreakpoint, oldBreakpoint) => {
document.body.classList.remove(oldBreakpoint)
document.body.classList.add(newBreakpoint)
}, { immediate: true })
О какой половине шла речь? Специально сравнил с предоставленными исходниками. Я предпочту поддерживать вариант с vueuse. Тут ровно 5 строк предельно понятной логики. Те разница почти в 8 раз и не надо думать что там идет не так.
Как вы и сказали это реактивный код. И дополнили "которые ты не используешь". Да, вью реактивный и это почти полностью компенсирует сказанное в статье. Неиспользуемые вычисляемые свойства на которые нет подписчиков... не обновляются. Во Vue pull модель реактивности. Нет подписки - нет обновления. И комментарий о Vue 3.4 тут не причем, он влияет лишь на вычислимые свойства с подписками. Поэтому аргументация тоже вышла мимо. Хотя да, часто избыточная логика может присутствовать чтобы покрыть различные кейсы или закрыть граничные случаи, но которые для большинства не критичны, что в теории в какой-то момент может спасти от выстрела в ногу.
"написать свой код всегда намного эффективней". Это если хватает компетенции. Если не хватает, то можно получить монстров гораздо страшнее чем универсальное решение от опытного разработчика. (тут оставлю ремарку, что читать исходный код таких библиотек очень полезно, даже если решил реализовать по-своему, то проще взять универсальное и отрубить ненужное, опять же экономит время и силы)
А еще ваше приложение работает на Vue. Ну какой-то совсем притянутый за уши аргумент. В чем же критичность того что создается не ref / reactive а уже готовый ref и watch к нему? Да и какая диктатура архитектуры. Это утилиты, пользуйся в той мере насколько и как надо.
Удобно, не удобно. Слишком субъективно. Мне вот удобно, вам нет. На чем сойдемся? Для чего делать отдельную переменную и синхронизировать ее тем более непонятно. Исключение: вы хотите работать с LS только по какому-то событию, но это уже совсем другая логика.
Как выше заметили. "Пишите все сами", если это не джун который разбирается в азах - такой же популизм.
Добавлю от себя:
Выбор что использовать, а что нет - за вами
Если вы берете SPA, то не факт что вам не понадобится SSR в будущем. Тут же поддержка из коробки
Как хорошо выше заметили: чем больше людей используют vueuse тем проще людям вкатываться в проект
Vivaldi ставит целью скорее дать полный простор для для персонализации (буквально миллионы настроек и каждая кнопочка может быть перемещена и тд). Тогда как Arc ближе к Apple по идеологии, что мы вам даем красивые свистоперделки из коробки. И это тоже вполне себе путь.
Короч опять битва великой кастомизации и "удобно красиво из коробки"
Скорее всего если вы искали документацию по tailwind, то ее конечно нет на unoCSS. Базовая информация представлена по кнопке Getting Started. И ключевое что нужно было понять: это не новый Tailwind а буквально фреймворк для создания CSS с атомик подходом (там как раз пример с 1 правилом).
И из коробки он имеет ровно 0 выхлопа и вам показывают как создавать ваши правила для создания утилити классов.
Дальше вам сообщается что вот все это объединяется в preset-ы. А сами пресеты уже подключаются к проекту: вас отсылают к стандартным пресетам по ссылке. И уже от выбранных пресетов зависит подход (в том числе есть пресет для подобия tw)
Продающих страниц особо у технологии нет. Да и подход отличается еще раз от tw вместо готового решения это буквально супер комбайн по решению задач связанных с атомик подходом (кастом правила, аттрибутифай, айконифай, тегифай и тд)
В целом уверен что сдружить их возможно. Но как писали ниже, то есть реактивные примитивы как Reactive которые могут прятать все эти .value. Однако, если вам не переписывать с React на Vue, то лучше принять .value. От нее пытались избавиться на этапе сборки но это порождало слишком много магии и дополнительных корнер кейсов проблемного вида
Сюда же можно отнести как оперативно vitest захватывает поле еще одного "монополиста" в виде Jest-а активно смещая его позиции. Да, фокус команды в этом году был явно не на стороне Vue (что понятно по отсутствию обещанного Vapor Mode)
Так же недооценено влияние языкового туллинга как Volar который тоже выходит за пределы Vue уже. Например языковой туллинг Svelte уже на нем.
Как по мне дико не хватает качественной UI-библиотеки. Вот чтоб от создателей со всей той любовью к DX-у что и в других продуктах от этих ребят. Именно в области UI-библиотек сейчас САМОЕ слабое место у Vue. Пока пытается это исправить только Nuxt со своим Nuxt UI, но он завязан на Nuxt экосистему и вне Nuxt не жизнеспособен сейчас, поэтому пользы мало.
Если появится что-то по кач-ву близкое или превосходящее условный Mantine, то это даст невероятный буст всей экосистеме
На самом деле SMI это далеко не только то что это целое представление и оно быстрее FPU. Чтобы этот вопрос отпал сам собой нужно понять как работают идентификаторы в v8. Они всегда работают как указатель на значение в куче. Но каждый раз создавать новое значение в куче / следить за его жизнью / обращаться через особую структуру HeapNumber -- это дорого. В то время как SMI это буквально число вставленное вместо указателя. Те 1ый бит в значении идентификатора говорит: Я не SMI а указатель, иди по нему там реальное значение. А SMI - хей тут уже лежит число, бери его и делай что хочешь. Чем и обусловлено ограничение в 31 бит ибо 32-ой бит это указатель на то что это число. Думаю с этого момента понятно чем обсулавливается кратная разница по перфу
Ошибка дизайна языка, когда планировалось делать его схожим с Java? Можно обнаружить в старых спеках языка кучу заразервированных слов из Java/C++ на всякий случай. На практике же undefined и null достаточно сильно отличаются и это важно учитывать. Смысл несут они разный
Обычно я не рекомендую напрямую юзать provide / inject а сделать композабл (ака хук в реакте) и в нем типизировать значения относительно provide / inject. Если хочется, то сделать ~99%-ую компию по API контексту из реакта можно в строк 30-50
Сравнение с экосистемой вебпака. Да сейчас экосистема вебпака больше, но это будет оч быстро меняться. Уже все современные фреймворки и продукты уходят от поддержки первого уровня webpack-а на поддержку в первую очередь vite (Angular тоже уже заявил о переходе на vite. только с React вопросы ибо им все равно)
rollup - ну и чем это плохо? тем более на последней конференции объявили что уже в разработке Rolldown (Rollup на Rust)
В комменте про китайца и автобус. Ну глупости то зачем говорить? Он создатель, но далеко не единственный разработчик. Для опровержения бас-фактора можно посмотреть, что сейчас он уже оч мало своего вносит https://github.com/vitejs/vite/graphs/contributors
ох не по тем стопам вы пошли, неужели чужие истории не научили ничему? (это я о методах продвижения вашего решения)
Звучит как какая-то обида. Нет, Vite стал популярен, так как он обходит webpack по всем характеристикам, кроме гранулярного контроля над чанками (с переездом на rolldown и это останется в прошлом). Иначе бы все "чуть менее чем все" на него не перешли.
Вспоминаю сколько сил забирал Webpack у меня в прошлом буквально 0 желания к нему вновь прикасаться.
PS. В последний раз трогал Webpack когда надо было проект с SSR+SSG Vue2 на Vue3 пернести, мата было много. В итоге переехали компанией на Vite и все остались супер счастливы
Компоненты как раз ничего не запрашивают, а в них проталкивают значение сверху вниз. В то время как у Solid пропсы это Pull-based так как они ленивы и значение пропса вычисляется только в момент попытки обращения значению пропса.
Нужно нехилую ментальнужю гимнастику применить, чтобы хоть как-то натянуть модель реактивности React на Pull-семантику. А если с точки зрения вычисления смотреть, то это прям совсем push push
А зря, Vue с 3кой в итоге расцвел, библиотеки подтянулись и он вполне имеет право заменять React полноценно
Так как это изначально не было целенаправленным функционалом Vue. Скорее случайным образом обнаруженная возможность для реализации. Просто из Vue в целом выпилили идею топорных событий (теперь они заранее регистрируются). Если так подумать то действительно смешно было наблюдать по 5-6 инстансов Vue для того чтоб сообщениями обменивались компоненты, как-то логика нарушается
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Там уже почти официально свой язык программирования SvelteScript. И код всего проекта пишется только в файлах .svelte.js. Очень ванильно) По сути 5ка несет еще больше магии и подкапотной работы по итогу. В чем ванильность решения - не ясно
Вы уж больно сильно давите на "невероятную разницу Vue 2 и Vue 3". А по факту единственное что нужно будет изучить (и что является причиной мажора): разница системы реактивности на Proxy и системы реактивности на getter/setter. Это тема 1 занятия. Там же изучается 2 ушедших метода Vue.$set / Vue.$delete. Все. никаких x1.5 или 1.3 для 90%+ случаев.
Да будут некоторые особенности но не страшнее чем изучение разницы между react 14 / 18. Выбор между вакансиями тоже синтетический. Я особо не встречал, чтобы строго разделяли знания Vue2 и Vue3. Если знаешь одно, то спокойно возьмут на другое, так как на адаптацию и недели не уйдет. Были на практике даже случаи(буквально в прошлом году), когда джуны 0 опыта проходили на Vue вакансию после изучения реакта буквально 3-4 дня потренировав Vue и уловив основные концепции.
vue сейчас, кстати, тоже активно ведет разработку над no-vdom решением на основе реактивности как в Solid: vue vapor mode. Это будет опциональный режим для работы компонентов
И действительно важной ни одной причины.
Да они небольшие. Но вот эту пачку утилит которую все пишут как попало. Таскают из проекта в проект накапливая устаревания, бед-практисы и тд. Часто на вопрос: а на кой эта утилита? Ответ: ну вот из проекта в проект таскаю привык уже. Так что единая точка для утилит: замечательный выбор. Они всегда протестированы, задокументированы и поддерживаются силами всего сообщества
Зависимость и зависимость. Проблем от создания велосипедов гораздо больше: неожиданные корнер-кейсы. Дополнительная точка для тестирования и потенциальная проблема (Ваш пример с useLocalStorage тоже не с первого коммита заработал корректно. Мне бы хватило взять функцию и не переживать о остальном)
Да они могут делать что-то другое что в 90%+ случаев будет более подходящим. Пример опять вышел мимо:
О какой половине шла речь? Специально сравнил с предоставленными исходниками. Я предпочту поддерживать вариант с vueuse. Тут ровно 5 строк предельно понятной логики. Те разница почти в 8 раз и не надо думать что там идет не так.
Как вы и сказали это реактивный код. И дополнили "которые ты не используешь". Да, вью реактивный и это почти полностью компенсирует сказанное в статье. Неиспользуемые вычисляемые свойства на которые нет подписчиков... не обновляются. Во Vue pull модель реактивности. Нет подписки - нет обновления. И комментарий о Vue 3.4 тут не причем, он влияет лишь на вычислимые свойства с подписками. Поэтому аргументация тоже вышла мимо. Хотя да, часто избыточная логика может присутствовать чтобы покрыть различные кейсы или закрыть граничные случаи, но которые для большинства не критичны, что в теории в какой-то момент может спасти от выстрела в ногу.
"написать свой код всегда намного эффективней". Это если хватает компетенции. Если не хватает, то можно получить монстров гораздо страшнее чем универсальное решение от опытного разработчика. (тут оставлю ремарку, что читать исходный код таких библиотек очень полезно, даже если решил реализовать по-своему, то проще взять универсальное и отрубить ненужное, опять же экономит время и силы)
А еще ваше приложение работает на Vue. Ну какой-то совсем притянутый за уши аргумент. В чем же критичность того что создается не ref / reactive а уже готовый ref и watch к нему? Да и какая диктатура архитектуры. Это утилиты, пользуйся в той мере насколько и как надо.
Удобно, не удобно. Слишком субъективно. Мне вот удобно, вам нет. На чем сойдемся? Для чего делать отдельную переменную и синхронизировать ее тем более непонятно. Исключение: вы хотите работать с LS только по какому-то событию, но это уже совсем другая логика.
Как выше заметили. "Пишите все сами", если это не джун который разбирается в азах - такой же популизм.
Добавлю от себя:
Выбор что использовать, а что нет - за вами
Если вы берете SPA, то не факт что вам не понадобится SSR в будущем. Тут же поддержка из коробки
Как хорошо выше заметили: чем больше людей используют vueuse тем проще людям вкатываться в проект
Не совсем.
Vivaldi ставит целью скорее дать полный простор для для персонализации (буквально миллионы настроек и каждая кнопочка может быть перемещена и тд). Тогда как Arc ближе к Apple по идеологии, что мы вам даем красивые свистоперделки из коробки. И это тоже вполне себе путь.
Короч опять битва великой кастомизации и "удобно красиво из коробки"
Скорее всего если вы искали документацию по tailwind, то ее конечно нет на unoCSS. Базовая информация представлена по кнопке Getting Started. И ключевое что нужно было понять: это не новый Tailwind а буквально фреймворк для создания CSS с атомик подходом (там как раз пример с 1 правилом).
И из коробки он имеет ровно 0 выхлопа и вам показывают как создавать ваши правила для создания утилити классов.
Дальше вам сообщается что вот все это объединяется в preset-ы. А сами пресеты уже подключаются к проекту: вас отсылают к стандартным пресетам по ссылке. И уже от выбранных пресетов зависит подход (в том числе есть пресет для подобия tw)
Дальше есть ссылки на плейграунд и интерактивную документацию по стандартным пресетам.
Продающих страниц особо у технологии нет. Да и подход отличается еще раз от tw вместо готового решения это буквально супер комбайн по решению задач связанных с атомик подходом (кастом правила, аттрибутифай, айконифай, тегифай и тд)
кстати да Astro тоже на основе Volar-а сделан
В целом уверен что сдружить их возможно. Но как писали ниже, то есть реактивные примитивы как Reactive которые могут прятать все эти .value. Однако, если вам не переписывать с React на Vue, то лучше принять .value. От нее пытались избавиться на этапе сборки но это порождало слишком много магии и дополнительных корнер кейсов проблемного вида
Сюда же можно отнести как оперативно vitest захватывает поле еще одного "монополиста" в виде Jest-а активно смещая его позиции. Да, фокус команды в этом году был явно не на стороне Vue (что понятно по отсутствию обещанного Vapor Mode)
Так же недооценено влияние языкового туллинга как Volar который тоже выходит за пределы Vue уже. Например языковой туллинг Svelte уже на нем.
Итого по векторам суммируя:
Frontend Framework - Vue
SSR Framework - Nuxt
SSG / Static Sites - Vitepress
STM - Pinia / @vue/reactivity
Builder - Vite
Test - Vitest
CSS framework - UnoCSS (убийца тейлвинда)
Linting / Formating - Stylistic / antfu-eslint-config
Language Tools - Volar
Презентации - Slidev
common web tasks - unjs
И уверен что я много чего еще пропустил
Чего же тут не хватает?
Как по мне дико не хватает качественной UI-библиотеки. Вот чтоб от создателей со всей той любовью к DX-у что и в других продуктах от этих ребят. Именно в области UI-библиотек сейчас САМОЕ слабое место у Vue. Пока пытается это исправить только Nuxt со своим Nuxt UI, но он завязан на Nuxt экосистему и вне Nuxt не жизнеспособен сейчас, поэтому пользы мало.
Если появится что-то по кач-ву близкое или превосходящее условный Mantine, то это даст невероятный буст всей экосистеме
На самом деле SMI это далеко не только то что это целое представление и оно быстрее FPU. Чтобы этот вопрос отпал сам собой нужно понять как работают идентификаторы в v8. Они всегда работают как указатель на значение в куче. Но каждый раз создавать новое значение в куче / следить за его жизнью / обращаться через особую структуру HeapNumber -- это дорого. В то время как SMI это буквально число вставленное вместо указателя. Те 1ый бит в значении идентификатора говорит: Я не SMI а указатель, иди по нему там реальное значение. А SMI - хей тут уже лежит число, бери его и делай что хочешь. Чем и обусловлено ограничение в 31 бит ибо 32-ой бит это указатель на то что это число. Думаю с этого момента понятно чем обсулавливается кратная разница по перфу
Ошибка дизайна языка, когда планировалось делать его схожим с Java? Можно обнаружить в старых спеках языка кучу заразервированных слов из Java/C++ на всякий случай. На практике же undefined и null достаточно сильно отличаются и это важно учитывать. Смысл несут они разный
Обычно я не рекомендую напрямую юзать provide / inject а сделать композабл (ака хук в реакте) и в нем типизировать значения относительно provide / inject. Если хочется, то сделать ~99%-ую компию по API контексту из реакта можно в строк 30-50
Легковесность - тут скорее про тулчейн, чем про выходной файл
Быстрая Сборка - проекты на вебпаке прямо ощутимо дольше собираются чем на vite. Особенно если хорошая работа над разбиением на чанки была произведена
Простая Настройка - бабель там не используется. Вместо него esbuild, что и дает заметный выигрыш по скорости
Давайте все по пунктам разберем.
Сравнение с экосистемой вебпака. Да сейчас экосистема вебпака больше, но это будет оч быстро меняться. Уже все современные фреймворки и продукты уходят от поддержки первого уровня webpack-а на поддержку в первую очередь vite (Angular тоже уже заявил о переходе на vite. только с React вопросы ибо им все равно)
Официальное решение по SSR это vike
rollup - ну и чем это плохо? тем более на последней конференции объявили что уже в разработке Rolldown (Rollup на Rust)
В комменте про китайца и автобус. Ну глупости то зачем говорить? Он создатель, но далеко не единственный разработчик. Для опровержения бас-фактора можно посмотреть, что сейчас он уже оч мало своего вносит https://github.com/vitejs/vite/graphs/contributors