React vs Vue – подробное сравнение и перспективы

React + MobX с 2016 года избавлен от главного недостатка - ущербной системы управления состоянием. Когда управление состоянием на себя берет MobX (локальное у компонента и глобально), то это уже небо и земля.

React vs Vue – подробное сравнение и перспективы

И чем же React + MobX лучше, чем Vue?

В основном JSX'ом (в том числе из-за возможности early return) и хуками

React vs Vue – подробное сравнение и перспективы

React + MobX на 10 голов выше чем просто React или react + что угодно другое. Поэтому Vue лучше чем голый реакт, да, но не лучше чем React + MobX

Redux: Реанимируем легаси проект

но на практике работу ускоряют очень прилично 

Ну и как именно ускоряется работа?
Как можно обогнать ctrl+c / ctrl-v из фигмы?

Вот например прям с сайта tailwind'a это уже real world

Это ж ппц, это же прям дичь

Максимум что может быть. это не сильно отстать от SCSS. Получается в итоге преимуществ нет, но при этом приходится платить такую цену:

• Проигрыш по скорости (в розовом мире небольшое отставание)

• Жесткое месиво в разметке, что опять же крайне негативно виляет на скорость, т.к. надо ещё раздуплить что это вообще за блок такой h-10 px-5 sm:px-10 rounded-md w-full sm:w-auto cursor-pointer outline-none border-none flex sm:inline-flex items-center justify-center transition-all ease-linear duration-300 text-thin-14 sm:text-regular-16 data-[full-width]:flex data-[full-width]:w-full data-[rounded]:rounded-xl data-[disabled]:opacity-50 data-[disabled]:pointer-events-none sm:hover:bg-purple-3 active:bg-purple-2 ибо в tailwind нет логических подсказок в разметке аля .button / .title / .container

• Крайне затруднен сам по себе поиск файла и места с кодом куда внести правку, в CSS modules + scss все супер просто, ты видишь где проблемное место, нажимаешь правой кнопкой, показать код и вуаля, видишь класс src-pages-main-components-ArticlesList-components-ArticleListMobileView-___styles-module__card_content___SVA-I в котором сразу видно где именно лежит проблемный компонент и его класс, открываешь этот файл, далее ctrl+f по названию класса и ты сразу стоишь в нужном месте в коде, это настолько быстро, просто и приятно, что тут даже близко никакой конкуренции и аналогов нет.

На выходе, tailwind только замедляет разработку, срёт в разметке и мешает дебагу/фиксу багов/навигации по коду. Всё это негативно сказывается на скорости разработки, что в свою очередь сказывается на трате нашего времени впустую, а время это ресурс который нельзя вернуть, нельзя купить за деньги. И платя эту цену, ты по ничего не обретаешь.

Например когда мы используем Node.js на бэкенде для REST API, вместо С++, мы платим цену в виде уменьшения производительности, но в замен получаем очень сильное ускорение разработки, и очень сильное улучшение самого удобства разработки. Производительность падает не так страшно, как то, насколько сильно повышается скорость и удобство разработки. Вот это я понимаю справедливое и оправданное применение Node.js.

Ну и на закуску, например открываем тот же сайт tailwind'a и видим

Это же ппц просто) Если просмотреть разметку, получается полезной разметки там 10% от всех символов, остальные 90% это месиво от tailwind классов. Получается сайты с SSR каждый раз по сети гоняют дополнительную тонну мусора, хотя могли бы и не гонять)

Redux: Реанимируем легаси проект

Если бы вы прошли все виды верстrи, то как минимум с 2015-2016 года вы бы использовали SCSS, а не CSS. Между ними небо и земля. А SCSS видимо вы не использовали, что супер странно. В любом случае просто сделайте полноценный аналог комменту выше и все будет видно наглядно.

Redux: Реанимируем легаси проект

Удобно, быстро, легко и никаких проблем не испытываю.

Если всё действительно так, то для вас не составит труда и времени как для меня сделать тоже самое, только с tailwind. Нужно всего на всего отстилизовать кнопку, разумеется адаптивно, и для простоты всего 2 варианта, десктоп и мобайл, без планшета:

