Comments 37
Из действительно значимого в разработке angular vs react:
1) dependecy injection: из коробки, в том числе, между раутами.
2) SSR: universal в гораздо более продакшен реди, чем какой-нибудь next.
3) Стейт менеджмент можно довольно элегантно заворачивать через какой-нибудь RxJS: выглядит декларативно, легко описывать.
4) Реакт же - меньше бойлерплейта, проще формировать и отслеживать перерисовку элементов на изменения стейта. Как результат, стандартный формошлёпинг в разы быстрее и комфортнее.
Иными словами, react - большая либа, где сложные решения надо "решать", но и джунов легче интегрировать. Ангуляр - фреймворк, который требует сетапа, но имеет ответы на большинство вопросов из коробки. По производительности крайне близко. Так что дело вкуса. Странно сталкивать их лбами.
А чем SSR: universal лучше чем то что предлагает next?
Next.js и Universal даже не в одной весовой категории:
Next.js: npm – 3.63 млн скачиваний в неделю, Github – 97.5 тысяч звезд;
Universal: npm – 0.132 млн скачиваний, Github – 3.9 тысячи.
А как же $mol?
/sarcazm
Сравнение станет гораздо интереснее с указанием уровня зарплат и количеством вакансий.
Я начал учить Vue, но корп-рынку почему-то нужен React. Так что скорость добавления 1000 строк - это хорошо, но надо исходить из реальных потребностей рынка.
react/vue очень и очень похожи. Знаешь один - быстро вольешься в другой.
Рынок: начиная с некоторого уровня разработчик может сам выбирать. Зарплаты сопоставимы.
Я начал учить Vue, но корп-рынку почему-то нужен React.
Рынку нужен React наверняка потому, что большие компании имеют давние продукты построенные на нем и переписывать все допустим на Vue очень дорого и бессмысленно.
Сам предпочитаю Vue, но React появился раньше и конечно устоялся. Проекты на Vue это в частности перезапуски старых продуктов с нуля на новый лад, стартапы, квизы, spa, crm
React также поддерживает TypeScript, но, к счастью для менее опытных разработчиков, его использование есть опциональным.
Ну typescript похоже уже давно не опциональный, а обязательный на рынке.
Скорее рекомендованный. Ровно в настоящее время веду проект, причем довольно свежий, где фронт написан на чистом JS, без типизации
А зачем он так написал? Я не вижу ни одной причины не юзать ts в 2022: ошибки отлаживать легче, да и многие исключаются, что увеличивает скорость выхода продукта в прод. А если команда не знает ts, то по времени выйдет то же самое, что и на js. А если мы пользуемся чудесами openapi, тому нас и контакты с бэком будут заранее описаны.
В общем, выбор js для нового проекта это уже минимум года два признак низкой квалификации ведущего разраба/архитектура/etc.
Изначально предполагалось, что проект будет сравнительно небольшой. Не лендинг, но - несколько форм, 2 сокета и десяток гет запросов (немного утрирую, но суть такова). И ТС тогда воспринимался как забивание гвоздей микроскопом и удорожание проекта.
В итоге вместо дорогого TS разработчика проект начал дешевый разработчик, с тайпскриптом не знакомый. Ну и постепенно проект вырос, человекочасов в него натекущий момент вложено в ~40 раз больше, чем наальная оценка. И это еще не конец.
Переезд на TS запланирован, но под это пока что нет ресурсов.
Да, вы только подтвердили: низкая квалификация принимающего решения. Ложные суждения на каждом шагу. Начиная от микроскопа, заканчивая «ts-дорого».
Согласен с недальновидностью, но по поводу микросокопа позволю себе не согласиться - если делать типизацию правильно, не отдавая большую часть вопросов на откуп автоопределенным типам и не используя any/неочевидные преобразования, ТС начинает работать на проектах хотя бы среднего размера, до этого он за счет накладных расходов на поддержание системы типов выходит примерно в 0, или даже небольшой минус.
Это (по ощущениям) справедливо примерно до момента когда на проекте не более чем 1 разработчик на 1 обособленный модуль (например, панель администратора) и вся структура АПИ для общения с беком умешается на паре экранов сваггера.
Расходы на типы ts сопоставимы с расходами на отладку багов в js.
А если проект не на выброс (а таких я никогда не видел, если честно), то любой жизненный цикл больше месяца уже требует самодокументации от кода. А это либо jsdoc, либо ts.
В рамках того проекта о котором говорю, предполагалось, что мы быстро и дешево создаем МВП, начинаем его продвигать, параллельно неспеша и вдумчиво собирая версию 2.0
Концепция поменялась, но изначально предполагалось в чистом виде "писать на выброс"
Во первых, вы сравниваете теплое с мягким. Если вы годовалый Джун, то да, расходы сравнимы. Но расходы на отладку багов js имеют накопительный эффект - спустя какое то время человек обучается и багов больше не лепит. А на ts писать тонны мусора придется всегда.
Во вторых, если сравнить мягкое с мягким - отладка багов ts гораздо более трудоемкий и долгий процесс. Чтоб поправить баги в тс, вам все равно придется читать js, который он нагенерил, а читать эту портянку собранного из кусков копипасты кода с невменяемыми названиями переменых.. ну как по мне, лучше работать сразу с кодом. Получается короче, чище, производительнее, а если нормально владеть языком - то ещё и быстрее.
Я, будучи бэк-енд программистом, написал корпоративный веб ui для бэка на vue. Сотня экранов со всякими сложностями - с таблицами, фильтрами, диалоговыми окнами, выпадающими списками, куда можно добавить элемент, сложные карточки редактирования с вкладками и вложенными объектами и коллекциями, json поля которые можно редактировать через диалоговое окно. И мне нигде не понадобилось хранить стейт с использованием vuex. Что я делаю не так? Для чего он вообще нужен? Для кэширования данных с сервера?
https://vuex.vuejs.org/#what-is-a-state-management-pattern
в самом низу страницы про это написано.
"Flux libraries are like glasses: you’ll know when you need them"
Выражу опасное мнение: Vuex — спасательный круг для плохо спроектированных приложений.
>И мне нигде не понадобилось хранить стейт с использованием vuex
А вообще идею вы поняли зачем оно создавалось? Или не смотрели? Это не в укор, ибо я сам идею Redux и пр. надстроек не понимаю, думаю какой-то смысл есть, но пока не сталкивался.
Нет, я прочитал, но так и не понял. Типа существуют какие-то абстрактные сложные приложения, где нужно что-то передавать между компонентами. И вот там нужен стейт. Интересно 100 экранов - это достаточно сложное приложение, что я обязан использовать vuex или пока еще нет.
Так-то стейт у меня есть - в самом компоненте-экране. И я передаю его в дочерний компонент-экран. Например, в диалоговое окно при редактировании на клиенте. Так же у меня есть другой механизм - я передаю идентификатор сущности в дочерний компонент-экран и он заново подгружает сущность из бэка.
Передача стейта и ID - либо через route.parameters и либо через параметры компонента.
Меня просто стало смущать, что мне он пока так и не понадобился, а в каждой второй вакансии это требуют и видимо задают каверзные вопросы на собеседовании.
Мое предположение, для чего его можно было бы использовать - это хранить отражение БД на клиенте. Ну т.е. представьте ORM на яваскрипте, по типу Hibernate или EF. Ну и периодически сливать обновления на бэк и подгружать с него. Но это автоматически означает бизнес-логику на клиенте. Для сайта-визитки может и заработает. Но для корпоративных приложений - неа.
Не, Redux для этото не подходит. Тут нужно хранение данных в conflict-free форме типа CROWD.
Интересно 100 экранов - это достаточно сложное приложение
Это точно большое приложение. Но большое приложение - не обязательно сложное, если каждый экран это форма или табличка.
Сложное приложение - это скорее всего типа какие-нибудь - фигма, веб-игра, онлайн-эксель\онлайн-фотошоп и т.д.
Это всё старые пердуны (те самые, которые еще MVC придумали) с чего-то решили, что бизнес-логику лучше хранить отдельно от представления. Но вы не обращайте внимания, продолжайте размазывать данные равномерно по всему приложению, как масло по хлебу. Так удобнее ?
Ниасилил, пояснительную бригаду пжлста)
PS: Просто для меня, как бэкендщика со стажем, бизнес логика - это в том числе пакетно забирать по 30-50 тыс документов в час, парсить и проверять их по определенным правилам и потом разбрасывать по другим сервисам тоже по бизнес-правилам через какую-нибудь кафку или раббит или даже Oracle Service Bus. А не только скрыть кнопку или покрасить строку в таблице на фронте в красный цвет, в зависимоти от значения колонки "статус".
Так отображается ли кнопка или какого цвета строка в таблице – это не бизнес-логика, это стейт представления. Он и не должен храниться в сторе, он должен лежать в компоненте.
А: Я не понимаю, зачем нужен Redux.
Б: Это Model, как Model в MVC.
А: Понял.
Вот так я представлял разговор с "бэкендщиком со стажем".
а вы один все это писали? один поддерживать будете?
Привет, ChatGPT!
А как же knockout.js))
React vs Vue vs Angular