Кому легше знайти роботу: Vue чи React розробнику?

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Нещодавно Full-Stack розробник із Люксембургу Марк Бейкс (англ. Marc Backes) поділився у X думкою, що знайти роботу Vue-розробнику набагато важче, тоді як фахівці з React мають значно більше можливостей.

Цікаво, що згідно з нашою зарплатною аналітикою, Vue-розробники отримують помітно нижчу зарплату, ніж їхні колеги, які працюють із React. Чи може це бути однією з причин, чому Vue поступово втрачає позиції на ринку?

Спільното, а ви як вважаєте: це справді глобальний тренд чи лише особистий досвід Марка? Чи справді Vue-розробникам значно складніше знайти роботу, ніж тим, хто працює з React?

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

З профіля Марка бачу, що він full-stack на Node.js. Він вариться у бульбашці front-end розробників, де React дійсно популярніший, але на кількох проектах підряд бачив як мінімум адмінку з «локшини» Laravel-Vue, де Vue банально простіше інтегрувати з бекендом в одному проекті через те, як реєстрація компонентів та реактивність влаштовані. Тому багато залежить від стеку на вашому проекті.

Особистий досвід пошуку роботи в 2024-му говорить протилежне.
Так, вакансій на React’i більше, але і конкуренція скажена. Двічі вийшло працевлаштуватись (і зараз працюю) на Vue.

Розробнику, що тримається подалі від фронт-енду.

Існує статистика. gist.github.com/...​3a185629299ec234d2314e190
Відповідно до неї 39.5% проектів використовують React, а Vue.js 15.4%
Тобто статистично шанси що буде вакансія в проекті де React в двічи вища за Vue. Інша справа яка при цьому буде пропозиція. Тобто на Vue умовно можуть брати і дуніорів, а на Ract може бути 30 людей на вакансію сініора. Це вже треба дивитись статистику по сайтах роботи. Скажімо DOU jobs.dou.ua/...​ancies/?search=Junior Vue — 3 вакансії, Junior React — 10 jobs.dou.ua/...​cies/?search=Junior React
Senior React jobs.dou.ua/...​cies/?search=Senior React 49 вакансій
Senior Vue jobs.dou.ua/...​ancies/?search=Senior Vue 13 вакансій.
Тобто із комерціної точки зору, React значно кращі вибір. Кокретно зараз для джуніора React переспективи кращі на 70%, для сініора 73.5% кращі перспективи.

думаю проще найти работу, если ориентироваться на то, чтобы стать лучше как инженер, а не мастером фреймворка

как и легче найти работу тем, кто вместо того чтобы надувать щеки, мол смотрите, у меня тут темплейт, а у них — jsx, в принципе задумывается какие проблемы фронтендные фреймворки решают и почему делают вещи именно так, а не иначе

Не правильно думаеш в наших реалиях, так фриланс и аутсорс рынок не рабоатет. Человек нужен здесь и сейчас делать конкретную работу, посему должен как можно лучше знать фреймверк, комерческий опыт в конкретно запрашиваемом тех стеке и фремворке будут смотреть HR в CV и задавать вопросы на собеседовании. Почему — потому что нанимающий менеджер всегда стремится к одному, минимизации своих рисков.
В Долине и Америке вообще — там да, там другой подход. Там по аглоритмам гоняют и т.д.
А по существу по факту работы, т.е. когда уже испытательный срок и т.д. там в целом множетсов фаторов, но в основном как руководитель себе выберает в приоритеты. Одному одно важно, другому свсем другое.

если работу я нахожу легко, могу ли я считать что думаю все-таки правильно?

в этом, собственно и разница — выглядит будто ты формируешь свое мнение статистикой, тем что ты где-то слышал или где-то прочитал

мое формируется практикой

