Комментарии

Ну на пальцах основные отличия для новичка, который не знает, что «потрогать» первым.

1. Vue не требует вообще никакой инфраструктуры, его можно воткнуть в существующий сайт с вордпрессом на шаред php хостинге, особенно если вы в курсе, что ослик сдох. Для реакта и ангуляра надо где-то поднимать ноду, npm/yarn, webpack/parcel, а потом два дня разбираться, чем babel/core отличается от babel/core и почему на первом create-app не заводится. Ну то есть какой-нибудь бандлер потом, перед выпуском в прод, настроить придётся, но это будет потом, и для vue достаточно будет parcel с нулевой конфигурацией.

2. Vue не требует изучать новые языки, работая на чистом HTML и JS. Гипотетически реакт тоже так может, но по факту 99% примеров и готовых react компонентов используют JSX и ~50% — Typescript. Это всё заметно увеличивает порог входа.

3. Vue не настаивает на функциональной парадигме, его вполне устраивает ООП. Если вас пугают выражения типа

let b = f => g => h => x => f(g(x))(h(x))

в реакте будет сложновато. При этом, если вам нравятся god object-ы на 100500 полей и методов, которые отвечают за всё, включая состояния кнопок, то vuex (аналог redux/flux/...) вполне себе есть, берите и пользуйтесь.

4. Следствие п. 3 — двусторонние биндинги. Они просто работают. Вам не надо, как в 90-ых, писать handleChange/handleKeyUp/… для каждого html элемента, а потом городить UNSAFE_ComponentWillRecieveProps и делать прочие приседания в скафандре. В результате наличию этой и других мелких сладких плюшек (например, стандартного роутера из коробки) кода на vue получается стабильно раза в 2-3 меньше, чем в таком же проекте на реакте, а пишется он быстрее.

При всём при этом реакт, конечно, дико распиарен.

Что, React Hooks прям отменяет и lifecycle, и JSX, и HOC? Создатели сами пишут, что внедрять рекомендуется неспешно, основная парадигма программирования на React не меняется. И, естественно, нужно поддерживать тонны старого кода на классах. Кроме того, можно продолжать писать новый код на тех же классах.
На свалку, ага, facepalmjpg

Спасибо, полезная информация, пригодиться многим

Это очень большая тема. И в одном абзаце не напишешь пожалуй. Там, как и везде наверное, огромное количество нюансов, ограничений и прочих тонкостей.
Если очень обобщённо и упрощённо, то платить нужно за хранение данных и за чтение данных (во время запросов). На самом деле там ещё куча всего, за что нужно платить (и куча всего бесплатно), но эти две вещи на поверхности.
cloud.google.com/bigquery/pricing
Если говорить о хранении данных (тупо, глупо и в лоб), то
cloud.google.com/bigquery/pricing
и
cloud.google.com/storage/pricing
И, взяв первый же вариант (US Multi Region), то хранение будет стоить (в месяц)
BigQuery — $0.020 per GB
Standard Storage — $0.026 per GB
То есть BigQuery как бы дешевле…
Запросы — $5.00 per TB прочитанных данных

У меня получались запросы, которые стоили по несколько десятков долларов, но это редкость.

На тему скорости — если интерактивный запрос выполняется дольше 30 — 40 секунд (независимо от объёма данных), то я бы остановил его и стал бы думать, а что я собственно делаю (не так).

Что касается того, что можно покупать заранее (в BigQuery) — то это слоты (для запросов) — cloud.google.com/bigquery/docs/slots — но это для больших потребителей (сам никогда не использовал, но наверное кто-то использует).

И ещё нужно помнить про ограничения — cloud.google.com/bigquery/quotas

Если у вас более конкретные вопросы — напишите в googlecloud-community.slack #bigquery channel. Я ежедневно его просматриваю, и, если могу помочь, то отвечаю.

Изучая React вы теоретически(!) быстрее найдёте себе работу (больше спрос) чем изучая Vue.

