Комментарии 51
создающий приложения на нативном React
React Native - название технологии, я не думаю что корректно было так вот переводить.
Как писать простой и читаемый код
… не упоминая библиотеку из Github с наибольшим количеством звёзд, а показав мне пару своих лучших примеров кода.
Если кто-то отвечает на вопрос о том, как писать простой и читаемый код через "прост возьмите готовое" — он профнепригоден, только и всего.
Как управлять состоянием
… без упоминания популярной библиотеки управления состояниями (предпочтительно заканчивающейся буквой «X»), а объяснив мне, почему «данные должны двигаться вниз, а действия — вверх». Или почему состояние должно изменяться там, где оно было создано, а не глубже в иерархии компонентов.
Если и объяснения будут даны, они не отвечают на вопрос "как управлять состоянием". Они отвечают на вопрос "что такое вообще это ваше состояние". А вопрос "как" — как раз и затронет эту вашу популярную библиотеку на Х, потому что напрямую касается вопросов о масштабировании проекта, о легкости внесения изменений, и об этом всём.
А на уровне "данные должны двигаться вниз, а события вверх" — можно управлять хоть голым реактом, хоть самопиской, хоть еще как. Когда это всё зароется в проблемах масштаба — вот тогда и придёт понимание, что тут кое-что еще нужно.
Как тестировать свой код
<...> почему минимальные значимые тесты рендеринга требуют 10% усилий и дают 90% выгоды.
А они дают? Ни разу не видел в живой природе "минимальных тестов рендеринга", которые легчайше делаются и дают огромный профит. Наоборот, любому не набрасывающему на вентилятор, должно быть понятно, что тесты рендеринга — это всегда крайне непростая штука, ибо по своей природе это интеграционные тесты вашего кода с black box многочисленных браузеров.
А если это какие-либо "приближения", как тот же Jest, который проводит "тесты рендеринга" через генережку DOM — они дают не просто 90% выгоды, а ровно 0%. Т.к. тестируют сферическую хрень в вакууме.
Как релизить свой код
См. "как управлять состоянием". На практике этого тупо недостаточно.
Как писать код, который удобно анализировать
Никак. Можно еще долго ломать копья вокруг этого, но практика от теории не отличается только в теории. На практике — есть такие изменения в коде, которые нельзя "удобно анализировать", и которые невозможно свести к "удобным для анализа" за хоть сколько-нибудь вменяемое количество времени.
А за пределами этого замечания — это то же самое, что и "писать понятный код".
Короче, набросы какие-то, из преимущественно спорных моментов и попытке что-то придумать просто потому, что надо бы придумать. Здравые моменты есть, но нездравых сильно больше. И ах да, а при чем тут реакт? А вот причем:
Мы вели потрясающие беседы с несколькими опытными React-разработчиками. Никто из них не согласился с названием этой статьи, они говорили, что «испортил» — слишком сильное слово.
"Просто нам хотелось погромче набросить" (с).
Про тесты на Jest + RTL не соглашусь. Это рекомендуемый способ компонентного тестирования, и при правильном применении - он даёт отличные результаты. Тестировать комбинации разных параметров интеграционно - путь к очень долгим и нестабильным тест-пакам. Change my mind :)
Его рекомендуемость не делает его лучше.
Любой тест, про который заранее известно, что он упадёт при изменении кода (верстки, в данном случае) — бессмысленен. Любой тест, который не фиксирует разумные ожидания — бессмысленен. Когда упал тест, ожидающий где-то <div>, в то время как после правок там <button> — всё, что тут прибавилось, так это необходимость пойти и привести падающий тест в соответствие с версткой. И нафига он тогда?
Ну и если у вас столько комбинаций пропсов, что это уже неохватываемо — самое время рефакторить компоненты и уже таки наконец как-то управлять состоянием.
PS: Юнит-тесты на логику работы кода — они да, полезны. Но это не про рендеринг, естественно.
где-то <div/>, в то время как после правок там <button/>
Ну так react testing labriry есть возможность искать не по элементу а по тексту в элементе
getByText
а то что верстка съехала да тестируем скриншот тестами
Ну так react testing labriry есть возможность искать не по элементу а по тексту в элементе
Не поможет, когда текста у вас нет.
а то что верстка съехала да тестируем скриншот тестами
Изменился код — упали тесты. Не изменился код — не упали тесты. Зачем оно? У вас много случаев, когда вы считали, что ничего не должно поменяться, а оно менялось? Если много — тут повод много думать об архитектуре приложения, а не тесты дальше фигачить.
Не поможет, когда текста у вас нет.
Всмысле нет а тогда что вы показываете пользователю и что там проверяете ?
Изменился код — упали тесты. Не изменился код — не упали тесты. Зачем оно?
Помогает при малейшем рефакторинге (при быстром деливвиринге фитч всегда падает планка хорошего кода оптимизации и т.д.)
У вас много случаев, когда вы считали, что ничего не должно поменяться, а оно менялось?
ни кто не убирает человеческий фактор что кто то может что то не заметил
или вы предпалагает е что все 100% пишут всегда лаконичный код который лишнего не цепляет и ничего не забывает сделать (а как же тип программирование через тестирование когда в начале пишут тест а потом пишут интерфейс, функцию коотрая этот тест проходит)
Если много — тут повод много думать об архитектуре приложения, а не тесты дальше фигачить.
везде есть есть тонкости но говориьт что тесты писать не нужно это перебор
Всмысле нет а тогда что вы показываете пользователю и что там проверяете ?
Вам рассказать, сколько всего можно сделать и показать в вебе без единой строчки текста, или вы таки воображение сами включите?
Помогает при малейшем рефакторинге (при быстром деливвиринге фитч всегда падает планка хорошего кода оптимизации и т.д.)
Ничего не понял. Ну вот вы поменяли что-то. Тесты упали. Вы пересоздали снапшоты и счастливо пошагали дальше. Что конкретно тут "помогает" и чему оно помогает?
ни кто не убирает человеческий фактор что кто то может что то не заметил
Для этого существует code review.
И да, вполне возможны ситуации, когда из чтения пулл реквестов — не особо понятно, что конкретно изменится, а что нет. Корень всех таковых ситуаций — говнокод и говноархитектура. Пытаться решать этот вопрос тестами — порождает только еще больше проблем.
везде есть есть тонкости но говориьт что тесты писать не нужно это перебор
Я где-то говорил "тесты писать не нужно"? Ссылочку дадите?
Вам рассказать, сколько всего можно сделать и показать в вебе без единой строчки текста, или вы таки воображение сами включите?
токсично, но я ориентировался на ваш пример где использовался button и div
Ничего не понял. Ну вот вы поменяли что-то. Тесты упали. Вы пересоздали снапшоты и счастливо пошагали дальше. Что конкретно тут "помогает" и чему оно помогает?
Упал тест — заскипал, пошел, дальше. Я вас верно услышал ?
говнокод и говноархитектура
"Для этого существует code review" — это ведь то же бы могло решить это проблему но видимо не решает
Я где-то говорил "тесты писать не нужно"? Ссылочку дадите?
"Любой тест, про который заранее известно, что он упадёт при изменении кода" — все тесты пишутся чтобы изминением кода не затронуть лишние части приложения. Или я вас не так понял? и вы не имели ввиду "любой" тест
Упал тест — заскипал, пошел, дальше. Я вас верно услышал ?
Я могу пояснить подробнее, если вам что-то непонятно. Вот у вас есть скрин/снапшот, и тест, проверяющий, что какой-то код выдаёт то самое. Вот вы меняете этот код. Тест очевидно валится. Какие у вас есть другие варианты действий, кроме как "обновить скрин/снапшоп"? Может быть, упавший тест вам как-то покажет, что вы поменяли код не так, как надо было? Нет, не покажет.
"Для этого существует code review" — это ведь то же бы могло решить это проблему но видимо не решает
Значит такой code review ¯\_(ツ)_/¯
все тесты пишутся чтобы изминением кода не затронуть лишние части приложения. Или я вас не так понял? и вы не имели ввиду "любой" тест
Я имел в виду "любой, про который заранее известно, что он упадёт". Собственно именно потому я именно так и написал, ага. Про снапшот- и скриншот-тесты заведомо известно, что они упадут при любом изменении кода компонента. Ergo, они не нужны.
Против тестов, про которые нельзя заведомо сказать "они упадут при любом изменении кода" — я ничего не имею.
Про снапшот- и скриншот-тесты заведомо известно, что они упадут при любом изменении кода компонента.
Придумываем ситуацию где на гавнокодили сделал долгие операции в компоненте, но написали все тесты, затем рефакторинг (да даже переход с js\flow\ts на js\flow\ts) и после тестов понятно изминился результат после рефакторинга или нет
Придумываем ситуацию где на гавнокодили сделал долгие операции в компоненте, но написали все тесты, затем рефакторинг (да даже переход с js\flow\ts на js\flow\ts) и после тестов понятно изминился результат после рефакторинга или нет
И как часто вам нужен рефакторинг вида "переход с js/flow/ts на js/flow/ts"? Раз в недельку-то хотя бы переходите?
Вот тут мы плавно подходим к единственной очень особой ситуации, когда такие тесты и вправду могут быть полезны: когда вам нужно "взять и всё переписать, но чтоб результат был такой же". Но это во-первых очень особая ситуация, и держать эти тесты ради неё — нет никакого смысла. Надо — создали, порефакторили, проверили, выкинули.
А во-вторых, и даже тут оно не во всех случаях работает. Поменяли при рефакторинге структуру компонентов? Ну всё, ваши скрин/снапшоты бесполезны. Вам не нужен pixel-perfect и в ходе рефакторинга кое-какие вещи подвинулись? Скриншоты бесполезны. Вы переверстали кое-какие внутренности с сохранением того же внешнего вида? Снапшопы бесполезны.
Короче, даже не то, что не серебрянная пуля, а вообще очень специфичная штука, которая помогает только в очень ограниченных рамках применимости. А в других случаях — просто отжирает время зря.
я ориентировался на ваш пример где использовался button и div…в которых может быть, например, картинка.
Я могу дать более развернутый ответ, но сначала хочу убедиться, что мы говорим об одним и том же. Под Jest + RTL я имею ввиду не snapshot тесты, а именно функциональные, просто в изолированной среде. Подробнее можно почитать у Kent C. Dodds и Robin Wieruch. Изменения компонента такие тесты переживают очень хорошо, падают только по делу.
Я понимаю, что вы не про снапшот-тесты говорили.
1) В компонентах не должно быть кода, который не относится напрямую к презентации и не "близок" к DOM. Для этого есть другие места (абстракции стейт-менеджера и так далее), которые спокойно покрываются юнит-тестами.
2) Код в компонентах либо совершенно тривиален (запустили экшен в onclick), либо нетривиален, но связан с браузерной спецификой.
Я не вижу никакой пользы в RTL в свете #1 и особенно #2. Проверять, что компоненты рендерятся "вообще" — бессмысленно, т.к. это один раз проверяется разработчиком при написании компонента, а затем легко выявляется на code reivew — если у вас нормально написанные презентационные компоненты без мусора, то их не выйдет "сломать" вроде бы не относящимся к ним изменением кода.
Проверять работу виртуального DOM — и вовсе бессмысленное занятие. Да, я могу найти нетривиальный кейс бага (или просто специфичной трактовки спек) в конкретном браузере, и попытаться "закодить" его с помощью RTL, чтоб в будущем про него помнить. Но во-первых, баги иногда закрывают (а тест будет висеть, пока вы сами не поймете, что баг уже закрыт, и не удалите его), а во-вторых — без css (с которой связано огромное количество проблем, всплывающих в e2e) это всё напоминает попытку искать ключи под фонарём, а не там, где потерял.
Какой-то профит от RTL можно представить только для случая, когда вы в 2021 году пишете на JS, и тогда вы просто можете ошибиться в верстке неочевидным образом, и всё поломать. Но… зачем в 2021 году писать на JS, а не на TS?
Cypress внедрили первые тесты очень быстро, сразу дало хороший профит
Здорово, я тоже надеюсь его в будущем припахать. Слышал много хорошего, да и плюс это честный e2e.
Что вы понимаете под "честным e2e"?
У Cypress есть проблемы с симуляцией пользовательских действий: https://github.com/cypress-io/cypress/issues/311
Что вы понимаете под "честным e2e"?
То, что запускается в браузере и эмулирует работу со стороны пользователя.
У Cypress есть проблемы с симуляцией пользовательских действий: https://github.com/cypress-io/cypress/issues/311
Было б странно, если б не было. Я вам больше скажу — проблемы даже и у селениума есть, мне тестировщики таких интересных историй нарассказывали.
Довольно странно катить бочку на JSDOM то что они "тестируют сферическую хрень в вакууме", и предлагать Cypress на замену. И там, и там пользовательские события эмулируются через прямое вмешательство в DOM и element.dispatchEvent(). Отличие Cypress в том, что там есть CSS, только и всего. Вероятность кликнуть на кнопку, которая реальному пользователю будет недоступна, в Cypress остается, в силу фундаментальных ограничений его архитектуры.
Селениум (равно как и puppeteer/playwright) использует другие механизмы для эмуляции событий, поэтому находится на шкале достоверности намного ближе к реальным действиям пользователя.
Довольно странно катить бочку на JSDOM то что они "тестируют сферическую хрень в вакууме", и предлагать Cypress на замену.
Один — сферическая хрень в вакууме, второй — сферическая хрень в браузере.
Разница, я считаю — огромная, пусть и "оба хуже" в сравнении с селениумом и прочими industry standards. Тестировать абстрактную логику DOM (то, что является потолком для JSDOM) — на редкость бессмысленное занятие, что тестируем-то? Код на соответствие спеке DOM? Проблемы будут не там.
Селениум — это отлично, но на этапе разработки это развёртывать — слишком муторно, а хотелось бы именно на этом этапе малой кровью иметь некоторые базовые тесты "всё ли ок в браузере", не доводя до QA.
что тестируем-то? Код на соответствие спеке DOM? Проблемы будут не там.
Тестируем Javascript часть компонента. В реальных проектах кастомного CSS не так много, большая берется из готовой дизайн-библиотеки, поэтому нужно лишь проверить что в таком-то сценарии показываются такие-то компоненты с определенным контентом.
Для UI компонентов конечно же нужны другие виды тестов, но это отдельный проект, и не каждый разработчик изобретает свою версию ant.design
Селениум — это отлично, но на этапе разработки это развёртывать — слишком муторно
Что муторного в npm install chromedriver? Видимо, пора уже написать отдельную статью "разрушаем миф сложного selenium", потому что ну очень часто вижу заблуждение "не хотим selenium потому что сложнааа"
Тестируем Javascript часть компонента.
Откуда там что-то, что достойно тестирования, но при этом не связано с тонкостями работы DOM в тех или иных браузерах? Мы в 2021 всё еще пишем на голом реакте, где кроме компонент ничего нет, или как?
Для UI компонентов конечно же нужны другой вид тестов
А не-UI компоненты не нужны вообще. Или вы про компоненты, показывающие другие компоненты? У них у всех должна быть настолько тривиальная вёрстка, что тестами покрывать её просто не требуется.
Что муторного в npm install chromedriver?
А не в хром-браузерах как?
На мой опыт, основной (>90% кейсов) проблемной точкой, когда с бизнес-логикой всё хорошо, а e2e или ручное тестирование валится — является как раз браузерная специфика.
JFYI: в Cypress есть реальные эвенты через CDP. Пока что только для chrome-based, но, думаю, допилят.
Я в курсе про эту штуку. Более того, она появилась отчасти из-за моих усилий по распространению информации об этом недостатке.
думаю, допилят
А я вот так не думаю. Автор сделал это как хобби-проект, core-команда в этом не заинтересована. Пруф.
Ты же понимаешь, что наличие проблем не обязательно является "блокером" для тестирования конкретного приложения? Ну, это то же самое что кинуть issue по производительности питона и говорить чувакам у которых лям пользователей, что они зря выбрали питон.
В нашем случае он хорошо эмулирует пользовательский опыт и дает условное "ок" по проверке самых используемых. Также мы не насилуем тулу и не пытаемся протестировать каждую мелочь с его помощью. Это как раз высокоуровневый инструмент, которые дает самое простое, но целостное покрытие.
Условно как руководитель, который не просто взял расчет подчиненного, а взял калькулятор и проверил самую первую строку и нашел косяк. Сложно? - Нет. Полезно? - Да.
Я изначально отвечал на коммент о том что Cypress это "честный e2e".
Если понимать его ограничения и его место в тестовой пирамиде (была на эту тему релевантная статья), то инструментом вполне можно пользоваться
И отдельно по поводу картинки-наброса про стейт менеджмент: если до 2016 года она абсолютно бесспорна (разные подходы, разные концепции), то далее — сплошная профанация:
2018 — Contexts: контексты были подачкой тем, кто по каким-то причинам в 2018 году всё так же сидел в глубинах props hell, пользуясь одним только реактом. Контексты всё так же отвратительно масштабировались, как и передача пропсов — но чуть получше. Тем, у кого было всего лишь по 5 оберток над компонентами — вполне могло помочь, тем, у кого было по 50 — неа. Те, кто сидел на редаксе или мобх — в сторону контекстов даже и не взглянули, т.к. для них это было шагом в сторону и 10 шагами назад.
2018 — Hooks: говорить про хуки как про стейт-менеджмент — это только сову рвать. Это переделка реакта в целом, и не самая плохая переделка, кстати. Но да, стейт-менеджмент на кастомных хуках оказалось сделать на удивление легко, и поэтому…
2019 — Zustand: один из чуваков просто взял и выложил эти кастомные хуки на гитхаб. Ага, прям новая технология.
2020 — Recoil: мобх, только не мобх. Наверное, у авторов аллергия на букву Х. От еще одной очередной либы для реактивного программирования наверное всё изменится (нет).
Эти все игры в песочнице прекрасны, у меня более важный вопрос. Кто из двоих на первой фотке косплеит Краудера?
Однако после того, как React набрал популярность, начался хаос. Он зародил в сообществе новый тренд, когда всё вращается вокруг хайпа, новизны и создания новых сдвигов парадигм.
Это вообще характерно для JS среды, и фронтенда в частности. React был далеко не первый.
Автор драматизирует, когда говорит, что во фронтенд каждый год меняется парадигма. С того момента, как веб перешёл на SPA, ничего кардиально не менялось, менялись только best practices, и то довольно медленно.
А то, что сообщество активно и постоянно придумывает новые варианты решения одних и тех же проблем, пытается сдвинуть парадигму (зачастую безуспешно) — по-моему, очень даже хорошо.
Как писать код, который удобно анализировать
… не говоря, что ты «командный игрок», а рассказав мне, что анализ кода так же сложен для ревьюера, и что ты знаешь, как оптимизировать свои пул-реквесты, чтобы они были читаемыми и понятными.
Читая вот это какой-нибудь джун запомнит это и будут писать mySuperNewAwesomeFunctionThatMakesSomeCoolStuff и будет ставить читабельность кода превыше его эффективности. Тут вопрос о компромиссе чтения кода и его работы. И вопрос, можно ли написать такой код, который будет эффективен, при этом ревьювер потратит 3 минуты на чтение его и сразу поймет?
Как разобраться в любом JS-фреймворке
… потому что дело не в звёздах GitHub, а в общих принципах, разделяемых большинством современных JS-фреймворков. Определение сильных и слабых сторон других фреймворков позволяет лучше понимать выбранный тобой фреймворк.
Звёзды на гите лишь небольшое указание, что если комьюнити одобряет, то на это можно посмотреть и потрать время на ресёрч и только тогда можно будет сказать что-либо о фреймворке. И я говорю сейчас исключительно в разрере какой-либо существующей бизнес задачи.
почему «данные должны двигаться вниз, а действия — вверх». Или почему состояние должно изменяться там, где оно было создано, а не глубже в иерархии компонентов.
«почему?» не объясняет «как?». Вот та самая библиотека Х как правило на первой странице своей документации отвечает на некоторые «почему?» и «как?».
у каждого проекта есть технический долг, нужно перестать ныть об этом и приступать к рефакторингу. Каждой новой фиче должен предшествовать небольшой рефакторинг кода.
Рефактор ради рефактора — хождение по кругу. Это не дает, конечно, право писать плохой код и все выходящие, в т.ч. опыт написания кода, но как правило техдолг остается техдолгом навсегда, потому что бизнесу вообще плевать на эффективность твоих алгоритмов до тех пор, пока он из-за этого не теряет деньги. Конечно, можно программировать «для души», но лично такой подход в моей жизни еще не прокормил (это дабы пресечь сразу этот вариант), а задачам бизнеса, снова, плевать на твою душу.
Я к чему вообще веду. Может, не реакт испортил разработку, а сами разработчики? Гикбрейнсы, Хекслеты, Яндекс.Практикумы, выпускающие непонятного кого, которые, наслушавшись обещаний о классной работе и печеньках в офисах, на собесе требуют 100к+ зарплаты?
Я к чему вообще веду. Может, не реакт испортил разработку, а сами разработчики? Гикбрейнсы, Хекслеты, Яндекс.Практикумы, выпускающие непонятного кого, которые, наслушавшись обещаний о классной работе и печеньках в офисах, на собесе требуют 100к+ зарплаты?
Ну так и да — программистов очень не хватает, есть большой поток всяких "обучившихся на курсах", а там занимаются не базой, а конкретикой с осязаемым выхлопом. Но, на мой взгляд, это не так уж и страшно — я вот тоже в 2009 году в вебе оказался просто потому, что кому-то надо было делать веб. Базу потом самостоятельно набирал еще несколько лет, потому что мало того, что кому-то надо было делать веб, так еще и ни одного гуру в области досягаемости не было.
А так, если обучившихся на курсах способных и любопытных людей легонько поворачивать в сторону базовых знаний, а не конкретных либ — они этот путь гораздо быстрее пройдут.
И затем компании тратят время на выбивание дури и подтягивание основ, но большинство не выдерживают и уходят работать на галеру, куда их с руками и ногами отрывают, попутно демпингуя в 0.
Я сам прошел путь от такого же человека, но у меня просто не было денег на курсы и я просто потихоньку работал, а основы подтягивал позже, о чем сейчас нисколько не жалею, хоть и потратил достаточно много времени.
Достаточно холиварный вопрос, но на лицо:
1) типичная проблема образования — переполнение низкокачественными кадрами и шутка про «забудь, чему тебя учили» вообще не смешная становится, потому что это реальность.
2) чистый бизнес — получаем прибыль в моменте. Да, базу вроде бы дали, показали то и се, а как усвоили ученики уже не их проблема.
3) когда соискатель выходит на рынок, у него уже в теории ламборгини в гараже стоит через пару лет, а по факту у него глаза на лоб лезут, видя, что происходит за кулисами компаний. И Эльдорадо в виде программирования в целом оказывается даже не прикольно — оказывается, тут лутают бабки не за просто знание доки и что такое html и css, да и борода не признак хипстерства
Понять можно всех, но за одним вопросом стоит череда других и это явно не проблема библиотек. Скорее, их использования и то, спорно достаточно
...если обучившихся на курсах способных и любопытных людей легонько поворачивать в сторону базовых знаний, а не конкретных либ...
Не делайте из еды культа.
Читая вот это какой-нибудь джун запомнит это и будут писать mySuperNewAwesomeFunctionThatMakesSomeCoolStuff и будет ставить читабельность кода превыше его эффективности.уж лучше чтобы джун писал mySuperNewAwesomeFunctionThatMakesSomeCoolStuff чем func1 и func11
Тем более что длина имен уже давно как на эффективность и скорость работы кода никак не влияет.
Читая вот это какой-нибудь джун запомнит это и будут писать mySuperNewAwesomeFunctionThatMakesSomeCoolStuff и будет ставить читабельность кода превыше его эффективности
или ему обьяснят, что коммиты в ПР должны понятными и читабельными
кроме того, а почему читабельный код обязательно д.б. неэффективным?
Автор статьи жалуется на динамику, но не экстраполирует её. Читатель может прийти к выводу, что тенденция сохранится, и ситуация станет с годами ещё запутаннее. Это не обязательно так.
Мне на ум приходят 90-е и то, что последовало потом. Вот стоит советский спальный район, в нём один гастроном, а там продавщица из серии «вас много — я одна». Годами ничего не меняется.
Наступает рыночная экономика, то есть вводятся новые правила игры.
Буквально за пару лет открывается куча магазинов всех мастей, люди и их идеи начинают конкурировать. Названия и хозяева магазинов постоянно меняются, качество обслуживания — далеко не идеал. Точки закрываются так же внезапно, как и открылись.
Можно наблюдать за этим процессом в моменте и решить, что так будет всегда.
Но вот проходит 20-30 лет, и мы больше не в «диких джунглях». Среди сотен открытых магазинов выжили буквально 3-4 сети. Они чутка отличаются по параметрам, но в совокупности занимают практически всё пространство рынка. Выбрать магазин по душе и достатку теперь довольно легко. Сами правила торговли тоже более или менее неизменны, хотя в первые годы законы переписывали по несколько раз в год. Теперь, если что-то и меняется, то редко и вряд ли на 180°.
На мой взгляд после выхода React 18 мы увидим успокоение экосистемы — примерно то же, что россияне наблюдали в продуктовом ритейле в поздние 2000-е. Если я неправ, поправьте меня пожалуйста в комментарии году так в 2025-м :–)
Я дико извиняюсь, а причем тут реакт? Проблема как раз в том, что многим ударила в голову концепция SPA даже там, где не надо. Ну и вайти в айти через фронтенд, это ж сам бог велел, если не хочешь быть простым QA.
У продуктовых компаний вполне хватает ресурсов чтоб не страдать от выбора стейт менеджера, а после анализа запилить свой. А ведь ещё в 2010 уважающая себя веб студия имела свои cms самописные и ui компоненты. Теперь же если проблему решить нельзя через npm install --save жидкобородые 21-летние сеньер ангуляр девелоперы считают проблему нерешаемой. Обновить стейт по вебсокетам? Нужен срочно коннектор socket.io в redux, я же не осилю 50 строчек написать. О, я нашел этот коннектор, нечто, что 2 года уже не суппортится, пожалуй все равно добавлю в package.json. underscore для мержа двух объектов простых? Легко. Moment потому что я не знаю про Date.now. Конечно.
Native это способ руками фронтедеров запилить мобайл АПП, не нанимая по 300к Андроид девелоперов и iOS девелоперов. Ещё б дизайнеров обучили, что нейтив это убогий обрезок и мобильная веб версия и нейтив АПП это две огромные разницы. До сих пор помню муки с Vue native, Weex и Android studio. Не работало буквально всё, но на каждую ошибку было решение на SO, что примечательно. К сожалению даже в 2021 сделать красиво под все платформы можно только изначально некрасивое приложение.
Не знаю как вы, но у меня от этого поста поутихомирился синдром самозванца.
приложение становится медленным не из-за медленного JS-фреймворка, а из-за плохого кода
Золотые слова
React испортил веб-разработку