Покажи мне циферки, легко не показатель совсем. Что одному легко — другому очень трудно.
Неявная математика — легко, трудно и т.д. на самом деле тоже формализуется все приводится у усредненнім диапазонам (когда-то курсовой проект писал на єту тему).
Легко нахожу работу, например в єтом месяце біло 20 предожений от рекрутеров и 5 от хедхантеров про рефералам рекомендациям и т.д. Біло 6 собеседовний и три офера, на которіе ушло 6 дней. Вібрал лучштй офер с предложением на новий кроект без легаси, компенсация по верху ринка, хорошие условия типа оборудование, мед стаховка, уютній офис в удобном месте и т.д.
Вот — то что я би назвал «нахожу легко». Сечас рінок очень далек от такого легко. Сечас до 700 человек на одно ремоутное место может біть по некоторім позициям, и при том зарплата в $300 в месяц как будто нулевіе годі.

нечего сказать по делу — решил придушить статистикой :(

мне достаточно того, что у меня были оферы на проекты с технологиями, с которыми у меня не было опыта (ШОК)

ты в свою очередь можешь себе считать процентики — почему бы и нет

Полностью согласен за нынешние реалии в IT рынке. Нет смысла обьяснять людям которые равняют всё в жизни по собственному опыту. Так же как все считают кто не в теме, что раз программист значит зарплата 5000$+.
Мне с трудом всё даётся, поэтому смысла нет вступать в спор с удачливыми сеньорами диванными экспертами.

видимо это оказалась слишком сложная идея, что фокус на основах дает возможность подаваться на вакансии на нескольких фреймворках вместо одного, более того — повышает шансы (собственно делает поиск легче) даже в рамках того самого одного фреймворка (ВОТ ТАК ШОК)

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

для чистоты эксперимента также прикрепляю свое число удачи из квадрата пифагора — 7. это очень низкий показатель — можно сказать удача практически отсутствует

Мне нравится ваш подход. Он кажется мне правильным. А можете поделиться опытом, где эти основы взять? В какую сторону смотреть, кроме просто конкретных технологий, фреймворков?

я бы советовал глянуть solid/grasp — у Шемсединова неплохие лекции
не нужно заучивать — просто уловить идею

мельком глянуть чистые функции — просто уловить идею, что чистые функции удобные и предсказуемые

потом глянуть паттерны — опять же, не надо заучивать, важнее обратить внимание как используют принципы из #1 — как пытаются уменьшить коуплинг, как разделяют логику по сущностям, прикинуть какие были бы проблемы если бы паттерн не использовался

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

мне кажется, что важно именно стараться уметь оценивать решения — для этого как минимум нужно знать критерии оценивания (вся эта теория выше). дальше уже нужно стараться чаще их пытаться применять чтобы развивать этот навык

потом любой фронтендный фреймворк — обратить внимание на то, для чего в принципе он дает средства.
фронтендные фреймворки они в первую очередь о компонентах. вне зависимости от фреймворка эти компоненты должны будут уметь:
— рисовать разметку
— принимать параметры
— вызывать коллбеки от родителей когда что-то происходит
— реагировать на то, когда они отрисовываются/удаляются параметры
— реагировать когда меняются их параметры
— не ломаться от внешнего цсса
— считывать какие-то элементы из dom

ну и при знакомстве с фреймворком обращать внимание на примеры — опять они будут пытаться реализовывать идеи из #1, где-то будут использовать паттерны. какие-то предложат сразу решения чтобы работать с разными слоями, какие-то будут просто о компонентах.
важно также обращать внимание на секции в документации, где рассказывается об идеях — чем вообще руководствовались авторы, как они видят использование фреймворка.

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

Вау! Спасибо большое за такой развернутый ответ

мое формируется практикой

треба зважити на те, що це твоя особиста практика і не факт, що щось з твого досвіду буде корисно топік-стартеру. В плані, що він так же, як ти зможе пройти.
А статистика йому може допомогти краще.

З іншого боку немає жодного сенсу не погоджуватися з таким твоїм виразом

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

Я не веб розробник, але в мене був сайт на конструкторі який потрібно було переводити на якийсь адекватний рушій.

З одним розробником спробували Svelte, але невдало. З моєї точки зору всі ці модні непопулярні фреймворки краще не тягнути в проект. Відсутність бібліотек та документації до них робить дуже багато ризиків.

Потім я вирішив зануритись в тему і розібратися що саме нормальне з популярної трійки vue/react/angular. Дивився синтаксис, читав статті, дивився ролики від різних крутих веб розробників.

Дійшов до висновку що Angular самий гірший з них з технічної точки зору та і популярність також падає,

А з пари React/Vue вибрати було нелегко. Але базуючись на моєму розумінні програмування як такого мені здалось що Vue кращий. Хоча це звісно не експертна думка.

Тому мені дивно читати про зниження популярності саме Vue. Можливо дійсно проблема в відсутності великої компанії за ним?

мені здалось що Vue кращий

Принаймні він так би мови більш цільний, бо реакт це ж збірник ліб.
Мені теж В’ю здається кращим, зрозумілішим, легшим, швидшим, зручнішим.

п.с. прям оду написав )