А вообще и тот и другой в этом году резко «меняют шкуру»:

React -> React 16.8 with Hooks — уже не React, а что-то другое.
Vue -> Vue 3 — уже не Vue, а что-то другое.

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

Всё что писали про React и Vue в прошлом году, можно выкинуть на свалку истории. На свалку.

Я не понимаю какая разница между react.js и vue, пожалуйста, поясните ;)

А можно поподробней, как работает BigQuery? Я думаю всем будет полезно. Я точно знаю про Redshift, Azure DW и Snowflake.

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

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

Мои личные наблюдения подтверждают тренд на снижение доли React на рынке. В первую очередь за счет увеличения доли Vue, к тому же растут и другие фреймворки вроде Aurelia, Svelte. Существенного изменения ждать не стоит, скорее всего React продолжит, постепенно замедляясь, терять долю рынка.

О библиотеке или фреймворке, который обойдёт React в будущем

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

О Redux и других инструментах управления состоянием

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

О целесообразности изучения

Ради востребованности на рынке труда, безусловно, эту библиотеку учить стоит. Шансы на то, что в интересующей вас компании будут применять React, очень высоки. По моему мнению, React чаще выбирают в компаниях, где он уже используется в качестве основного инструмента в одном или нескольких проектах.

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

Сложно вообще представить специалиста, который освоил какие-то альтернативные фреймворки, при этом не применив ни разу что-нибудь из большой тройки — React, Vue, Angular. Определенно можно сказать, что знание React делает любое резюме весомее, даже если работать с React не предполагается вовсе.

Ещё хочу акцентировать внимание на усилении тенденции использования TypeScript. Она есть как на фронтенде, так и на бэкенде, чему лично я рад. Таким образом, стоит уделить внимание изучению фреймворков именно в связке с TypeScript.

Об эксперте

Алексей Резвов, организатор разработки программного обеспечения.
Ключевые тезисы

— React — это JavaScript-библиотека для работы с пользовательскими интерфейсами;

— к важным особенностям библиотеки относятся декларативность, универсальность, компонентный подход, использование Virtual DOM и JSX;

— в 2020 году React — самый популярный инструмент среди библиотек и фреймворков для работы с UI;

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

— эксперты рекомендуют изучать React, так как знание этой библиотеки повышает шансы на успешное трудоустройство.

По-моему мнению, в IT, а тем более в такой динамичной развивающейся его части, как технологии для веба и всё, что с ним связано, «обозримым будущим» можно называть период времени максимум в 2-3 года. React дает действительно неплохое видение, как нужно делать интерфейсы и веб в целом (с учетом всей той экосистемы, которая образовалась вокруг него). И то, что он предлагает, в достаточной степени гибко, производительно и совместимо с браузерами. Да есть интересные вещи типа Polymer Project, да и много чего ещё, что может давать какие-то плюсы, например, в производительность, но это требует каких-то дополнительных усилий, чтобы понять, как это правильно готовить. Такой же крутой экосистемы, как у React, именно с точки зрения порога вхождения, гибкости, производительности на горизонте «обозримого будущего» пока не видно, по-моему.

О библиотеке или фреймворке, который обойдёт React в будущем

Честно говоря, для меня это не является провокационным вопросом :-) Сами создатели React считают его библиотекой, и я склонен с ними согласиться. Да, React с легкостью можно назвать MV-фреймворком, который берет на себя довольно большую часть ответственности за архитектуру вашего приложения. Но степень этого охвата в то же время не такая всеобъемлющая, как у Angular, Vue, Ext — они в своей официальной документации дают вам полное видение того, как должна выглядеть ваша архитектура, и вполне обоснованно называют себя фреймворками. С другой стороны, вокруг React образовалась существенная экосистема, которая в большинстве случаев говорит вам, как нужно делать React-приложение. И вот если взять React + экосистема, то можно увидеть уже кучку фреймворков. Вы сами можете сделать еще один фреймворк на React, если вам это нужно.