.button {
    height: 40px;
    padding: 0 40px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    border-radius: 5px;
    cursor: pointer;
    transition: all .3s ease;
    outline: none;
    border: none;
    // Набор стилей для текста из дизайн системы
    @include typography('Text Regular_16', '#afceff');

    // Через props можен сказать чтобы кнопка тянулась на всю ширину
    &[data-full-width="true"] {
        display: flex;
        width: 100%;
    }

    // Через props можен сказать что кнопка закругленная
    &[data-rounded="true"] {
        border-radius: 18px;
    }

    // Через props можен сказать что кнопка заблокирована
    &[data-disabled="true"] {
        opacity: .5;
        pointer-events: none;
    }
    
    // На мобильных устройствах hover нам может вредить
    @include respond-to-desktop-only {
        &:hover {
            // Цвет из дизайн системы
            background-color: color('Purple_3');
        }
    }

    &:active {
        // Цвет из дизайн системы
        background-color: color('Purple_2');
    }

    @include respond-to-mobile {
        display: flex;
        width: 100%;
        padding: 0 20px;
        // Набор стилей для текста из дизайн системы
        @include typography('Text Thin_14');
    }
}

Просто повторите аналогичный стиль для кнопки, где

@include typography('Text Thin_14');
пусть будет

font-size: 14px;
font-weight: 300;
line-height: 14px;
letter-spacing: 0.02em;
font-family: lalala;

@include typography('Text Regular_16', '#afceff');
пусть будет

font-size: 16px;
font-weight: 400;
line-height: 16px;
letter-spacing: 0.02em;
font-family: lalala2222;
color: #afceff;

Ну и сама кнопка -

<button 
  className={styles.button}
  data-full-width={props.fullWidth}
  data-rounded={props.rounded}
  data-disabled={props.disabled}
>
  {children}
</button>

И сравним результат. @Telichkin присоединяйтесь тоже

Redux: Реанимируем легаси проект

потому что по всем остальным глобальным вопросам во фронтенде мы, кажется, сходимся :)

Значит мышление должно быть схожее) И отсюда зеркальное удивление от того, как tailwind может реально нравится)

но лично мне гораздо удобнее и быстрее работать с Tailwind.

Может быть, но всё равно не могу понять как такое возможно)

Redux: Реанимируем легаси проект

Для меня лично самый большой плюс Tailwind'а -- это отсутствие головной боли от придумывания бесконечного количества имён для классов

Когда появился CSS modules (10 лет назад), уже этой проблемы не было. У меня в проектах 100500 .item или .title и т.п. Именно с таким названиями. И никто ни с кем не конфликтует, ибо CSS modules + SCSS.
Плюс на уровне вложенности это решается и решалось вообще со времен динозавров

.my_cart_container {
  .item { /* ... */}
  .title { /* ... */}
}

.my_other_block {
  .item { /* ... */} // Никак не связан с .item выше
  .title { /* ... */} // Никак не связан с .title выше
}

Никаких конфликтов, никаких выдумываний уникальных синонимов для item'ов, title'ов и т.п.

Получается самый большой плюс на самом деле не актуален с момента создания tailwind, за много много лет до него уже был не актуальным)

Такие длинные классы только выглядят непривычно

Если бы непривычно, хотя бы. Но выглядит скажем так значительно хуже) Чрезмерная, абсолютно лишняя когнитивная нагрузка, не разборчивость в inline мешанине и т.п. Это кстати тоже самое как окунуться в далекое прошлое и поверстать письма, там как раз в inline всё было, вот это я понимаю боль и страдания. А теперь, почти тоже самое, только назвали это tailwind. В традиционном подходе всё супер понятно, div в котором className={styles.title} сразу дает тебе понять что тут какой-то заголовок ну и так далее. Про то, что сама по себе верстка в разы компактнее при традиционном подходе я вообще молчу)

но на практике работу ускоряют очень прилично

Никогда не поверю. В розовом мире максимум не сильно отставать будет от традиционного подхода. В реальном, будет отставать значительно, например заходим в фигму, ctrl+c ctrl+v и всё. Плюс в SCSS абсолютно никаких ограничений на стили, там тебе и переменные и функции и условия и т.д. и т.п. Опять же, в той же фигме при условии если дизайнер адекват, есть тот же ui kit, например для типографии у них какой нибудь Subheader 2, ты просто берешь нажимаешь на него, его название тебе копируется в буфер обмена и далее

