Там уже почти официально свой язык программирования 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
Я просто уточнил, что строгость это не дихотомия "строго" или "не строго", а вопрос меры и кол-ва строгости. Например в JS-е тоже есть некоторая строгость: нельзя сложить BigInt и number(речь о неявном те 150n + 150).
Вы правда верите, что все кто хвалят $mol это фейки?
Я могу понять неоднозначную реакцию на автора, но сама технология от этого не становится $trash-ом, как вы позволяете себе выражаться (с высокой долей вероятности не попробовав его толком)
Любопытно было бы увидеть полноценное сравнение Vivaldi и Arc. Так как оба браузера, как я понял, сосредоточились на кастомизации и максимизации комфортного пребывания в интернете.
Некоторые вещи уже хотелось бы, чтобы разработчики Vivaldi взяли себе на заметку:
Облегченный режим до отправки в конкретное окно
Так называемые "бусты" для стилизации (возможно поддержка UserScript-ов из коробки)
Кастомизация пространств (чтобы сразу понимать в каком ты). Пространства были добавлены недавно и хочется верить, что они будут активно развиваться
В остальном выглядит некоторым переосмыслением UX и это шаг в верную сторону экспериментов с настолько важной для современного человека вещью. Однако, пока, Vivaldi выглядит поинтереснее и помощнее
Вполне работает, только как я и написал, нужно будет каждый раз catch с onerror явно прописывать. Но `unhandledrejectuin` все же предпочтительнее, соглашусь
Там уже почти официально свой язык программирования 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
тогда в чем смысл статьи? Выдать нам набор имен... чтобы что? Они ссылочку на эту статью в резюме положат?
А я где-то давал оценку этому?
Я просто уточнил, что строгость это не дихотомия "строго" или "не строго", а вопрос меры и кол-ва строгости. Например в JS-е тоже есть некоторая строгость: нельзя сложить BigInt и number(речь о неявном те 150n + 150).
чтож вы так к этому сложению пристали? Полиморфизм выражается и в других операторах. Например:
И что делает эта функция? Умножает числа?
Нет, я ее создал для умножения строк
Да, это не авто-каст типов, но защиты от дурака в данном случае не шибко больше.
Ну и строгость это скорее шкала. И в питоне ее нельзя назвать супер строгой:
В условном Rust выдаст ошибку, так как тут авто-каст целочисленного и нецелочисленного
Вы правда верите, что все кто хвалят $mol это фейки?
Я могу понять неоднозначную реакцию на автора, но сама технология от этого не становится $trash-ом, как вы позволяете себе выражаться (с высокой долей вероятности не попробовав его толком)
Любопытно было бы увидеть полноценное сравнение Vivaldi и Arc. Так как оба браузера, как я понял, сосредоточились на кастомизации и максимизации комфортного пребывания в интернете.
Некоторые вещи уже хотелось бы, чтобы разработчики Vivaldi взяли себе на заметку:
Облегченный режим до отправки в конкретное окно
Так называемые "бусты" для стилизации (возможно поддержка UserScript-ов из коробки)
Кастомизация пространств (чтобы сразу понимать в каком ты). Пространства были добавлены недавно и хочется верить, что они будут активно развиваться
В остальном выглядит некоторым переосмыслением UX и это шаг в верную сторону экспериментов с настолько важной для современного человека вещью. Однако, пока, Vivaldi выглядит поинтереснее и помощнее
Команде Arc удачи и развития!
Вполне работает, только как я и написал, нужно будет каждый раз catch с onerror явно прописывать. Но `unhandledrejectuin` все же предпочтительнее, соглашусь