О новых возможностях

Мне нравится их идея сделать в React 17 механизм, позволяющий из коробки рендерить некие заглушки в момент асинхронной загрузки данных.

О Redux и других инструментах управления состоянием

По-моему, этих конкурентов уже и так полно, вы не находите? Да, все они — некая вариация на тему Flux(читай MVC)-подобных архитектур c однонаправленным потоком данных, но их действительно много. Redux, MobX, Cerebral, xstate, и я думаю, это даже не половина всего, что есть в современной экосистеме. Да, Redux наиболее популярен, наверное, но совсем не значит, что он общепринят и безальтернативен на данный момент. Если же имеется в виду что-то принципиально новое, то я даже не знаю, скорее всего ничего лучше вариаций на тему MVC всё-равно не придумаешь, особенно если в качестве View у тебя «реакт головного мозга».

О целесообразности изучения

Однозначно стоит. Но нужно понимать, что самое важное — не знать все тонкости React, а понимать принципы, на которых он построен, что лежит в основе его архитектуры. Также не стоит забывать про базовые знания касательно JS и веба в целом. То есть если вы научились в хуки на React, но не понимаете, зачем в JS нужны прототипы, что такое замыкание, не представляете same origin policy и для чего оно нужно — это повод задуматься и изучить вопрос.

Такой же крутой экосистемы, как сейчас у DST, на горизонте не видно, за этим будущее

Да, думаю, что в какой-то момент ситуация может измениться, но это будет не очень быстро, как с jQuery. Когда появилась эта библиотека, она заняла большую нишу. Но ведь jQuery еще используют где-то, также будет и с React.

О библиотеке или фреймворке, который обойдёт React в будущем

Пока, наверное, реальной альтернативы не существует. Я думаю, что если бы уже существовала такая библиотека или фреймворк, то она бы также быстро и много стала использоваться, как React.

О новых возможностях

Жду от React стабильности и совместимости.

О Redux и других инструментах управления состоянием

Ответила бы тут также, как и на второй вопрос. Очень много проектов написано с использованием связки React/Redux, поэтому пока Redux вне конкуренции.

О целесообразности изучения

Да, безусловно стоит, так как много компаний с современным стеком технологий используют React.

Сейчас слишком много компаний с современным стеком технологий используют Node, поэтому эту библиотеку стоит учить

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

Чем опытнее разработчик, тем менее важной для него становится конкретная библиотека, фреймворк и даже язык программирования

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

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

В ближайшее время чего-то подобного не предвидится, но, безусловно, нельзя полностью исключать возможность внезапного появления принципиально новой технологии, которая повлечет за собой очередной эволюционный виток или даже техническую революцию. Например, всё чаще и чаще подход SPA подвергается критике, звучат призывы к возврату бизнес-логики на сервер с сохранением отзывчивости, присущей SPA-приложениям. Одним из наиболее интересных и стабильных решений подобного плана является Phoenix Framework, который, тем не менее, пока не стал популярным и остается довольно нишевым продуктом.

Второй фактор — маркетинговый. Facebook может прекратить существенную поддержку и продвижение React, параллельно с этим другая компания начнет вкладывать огромные суммы денег в другую библиотеку или фреймворк, и это может привести к значительному изменению статистики. Но даже такие изменения вряд ли произойдут быстро.

О библиотеке или фреймворке, который обойдёт React в будущем

Оба варианта возможны. Но мне кажется, что второй вариант более правдоподобен. При этом нельзя исключать, что библиотекой, которая обойдет React в будущем, может стать условный React 2. Так или иначе, прогнозы по этому поводу делать очень сложно, но хотелось бы верить, что решение, которое станет популярнее React, будет чем-то принципиально новым, иначе это просто очередная смена шила на мыло.

О новых возможностях