Начинать учить сейчас Vue/React для получения работы безсмысленно. Учить чтобы поиграться можно при наличие свободного времени

Не фронтенд и не QA )

Там много желающих. В ембедид мало платят.

Куда лучше?

Times are tough :)

Причому незалежно від фреймворку.

Disclaimer: я мейнтейнер @vue/test-utils (тож маю доступ до чату кор-тіми вʼю, хоч не належу до неї), однак 80% проєктів на консалтингу в мене на реакті

Я бачу майже однакове зниження кількості вакансій на «розробку» у Вʼю та Реакт принайні серед моїх клієнтів та їх середовища (тут дуже важко описати «хто саме вони», це конкретні домени, конкретні країни і т.д. — наприклад в Азії ЧУВ що ситуація інша)

З цікавого — в одного з моїх клієнтів прям позиція «мені треба менше розробників на Вʼю бо підтримувати його легше» — не починаючи холівар чи це дійсно так — цікаво, як сильна сторона фреймворку бʼє по ринку

80% проєктів — абсолютно все одно чи то буде Вʼю, чи то буде Реакт, чи то Ангуляр. Скрізь будь свої переваги та недоліки — у Вʼю отримаємо швидкий старт, але за рахунок «простоти» входу і (як наслідок) нижчого середнього рівня розробки — якість коду буде, на жаль, менша і дізнаєтеся ви про це пізніше (бо фреймворк завдяки fine-grained reactivity приховує неефективні рішення там, де в реакті ви б побачили б 100500 ререндерів)
Візьмете Реакт — отримаєте, перш за все, ПОТУЖНИЙ AI (хоча Клод 3.7 досі збивається на старий роутер в нексті, навіть якщо йому регулярно нагадувати про app router), однак отримаєте купу сумнівних технологій (на кшталт RSC) які вважаються ключовими в сучасному реакті і просуваються активно
Візьмете Ангуляр — і отримаєте кривавий ентерпрайз на початку (хоча з цим стає краще, привіт сигнали, стенд-елон компоненти і так далі) і меншу (поки що) за двох конкурентів швидкість розробки

А взагалі я сьогодні вже цитував в твітері Traversy Media — x.com/...​tatus/1895047099684921558 — він жаліється що все «швидко змінюється» — якщо фокусуватися на підходах а не на фреймворку, то при переході з Nuxt на Next наприклад (спеціально взяв фреймворк до фреймворку, а не наприклад Angular та React) виявиться що вчити з концепцій всього нічого

за рахунок «простоти» входу і (як наслідок) нижчого середнього рівня розробки — якість коду буде, на жаль, менша

А це ж можна виправляти?

Да тут все просто, во первых можно сказать что все фреймворки плюс минус одинаковые, скажу как человек который писал на 4х за карьеру

