React быстро. Веб-приложения на React, JSX, Redux и GraphQL
Как решить проблемы front-end-разработчиков и сделать их жизнь более счастливой? Нужно всего лишь познакомиться с возможностями React! Только так вы сможете быстро выйти на новый уровень и получить не только моральное, но и материальное удовлетворение от веб-разработки.
Успешные пользовательские интерфейсы должны быть визуально интересными, быстрыми и гибкими. React ускоряет тяжелые веб-приложения, улучшая поток данных между компонентами UI. Сайты начинают эффективно и плавно обновлять визуальные элементы, сводя к минимуму время на перезагрузку страниц.
Перед вами труд, над которым на протяжении полутора лет работало более дюжины человек. Тщательно отобранные примеры и подробные комментарии позволяют разработчикам перейти на React быстро, чтобы затем эффективно создавать веб-приложения, используя всю мощь JavaScript.
«Эта книга — лучший способ разобраться в React.js». Джон Сонмез, автора книги «Путь программиста»
«Азат — один из самых авторитетных источников в области программирования. Эта книга выходит за рамки начального уровня и глубоко погружает в основы и архитектуру React». Эрик Хэнчетт, автор книги «Ember.js Cookbook»
«React быстро — универсальный источник информации для читателя, который желает освоить React с его экосистемой инструментов, концепций и библиотек». Питер Купер, редактор «JavaScript Weekly»
«Эта книга — отличный ресурс для изучения React. Четко и по делу. Я буду пользоваться ей в работе над своим следующим приложением».
Натан Бэйли, полностековый разработчик, SpringboardAuto.com
Здесь можно скачать книгу «React быстро. Веб-приложения на React, JSX, Redux и GraphQL» для ознакомления (бесплатный PDF фрагмент от правообладателя), почитать онлайн или купить полную электронную версию в форматах FB2, PDF, EPUB, TXT, FB3, MOBI.
React быстро, Веб-приложения на React, JSX, Redux и GraphQL, Мардан А., 2019
К сожалению, на данный момент у нас невозможно бесплатно скачать полный вариант книги.
Но вы можете попробовать скачать полный вариант, купив у наших партнеров электронную книгу здесь, если она у них есть наличии в данный момент.
Также можно купить бумажную версию книги здесь.
React быстро, Веб-приложения на React, JSX, Redux и GraphQL, Мардан А., 2019.
Как решить проблемы front-end-разработчиков и сделать их жизнь более счастливой? Нужно всего лишь познакомиться с возможностями React! Только так вы сможете быстро выйти на новый уровень и получить не только моральное, но и материальное удовлетворение от веб-разработки.
Успешные пользовательские интерфейсы должны быть визуально интересными, быстрыми и гибкими. React ускоряет тяжелые веб-приложения, улучшая поток данных между компонентами UI. Сайты начинают эффективно и плавно обновлять визуальные элементы, сводя к минимуму время на перезагрузку страниц.
Перед вами труд, над которым на протяжении полутора лет работали более дюжины человек. Тщательно отобранные примеры и подробные комментарии позволяют разработчикам перейти на React быстро, чтобы затем эффективно создавать веб-приложения, используя всю мощь JavaScript.
Знакомство с React.
Когда я только начинал работать в области веб-разработки в начале 2000 года, все, что мне было нужно — HTML и серверный язык (такой, как Perl или РНР). Старые добрые времена, когда для обычной отладки кода клиентской части (frontend) приходилось набивать его вызовами alert()! Время шло, интернет-технологии развивались, и сложность построения сайтов радикально возросла. Сайты превратились в веб-приложения со сложными интерфейсами, бизнес-логикой и уровнями данных, которые требовали постоянных изменений и обновлений — часто в реальном времени.
Для решения проблем с построением сложных пользовательских интерфейсов (UI, User Interface) было написано много библиотек шаблонов JavaScript. Однако все они требовали, чтобы разработчики придерживались классического «разделения труда» — то есть разделения стилевого оформления (CSS), данных и структуры (HTML) и динамических взаимодействий (JavaScript) — и не удовлетворяли современных потребностей. (Помните термин DHTML?)
Оглавление.
Вступление.
Предисловие.
Благодарности.
О книге.
Об авторе.
Об обложке.
ЧАСТЬ I. ОСНОВЫ REACT.
Глава 1. Знакомство с React.
Глава 2. Первые шаги с React.
Глава 3. Знакомство с JSX.
Глава 4. Состояния и их роль в интерактивной природе React.
Глава 5. События жизненного цикла компонентов React.
Глава 6. Обработка событий в React.
Глава 7. Работа с формами в React.
Глава 8. Масштабируемость компонентов React.
Глава 9. Компонент меню.
Глава 10. Компонент Tooltip.
Глава 11. Компонент Timer.
ЧАСТЬ 2. АРХИТЕКТУРА REACT.
Глава 12. Система сборки Webpack.
Глава 13. Маршрутизация в React.
Глава 14. Работа с данными с использованием Redux.
Глава 15. Работа с данными в GraphQL.
Глава 16. Модульное тестирование кода React c Jest.
Глава 17. Использование React с Node и универсальный JavaScript.
Глава 18. Проект: создание книжного магазина с React Router.
Глава 19. Проект: проверка паролей с Jest.
Глава 20. Проект: реализация автозаполнения с Jest, Express и MongoDB.
ПРИЛОЖЕНИЯ.
Приложение А. Установка приложений.
Приложение Б. Шпаргалки по React.
Приложение В. Краткая сводка Express.js.
Приложение Г. Шпаргалка по MongoDB и Mongoose.
Приложение Д. ES6 для успеха.
По кнопкам выше и ниже «Купить бумажную книгу» и по ссылке «Купить» можно купить эту книгу с доставкой по всей России и похожие книги по самой лучшей цене в бумажном виде на сайтах официальных интернет магазинов Лабиринт, Озон, Буквоед, Читай-город, Литрес, My-shop, Book24, Books.ru.
По кнопке «Найти похожие материалы на других сайтах» можно найти похожие материалы на других сайтах.
On the buttons above and below you can buy the book in official online stores Labirint, Ozon and others. Also you can search related and similar materials on other sites.
React быстро, Веб-приложения на React, JSX, Redux и GraphQL, Мардан А., 2019
По кнопке выше «Купить бумажную книгу» можно купить эту книгу с доставкой по всей России и похожие книги по самой лучшей цене в бумажном виде на сайтах официальных интернет магазинов Лабиринт, Озон, Буквоед, Читай-город, Литрес, My-shop, Book24, Books.ru.
По кнопке «Найти похожие материалы на других сайтах» можно искать похожие материалы на других сайтах.
On the buttons above you can buy the book in official online stores Labirint, Ozon and others. Also you can search related and similar materials on other sites.
React быстро, Веб-приложения на React, JSX, Redux и GraphQL, Мардан А., 2019.
Как решить проблемы front-end-разработчиков и сделать их жизнь более счастливой? Нужно всего лишь познакомиться с возможностями React! Только так вы сможете быстро выйти на новый уровень и получить не только моральное, но и материальное удовлетворение от веб-разработки.
Успешные пользовательские интерфейсы должны быть визуально интересными, быстрыми и гибкими. React ускоряет тяжелые веб-приложения, улучшая поток данных между компонентами UI. Сайты начинают эффективно и плавно обновлять визуальные элементы, сводя к минимуму время на перезагрузку страниц.
Перед вами труд, над которым на протяжении полутора лет работали более дюжины человек. Тщательно отобранные примеры и подробные комментарии позволяют разработчикам перейти на React быстро, чтобы затем эффективно создавать веб-приложения, используя всю мощь JavaScript.
Знакомство с React.
Когда я только начинал работать в области веб-разработки в начале 2000 года, все, что мне было нужно — HTML и серверный язык (такой, как Perl или РНР). Старые добрые времена, когда для обычной отладки кода клиентской части (frontend) приходилось набивать его вызовами alert()! Время шло, интернет-технологии развивались, и сложность построения сайтов радикально возросла. Сайты превратились в веб-приложения со сложными интерфейсами, бизнес-логикой и уровнями данных, которые требовали постоянных изменений и обновлений — часто в реальном времени.
Для решения проблем с построением сложных пользовательских интерфейсов (UI, User Interface) было написано много библиотек шаблонов JavaScript. Однако все они требовали, чтобы разработчики придерживались классического «разделения труда» — то есть разделения стилевого оформления (CSS), данных и структуры (HTML) и динамических взаимодействий (JavaScript) — и не удовлетворяли современных потребностей. (Помните термин DHTML?)
React медленный, React быстрый: оптимизация React-приложения на практике
Всем привет! Хочу поделиться своим переводом статьи React is Slow, React is Fast: Optimizing React Apps in Practice автора François Zaninotto. Надеюсь, это кому-то будет полезным.
React может быть медленным. Я хочу сказать, что любое React приложение среднего размера может оказаться медленным. Но прежде, чем искать ему замену, вы должны знать, что и любое среднее приложение на Angular или Ember может также оказаться медленным.
Хорошая новость в том, что если вы действительно заботитесь о производительности, то сделать React приложение очень быстрым довольно легко. Об этом — далее в статье.
Измерение производительности React
Что я подразумеваю под «медленным»? Позвольте привести пример:
Я работаю над одним open-source проектом, который называется admin-on-rest, использующий material-ui и Redux для предоставления графического интерфейса (GUI) админ-панели для любого API. В этом приложении есть страница, отображающая список записей в виде таблицы. Когда пользователь изменяет порядок сортировки, или переходит на следующую страницу, или фильтрует вывод, интерфейс не так отзывчив, как хотелось бы.
На следующем анимированном скринкасте, замедленном в 5 раз, показано, как происходит обновление:
После обновления данных, я снова кликаю на кнопку записи, чтобы остановить её. Chrome отобразит жёлтый график под меткой «User Timing».
Если вы никогда не видели этого графика, он может показаться пугающим, но, на самом деле, им очень просто пользоваться. Этот график показывает время работы каждого из ваших компонентов. Он не показывает время внутренних компонентов React (вы всё равно не можете их оптимизировать), таким образом он позволяет вам сфокусироваться на оптимизации своего собственного кода.
Временная шкала выводит этапы записи работы приложения и позволяет приблизить тот момент, когда я кликнул на заголовке таблицы:
Иначе говоря, приложение занимает 500 мс, чтобы визуально отобразить ответную реакцию на клик. Полсекунды это значительный показатель — эксперты по UI говорят, что пользователи считают реакцию приложения мгновенной, только когда она меньше 100 мс. Реакция приложения более 100 мс — вот то, что я называю «медленным».
Почему ты обновился?
На графике выше можно увидеть много крошечных ямок. Это плохой знак, так как это означает, что множество компонентов перерисовались. На графике видно, что обновление занимает больше всего времени. Почему приложение обновило всю таблицу с данными прежде, чем получило новые данные? Давайте разбираться.
Попытки понять причины перерисовки часто подразумевают добавление console.log() в render() функцию. Для функциональных компонентов вы можете использовать следующий компонент высшего порядка (HOC):
Совет: стоит также отметить why-did-you-update — ещё один инструмент для эффективности React. Этот npm пакет заставляет React выводить в консоль предупреждения всякий раз, когда компонент перерисовывается с теми же props. Предупреждаю: вывод в консоли довольно подробный и он не работает с функциональными компонентами.
Обычно, React становится медленным не из-за одного медленного компонента (что будет отображено на графике, как одна большая яма). В большинстве же случаев, React становится медленным из-за бесполезной перерисовки множества компонентов.
Вы возможно читали, что VirtualDOM в React очень быстрый. Это правда, но в приложении среднего размера полная перерисовка может легко содержать в себе отрисовку сотни компонентов. Даже самый быстрый шаблонизатор VirtualDOM не может сделать это меньше, чем за 16 ms.
Оптимизация через разбиение на компоненты
Вот метод render() компонента :
Чтобы избежать бесполезной перерисовки тела таблицы, для начала я должен *извлечь* его:
Я создал новый компонент путём извлечения логики из тела таблицы:
Само по себе, извлечение тела таблицы никак не оказывает влияния на производительность, но оно открывает возможности для оптимизации. Большие компоненты общего назначения трудно оптимизировать. С маленькими же компонентами, отвечающими только за что-то одно, справиться легче.
shouldComponentUpdate
Поэтому компонент должен выглядеть так:
Совет: Вместо того, чтобы прописывать shouldComponentUpdate() вручную, я мог бы наследовать этот класс от PureComponent вместо Component. PureComponent будет сравнивать все props используя строгое сравнение (===) и перерисовывать, только если props изменились. Но я знаю, что resource и children не могут измениться в данном контексте, поэтому мне не нужно их сравнивать.
Благодаря этой оптимизации перерисовка после клика на заголовке таблицы пропускает её содержимое и все 231 компонент. Это уменьшило время обновления с 500 мс до 60 мс. Это чистое повышение производительности более чем на 400 мс!
Совет: Не обманывайтесь шириной графика, он приближен даже больше, чем на предыдущем графике. Это определённо лучше!
Метод shouldComponentUpdate удалил множество ямок на графике и сократил общее время отрисовки. Я могу использовать этот же способ, чтобы избежать ещё больших перерисовок (например, не перерисовывать боковую панель, кнопки действий, не изменившиеся заголовки таблицы, пагинацию). Примерно, после часа возни со всем этим, вся страница отрисовывается всего за 100 мс после клика на заголовок столбца. Это достаточно быстро — даже если осталось ещё что оптимизировать.
Добавление shouldComponentUpdate метода может показаться громоздким, но если вы заботитесь о производительности, то большинство компонентов должны содержать его.
Но не вставляйте его везде, где только можно — выполнение shouldComponentUpdate в довольно простых компонентах может порой замедлить его отрисовку. Не делайте этого слишком рано в жизненном цикле приложения. Добавляйте этот метод лишь по мере роста приложения, когда вы сможете определить проблемы производительности в ваших компонентах.
Recompose
Я не особо доволен предыдущими изменениями в : из-за shouldComponentUpdate я должен был трансформировать простой, функциональный компонент в класс. Это добавляет много строк кода, каждая из которых имеет свою цену — в виде написания, отладки и поддержки.
К счастью, вы можете реализовать логику shouldComponentUpdate в компоненте высшего порядка (HOC), благодаря recompose. Это функциональный инструментарий для React, предоставляющий, например, HOC функцию pure() :
Я даже могу быть более конкретным и ориентироваться только на те props, о которых я точно знаю, что они могут измениться, используя shouldUpdate() вместо pure() :
checkPropsChange — это чистая функция, и я даже могу экспортировать её для unit-тестирования.
Redux
Если для управления состоянием приложения вы используете Redux (который я также рекомендую), тогда подключенные к нему компоненты уже чистые. Нет нужды в каком-либо другом HOC.
Просто запомните, если изменилось всего одно свойство, то подключенный компонент перерисуется, — и все его потомки тоже. Поэтому, если вы используете Redux для компонентов страницы, вам следует использовать pure() или shouldUpdate() для нижележащих по дереву компонентов.
Но также помните, что Redux использует строгое сравнение для props. Поскольку Redux связывает state c props компонента, то если вы будете изменять объект в state, то Redux просто проигнорирует это. И вот по этой причине вы должны использовать иммутабельность в ваших reducers.
К примеру, в admin-on-rest, клик по заголовку таблицы диспатчит SET_SORT action. Reducer, который слушает этот action, должен заменить объект в state, а не обновить его:
Следуя коду этого reducer-а, когда Redux проверяет state на изменения, используя тройное сравнение, он обнаруживает, что объект state изменился и перерисовывает таблицу с данными. Но если бы мы мутировали state, то Redux бы пропустил это изменение и соответственно ничего бы не перерисовал:
Чтобы писать иммутабельные reducers, некоторые разработчики используют библиотеку immutable.js, которая также от Facebook. Но с тех пор, как деструктуризация ES6 упростила выборочную замену в свойствах компонента, то я не считаю, что эта библиотека необходима. Кроме того, она тяжеловесная (60 kB), поэтому подумайте дважды, прежде чем добавить её в зависимости своего проекта.
Reselect
Для предотвращения ненужной отрисовки подключенных к Redux компонентов, вы также должны убедиться, что функция mapStateToProps не возвращает новые объекты при каждом её вызове.
State содержит массив всех ранее загруженных записей, проиндексированных ресурсом. Например, state.admin.posts.data содержит список постов:
Функция mapStateToProps фильтрует объект state и возвращает только те записи, которые фактически отображаются в списке. Что-то вроде этого:
Что касается recompose, selectors — это чистые функции, лёгкие для тестирования и компоновки. Написание своего selector для подключенных к Redux компонентов — это хорошая практика.
Остерегайтесь объектных литералов в JSX
Однажды ваш компонент станет ещё более «чистым», и вы можете обнаружить у себя в коде плохие паттерны, приводящие к бесполезным перерисовкам. Наиболее общим примером этого является использование объектных литералов в JSX, которые мне нравится называть «Печально известные <<«. Позвольте привести пример:
Это выглядит весьма просто, но я столько раз видел эту ошибку, что у меня развилось чувство по обнаружению «печально известных << " в JSX. Я регулярно заменяю их константами.
Я обжёгся на этом пару раз с material-ui на примере следующего кода:
Заключение
Сам по себе, React — не быстрый, но он предлагает все инструменты, чтобы сделать быстрым приложение любого размера.
Это выглядит нелогичным, особенно, когда множество фреймворков предлагают альтернативы React, утверждая, что они быстрее его в N раз. Но React ставит во главу угла удобство и опыт разработчика, а не производительность. Это та причина, по которой разработка больших приложений с React это приятный опыт, без плохих сюрпризов и со стабильным темпом реализации.
Не забывайте время от времени профилировать ваше приложение и посвящать некоторое время на добавление pure() вызовов при необходимости. Но не делайте этого в самом начале, и не тратьте слишком много времени на оптимизацию каждого компонента — за исключением, если вы не делаете это под мобильные устройства. И не забывайте тестировать на разных устройствах, чтобы получать хорошие впечатления об отзывчивости вашего приложения с точки зрения пользователя.
Если вы хотите узнать больше об оптимизации производительности React, то вот список отличных статей по этой теме:
Введение в React и Redux для бекенд-разработчиков
Если вы как я долгое время считали, что JavaScript – это такой «игрушечный» язык на котором пишут анимашки для менюшек и падающие снежинки на форумах под новый год, а потом очнулись в 2016 году с мыслями WTF: react, flux redux, webpack, babel,… не отчаивайтесь. Вы не одиноки. Материалов по современному фронтенду в сети много, даже слишком много. Под катом еще одно альтернативное мнение о том, каково это учить JavaScript в 2016 году.
Итак, нам потребуются: React, React Dev Tools, React-Hot-Loader, React-Router, Thunk, Redux, Redux Dev Tools, Semantic-UI, Webpack, Babel и npm.
На первый взгляд много. Сравним с бекендом: MVC-фреймворк, ORM, Data Mapper, IOC-контейнер, логер, профайлер, очереди, управление конфигурациями, сборка и выкладка… Список можно продолжить, но думаю идея понятна и так: с ростом сложности решаемых задач растет и сложность инструментов. Все чаще мы употребляем термин Web App вместо Web Site, акцентируя внимание на богатых возможностях современных веб-приложений.
Почему именно этот стек?
Если вдуматься и отбросить все лишнее, то единственный ресурс постиндустриальной эпохи, через который можно выразить все остальные – это время. Освоение каждой новой технологии требует затрат времени, а значит более перспективны инвестиции в технологии, которые не устареют в ближайшие пару месяцев. Дополнительный плюс получают технологии с пологой кривой обучения.
React + Redux VS Angular VS Yet Another JS Framework
Только ленивый не сравнил Angular с React’ом (приписав при этом, дескать, сравнение не корректно, Angular – фреймворк, React – библиотека). Пойдем от обратного. Почему бы не выбрать что-нибудь эдакое, типа Vue, Ember или, упаси боже, Elm?
Если вам нравится TypeScript, ничто не мешает использовать его вместе с React. Просто конкретно мне он пока не дал критического объема преимуществ, чтобы заставить тратить время на еще один элемент в стеке.
Да, Redux можно использовать и с Angular, он никак не привязан к React, но для React уже есть react-redux и react-hot-loader. Наверное, для Angular тоже есть, но мейнтейнер Redux’а явно на стороне React.
Для React и Redux доступно два расширения Chrome. Рекомендую поставить оба, чтобы сделать отладку приятной.
Есть еще всякие ништяки, вроде React Native, но я им не пользовался, поэтому поделиться на эту тему мне, к сожалению, нечем.
А flux и все эти модные словечки. Как это работает?
Пакет react-redux осуществляет односторонний байндинг redux state => react component с помощью метода connect. При изменении состояния Redux сам перерисует необходимые компоненты, передав в props dispatch и часть общего state, хранимого в Redux. Какую часть состояния и какие функции на основании store.dispatch передавать — решать вам. Я рекомендую передать все обработчики событий компонента и не «светить» dispatch в компонентах.
State содержится в Redux, но и у компонентов есть свой state. Какой из них использовать?
Разработчик Redux предлагает делать как удобнее. Это не совсем формальный совет. У нас сложилась практика использовать state компонента только для форм или в целях оптимизации.
JSX – это не JavaScript. Да, React можно писать без JSX, но проще тогда без React’а. Вообще ситуация с HTML-шаблонами напоминает мне засилье шаблонизаторов для PHP лет десять назад. Самым монструозным из всех был конечно Smarty. Мне казалось, что люди сошли с ума. Как иначе можно было объяснить желание написать шаблонизатор… для шаблонизатора?
Функциональная запись короче и лучше читается. Но я рекомендую не увлекаться экономией строк и вместо:
использовать чуть менее лаконичное, но более безопасное:
Во-первых, если вы не передадите параметры, то React недвусмысленно намекнет в консоли, что вы не правы. Во-вторых, WebStorm умеет анализировать PropTypes и при авто-дополнении заботливо вставит все required props.
Babel
Если вы не поняли на каком языке примеры кода выше, не расстраивайтесь. Это не JavaScript, ну не совсем JavaScript. Это ES6 + JSX. С JSX мы разобрались в параграфе выше – это просто синтаксический сахар для шаблонизации (почти как в PHP или @Model.Param в Razor).
С ES6 ситуация чуть сложнее и запутаннее. Если коротко:
Стоит отметить, что ES6 – это не истина в последней инстанции. Некоторые фичи до сих пор являются экспериментальными (например, генераторы) и для их использования потребуются полифиллы (библиотеки, реализующие экспериментальные фичи стандарта). Частично из-за этого мы решили отказаться от redux-saga в пользу redux-thunk, хотя и идея диспатчить функции до сих пор не кажется мне изящной (она просто работает).
Webpack
Так, то есть пишем мы на ES6 + JSX, а в бразуере выполняется минифицированный JS. Все это напоминает историю изобретения высокоуровневых ЯП. Люди могли писать более эффективные программы на ассемблере, но предпочли удобство и продуктивность. Раз есть исходники и компилятор (транспилятор в нашем случае), то потребуется и система сборки. Если в вашей пещере было достаточно тепло и уютно, возможно, названия grunt и gulp вам ничего не говорят. Что к лучшему. На данный момент, можно считать (слава богу), что для JS есть только один сборщик – Webpack — оставивший конкурентов позади. Можно считать, что webpack — аналог maven или msbuild (кому что ближе) в мире фронтэнда. Не смотря на то что, конфиги webpack’а на первый взгляд напоминают некромантские свитки, через какое-то время привыкаешь. Наверное, каждый любитель фронтенда должен хотя-бы раз в своей жизни написать tutorial по настройке webpack, также как каждый фанат ФП – tutorial по монадам.
Вообще Webpack собирает не только JS, но еще и sass, svg, шрифты и вообще все что душе угодно, но я пока еще не готов написать полноценный туториал, так что поищите на просторах интернета.
Без этих строк npm run build и npm start не заработают.
React-Hot-Loader
React-Router и Thunk
Основная ниша React’а в Web – это конечно SPA-сайты. А какой SPA-сайт без навигации и общения с сервером. Первую задачу решает react-router. Здесь альтернатив нет. Из неприятных сюрпризов:
Semantic-UI
Раз мы заговорили про SPA-приложения, то кроме навигации и запросов к серверу нужны еще компоненты, которые будут ту самую серверную информацию отображать. Для React есть обвязки Bootstrap, Material UI, Syncfusion Web Essentials (хотя эти обвязки не честные – там внутри jQuery). Наш выбор остановился на Sematic-UI. Решение удалось принять очень быстро – сначала отмели платные компоненты. Material UI не стали использовать из-за обилия анимации (сложнее модифицировать). Остались Bootstrap и Semantic. На Бутстрапе уже пол интернета сделано и в целом, Семантик показался более визуально-привлекательным. В общем, остановились на нем. Сразу оговорюсь, что использование Semantic UI – строго опционально, потому что минифицированная версия весит около 500кб.
Так что разрабатывать фронтенд в 2016 году вполне себе комфортно. Да инструментов много, многие библиотеки не совместимы, новые версии выходят очень часто. Это разумная плата за гигантский скачок в качестве фронтенд-стека.