На мой взгляд, вместо добавления чего-то нового команде React стоит сфокусироваться на доработке и стабилизации старого. Переработка методов жизненного цикла и добавление хуков привели к тому, что сейчас есть несколько разных способов делать похожие вещи, при этом best practices на этот счет в сообществе пока еще не сложились. Соответственно, мы имеем два параллельных мира: мир разработчиков, предпочитающих классы, где все еще есть неоднозначная замена componentWillReceiveProps на getDerivedStateFromProps, и мир разработчиков, предпочитающих функциональные компоненты и хуки, имеющие перегруженный и местами запутанный API.

Добавление каких-то нововведений в библиотеку может фрагментировать сообщество ещё сильнее и повысить порог входа в React. Это сложно считать движением в правильном направлении, поэтому, как мне кажется, стоит сначала довести до ума всё, что еще не доведено, а уже потом только думать над добавлением чего-то нового.

О Redux и других инструментах управления состоянием

Такие решения уже появились. Например, те же MobX и Effector являются отличными production-ready альтернативами. Конечно, нельзя сказать, что они настолько же популярны, как Redux, и это, возможно, является сейчас их основным недостатком, из которого уже вытекают более конкретные. Например, сообщество этих библиотек значительно меньше, чем у Redux, из-за чего может быть сложнее найти готовые решения или ответы на возникшие вопросы. Банальное, но существенное преимущество Redux — огромное количество статей и гайдов по связке React + Redux.

Безусловно, есть много опытных разработчиков, для которых отсутствие готовых решений и малочисленное сообщество не являются минусом, так как они вполне могут сами написать необходимые библиотеки или дописать недостающую этим state-менеджерам функциональность, а также найти ответ на свой вопрос, прочитав исходники этих библиотек. Но не стоит забывать, что есть очень много разработчиков, которые просто не видят смысла переходить на другие библиотеки, понимая, что те недостатки, которые, безусловно, есть в Redux, не перевешивают для них его достоинств. Так или иначе монополии Redux уже не существует, разные команды по разным причинам выбирают разные решения, и выбор у них, безусловно, есть.

О целесообразности изучения

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

Опытный разработчик, который много лет работал с Vue, довольно быстро может переключиться на проект, где используется React. Это возможно, потому что он понимает, на каких принципах базируются данные библиотеки, видит похожие абстракции и пересечение концепций этих библиотек. Поэтому на самом деле, хоть React и вполне хорош для старта карьеры, выбор любой другой современной библиотеки или фреймворка будет не менее хорошим.

В обозримом будущем, кажется, крупных изменений не стоит ждать. Во-первых, из-за инертности — очень уж много написано на React и вокруг него. Во-вторых, инструмент объективно удобный.

О библиотеке или фреймворке, который обойдёт React в будущем

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

О новых возможностях

Лично мне хочется дальнейшего развития create-react-app как инструмента для быстрого старта. Разработчики пошли по пути кастомных темплейтов вместо конфигурирования через cli при создании приложения. Это, конечно, уже лучше, чем создавать и поддерживать собственные бойлерплейты, но всё ещё недостаточно для того, чтобы считать CRA промышленным стандартом.

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

О Redux и других инструментах управления состоянием

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

За последние годы вокруг Redux возникла целая экосистема библиотек с мидлварами и хэлперами для удобной работы, а квинтэссенцией стала библиотека redux-toolkit. Из существующих альтернатив лично мне нравится библиотека mobx-state-tree, построенная поверх Mobx. И если для небольших приложений эта библиотека выглядит избыточной, то на проектах с большим количеством логики в тандеме с хуками она прекрасна.

О целесообразности изучения

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

В обозримом по меркам фронтент-разработки будущем доля React существенно не упадёт. На нём уже написано слишком много, глобально бизнесу не выгодно его депопуляризация.

О библиотеке или фреймворке, который обойдёт React в будущем