Когда-то появился Вью, он был прикольный и молодежный и на нем стартонули проекты, дальше там появилось куча проблем, плюс проблемы с поиском новых фронтов, которых надо переобучать. Вроде апргрейды с 1 на 2 или/и с 2 на 3 — были без обратной соместимости. Плюс за тем же Реактом стоит ФБ, за Ангуляром Гугл, а за Вью кто? Алибаба и чел мейтейнер? Понятно, что клиенту легче продать реакт.

Вью занял нишу, пояивлись проекты, и теперь их дальше мейтейнят, новые нет смысла начинать на вью, ибо зачем?
— если хочется чего-то нового — есть миниум 5 фреймворков новых
— хочешь быстро нанять хорошую команду, которая сразу будет работать — тут у вью тоже проблемы

Реакт — далеко не ок, особенно куда он движется, но опять же тут все решает количество спецов на рынке, которых легко найти и поменять, которых не надо переобучать.

Единсвтенное, что не понятно, почему у Вью меньше зп, ибо по идеи он как Руби, на который тяжело найти спецов и поэтому там зп — топ. Наверное потому что берут дешевых реакт разрабов и переучивают

Как насчёт перспектив Svelte, Solid.js, Qwik? Что более перспективнее? я вообще не фронтендщик, но надо переквалифицироваться на full-stack чтобы найти работу в наше время.
Meta как Google могут в любой момент перейти на другую технологию и сделать свою deprecated, тем более этот цукердемон там массово сокращает персонал и нацелен на Metaverse. Не хочу рисковать с напрасным изучением React.

Svelte, Solid.js, Qwik

— это и есть риск, это технологии для пет проектов, которые вдруг выстрелят — будет прикольно уже иметь в них опыт

Meta как Google

— уже сидят на это всем по 10+ лет, зачем им что-то дюпрекейтить)

реакт — это и есть стабильность, если это можно так назвать)

Вивчіть HTML та CSS в решті решт. ;)

Мені як бекенд розробнику, якого періодично заносить на фронт більш імпонує vue. Більш логічна, має більш чітку та зрозумілу структуру. Я не розумію JSX, а структуровані компоненти і з темплейтом, методами, геттерами та хуками це цілком зрозуміло. А якщо копнути ще в глиб у магію redux то це взагалі якась ***ана магія. Я не люблю магію, а люблю чіткі, лаконічні і зрозумілі без поглиблення у пізнання цієї магії структури
React на мою думку занадто переоцінений монстр. Але я розумію що історично має ширше комьюніті та різноманітніші бібліотеки.
Тому на теперешній роботі Go + трохи react із ненавистю до цих тасок. Та хочу знайти роботу якщо вимагають фуллстек то go +vue
Якщо хочете чистий фронт то однозначно react. Із чистим vue там робити нічого.

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

Я знаю як він працює
Но я людина консервативна
Я хочу що там де темплейт був ВИКЛЮЧНО темплейт і нічого більше
Там де написано — methods — виключно методи компонента
Там де написано — created — той код що працює тільки коли компонент створено.
Чітка структура дає менше можливостей наговнокодити

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

И почему, если ты шаришь как работает jsx, он для тебя магия, а в том же темплейте есть v-for, v-if и тп — это уже не магия)

А так да, в реакте можно писать как хочешь, и ок команды пишут правила, где и что должно быть. Где бизнес логика и тп. В том же реакте можно писать чисто jsx — а всю бизнес логику хранить в «сторах» разных либ — и вот это тоже считай, что темлейт и логика отдельно.

конечно если правил нет — там полная жесть — и это минус реакта в какому-то смысле

Да и почему просто не юзать Ангуляр, который явно более строгий чем Вью

ну короче, тут тема то того что реакт — вариативный и кому-то это нравится, а кому-то нет

но основная тема топана, это все-таки поиск работы и зп

Для мене вью класний тим, що це надбудова над HTML. Типу
<button>Login</button>
це нативна кнопка, а
<button v-click="login">Login</button>
це вже вью

а jsx, з його className, з його id={}, ітд — це вже не HTML, це нова мова, яка намагається сидіти на двох стільцях — і на html бути хоч трохи схожа, і якісь свої приколи додати. На виході — полурак-полух*й

