Кажется, мы стали забывать основы фронтенда

Наркомания какая-то, если честно. Особенно часть про children, где они предлагают делать так

const Component = React.memo(() => {
   const children = useMemo(() => <div>content</div>, []);
   return <Container>{children}</Container>
});

Вместо того чтобы

function Component() {
   return <Container>
      <div>content</div>
   </Container>
}

Для пятничного поста в "ненормальное программирование" еще бы зашло, но писать такое регулярно - увольте.

Кажется, мы стали забывать основы фронтенда

Насколько я знаком с Angular, там ровно такая же проблема:

<div class="footer">
   <ng-content select="footer"></ng-content>
</div>

Как вы заранее узнаете, есть ли что-то в ng-content или нет?

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

Замедления в скорости разработки – конечно были. В этом и суть, что такие псевдо-оптимизации добавляют команде мартышкин труд по их поддержке.

Кажется, мы стали забывать основы фронтенда

Вы считаете нормальным решением отрендерить лишний дом элемент, чтобы его не показывать?

Нет, золотая рыбка, $mol я использовать не буду

Вы считаете нормальным потратить в каждом компоненте 1/16 от фрейма анимации впустую?

А к какому случаю из статьи это относится?

50 цветных оттенков Mavo. Решение задач веб-разработчика без JavaScript

Кажется, тут переизобрели AngularJS

Кажется, мы стали забывать основы фронтенда

Про empty:

Такой подход прекрасно попадает под pareto principle – работает для большинства случаев с минимальным оверхедом. Там где не проткатит – так уж и быть, придется расчехлять свои компоненты и передавать явный null вместо неявного.

Про мемоизацию:

В общем тут нужно видеть код.

В общем-то в демке я почти весь код и показал, кроме разве что обработчиков событий и стилей.

Понимаю, что при усложнении кода тут может оказаться проблема (а может и нет, кто же знает). Но фиксить сейчас не существующую проблему – это классическая преждевременная оптимизация

Кажется, мы стали забывать основы фронтенда

Ну и вообще, для человека из Ангуляра первые два решения смотрятся диковато.

А как бы вы это сделали?

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

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

Кажется, мы стали забывать основы фронтенда

Конкретно в этой ситуации – нет. Когда я показал как надо, разработчики согласились тоже. Проблема именно в том что они не знали что так можно. Не научили в свое время

Кажется, мы стали забывать основы фронтенда

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

Кажется, мы стали забывать основы фронтенда

Имеется в виду почему не было подписки на событие DOMContentLoaded?

Потому что ReactDOM.render обычно синхронно исполняется. Вон и в популярнейшем create-react-app так и сделано. Если перенести код в обработчик, то тоже работать будет.

npm audit работает неправильно — это настоящий театр безопасности

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

Пишем frontend на golang

Разработчики:

Фронтенд на реакте занимает 200 килобайт, это непозволительно много, не позволим!

Те же разработчики:

У нас тут hello world на Go, всего 500 килобайт, как мило и компактно, за этим будущее!

Как я писал тестовое задание на Angular и почему некоторым разработчикам не стоит давать тестовое задание

Если вы реально 2 часа писали приложение, только чтобы ответить этим комментарием, то снимаю шляпу, моё уважение

Как я писал тестовое задание на Angular и почему некоторым разработчикам не стоит давать тестовое задание

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

Как я писал тестовое задание на Angular и почему некоторым разработчикам не стоит давать тестовое задание

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

В моем опыте собеседующего было слишком много кандидатов, которые д'Артаньяны в теоретической части (лидил команду в 10 человек, настроил CI/CD, всё модульное и идеально протестированное). А стоит такому дать простую задачку написать два UI компонента и продумать их API, чтобы гибко и тестируемо, и он моментально скисает.

Тестовое задание не должно быть большим. Не нужно требовать полностью функциональное приложение. Достаточно написать пару компонентов, и уже будет понятно, годится кандидат или просто бросается модными словами.

React Server Components — что это?

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

Почему иногда React/Redux в текущем состоянии give me creeps

Не очень понимаю смысл претензий. Когда вы используете компонент, вам же не обязательно заглядывать в его код, чтобы понять, какие props он ожидает и чего отрендерит? Так же и с переиспользуемыми хуками – есть четкое API, что он получает на вход и что даёт на выход.

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

Оптимизации в вебе — дорого, сложно, и уже не нужно?

Это не ошибка архитектуры, это просто moment – проклятая библиотека. Ее нужно избегать в любом случае: https://github.com/you-dont-need/You-Dont-Need-Momentjs

React испортил веб-разработку

Я изначально отвечал на коммент о том что Cypress это "честный e2e".

Если понимать его ограничения и его место в тестовой пирамиде (была на эту тему релевантная статья), то инструментом вполне можно пользоваться

React испортил веб-разработку

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

думаю, допилят

А я вот так не думаю. Автор сделал это как хобби-проект, core-команда в этом не заинтересована. Пруф.

React испортил веб-разработку

что тестируем-то? Код на соответствие спеке DOM? Проблемы будут не там.

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

Для UI компонентов конечно же нужны другие виды тестов, но это отдельный проект, и не каждый разработчик изобретает свою версию ant.design

Селениум — это отлично, но на этапе разработки это развёртывать — слишком муторно

Что муторного в npm install chromedriver? Видимо, пора уже написать отдельную статью "разрушаем миф сложного selenium", потому что ну очень часто вижу заблуждение "не хотим selenium потому что сложнааа"