Думаю, такого инструмента ещё нет. Но это мне как идеалисту хочется чего-то принципиально нового. Опыт Vue показывает, что может быть иначе.

О новых возможностях

Я знаю много приложений, которые реально станут быстрее при включении конкурентного режима. Хочется, чтобы это случилось быстрее, эта задача не такая сложная, как может показаться. Также хочется, чтобы в React появилась более явная система реактивности, хуки мне не нравятся.

О Redux и других инструментах управления состоянием

Это сложный вопрос, но серебряной пули, думаю, не будет. Redux Toolkit может ещё продлить жизнь Redux, но, честно говоря, это выглядит как серьезный костыль, и часть очень важных проблем он все ещё не решает. Reatom выглядит логичной эволюцией и я, конечно, надеюсь, что он отнимет часть рынка. При этом интересными выглядят и альтернативные подходы вроде graphQL-driven или grammarly/focal, думаю, они тоже будут развиваться.

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

Возможно будет ещё оптимизирован в плане DX и обезмагивания MobX, и его будут ждать новые высоты — автор все ещё активно им занимается.

XState мне кажется очень нишевым, как Rx и Effector.

В общем, подходов много, каждому своё, при этом я смогу точно сказать, что нам ещё предстоит встретить что-то новое и, возможно, нас ждёт более выраженная дисперсия, а не появление стандарта такой же популярности, как сейчас/раньше Redux.

О целесообразности изучения

Точно стоит, индустрия в лице бизнеса ещё долго будет нуждаться в разработчиках на React.

На мой взгляд, ситуация будет меняться, но несущественно, если говорить о цифрах. State of JavaScript наглядно показывает, что лидеры на рынке фреймворков постоянно меняются, и в любой момент могут появиться конкурентоспособные новички.

История успеха Svelte говорит о том, что в ближайшем будущем может появиться что-то новое, что заберет часть аудитории у React. Скорее всего, React еще долгое время будет если не на первом месте, то определенно в топе фреймворков.

Стоит отметить также, что существующие фреймворки различаются концептуально и используются для разных типов проектов. Поэтому популярность можно предсказывать, основываясь также на развитии технологий и подходов. На фоне развития мобильной разработки наличие React Native также играет в пользу фреймворка.

О библиотеке или фреймворке, который обойдёт React в будущем

Во фронтенде популярность и востребованность крайне переменчива. Возможно, какой-то из существующих фреймворков в будущем станет популярнее React, а спустя год выйдет новый, который обойдет обоих, но тоже ненадолго. При этом разница в популярности может быть минимальной.

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

О новых возможностях

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

Учитывая эти факторы, уже завтра может появиться что-то новое, что позволит улучшить проект. Но, честно говоря, это даже пугает. Ведь мне тут же захочется отрефакторить код и использовать возможности, а на это требуется время, которого у фронтенд-разработчика обычно не хватает.

О Redux и других инструментах управления состоянием

Новые инструменты появятся. Я бы даже сказала, что уже сейчас они есть. С одной стороны, появление хуков заставило взглянуть на управление состоянием под другим углом. С другой стороны, клиентские реализации для GraphQL (например, Apollo) позволяют некоторым проектам обходиться без Redux. Также не стоит недооценивать MobX, который развивается и в будущем может предложить неплохую альтернативу.

О целесообразности изучения

Вот этот вопрос мне кажется более провокационным. Потому что нужно начинать изучение не с фреймворка, тем более, такого специфического, как React, а с чистого JavaScript. А потом уже можно попробовать разные фреймворки, чтобы понимать, как они устроены, и различать подходы к разработке проектов.

Как раз недавно на митапе MinskJS, который я помогаю организовывать, соорганизатор митапов MinskCSS и MinskJS Саша Шинкевич рассказывала доклад на тему «Как перестать выбирать фреймворки и начать жить». Мне кажется, это хорошая иллюстрация современного фронтенда. Выбирайте фреймворк не ради фреймворка, а для достижения хорошего результата.