#статья дня

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

Впрочем, здесь мне помогут Александр Беспоясов, Вадим Юмадилов и Андрей Романов. Фамилия Беспоясова должна быть вам знакома – он отметился в Солидбуке.

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

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

И обязательно обратите внимание на прикреплённые к статье материалы. В них есть всё.

#work #frontend #psychology

#ссылка дня

А помните Сашу Беспоясова? Ну это который в том числе написал статью «Фронтенд — это не больно»? Ну если не помните — тогда почитайте. И «Солидбук» тоже заодно, про Solid и ООП.

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

Что такое Дока? Это онлайн-энциклопедия, написанная понятным языком: https://doka.guide/

О том, чем конкретно занимался Саша — его статья: https://bespoyasov.ru/blog/doka/

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

#дока #учебник #статья #learn #frontend

#заметка дня

Я в очередной раз уронил продакшен. На сей раз, не для всех пользователей, а только для параноиков.

Как оказалось, некоторые люди ставят запрет не только на cookies, но и на local storage и даже на session storage. Возможно, такова политика безопасности. Возможно, за них это делает антитрекинговое расширение или условный блокировщик рекламы. Но факт есть факт.

Так вот, дамы и господа. Обращение к любому API, даже, казалось бы, внутреннему всегда может упасть.

Вы должны быть к этому готовы и либо использовать try-catch, либо проверять доступность объекта. А лучше всё и сразу.

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

А касаемо падения прода… Это очень плохо. Не потому что упало, а потому что я повторил ошибку, допущенную чуть больше года назад. Т. е. я тогда не сделал выводов и даже не установил мониторинг.

Ошибаться — можно, ошибаться одинаково — нельзя. Совсем.

Ну и чтобы не повторилось, мы настроили фронтенд-мониторинг — Datadog Real-User Monitoring. Теперь получаем информацию об ошибках в реальном времени.

Естественно, это не единственный подобный сервис:
- Stackdriver Error Reporting
- MONQ
- Sentry
- TrackJS

И так далее, очень и очень много, выбирать есть из чего.

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

#frontend #trycatch #localstorage #monitoring

#статья дня

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

Впрочем, здесь мне помогут Александр Беспоясов, Вадим Юмадилов и Андрей Романов. Фамилия Беспоясова должна быть вам знакома – он отметился в Солидбуке.

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

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

И обязательно обратите внимание на прикреплённые к статье материалы. В них есть всё.

#work #frontend #psychology

#статья дня

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

Впрочем, здесь мне помогут Александр Беспоясов, Вадим Юмадилов и Андрей Романов. Фамилия Беспоясова должна быть вам знакома – он отметился в Солидбуке.

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

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

И обязательно обратите внимание на прикреплённые к статье материалы. В них есть всё.

#work #frontend #psychology

#статья дня

— Да сколько там того фронтенда?

Ну признавайтесь, слышали же хоть раз подобное высказывание, да?

Количество шуток в сторону фронтенд-разработки поражает. Да, не всегда от знающих людей, но тем не менее.

Но вопрос-то остаётся открытым. А в самом-то деле, сколько там того фронтенда? Как посчитать?

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

Начать можно с простого: а что такое, собственно, UI? В математическом смысле в последнее время пропагандируется что-то вроде: "Интерфейс это функция состояния".

И так и есть: в модных нынче декларативных фреймворках (и в CSS, кстати, тоже) вы определяете состояния, от которых потом строится интерфейс. Разные состояния — разный результат.

Кстати, вот и подошли: а сколько их, этих состояний? Их считали?

Таки да, считали! Вот, например, статья Винса Спилмана о девяти состояниях UI:

Nothing — Пустой элемент
Loading — Загрузка
None — Ничего не вернулось
One — Одна сущность
Some — Коллекция сущностей
Too Many — Сущностей слишком много, нужна пагинация
Incorrect — Ошибка, неуспех
Correct — Успех
Done — Операция завершена

Посмотрите саму статью, там с иллюстрациями и подробнее.

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

Состояние курсора, атрибуты, язык, псевдоклассы, псевдоэлементы, фокус, ARIA, размер и положение экрана, режим энергосбережения, выбранная пользователем тема, состояние сети...

В итоге, что-то получается что фронтенда-то того действительно очень много: https://daverupert.com/2024/02/ui-states/

Я настоятельно рекомендую прочитать статью. Она короткая, просто перечисление, но любой чеклист сдачи проекта обязательно будет содержать если не всё, то часть из списка.

Чем раньше вы уложите у себя в голове факт, что делать и учитывать нужно очень много — тем лучше, котаны.

#frontend #ui #state

​​⚛️ React 19 — useOptimistic

useOptimistic — новый хук, который позволяет отобразить “оптимистичное” состояние. Оно называется “оптимистичным”, потому что мы “оптимистично” надеемся, что наш запрос не свалится с ошибкой и после выполнения запроса состояние будет выглядеть именно так.