@include typography('Subheader 2');

и всё, которое проератится в допустим

font-size: 18px;
line-height: 20px;
font-weight: 500;

Потом через пол года гайд лайны не много изменятся и Subheader 2 теперь будет font-weight: 500;, просто в 1 месте это заменил и всё, сразу же это применилось везде.

Ну что это, если не максимально возможно большая скорость и блаженство?

Про всякие супер удобные хэлперы я тоже молчу, аля

 // На мобильных устройствах hover нам может вредить
@include respond-to-desktop-only {
    &:hover {
        // Цвет из дизайн системы
        background-color: color('Purple_3');
    }
}

@include respond-to-mobile {
    display: flex;
    width: 100%;
    padding: 0 20px;
    // Набор стилей для текста из дизайн системы
    @include typography('Text Thin_14');
}

И т.д. и т.п.

Redux: Реанимируем легаси проект

1) styled-components

• Писать CSS в JS'e ну такое себе мягко говоря.

• Компоненты не отделяются от верстки, все написаны с заглавной буквы, отсюда каша и в итоге говнокод.

• Ну и вообще любое CSS-in-JS это противоестественно. Это как пить чай из двигателя внутреннего сгорания.

2) Tailwind

Тут всё просто, вместо тысячи слов

<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
    <div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
  <div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
   <div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
    <div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>
<div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500">
    <div class="bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 bg-gray-20">Content</div>
</div>

Думаю не надо объяснять почему это write only once нечто, всё что угодно, но точно не код и не верстка.

10 лет назад была придумана идеальная связка, это CSS Modules + SCSS.
По сей день, альтернатив ей нет.

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

это мало того, что медленно

Медленно?)) Это нативная скорость. Все работают в едином процессе и едином потоке. Мы не говорим про шину гоняющую только строки, где нужно делать каждый раз JSON.stringify / JSON.parse.

// Microfront #1
window.$transport.emit('any_key', anyData);
// Microfront #2
window.$transport.on('any_key', (anyData) => {
  myState.data = anyData;
});

так ещё и концы с концами фиг сыщешь, всё влияет на всех

Ну если писать кривыми руками, которые даже не знают что такое console.log, то да. Но в этом случае вообще ничего не спасет) А так, всё нормально будет на самом деле.

// Смотрим всё что проходит через шину
// Можно даже логировать тех, кто ловит ссобытия через .on()
window.$transport.logEmit = true;
window.$transport.logHandlers = true;

Вжух и концы с концами отыскали)

Плюс никто не мешает расшаривать реактивные стейты

window.$states.appState.toggleTheme();
window.$states.cartState.clear();
window.$states.favoritesState.addItem(item);

Тут уже и шины нет) Миксовать можно как угодно, простор для творчества большой

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

Вопрос в том что растет связанность между сторами что при росте проекта превращается в большую свалку И замедляет развитие проекта.

Ну на самом деле тут ключевой аспект, это размер проекта. К сожалению тут без вариантов, если он большой, то это априори свалка, он будет неповоротливым, каждая новая правка всё сложнее и медленнее и т.п., как снежный ком, что бы мы не делали, и чем больше человек пишут в него код, тем эта свалка хуже. Единственный реально работающий способ это микрофронты, но и для них действует то же правило, чем больше микрофронт, тем больше он свалка) И как раз, для микрофронтов шина ложится отлично, а в рамках монолита это просто дополнительный уровень сложности.

Единственный способ это не иметь прямых ссылок между сторами

Да, ну это на самом деле связь между сторами вообще не проблема, ибо она решается легко, всего лишь setTimeout, а взаимосвязь между сторами появляется не просто так, она продиктована:
а) Удобством разработки
б) Бизнес логикой

А через шину событий получать необходимые данные из другого стора и хранить их как часть своего состояния.

К сожалению это не решает истинную проблему больших проектов, это просто альтернатива setTimeout'у, не более. Но если речь идёт о микрофронтах, то шина must have для взаимодействия между собой.

