Comments 52
...и многие аспекты не были рассмотрены полноценно.
Скажу больше: я был уверен, что читаю лишь введение, когда статья вдруг закончилась.
Подключаем JSX к Vue и все позитивные моменты React сходят на нет (исходя из текста статьи). Не стоит начинать писать статьи с подобного рода текстов, по моему мнению.
Похоже на очередную интерпретацию древнейшего холивара «какой язык/фреймворк использовать для проекта?».
И выводы всё те же: «используйте тот, которым умеете пользоваться, а тот, которым не умеете - не используйте». Хотелось бы большего раскрытия темы. Чем фреймворк отличается от библиотеки - понятно было и так. Насчёт производительности, опять же - вопрос крайне спорный.
На Vue тоже можно таких делов наворотить при неумелом использовании - мама не горюй. Там есть, где разгуляться. От проекта к проекту, что я видел, разве, что структура директорий, в целом, схожи, а в остальном - кто во что горазд.
Так в итоге: Vue или React изучать начинающим? И почему? Ожидал увидеть в статье нечто подобное. Какой профит на длительной дистанции можно получить при выборе той или иной технологии?
По моим личным впечатлениям во Vue "зайти" проще и что-то начать делать.
Присоединюсь
Начать делать «что-то» - да. Речь в статье о длинной дистанции и техдолге. И здесь во Vue есть, где разгуляться. Особенно с появлением третьей версии при близкой к полной обратной совместимостью со второй.
Я и сам люблю Vue, использую его в проектах чаще прочих, но, поверьте, видел всякое. И взаимодействие всех подряд компонентов через стор. И абсолютно запутанные схемы взаимодействия компонентов с помощью EventBus. И бесконечные череды совершенно однотипных props и emits при глубокой вложенности. И ещё многое-многое-многое, что тяжело поддерживать и нужно приводить в порядок.
Процитирую комментатора из ветки чуть ниже:
При этом, если рассматривать рост техдолга, то Vue 3 все же догоняет React. Да, стили и сторы все еще организованы лучше чем React, но вот для разработки компонентов создатели Vue оставили слишком много места. Их теперь можно писать и на JSX, и с render функциями, и темплейты, и с options API, и с setup-функцией, и со script setup.
Всё так. Зайти - проще. Начать делать «что-то» - проще. А вот накопить техдолг - без проблем.
Зайти однозначно проще. Я быстро зашел. Но потом так же быстро вышел т.к. Vue 3 + Typescript почти невозможное сочетание. А без Typescript - зачем вообще так жить? После довольно долгих мучений я таки подружил его с Typescript, а потом напоролся на то что часть сторонних библиотек не обновлена под Vue 3 и полностью с ним несовместима. Мне, например, не улыбается самостоятельно велосипедить Bootstrap компоненты, но пришлось бы если б остался. После прототипирования пары страниц я понял что работая с Vue я превозмогаю его, а не использую с удовольствием. На этом я ушел в React и настроил всё что мне нужно было намного быстрее, с меньшей болью и усилиями. Даже удовольствие получил от того что оно "просто работает". Typescript из коробки доступен, всё прекрасно работает в IDE со всеми возможными подсказками включая стили. Добавить react router, i18n, transition и набор бутстраповских компонентов на выбор - и можно работать. Для react есть практически все возможные либы и многие из них поддерживаются на свежих версиях реакта, т.е. есть вполне живая экосистема. Для vue 3 экосистемы за пределами стандартных либ можно считать что нет. Такое чувство было что многие решили не обновлять либы с Vue 2 на Vue 3 из-за довольно объемных изменений в ядре Vue 3. Единственное что мне прямо очень понравилось во Vue - как красиво и удобно реализовано глобальное состояние. Redux, часто используемый в паре с React - это мозговыносящая переусложненная боль прямо. Может для супер больших online+offline проектов оно и оправдано, но у меня проект довольно средненький и я предпочел Modx - как-то он логичнее и понятнее. Тем не менее лучшее решение из тех что я пробовал именно у Vue. Хотя в общем я согласен с автором что React слишком либерален и для совсем кривых рук не подходит - там нужно понимать что ты делаешь. Те же хуки - это прямо кладезь потенциального технического долга. Но при этом и очень мощный инструмент при правильном использовании.
Использовать фреймворк не имеющий нормальной поддержки и не получившей её за 4 года существования равносильно выстрелу в голову для руководства. Каким бы ни был прогрессивным фреймворк - если его не используют массово, то он никому не нужен. Ну и синтаксис шаблонов - это отдельный трэш. Шаблоны невозможно понять быстро - они почти полностью нечитабельны. Соответственно нужно вникать в каждую строку и расшифровывать бесконечные спецсимволы, даже если их всего несколько. Это контрпродуктивно как для разработки, так и для поддержки. В добавок нет поддержки со стороны IDE что еще больше усугубляет ситуацию. Я оценил фичи, некоторые действительно крутые, но поймите - как бы Вы не пиарили фреймворк, если его разрабатывает пара человек в свободное время без поддержки со стороны бизнеса, то использование такого фреймворка имеет высокие риски остаться с непопулярным фреймворком наедине. И им придется переписывать проект на что-то другое. Высокие риски допустимы для некоторых стартапов, но не для более-менее крупных компаний. И стартапы тоже предпочтут React/Vue/Angular т.к. у всех у них есть много документации, экосистема, сообщество, разработчики, которых можно нанять. Где вы найдете разработчиков знающих или готовых работать со $smal на замену ушедшему? На рынке сейчас итак недостаток качественной рабочей силы, а тут еще и неизвестный малопопулярный фреймворк. Да все качественные кандидаты просто пойдут к конкурентам после того как ознакомятся со $mol и Вашими статьями в стиле "всё вокруг говно, а $mal лучше всех!". Может и лучше, но почему-то никому не нужен...
Я бы ещё отметил и то немногочисленное сообщество, что по уровню токсичности догоняет, а то и превосходит форумы разрабочиков 00-х годов)
Вы сами-то хоть раз заглядывали к нам, чтобы такое утверждать? Или тоже повторяете чьи-то вбросы из какого-то по настоящему токсичного сообщества?
Да, без всяких шуток, на протяжении последних нескольких лет я читаю чисто из интереса почти все выходящие статьи многоуважаемого Карловского. И ваши, в том числе.
Стиля повествования статей и того, что разворачивается под ними в комментариях с упреканием непонимающих «великой миссии $mol» мне достаточно. Вы так рьяно сравниваете с землей все прочие фреймворки/библиотеки, а также всех несогласных, что, наверное, это и есть та причина, почему я их по-прежнему читаю. Очень любопытное явление в 22 году. И да, про вас я, в том числе. Взгляните на свои комментарии. Острые вбросы и обесценивание чужого опыта под вашими постами - это то, чем вы с Карловским прославились на хабре. Нет дыма без огня, товарищ.
И да, $mol я тоже смотрел. И так давно вас читаю, что, наверное, мог бы даже на нём что-то собрать. Сам не разворачивал, но с синтаксисом и конкретными решениями каких-то насущных проблем знакомился. Есть действительно хорошие идеи, но о великой миссии я бы не говорил. За столько лет даже демо-сайт так и не уменьшил степень кривизны. А когда речь заходит о том, что «всё плохо на устройстве X или в браузере Y», то, оказывается либо с устройством проблема, либо со сценарием использования, либо «вот-вот всё полетит».
На хабре тоже достаточно токсиков) ой, как немало. Не поспоришь. Но больше ни одна из конкретных тем для обсуждения не пропитана таким негативом насквозь.
То есть именно в наши сообщества вы так и не заглядывали, ясно.
Да, мне было достаточно того, что я увидел здесь, чтобы принять решение о том, что погружаться глубже мне не следует.
Тем не менее, благодарю за ссылки. За развитием вашего продукта продолжаю наблюдать с интересом. Пока что только здесь. А там посмотрим.
Куда вы там погружаетесь, меня не очень волнует, как и отношение лично ко мне. Но извольте следить за языком, и не заниматься клеветой неизвестных вам людей.
Клевета это или нет - вопрос глубоко дискуссионный в данном контексте. У меня, как и у многих других пользователей хабра это мнение сложилось неспроста.
Так что предлагаю оставить всё как есть. Тем более, раз уж вас это «не очень волнует».
Однако же, я вас понял. За «немногочисленное сообщество» - беру слова назад. В таком случае, сформулирую своё мнение как «токсичность представителей проекта и сообщества на хабре». Возможно, так будет правильнее.
это, разве, разные лица? Думал, что "нин-джин" и "винтаж" - один Карловский, просто "винтаж" в минус улетел
Использовать фреймворк не имеющий нормальной поддержки и не получившей её за 4 года существования равносильно выстрелу в голову для руководства.
У $mol одна из лучших платных поддержек среди конкурентов, так как мы можем позволить себе индивидуальный подход и глубокую кастомизацию без полного рефакторинга.
Ну и синтаксис шаблонов - это отдельный трэш. Шаблоны невозможно понять быстро
Согласен, поэтому..
если его не используют массово, то он никому не нужен
Тут у вас сломались круги Эйлера.
бесконечные спецсимволы, даже если их всего несколько
А тут - кардинальные числа.
В добавок нет поддержки со стороны IDE что еще больше усугубляет ситуацию.
Вот странность: поддержки IDE нет, а она всё прекрасно понимает.
если его разрабатывает пара человек в свободное время без поддержки со стороны бизнеса
Так поддержите его со стороны своего бизнеса, и не придётся бояться, что Google похоронит очередную свою поделку.
использование такого фреймворка имеет высокие риски остаться с непопулярным фреймворком наедине. И им придется переписывать проект на что-то другое.
Философия $mol: код фреймворка ничем не отличается от кода прикладного. Это не Ангуляр, где в исходниках чёрт ногу сломит. Вы же, надеюсь, не переписываете всё приложение только потому, что уволился один из его разработчиков?
Где вы найдете разработчиков знающих или готовых работать со $smal на замену ушедшему?
Подойдёт любой разработчик, знающий TS. Это не rocket science, недостающие абстракции осваиваются за неделю - две.
На рынке сейчас итак недостаток качественной рабочей силы, а тут еще и неизвестный малопопулярный фреймворк.
Ну вот один толковый разраб на $mol сделает больше и качественнее, чем два таких на React, и уж тем более больше, чем 8 бестолковых, которыми и завален рынок сейчас.
Может и лучше, но почему-то никому не нужен...
Земля может и круглая, но глобусы никому не нужны. Всем плоские карты подавай в проекции Меркатора, где остров Гренландия оказывается больше материка Австралии.
т.к. Vue 3 + Typescript почти невозможное сочетание.
А можно конкретный пример, что там такое за "невозможное сочетание"? Очень интересно, с учетом, что весь тулинг вокруг Vue 3 делает упор в первую очередь на TS.
К сожалению уже нет конкретного примера. Было это год назад и после того как понял что дело так дальше не пойдет, я удалил всё что там было. Если правильно помню, то проблема там была в том что практически все сторонние либы под Vue не дружили с TS, что делало использование TS болью из declare module. Еще какая-то беда была с первоначальной настройкой TS. Глянул сейчас документацию по активации TS - мне кажется это довольно сложным даже сейчас, когда я намного больше знаю про настройку TS и webpack. С реактом всё как-то сильно проще было.
Глянул сейчас документацию по активации TS
Сейчас, в принципе, никакой активации и не нужно, по умолчанию рекомендуется писать компоненты на script setup, где достаточно поставить lang="ts" и все, дальше никто ни в чем не ограничивает. Пропсы объявляются через интерфейсы, эмиты тоже, в остальном весь компонент теперь выглядит очень похоже на функциональные компоненты в реакте - те же хуки, только сделанные немного иначе. Помимо этого, в VSCode есть отличное расширение Volar, которое добавляет типизацию даже шаблону (под капотом она основывается на JSX).
В общем, с типизацией сейчас едва ли есть какие-то проблемы. Но стоит отметить, что год назад не было script setup и там действительно требовалось чуть больше усилий для типизации чистого Composition API.
Вот скорее всего допилили поддержку. Я не помню конструкций вида `lang="ts" ` и `script setup`.
Я бы ещё отметил сложности с типизацией родного стора, но эту проблему решает Pinia. К слову, она сейчас входит в стандартную поставку инструментов, предоставляемых заменой vue-cli. Я про:
npm init vue@latestОтмечается, что Pinia полностью соответствует видению Evan You касательно Vuex 5. Так что если переезд и потребуется, то проблем особых быть не должно.
А в остальном - да, с новым синтаксисом описания шаблонов писать на TypeScript стало очень приятно.
Кстати, в новой версии Webstorm 2022.1 работу с типами во Vue 3 и Pinia тоже здорово подтянули. Сейчас особых проблем нет.
Примечательно, что все сторонние либы для $mol прекрасно дружат с TS с самого его рождения, так как пишутся именно на TS. А для Реакта и его либ тайпинги пишут какие-то левые люди да и то с запозданием. И для многих либ даже с тайпингами не заморачиваются.
Svelte + SvelteKit.
Спасибо за статью. Пишу проекты на разных фреймворках, и каждый раз возвращение к проектам на React сопровождается головной болью.
При этом, если рассматривать рост техдолга, то Vue 3 все же догоняет React. Да, стили и сторы все еще организованы лучше чем React, но вот для разработки компонентов создатели Vue оставили слишком много места. Их теперь можно писать и на JSX, и с render функциями, и темплейты, и с options API, и с setup-функцией, и со script setup.
Видимо, начинающему разработчику будет сложно в любом случае, хоть с React, хоть с Vue.
Когда то так могли написать про ангуляр в сравнении с реактом)
«React» словно тренер по плаванию, бросает вас в воду и говорит плыви, ему не важно будете вы правильно дышать или махать руками, ему важно чтобы вы плыли.
«React» приложения можно сделать быстрым, производительным и легко тестируемым. К сожалению, достичь этого крайне тяжело ...
... Это связанно с тем, что начинающим разработчикам сложно понять, как правильно писать приложения на «React».
... мы получаем возможность писать очень плохой рабочий код.
Даже немного страшно стало.
vue намного лаконичней . Фронтенд - пишешь как фронтент . А не копаешься в js для составления разметки.
Это все ерудна. Надо нормально писать и документировать код с увежением к тому, кто будет читать и модифицировать код после тебя. фреймворк неважен.
щас бы назвать реакт фреймворком
Я бы выделил ещё один аспект применения того или другого инструмента: кто именно будет взаимодействовать с системой для ввода/вывода информации. Если система предназначена для работы оператора (внутренний пользователь в организации), задача которого ввод информации и принятие решения по результатам обработки, то здесь нет необходимости применять сложные инструменты, как react. А если система предназначена для внешнего пользователя, задача которого получить быстро и удобно нужную ему информацию, и далее минимальным взаимодействием с интерфейсом ввода/вывода, выполнить действие, то здесь лучше использовать такие инструменты как react.
Как показывает практика: оператор системы работает качественнее, если инструмент этому способствует.
В b2c/b2b тоже нет играет роль уже решение проблем, интерфейс - это уже про конкурентное преимущество. Нет большого смысла делать хороший интерфейс, если конкурентов нет и не будет. Зачем вкладываться?
react/vue/etc - это про сложные или потенциально сложные интерфейсы, вне зависимости от их назначения, которое нужно развивать и поддерживать. Когда большую долю сложности забирает на себя библиотека/фреймворк :)
Спорное суждение, по моему мнению, качественная работа оператора не зависит от инструмента, а напротив, зависит от сценариев обработки вводимых данных. Т.е. данная проблема лежит не в плоскости инструментария, а в плоскости дизайна и анализа сценариев работы оператора, а следовательно, с помощью какого инструмента, оператор вводит данные, react это или vue, или jsf, или jquery, или dojo, или excel, не имеет значение ;)
Только вот огромные формы со сложными зависимостями полей друг от друга сильно проще делать как раз на Vue/React, а не на чистом js или js + dotJs, например. И дело не в визуальной части а именно в функциональной.
Я на своем проекте оценил насколько проще, быстрее и функциональнее стали формы после переделывания их на React. Это не повод, конечно, специально переделывать то что есть если оно работает и не требует серьезных изменений. Но новый функционал можно довольно эффективно внедрять в уже существующий проект. Если правильно настроить webpack.
Да, nps и его webpack это особая история. Главное, как не ломай его, он будет работать)). Но нет смысла это все разворачивать для оператора, если есть простые инструменты, типа jsf и тому подобное. Где как раз сложные формы неплохо работают в связки полей и т.п.. в том числе где нет необходимости поддержания реактивого вывода данных с использование асинхронного взаимодействия пользовательских интерфейсов с системой обработки данных.
Где как раз сложные формы неплохо работают в связки полей и т.п.. в том числе где нет необходимости поддержания реактивого вывода данных с использование асинхронного взаимодействия пользовательских интерфейсов с системой обработки данных.
В моем понимании это как раз и есть сложные формы =) Т.е. форма в которой, например создается родитель и дети, например - опрос с вариантами ответов. Знаю, вариант довольно простой, но бывают даже такие с кучей настроек как у опроса так и у вариантов ответов. Я рассматривал LiveWire как альтернативу, но решил что React меньше будет сервер грузить, да и опыт у меня с ним уже был неплохой. Вообще мне понравилось когда сервер - это просто API, а фронт как бы отдельно от этого всего. Есть в этом что-то правильное.
Раскройте тему поподробнее, а то действительно как будто введение получилось. И неплохо бы еще увидеть сравнение инструментов из их экосистем, например, vuex vs redux.
Писал про что-то похожее, примерно теми же словами 5 лет назад - https://blog.cloudboost.io/why-react-is-better-than-vue-js-and-when-9545049652d8
Главная проблема была в том что я думал - «я знаю React» и могу его использовать. Могу честно признать - был не прав.
Чтобы сделать хоть какие-то выводы, нужно собрать, обработать и прожить опыт джуна/мидла/синьора на Vue/React. Поруководить командой Vue/React. Позаниматься онбордингом. И много ещё другого. И в самом конце понять, что Vue/React - это разные инструменты, которые решают прблемы по-разному и выбор зависит от проекта, команды, сроков, компании и т. д. Объективные вопросы (производительность, вес, и т. д.) примерно на одном уровне.
Без этого стремится к объективности - просто глупо.
А вот субъективности уже предостаточно.
Моё субъективное по вопросу - С Vue работал (и работаю) гораздо больше, чем с React. Типичный вид компонента React для меня переусложнён излишней писаниной.
Справедливости ради отмечу, что бывал я на проектах, где использовали Vue... как бы выразиться... не зная его и не понимая. Классический проект-тех_долг. Там не осталось ни одного компонента, который можно было бы не трогать при рефакторинге. такое впечатление, что изначально его отдали на аутсорс, там сделали заготовку и дальше свои джуны (штук 5 поочереди) пилили как могли... Лучше уж реализовали на JQ, честное слово...
Во-первых, скорее всего скопированный код из интернета будет идентичен всему проекту
С подключением в 2022 год, во Vue уже давно есть Options API, есть Composition API и есть script setup, поэтому нет.
Вы если уж беретесь сравнивать в 2022 году Vue и React, то стоило бы для начала углубиться в тему и изучить оба инструмента, посмотреть, как сейчас на них пишут и что в них нового.
Итого: поверхностное сравнение уровня 2016 года на 2 минуты чтения. Абсолютно ни о чем.
Поддерживаю ))) "В отличие от моделей работы над более масштабными системами, которыми являются React и Angular, поддержкой Vue, опенсорсного проекта, занимается один разработчик, Эван Ю. Проект финансируется по схеме краудсорсинга. Эван говорит, что это — одна из особенностей проекта, которая отличает его от остальных, так как это вдохновляет на написание кода более высокого качества, чем обычно, и на создание отличной документации."
Примечательно, что поддержкой $mol тоже занимается один человек, а проект финансируется по схеме краудсорсинга, но это выдаётся уже не за достоинство, а за недостаток.
С чего это приложения на react быстрее чем на vue? Может наоборот?
Vue или React? Кратко о возможном росте технического долга и что лучше для начинающих