Так це головний коник був коли вони ще запускались Типу ти взагалі можеш просто підключити vue до html і юзати в голому html і ванільному js як лібу а не як фреймворк
А взагалі фреймворки стали вже дофіга складними і перелізли навіть на рендерінг на беку що думаєш — а нахріна це все?

А взагалі фреймворки стали вже дофіга складними і перелізли навіть на рендерінг на беку що думаєш — а нахріна це все?

Бо сучасні програмісти гадки не мають, що все, що вони роблять, вже давно було реалізовано та успішно забуто. Вони принципово не хочуть подивитися на проблему ретроспективно та передбачити наслідки своїх дій. А можливо перейняти якийсь інший досвід. Тому всі пішли шляхом «Будь-яку проблему можна вирішити шляхом створення додаткового рівня абстракцій. Окрім проблеми занадто великої кількості рівнів абстракцій».

Рішення лежить у всіх під носом, але всі принципово його ігнорують. Треба просто перестати починати розробку з JS, почати думати з точки зору UI/UX, а не даних та BE. Зараз дуже популярно починати роботу над проектом з API. А потім страждати, обкладаючися неймовірною кількістю проміжних рішень щоб зробити прості речі. Про підтримку я вже мовчу, її вартість зазвичай перевищує вартість початкової розробки.

Ви робите систему для людей? Тоді почніть з дизайну, компонентів, UX, а вже решту приведіть до цього. JS мусить обслуговувати, а не диктувати. Які там дані на сервері, нікого не мусить турбувати. Вони всі мусять бути приведені до того формату, що потрібно UI. Несподівано зʼясується через час, що на розбудову нових фіч треба витрачати мінімально часу.

Я спостерігаю постійне ходіння по колу та жрання одного й того самого кактуса. Покоління розробників змінюється, але не їхні проблеми. :D

І тільки php шники тихенько ржуть у сторонці. Трамп почне третю світову, пів світу вимре, а вони витруть радіаційний попіл з нутів і будуть продовжувати їбашити сайти так як хоче замовник
А vue доречі із бібліотечним підходом могла піти по шляху більш сучасної заміни jQuery а не ще одного фреймворку. Я знаю проекти які саме так vue і юзають

І це, скоріше за все, правильне рішення.

Якщо хочете чистий фронт то однозначно react. Із чистим vue там робити нічого.

Який-такий «чистий фронт»? Що мається на увазі? Я реакту взагалі не знаю, то ж якось незрозуміло, сорі

Ну типу реакт намагається у функціональне програмування, а в фп всі функції без сайд ефектів і їх називають чистими) може каламбур?)

Мене більше цікавить, а для чого аж так розділяти тих фронтендів? Невже ці бібліотеки/фреймворки настільки складні, що їх неможливо знати одночасно, або за 1-2-3 міс вивчити на проекті? Я тут на днях перечитав доки по Реакту, не скажу, що я різко став фронтендером але спокійно можу працювати на проєкті. Думаю те саме і з В’ю.
Чому раптом JS, CSS, HTML + браузерне АРІ стало недостатньо для фронтів?

2025 год и вопрос про

недостатньо для фронтів

^^

наверное потому что не все фронты это лендинг пейджи, а есть еще большие апки, в которых ты все равно приходишь к тому, что надо писать свои рендеринг фрейморки, и зачем это делать когда уже есть готовые

Думаю и буду — это разные вещи, у меня вот пол проекта фулстаки, которые тоже «думают», а потом сидишь фиксишь за ними кучу багов и ревью простых тасок расстягивается на пару недель.

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

Схоже, у вас не із фреймворками проблема, а із процесами

Це те саме, що взяти наприклад джуніора, фул-стека та кор розробника мови програмування. Зробити чергову ту-ду апку усі вони зможуть дуже швидко. Чи можна сказати що він вивчив мову програмування? Чому тоді щоб стати кор розробником потрібні роки. Чому нормальну архітектуру може закласти далеко не кожен Senior? Незважаючи на роки досвіду? Тому що складні системи — вони складні. Плюс в підходи і мову можна заглиблюватись і заглиблюватись.