❓Как используется

- В useOptimistic передаётся реальное состояние (cart) и функцию-reducer, для обновления оптимистичного состояния
- Компонент (Cart) использует “оптимистичное” состояние (optimisticCart) для рендера
- Перед выполнением запроса обновляется “оптимистичное” состояние
- Когда запрос завершился, нужно обновить реальное состояние
- Как только реальное состояние обновилось, оптимистичное состояние обновится автоматически, так как оно передано в useOptimistic первым параметром. ⚠️ Поэтому важно следить, чтобы приходило одно и тоже состояние.
- Если запрос упал с ошибкой, нужно откатить изменения в оптимистичном состояние.

ℹ️ Первый вопрос, которым я задался, а в чём отличие от обычного setState, путём экспериментов, вот что удалось найти:

- useOptimistic работает с формами. Работать с обычной кнопкой в Single Page Application мне не удалось, обновление происходило только после завершения запроса
- useOptimistic работает только внутри асинхронного обработчика, что логично. Если убрать async/await, обновление произойдёт только после завершения запроса
- Параметр в useState используется только для инициализации, и игнорируется в последующих рендерах. useOptimistic будет сихронизироваться со значением переданным первым параметром.

🤷‍♂️ Очень мало полезного удалось найти о useOptimistic. Во всех статьях и видео тривиальные примеры, нигде не рассказывается как обрабатывать более сложные ситуации:

- Как обновлять оптимистичное состояние, если запустить несколько запросов одновременно?
- Как использовать useOptimistic в SPA вне форм?

Поэтому пришлось создать пару ишью: раз и два. В любом случае, пока useOptimistic выглядит каким-то низкоуровневым API. Надеюсь скоро появится больше Best Practices по его применению. Если вам есть, что добавить — пишите в комментах.

Ещё по теме:

- Frontend First — Ep 179 - React Deep Dive: useOptimistic
- Официальная документация по useOptimistic
- Код из примера тут

#react #frontend #new

#ссылка дня

Подробное руководство по выгоранию входу во фронтенд в 2024 году.

Прекрасно оформленное и проиллюстрированое.

От базы сетей до популярных фреймворков и подготовки резюме. Все баззворды и их пояснение в одном месте.

Пользуемся:
https://frontendmasters.com/guides/front-end-handbook/2024/

#guide #frontend

#статья дня

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

Впрочем, здесь мне помогут Александр Беспоясов, Вадим Юмадилов и Андрей Романов. Фамилия Беспоясова должна быть вам знакома – он отметился в Солидбуке.

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

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

И обязательно обратите внимание на прикреплённые к статье материалы. В них есть всё.

#work #frontend #psychology #бородач

#рекомендация дня

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

Есть ребята из компании 53xapps, занимаются созданием сайтов и автоматизацией бизнеса. Ну и вот они решили запилить свой собственный курс по Frontend разработке.

Конкретно: введение в алгоритмы, HTML/CSS, JavaScript и Vue.js.

Разработка курса заняла около полугода. Большое количество видео и практики.

Подход к обучению немного отличается от других курсов: сперва несколько уроков вас учат понимать алгоритмы и рисовать блок-схемы. После этого обучение становится более осмысленным.

Курс довольно плотный, тестовые студенты проходили его по 15-20 часов в неделю 4 месяца, но сейчас есть возможность проходить курс в спокойном собственном темпе. Все для вас 🙂

Освоите JavaScript, HTML/CSS, Vue.js. Познакомитесь с несколькими популярными библиотеками. Для старта во фронте вполне достаточно.

Есть несколько бесплатных уроков, можно попробовать и пощупать.

Итак, цена. 5000 рублей. А подписчикам канала промокод HTMLSHIT даст 1000 рублей скидки.

Программа курса и бесплатные уроки доступны по ссылке.

#frontend #HTML #CSS #JavaScript

Дэн «наше всё» Абрамов разродился статьёй!

React for Two Computers

— Почему мой компонент работает в браузере, но не на сервере?
— Потому что у тебя теперь два компьютера. Привыкай.

💥 Что вообще происходит?

Раньше React жил в браузере и радовался жизни: всё происходило на клиенте, стейт в useState, кликнули — перерендерили.

А теперь у нас появился второй «компьютер» — сервер. С серверными компонентами, приватными API, тяжёлыми вычислениями и всем остальным. И теперь React — это не просто `f(state)`, а f(data, state), где:

- data — с сервера, рендерится один раз
- state — в браузере, реагирует на действия пользователя

🧠 React теперь работает в двух мирах:

- Сервер — отвечает за данные, безопасность и тяжёлую работу
- Клиент — за мгновенные отклики, интерактив и состояние

Они живут в разных средах, но должны строить один интерфейс. И вот тут начинается веселье.

🧩 Но в чём подвох?