signals в качестве альтернативы useState в React

скорее вот уже 10 лет пользователи mobX старательно воротят нос от чего-то другого)

Расшифруйте свою мысль пожалуйста

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

Это не свалки со страниц) Это то, что могут использовать страницы, лейауты, компоненты и т.п.

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

И как справляетесь с возникновением взаимо зависимостей между сторами

Проблема:

Раз

Два

Три

Ссылка - https://stackblitz.com/edit/vitejs-vite-rms3azjv?file=src%2FApp.tsx,src%2Fstores%2FstoreA.ts,src%2Fstores%2FstoreB.ts&terminal=dev

Решение:

Раз

Два

Ссылка - https://stackblitz.com/edit/vitejs-vite-fucf9b87?file=src%2FApp.tsx,src%2Fstores%2FstoreA.ts,src%2Fstores%2FstoreB.ts&terminal=dev

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

В каждой папке вырастает во многом похожая, но не идентичная иерархия, из за сложности их поддержки.

Чрезмерно притянуто за уши, с чего в друг в каждой папке? Если есть очень большая и сложная страница скажем, то разумеется в ней будет дополнительное разбиение на компоненты и т.п. В чем проблема то в итоге?)

Код получается гвоздями прибит к проекту и вынос фичей в отдельные проекты сопряжён с серьёзным рефакторингом.

Ну во первых "прибит", только тот, который относится чисто к бизнес логике конкретного проекта, всё остальное и так по умолчанию делают нейтральным и универсальным. Поэтому, даже если что-то в этих местах которые реально, в реальный жизни захочется переиспользовать, то они изначально уже не будут прибиты, либо прибиты слабо, и провести рефакторинг вынеся это в другой проект займет от силы 30 минут в 95% случаях.

Связанные файлы разбросаны по разным местам репозитория далеко друг от друга.

Всё что касается конкретной страницы лежит внутри страницы. Это как бы рядом. Всё что касается конкретного компонента, лежит внутри этого самого компонента. Это как бы рядом. То, что на страницах или других компонентах используются общие части, которые используются много где, они и не должны лежать рядом. Что за бред. Вы когда писал этот пункт, вообще видели структуру которую я показал или от балды настрочили?

Всё что должно быть рядом, то и лежит рядом.

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

Работает для небольших проектов

Работает на любых проектах.

Как только сложность становится больше N, понимаешь, что без предварительного разбиения на модули не обойтись

А тут что, код не разбит? Все в одном файле/папке? Кто-то мешает создавать подпапки для логической группировки?

Frontend-архитектура, которая работает: как я строю Vue-приложения с минимумом сложностей

Уже все придумано больше 10 лет назад, это называется классика, она же логика, она же интуитивно понятная, она же очевидная. КПД максимальное. Любому вновь прибывшему сразу понятно что где лежит, что куда класть.

signals в качестве альтернативы useState в React

Это да, а геттерам и сеттерам так вообще уже 15 лет

Прожариваем React

Ну вот общий принцип, тут всё работает, но уже под потребности можно расширять функционал и добавлять логики на любой вкус и цвет) У меня в более продвинутой форме реализация, например и ссылка на локальный стейт компонента формы тоже имеется чтоб можно было извне его внутренней логикой управлять если потребуется.

https://stackblitz.com/edit/vitejs-vite-naqjwa41?file=src%2FApp.tsx&terminal=dev

Прожариваем React

Я говорю о том, что, то что сейчас есть из готовых "решений", далеко от идеала и можно сделать самому значительно лучше, причем предела для улучшений нет. Но это не для всех. Для меня например нет проблем, если то, что есть из готового мне не нравится, я просто делаю сам и всё. Это ведь мне надо, а не кому-то ещё прежде всего) Я конкретно себе упрощаю жизнь в первую очередь) Но опять же, именно для разработчиков. я ничего нового не говорю, это вообще типичная практика. А для промысловиков которые решают любую задачу готовой библиотекой, а если не находят ее, то встают в ступор, увы их ах. Это не для них) Они гордо называет тех, кто легко решает свои проблемы велосипедистами) Думая таким образом, что они якобы выше уровнем как разработчики))