Схоже не всі зрозуміли, що я мав на увазі. По кожному із фронтенд фреймвоків, інженеру який знайомий на достатньому рівні із JS, CSS, HTML, достатньо тижня щоб почати щось писати, місяця-двох для повного занурення в фреймворк і екосистему. Якби я собі в команду шукав ФЕ я б не фокусувався на конкретному фреймворку. Вміє в React, зможе і у Vue і навпаки.

Ну якщо між бекендами може бути велика різниця — асинхрониий, не асинхронний, DDD, clean architechture, фреймворк з різним ступенем кастомізації. А ще — бізнес логіка. От і виходить, що планували, що людина буде виконувати вже з понеділка бойові задачі, а їй треба ще місяць-два занурюватись у специфіку конкретного фреймворку, не кажучи про бізнес-логіку.

Ну якщо між бекендами може бути велика різниця — асинхрониий, не асинхронний, DDD, clean architechture, фреймворк з різним ступенем кастомізації

Ага! Тобто треба окремо шукати Senior Async Engineer, Middle Not Async Engineer, Junior DDD Engineer (щоб оці всі асинки значили? :Р). І ще кожен вид розділити на ступені кастомізації і окремо розробники бізнес логіки. Фух!
А якщо серйозно, то на будь який проект зі складністю більше ніж Туду-ліст, буде потрібен якийсь час на онбоардінг. З понеділка не вийде виконувати бойові задачі.

Майже так. Ви не чули про доменну експертизу? Ну тобто — якщо я хочу хороший банк — я буду шукати спеціаліста, який вже з’їв усі едж кейси, і то бажано, по 10 разів. Якщо я хочу хорошого реакторщика — я його буду шукати. Який сенс брати vue розробника, який не зможе накидати перевірену часом реакт-архітектуру, ще й бажано в моєму домені. Тільки якщо такого знайти не вдалось. Як свідчить досвід — різниця між гелоу ворд і продакшн реаді — колосальна.

Змішались коні і люди. Так, якщо вам треба доменного експерта, ви його шукатимете. Але до чого тут фреймворки?
Також, якщо вам треба Тех лід для швидкого старту проєкту ви його теж шукатимете, і так, тут може грати роль експертиза в певному стекові.
Але скажіть чесно. Як часто ви стартуєте проєкти і накидуєте «перевірену часом реакт-архітектуру» (WAT?).
Я не стверджую, що знання фреймворків не потрібне, я лише переконаний що це не основне в наймі. Я б відніс би ці знання до «Nice to have/Will be a plus»

Якби я собі в команду шукав ФЕ я б не фокусувався на конкретному фреймворку

Я завжди шукаю інженерів, а не типографістів. ;)

Повезло Вашим кандидатам.
Вижу только работадателей в ЕС которые ищут фрейворкщиков чтобы в каждом фреймворке был опыт 3+. Можно знать как это устроенно под капотом, но когда на livecoding нужно за ограниченное время шустро и правильно решить задачи с использованием фреймворка, инженерные знания не спасают.
+ требуют исходный код проектов своих показать с использованием современных фреймворков.

Знання фрейморка не дорівнює знанням технологій, стандартів. Я багато бачу прикладів, коли замість того, щоб зробити один CSS клас, люди городять город, бо вони гадки не мають, що браузер давно це все вміє з коробки.

Бачив багато разів, як замість простого та елегантного рішення, коли треба просто замінити одну умову в задачі, щоб все зрослося як треба, фрейморкивісти бивалися з реалізацією та потім героїчно багато місяців баги ловили.

Тому типографістів не беру, сильно великі потім накладні витрати.

Я впевнений, що за місяць вам не вдасться навіть половини освоїти з RxJS на рівні правильного декларативного підходу з урахуванням принципів реактивного програмування. А це тільки одна бібліотека.