Абрамов говорит прямо: разделение компонентов на клиентские и серверные — это боль.

- Хочешь использовать хук? Прости, сервер не умеет
- Хочешь загрузить данные? Сервер умеет, но клиент не должен знать как
- Хочешь просто написать код? Удачи с этими use client, use server, границами, пропами и тайпингом

🧠 Примеры из статьи

- <Counter /> — типичный клиентский компонент. Быстрый отклик, стейт, интерактив
- <PostPreview /> — серверный. Может грузить пост из базы и вообще не попадать в бандл клиента

И вдруг возникает челлендж: а как показать список <PostPreview />, а рядом <Counter /> для лайков? Как они будут жить вместе?

Ответ: через пропсы, границы, и много боли.

📦 React как Lego из серверных и клиентских кусочков

Абрамов не просто жалуется — он исследует. Он пытается найти модель мышления, при которой:

- Ты не дублируешь код
- UI остаётся отзывчивым
- Компоненты переиспользуемы
- И при этом ты не хочешь сжечь проект через неделю

Он говорит: возможно, будущее React — это когда мы думаем не в терминах "компоненты", а в терминах "где этот кусок должен жить?"

🎥 Есть и видео!

Если лень читать или хочется живого контекста — Дэн рассказал всё это на конференции React Conf 2024.
Там много примеров и визуальных пояснений.

🧨 Финалим

«React теперь не просто библиотека для UI. Это **координация между двумя средами исполнения**. Между клиентом и сервером. И это сложно. Но в этом сила.»

Пока что — это боль.
Но если мы научимся думать в этой модели — React станет по-настоящему мощным инструментом для приложений нового поколения.

🔗 Читать статью целиком

📺 Смотреть видео React Conf 2024

#react #frontend #абрамов #servercomponents

The frontend is dead, long live the frontend! Evolve or die. What? Let's figure it out.

I've been in this business for a long time: I saw the era of BBS's and the sunset of perl-based sites, I saw the rise of php3 and jQuery, and how React killed everything else. And remember the profession of "HTML/CSS coder" or "Markup developer" (aka "verstalshik")? Well, it looks like classic frontend developers will soon follow them.

And it's not just that Claude can finally vertically align an element and you no longer need a senior dev with 15 years of experience for that - it's about the value of frontend as a whole.

🍄 Point 1: damn chats everywhere

Frontend is the UI for customers, which gives them the UX they pay for. Frontend devs make the frontend.

But what happens if all UIs get replaced by chats with a couple of buttons? - We'll get unification.

Literally, right now you can build a fairly complex startup where there's nothing but a landing page and a button to connect an MCP/skill to your Claude Desktop and ChatGPT. Moreover, sometimes a landing page isn't even needed, because everything is already inside agents ecosystems.

Somewhat reminds of the Telegram bots story, but at x1000 scale.

Why do we need frontend devs if there's no frontend?

🍄 Point 2: disposability

For the past week I've been working on a project, running 1-3 hour AI loops in Claude Code and Codex multiple times per day, and of course the resulting code was complete crap.
More precisely, overall it was more like the miracle of the creation of the world, but if you zoom it in places it was total garbage.

But that doesn't matter, for two reasons:
- I could point the agent at any place in the project, show it the browser (mcp devtools is love), write "this s**t doesn't work here, fix it", and it would fix everything
- despite extensive ideation, I missed the proper data flow, but even big logical misses were eliminated in half an hour with another loop run

So my value as a frontend developer was even lower than my value as a manual tester. And the entire frontend was literally disposable, and whole chunks were redone at my command in literally half an hour per case.

Now imagine an agent that watches how user clicks on a site, analyzes it, and then adjusts the UI itself to make the UX better for users. Almost live. Sounds crazy? Let's discuss it in 5 years.

🍄 The survivors

Meanwhile, the value of backend and cloud engineers is still much higher, due to questions of security and resources.

Although, I saw with my own eyes how Claude Code clicked around in my browser in the Google Cloud Console - it was really scary, though in the end everything went off successfully.

So what to do? At least N years from now.
- developers - accept fate and develop soft skills, primarily around product management and agent orchestration
- companies - look for these soft skills, look deeply into ways of working, not just at whether a person knows something about AI and Claude Code (which will be obsolete again in half a year), plus traditional non-coding skills
- another option - go work in chop-shops, where frontend wizards with long beards and 30 years of experience hand-carve Fabergé frontends, while others slather it on with a thick brush of agents, earning millions - there will always be demand for high art and its own clientele

Or am I being too gloomy? What do you think about the future of frontend developers as a standalone profession?

#Frontend #AI #Coding #SoftwareDevelopment #FrontendDevelopment #WebDevelopment #ClaudeAI #AIAgents #FutureOfWork #DeveloperTools

Original post: https://www.linkedin.com/posts/alexander-remi_frontend-ai-coding-activity-7453310522881359872-EHZZ