Comments 25
Я думал, уже почти все перешли на него. Я сам по бэкенду, но иногда для себя использую Vue, если надо что-то наклепать на фронте. И часто пишут с предложением работы на фронтенде - как и на постоянную работу, так и просто заказы на фрилансе - вроде для новых проектов все Vue 3+compostiton api просят использовать. Но, может, просто у меня такая выборка? Кто крутится в этом, расскажете, так оно или нет обстоит в целом?
До сих пор есть критическая масса приложений ещё даже на JQuery.
По поему опыту, "новые проекты" в студии/компании - это нечастое явление.
А вот 10 старых + 1 новый - вполне. Эти 10 старых вполне могут быть кто на JQuery, кто на vue 2.[5/6].
Поэтому под слоганом "все новые проекты делаем при помощи технологии Х" кроется мааааааленькая деталь, что новый проект будет раз в пару месяцев, а старые никто не отменял.
Это на Хабре все уже во всю гоцают на (Vue3/React)+TypeScript+(куча классных, модных и новых технологий для бекенда).
А возьмите Wappalyzer и пройдитесь по своим самым используемым сайтам и увидите, что не всё так однозначно.
В основном CMS'ки да React с Vue (r/v = ~3-5/1) в лучшем случае.
Редко попадается Angular. Ещё реже что-то прям огненное, типа Nuxt, Next или Quasar.
На свеженьким Svelte ещё ничего замечено мною не было, хотя технология прелюбопытнейшая.
Всё это из-за "зачем тратить человекочасы для перехода, если всё работает?".
Не, это я прекрасно понимаю. Я говорил именно про "Vue2/Vue3", потому что остальные фреймворки/библиотеки не рассматриваю при работе в принципе.
Кстати, именно Quasar понравился, первую версию использовал для личных целей с большим удовольствием, но ни одной вакансии с ним не предлагали( В основном, везде Vue+vuetify
Про реакты/ангулары и прочее вообще не знаю, как ситуация обстоит да и не особо интересно. Пробовал писать vk mini app на реакте - как-то очень тяжело давалось и некомфортно работать с ним было, код казался каким-то уродливым; больше не пытался
именно про "Vue2/Vue3",
Насколько я знаю, сейчас и ближайшее время править будет Vue 2. Особенно в крупных и средних компаниях. Именно из-за "зачем, если всё и так работает".
Quasar ... ни одной вакансии с ним не предлагали(
По причине выше. Со временем появятся, но через сколько - непонятно.
код казался каким-то уродливым; больше не пытался
React часто ругают за излишний "обязательный" код.
Сам пишу на Vue и действительно, React кажется враждебным после элегантных декларативных Vue компонентов. Но считаю, что React большинство используют неправильно.
React - это НЕ фреймворк. Это БИБЛИОТЕКА для рендеринга разметки.
А все пихают туда логику и даже сетевое общение, как в Angular и Vue.
Что в корне неверно.
Немного запозднил с ответом, но всё же)
Спасибо за ответ. Я прекрасно понимаю, что реакт - это просто либа для рендеринга html. Мне просто не нравится "синтаксис". Например, раздражает, что реакт НЕ РЕАКТИВНЫЙ и нужно явно вызывать setState(). Также мне просто не нравится визуально JSX. Я ни в коем случае не говорю, что он такой плохой, просто лично мне он режет глаза и вызывает дискомфорт, когда я его вижу. Самый приятный для меня - это svelte. Я, когда только попробовал его - чуть не кончил от удовольствия - очень просто, красиво, лаконично. Жаль, что работы на нём - чу-чу-чуть больше чем ноль
По всем признакам реакт - это фреймворк, так как задаёт ограничения на архитектуру, сам управляет жизненным циклом компонент, выступает инициатором рендеринга компонента и не отдаёт контроль за этим прикладному коду.
Подавляющее большинство проектов используют Vue2, а то и вообще какой-нибудь php шаблонизатор Blade
У меня двойственные впечатления от vue3.
С одной стороны composition api + script setup прекрасны и позволяют писать боле лаконичные компоненты. Попробовав писать реальный код в новом стиле понимаешь, что это удобнее старого подхода.
С другой стороны в реальной практике не редки случаи, когда компоненты содержат сотни строк кода. Когда разработчики фреймворка предлагают запихивать весь этот код в одну мега-большую лапшеообразную setup функцию, я понимаю, что пора переходить на другой фреймворк.
К счастью script setup больше не экспериментальная фича у vue3, но лучше бы в документации и примерах использования кода не писали примеры с синтаксисом export default { setup() { ... } }.
Мне кажется автор всё таки не понимает почему львинная доля продуктов остается на Vue2, и не переходит на новую версию. Причина, по моему субьективному мнению, в том что на переход с версии 2 на версию 3 понадобятся большое, неподьемное для бизнеса, количество человеко-часов. Я бы сравнил переход с Vue2 на Vue3 с переходом с Angular.js на Angular2, казалось бы, один и тот же фреймворк(нет), в чём проблема потратить тысячу сторипоинтов на это? Статья несёт более рекламный подход(интересно зачем?), нежели обьективный, который можно было бы предьявить клиентам.
Не обязательно переписывать весь работающий код на новый синтаксис при апгрейде. Со старым синтаксисом продолжит работать 99% кода, а оставшийся 1% это обновления сторонних vue2 пакетов и шаблонные замены/доработки.
Сложность обновления даже не сильно коррелирует с размером приложения, практически все изменения шаблонны, обновив несколько крупных компонентов, остальные будут обновляться поиском и заменой.
Основная проблема обновления это несовместимость библиотек/компонентов заточенных под 2 версию
А что, например, из написанного на Vue2, не будет работать при обновлении node_modules на третью версию? Есть фишки, которые у Vue3 есть и не работают на Vue2 (начнём с потребности последнего в корневом компоненте в template, Vue3 может сразу в несколько тегов там же).
Т.е., в чём проблема с тем, чтобы
обновить все пакеты из папки служебных
дальше писать новые компоненты на 3-ей версии
ну и по мере сил по возможности переписывать старые тоже на третью (а можно и не переписывать)
?
Как мы видим, в случае с composition API, структурировать код по логическому назначению легче. Это позволяет сохранять читаемость и масштабируемость компонента.
Да как-то не видим. Навалено всего в кучу. Вот, смотрите как выглядит настоящая структурированность (я использовал $mol_wire, но на Vue3 не сложно сделать аналогичные декораторы):
import {
$mol_wire_solo as solo,
$mol_wire_plex as plex,
$mol_wire_method as task
} from 'mol_wire_lib'
class Posts {
@solo list(): Post[] {
return fetchJson( 'https://jsonplaceholder.typicode.com/posts' ).data
}
@solo dict() {
return new Map( this.list().map( post => [ post.id, post ] ) )
}
@plex listByAuthor( authorId: string ): Post[] {
return fetchJSON( `https://jsonplaceholder.typicode.com/posts?userId=${authorId}` ).data
}
}
class Favorite {
constructor(
readonly posts: ()=> typeof Posts
) {}
@solo postId( next = null | string ) {
return next
}
@solo post( next = null as null | Post ) {
return this.posts().dict().get( this.postId( next?.id ) ) ?? null
}
}
class Comments {
@plex listByPost( postId: string ): Comment[] {
return fetchJSON( `https://jsonplaceholder.typicode.com/posts/${postId}/comments` ).data
}
}
class Auth {
@solo profile(): Profile {
return fetchJSON( `https://jsonplaceholder.typicode.com/users/${postId}` ).data
}
}
class Domain {
@solo posts() {
return new Posts
}
@solo favorite() {
return new Favorite( ()=> this.posts() )
}
@solo comments() {
return new Comments
}
@solo auth() {
return new Auth
}
}
class App {
@solo domain() {
return new Domain
}
@task putMyFirstPostToFavorite() {
const profile = this.domain().auth().profile()
const firstPost = this.domain().posts().listByAuthor( profile.id )[0]
this.domain().favorite().post( firstPost )
}
}для внедрения поддержки TypeScript необходимо было использовать классовые компоненты и декораторы. Это не всегда удобно и в целом усложняет процесс разработки.
Ну да, ну да, использование классов настолько сложно, что я даже уверен в корректности приведённого выше кода, хотя ни разу его и не запускал.
а стоило б:
class Auth {
@solo profile(): Profile {
return fetchJSON( `https://jsonplaceholder.typicode.com/users/${postId}` ).data
}
}откуда беретсяpostId?
Это была операция "мокрый сахар для муравьёв". Это ваша награда за внимательное чтение кода.)
судя про предыдущим комментариям с примерами от @nin-jin на хабре, либо там везде "сахар", либо, что скорее всего, это просто невнимательность.
Vue использует подход ViewModel из шаблона MVVM
Можете пояснить что это значит? Как подход отпочковался от шаблона и в чем этот подход заключается?
Для тех кто "боится", вышла версия vue 2.7, которая "почти" как 3 но с ограничениями второй. Например несуществующие свойства в реактивном объекте надо объявлять через (Vue|this).set (ну и удалить это все при переходе на 3ку)
А на самом деле я даже не думал как это удобно даже не думать об этом )
Одна из киллер фич (для меня) 3й версии в composition api - script setup. В 2.7 тоже перенесли.
Пишем на Vue 2, но на typescript (с декораторами). По-моему, это мегаудобно. Никто не знает - есть ли такое для Vue 3 (чтобы обычные переменные-члены классы автоматом были data, геттеры были computed, методы класса чтобы сразу в methods попадали)? Или я хочу чего-то необычного?
Крупные либы вроде Veutify и Quasar уже перешли на Vue 3? По идее они являются мажорными потребителями фич и могут провести dogfooding.
’’’Исходный код фреймворка был переписан с нуля, а при помощи использования TypeScript изменена система реактивности. ’’’
Глаз резануло
Улучшенная организация кода в компонентах
Эта проблема слишком преувеличена, сами собрали спагетину с кучей ответственностей, а потом жалуются. Теперь тоже самое пилят в script setup, но без чётко выделенных блоков данных, методов и пр.
Хочу перемен: почему пора переходить на Vue 3