А за два? Три? Чи треба RxJS університет закінчувати?
У мене Шварцмюлерівський курс Ангуляра куплений вже як років 5. Там 55 годин відео + хай самостійної роботи трохи. По дві-три години в день, місяць-два і вже можеш спокійно працювати Ангуляр-девом. Так всіх нюансів реактивного програмування це не дасть. Але їх і не потрібно на 90% всіх проєктів.
res.cloudinary.com/...​/ftbcmyo7vmxmdl4b7hau.png

Збрехав. Купив його 8 років тому.

действительно: это же надо глянуть целый курс на еггхеде, глянуть целых две статьи — building your own rxjs и building your own rxjs operators и поклацать операторы в rxmarbles

главное не забыть добавить сюда курс по надуванию щек — ведь не каждому дано стать реактивным программистом

на рівні правильного декларативного підходу

вот это кстати интересно. rx-ом можно как-то пользоваться императивно? может быть есть примеры?

да
Маск взагалі писав пайпал свій на плюсах щоб на сервері порт слухало і хтмл віддавало

І що тут поганого?))

Макс не писав PayPal взагалі ніколи. Реально програмував він над попереднім стартапом Zip2, який вони з братом успішно продали Compaq. Наступний стартап — X.com, був якраз онлайн банком який був поглинений компанією Confinity яку організували Макс Левчін и Пітер Тіль, останній по сьогодні один із головних опонентів і Маска разом із Марком Цукербергом. Обидва демократи і головне спонсори демократів. Цукерберг бізнес партнер Тіля з часів виходу The Facebook на загальний ринок.
Маска швидко виставили з керівної посади майже одразу, офіційно на волні технологічної конкуренції. Confinity працював на Unix/Linux — а X.com на Windows і програмні коди були взаємно не сумісні, увесь софт і напрацювання X.com пішли в корзину. Ідея самого Маска полягала в забезпеченні онлайн оплати в інтернет аукціонах, тобто був зроблений один з перших педимент провайдерів. Сам стартап було продано корпорації Ebay, за півтора мільярди долларів в 2002 році. Ілон Маск отримав 180 мільйонів доларів з угоди, Пітер Тіль 55 мільйонів. Макс Левчин СТО (між іншим народився в Києві і жив до 16 років) — отримав 34 мільйони.

Зазвичай я просто ігнорую пости від місцевого AI, але тут прям пригоріло.

Тіль трампіст/ізоляціоніст, борцун з загниваючим воук заходом і головний спонсор Венса, той навіть працював на нього певний час. Це буквально місцева пара Коломойський — Зеленський розлива 2018 року.

Спробуйте написати фронт для якоїсь ROZETKA на Angular, а потім на Next з урахуванням всіх приколів SSR, SEO, SSG, кастомних роутів, перфоменса, мікросервісів, CI/CD і тд.

Ви здивуєтесь, що це не просто лендос наверстати.

Ну от знову. Я десь згадував про лендоси? Я наголошував на знанні технологій, а не окремих фреймворків.

в розетке не пользуются апи гейтвеем/backend for frontend? почему так?

с какими проблемами в перфомансе столкнулись? пришлось кешировать ссг странички и добавить инфинит сколл на комментарии?

в розетке ко всем членам команды такие требования: либо ты можешь сделать розетку сам начиная с ci/cd, либо не подходишь? зачем тогда остальная команда, зачем тогда техлид? казалось бы, процесс наоборот должен строиться так, чтобы понижать порог входа

Як розробник на vue, кожного разу хочу чи то плакати чи то блювати коли дивлюсь на реакт. JSX — це фантазія хворого наркомана під барбітуратами

Так не дивись. :)

Vue нічим не краще. Angular туди ж ;)
Тому що підхід «JS first» є помилковим з самого початку. Це переускладнення з поганими наслідками.

Яка пропозиція — які альтернативи ? Задача проста — максимально товстий клієнт, мінімально навантажений тонкий сервер, щоби хендлити велику кількість клієнтів.
Можливості Web застосунку мають будти максимально приближені до повноцінного десктопу, щоби реалізовувати різноманітні адмінки, соціальні сіті типу Facebook, застосунки типу Gmail, Figma, Postman і т.п. Коротше усе те — що раніше зробили за допомогою Java Applets та Flash.
Насправді відносна альтернатива є — це WebASM та різноманітні Canvas-и та WebGL.
Щодо різних інших проектів, де треба індексація лендінги і т.п. — так реально не найкращій підіхід, через що вже дішло до повного відкату в Server Side Rendering і т.п. — що бред і нивілює сам сенс таких фреймверків із Virtual DOM.

так может в большинстве случаев и не надо того толстого клиента?
с учетом того, что наплыв пользователей не линеен, то сервера тоже не всегда нагружены. и там можно намного правильней реализовать «one source of truth» чем вот то траханье на клиенте.
да, есть некоторое количество приложений, где толстый клиент маст хев. Но их мизер реально.
и SSR и PHP (внезапно) то, что доктор прописал.

Такие феймрверки сделаны под чьи требования ? Правильно Big Tech — Meta и Google. А скажем у Amazon подобного нет, видимо другие требования.
А индустрия вообще говоря идёт за техническими решениями лидеров, технологии развиваются скорее маркетингово чем исходя из требований конкретного проекта. Конкретному проекту — надо найти человека на рынке со знанием фреймверка уже, чтобы он мог как можно быстрее и дешевле включится в работу, ибо так меньше риски и больше прибыль. Соответственно под это и готовят людей образовательные учреждения и т.д.

Задача проста — максимально товстий клієнт, мінімально навантажений тонкий сервер, щоби хендлити велику кількість клієнтів.

Ти рішення задачею називаєш. Хто сказав, що саме така архітекура найефективніша?

Насправді відносна альтернатива є — це WebASM та різноманітні Canvas-и та WebGL.

Це не альтернатива, це постріл в ногу. Ніхто не буде на них робити жодних інтерфейсів дійсно складних систем допоки хтось не напише фреймворк, який задовольнить мінімум 80% клієнтів. А це нереально дорого. Це аналогічно як вкладати в розробку браузера років так 15.

вже дішло до повного відкату в Server Side Rendering

О, панове винайшли PHP? Це просто неймовірне за тупістю шоу, яке я спостерігаю останні років 10 з посмішкою та певним подивом.

Як розробник на Vue, можу сказати що це правда. Вакансій не багато, ще й тепер зарплати занижують сильно.

Vue.js колись називали «вбивцею» React через сотні тисяч зірок на GitHub, вважаючи його чимось середнім між AngularJS і React. Однак насправді Vue зайняв свою нішу, подібно до Angular, і не виправдав тих високих очікувань, які були покладені на нього, щоб повністю зламати React-спільноту. Тому він став більш нішивим фреймворком, і ринок на це реагує.

Комьюніті вирішує.

Типова ситуація «хто перший встав, того і тапки». Люди просто не вкладаються в інші фреймворки, а зі всіх сторін «та бери реакт і забий». Логічно що так і є, але сумно.

Комьюніті вирішує.

А до чого тут комьюніті. Vue зроблений чуваком який пішов з Google, коли він працював у Google — як кращій Angular.JS. Google — зробив Angular на заміну Angular.JS і він зараз на другій позиції. А React — продукт Meta.
Підтримка корпорації яка виводе продукт на ринок вирішує, на практиці. В сучасному світі 75% процентів доданої вартості, це маркетинг. Особливо працює в ІТ.

Google — зробив Angular на заміну Angular.JS і він зараз на другій позиції.

вот тут уже не точно. я видел разные источники, но довольно много в последнее время попадается, что Vue все-таки смог обойти Ангуляр. Да, по сложности проектов их не сравнить, но по условному «числу скачиваний» (других метрик все-равно нет) Ангуляр скорее всего ан третьем месте.

Якась у вас вибірка не репрезентативна.

Підписатись на коментарі