#фронтенд — Public Fediverse posts

Книга: «Фулстек JavaScript: Секреты, которые должен знать каждый мидл»

Привет, Хаброжители! Как практикующий разработчик ПО вы уже умеете качественно выполнять задачи — на фронтенде или бэкенде. Пора перейти на следующую ступеньку карьерной лестницы и развить навыки, которыми обладают эксперты и senior-разработчики.

https://habr.com/ru/companies/piter/articles/1033060/

#JS #фулстек #фронтэнд #фронтенд #Симпсон #fullstack #javascript #книги_по_программированию #книга

Книга: «Фулстек JavaScript: Секреты, которые должен знать каждый мидл»

Привет, Хаброжители! Как практикующий разработчик ПО вы уже умеете качественно выполнять задачи — на фронтенде или бэкенде. Пора перейти на следующую ступеньку карьерной лестницы и развить навыки, которыми обладают эксперты и senior-разработчики.

https://habr.com/ru/companies/piter/articles/1033060/

#JS #фулстек #фронтэнд #фронтенд #Симпсон #fullstack #javascript #книги_по_программированию #книга

Книга: «Фулстек JavaScript: Секреты, которые должен знать каждый мидл»

Привет, Хаброжители! Как практикующий разработчик ПО вы уже умеете качественно выполнять задачи — на фронтенде или бэкенде. Пора перейти на следующую ступеньку карьерной лестницы и развить навыки, которыми обладают эксперты и senior-разработчики.

https://habr.com/ru/companies/piter/articles/1033060/

#JS #фулстек #фронтэнд #фронтенд #Симпсон #fullstack #javascript #книги_по_программированию #книга

Книга: «Фулстек JavaScript: Секреты, которые должен знать каждый мидл»

Привет, Хаброжители! Как практикующий разработчик ПО вы уже умеете качественно выполнять задачи — на фронтенде или бэкенде. Пора перейти на следующую ступеньку карьерной лестницы и развить навыки, которыми обладают эксперты и senior-разработчики.

https://habr.com/ru/companies/piter/articles/1033060/

#JS #фулстек #фронтэнд #фронтенд #Симпсон #fullstack #javascript #книги_по_программированию #книга

WebMCP. Что скрывается за черновиком стандарта

Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы. Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?

https://habr.com/ru/articles/1031164/

#webmcp #mcp #ииагенты #javascript #agentic_web #фронтенд #chrome

WebMCP. Что скрывается за черновиком стандарта

Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы. Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?

https://habr.com/ru/articles/1031164/

#webmcp #mcp #ииагенты #javascript #agentic_web #фронтенд #chrome

WebMCP. Что скрывается за черновиком стандарта

Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы. Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?

https://habr.com/ru/articles/1031164/

#webmcp #mcp #ииагенты #javascript #agentic_web #фронтенд #chrome

WebMCP. Что скрывается за черновиком стандарта

Действия ИИ-агента в браузере через скриншоты и клики — минута и десятки центов. Через WebMCP — секунды и доли цента. Два порядка разницы. Так что же под этим черновиком стандарта WebMCP и куда он нас ведёт?

https://habr.com/ru/articles/1031164/

#webmcp #mcp #ииагенты #javascript #agentic_web #фронтенд #chrome

Экономим нервные клетки: как передавать макеты в разработку

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

https://habr.com/ru/companies/lemana_tech/articles/1026956/

#чеклист #дизайн #фронтенд #передача_макета_в_разработку #передача_макетов #дизайнпроцесс #продуктовый_дизайн #дизайн_и_разработка #дизайн_интерфейсов

Разработка фронтенда интернет-магазина через Qwen 3.6 Plus и Qwen ClI

Привет всем. Расскажу про свой личный опыт разработки через Qwen 3.6 Plus и Qwen ClI. И да, статья полностью написана человеком. Это небольшой pet-проект, сделанный в момент, когда Qwen 3.6 Plus был бесплатным с лимитом в 1000 запросов в день. Проект представляет из себя фронтенд вымышленного интернет-магазина по продаже микрокомпьютеров. Цель была протестировать возможности Qwen. На весь проект у меня ушло 4 дня по 2-3 часа.

https://habr.com/ru/articles/1027928/

#Фронтенд #ииагенты #qwen36

Работа с легаси кодом: не переписывать, а приручить

Привет, Хабр! Я Валерий Маланин, фронтенд-разработчик в команде Modus BI. И по опыту знаю, что каждый разработчик хотя бы раз мечтал попасть на проект, где всё с нуля. Свежий стек, понятная архитектура, аккуратные модули, тесты, документация и никаких комментариев в духе «не трогать, иначе всё упадёт». В таком проекте легко писать новый код и приятно разбираться в старом. Но в реальности всё обычно выглядит иначе. Команда приходит в продукт — а там React 16, Webpack 2, компонент на две тысячи строк, круговые зависимости и ни одного теста. И это не исключение, а обычная картина для живой системы, которая давно работает в проде. Любой проект со временем накапливает легаси. Бизнес торопит и заставляет срезать углы. Команда меняется, и вместе с ней уходит контекст старых решений. Технологии устаревают, а код остаётся. В итоге систему становится страшно менять, потому что никто до конца не понимает, что сломается после очередной правки.

https://habr.com/ru/companies/modusbi/articles/1027368/

#legacy #legacyкод #рефакторинг #strangler_fig #археология_кода #модульность #фронтендразработка #фронтенд #frontend #webpack

Работа с легаси кодом: не переписывать, а приручить

Привет, Хабр! Я Валерий Маланин, фронтенд-разработчик в команде Modus BI. И по опыту знаю, что каждый разработчик хотя бы раз мечтал попасть на проект, где всё с нуля. Свежий стек, понятная архитектура, аккуратные модули, тесты, документация и никаких комментариев в духе «не трогать, иначе всё упадёт». В таком проекте легко писать новый код и приятно разбираться в старом. Но в реальности всё обычно выглядит иначе. Команда приходит в продукт — а там React 16, Webpack 2, компонент на две тысячи строк, круговые зависимости и ни одного теста. И это не исключение, а обычная картина для живой системы, которая давно работает в проде. Любой проект со временем накапливает легаси. Бизнес торопит и заставляет срезать углы. Команда меняется, и вместе с ней уходит контекст старых решений. Технологии устаревают, а код остаётся. В итоге систему становится страшно менять, потому что никто до конца не понимает, что сломается после очередной правки.

https://habr.com/ru/companies/modusbi/articles/1027368/

#legacy #legacyкод #рефакторинг #strangler_fig #археология_кода #модульность #фронтендразработка #фронтенд #frontend #webpack

Работа с легаси кодом: не переписывать, а приручить

Привет, Хабр! Я Валерий Маланин, фронтенд-разработчик в команде Modus BI. И по опыту знаю, что каждый разработчик хотя бы раз мечтал попасть на проект, где всё с нуля. Свежий стек, понятная архитектура, аккуратные модули, тесты, документация и никаких комментариев в духе «не трогать, иначе всё упадёт». В таком проекте легко писать новый код и приятно разбираться в старом. Но в реальности всё обычно выглядит иначе. Команда приходит в продукт — а там React 16, Webpack 2, компонент на две тысячи строк, круговые зависимости и ни одного теста. И это не исключение, а обычная картина для живой системы, которая давно работает в проде. Любой проект со временем накапливает легаси. Бизнес торопит и заставляет срезать углы. Команда меняется, и вместе с ней уходит контекст старых решений. Технологии устаревают, а код остаётся. В итоге систему становится страшно менять, потому что никто до конца не понимает, что сломается после очередной правки.

https://habr.com/ru/companies/modusbi/articles/1027368/

#legacy #legacyкод #рефакторинг #strangler_fig #археология_кода #модульность #фронтендразработка #фронтенд #frontend #webpack

Работа с легаси кодом: не переписывать, а приручить

Привет, Хабр! Я Валерий Маланин, фронтенд-разработчик в команде Modus BI. И по опыту знаю, что каждый разработчик хотя бы раз мечтал попасть на проект, где всё с нуля. Свежий стек, понятная архитектура, аккуратные модули, тесты, документация и никаких комментариев в духе «не трогать, иначе всё упадёт». В таком проекте легко писать новый код и приятно разбираться в старом. Но в реальности всё обычно выглядит иначе. Команда приходит в продукт — а там React 16, Webpack 2, компонент на две тысячи строк, круговые зависимости и ни одного теста. И это не исключение, а обычная картина для живой системы, которая давно работает в проде. Любой проект со временем накапливает легаси. Бизнес торопит и заставляет срезать углы. Команда меняется, и вместе с ней уходит контекст старых решений. Технологии устаревают, а код остаётся. В итоге систему становится страшно менять, потому что никто до конца не понимает, что сломается после очередной правки.

https://habr.com/ru/companies/modusbi/articles/1027368/

#legacy #legacyкод #рефакторинг #strangler_fig #археология_кода #модульность #фронтендразработка #фронтенд #frontend #webpack

Почему я так придираюсь к вёрстке (и вам советую)

Привет! Я Оля, лид дизайн‑системы Альфа‑Банка на мобильных платформах и я всерьёз считаю, что знания о вёрстке незаслуженно списали со счетов, особенно в 2026 году, когда дизайнеры всё чаще думают, что ИИ сделает за них всю работу, а вёрстку вообще можно не трогать. Увы и ах. Вёрстка — это не просто «разложить прямоугольники на макете». Это мост между дизайном и кодом. И — спойлер: ИИ тоже нужно учить, и учить на правильных примерах, но сначала стоило бы научиться вёрстке самому. Про ИИ в этой статье не будет — но зато будет много про православную ручную вёрстку: расскажу, почему считаю важным обращать на неё внимание при создании макетов и заранее закладывать правила, по которым она формируется. Особенно в эпоху, когда конкуренция высока, а ИИ кажется волшебной таблеткой.

https://habr.com/ru/companies/alfa/articles/1025680/

#продуктовый_дизайн #вёрстка #дизайн #дизайн_интерфейсов #дизайнеру #фронтенд

Фронтенд — это REST-сервер

Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел. Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо. Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API. Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые. Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.

https://habr.com/ru/articles/1022458/

#архитектура #проектирование #бэкенд #фронтенд #стандартизация #спецификация

Как контролировать токены: поиск ошибок, версионирование и графы в едином дашборде

Как только дизайн-система разрастается больше, чем на 10-20 кнопок, а брендов у вас становится несколько — JSON-файлы с токенами превращаются в кошмар. Дизайнеры экспортируют токены из Figma, разработчики получают пулл-реквест на 5000 строк измененного кода, и никто в здравом уме не может сказать: "А что именно поменялось и ничего ли мы не сломали?" А если вместо английской буквы "c" в коде будет русская? А что если токен зациклился сам на себя? А если у одних токенов более 3-х уровней вложенности, то как поведет себя система? А если нужного токена нет в одном из модов? Да и вообще, как узнать, какие токены можно вынести в примитивы, а какие в семантику и отдельные файлы для брендов? Чтобы решить эти проблемы, я написал веб-интерфейс Tokens Dashboard — ты кидаешь в него JSON (архив, папку, файл, несколько файлов — не важно), а он выдает красивую и понятную аналитику. И сегодня мы разберемся, как это работает. Программа полностью бесплатная и доступна как для пользователей Mac OS, так и Linux / Windows. Она портативна и не мусорит в системе — вы просто удаляете папку, если она вам больше не нужна. Посмотреть кейс

https://habr.com/ru/articles/1025146/

#дизайнсистема #дизайнтокены #figma #фронтенд #архитектура #кодревью #аудит_кода #json #графы #open_source

От #FFF к OKLCH: как эволюция цветовых моделей меняет веб-разработку

Помните времена, когда цвета в CSS выбирались почти наугад? Белый фон — #FFF , чёрный текст — #000 , акцент — какой-нибудь #3498db , который просто нормально смотрится? Для раннего веба этого хватало. Интерфейсы были проще, экраны — одинаковее, а требования к доступности, темам и визуальной консистентности ещё не давили на разработку так сильно, как сейчас. Но современная веб-разработка давно ушла от логики «подобрали цвет и забыли». Сегодня интерфейс должен одинаково уверенно жить в светлой и тёмной теме, не ломаться на широком цветовой охвате дисплеев, держать читаемый контраст в веб-дизайне и при этом оставаться удобным для поддержки. Именно поэтому эволюция цветовых моделей стала важной инженерной темой. Сейчас цвета в CSS — это целый набор подходов, через которые проект решает задачи доступности, масштабируемости и удобства разработки. И на этом фоне OKLCH всё чаще рассматривают как следующий логичный шаг: модель, которая лучше соответствует человеческому восприятию и помогает строить более стабильные палитры.

https://habr.com/ru/articles/1024482/

#css #oklch #вебдизайн #дизайнсистемы #фронтенд #hsl #rgb #цветовые_пространства

От #FFF к OKLCH: как эволюция цветовых моделей меняет веб-разработку

Помните времена, когда цвета в CSS выбирались почти наугад? Белый фон — #FFF , чёрный текст — #000 , акцент — какой-нибудь #3498db , который просто нормально смотрится? Для раннего веба этого хватало. Интерфейсы были проще, экраны — одинаковее, а требования к доступности, темам и визуальной консистентности ещё не давили на разработку так сильно, как сейчас. Но современная веб-разработка давно ушла от логики «подобрали цвет и забыли». Сегодня интерфейс должен одинаково уверенно жить в светлой и тёмной теме, не ломаться на широком цветовой охвате дисплеев, держать читаемый контраст в веб-дизайне и при этом оставаться удобным для поддержки. Именно поэтому эволюция цветовых моделей стала важной инженерной темой. Сейчас цвета в CSS — это целый набор подходов, через которые проект решает задачи доступности, масштабируемости и удобства разработки. И на этом фоне OKLCH всё чаще рассматривают как следующий логичный шаг: модель, которая лучше соответствует человеческому восприятию и помогает строить более стабильные палитры.

https://habr.com/ru/articles/1024482/

#css #oklch #вебдизайн #дизайнсистемы #фронтенд #hsl #rgb #цветовые_пространства

От #FFF к OKLCH: как эволюция цветовых моделей меняет веб-разработку

Помните времена, когда цвета в CSS выбирались почти наугад? Белый фон — #FFF , чёрный текст — #000 , акцент — какой-нибудь #3498db , который просто нормально смотрится? Для раннего веба этого хватало. Интерфейсы были проще, экраны — одинаковее, а требования к доступности, темам и визуальной консистентности ещё не давили на разработку так сильно, как сейчас. Но современная веб-разработка давно ушла от логики «подобрали цвет и забыли». Сегодня интерфейс должен одинаково уверенно жить в светлой и тёмной теме, не ломаться на широком цветовой охвате дисплеев, держать читаемый контраст в веб-дизайне и при этом оставаться удобным для поддержки. Именно поэтому эволюция цветовых моделей стала важной инженерной темой. Сейчас цвета в CSS — это целый набор подходов, через которые проект решает задачи доступности, масштабируемости и удобства разработки. И на этом фоне OKLCH всё чаще рассматривают как следующий логичный шаг: модель, которая лучше соответствует человеческому восприятию и помогает строить более стабильные палитры.

https://habr.com/ru/articles/1024482/

#css #oklch #вебдизайн #дизайнсистемы #фронтенд #hsl #rgb #цветовые_пространства

От #FFF к OKLCH: как эволюция цветовых моделей меняет веб-разработку

Помните времена, когда цвета в CSS выбирались почти наугад? Белый фон — #FFF , чёрный текст — #000 , акцент — какой-нибудь #3498db , который просто нормально смотрится? Для раннего веба этого хватало. Интерфейсы были проще, экраны — одинаковее, а требования к доступности, темам и визуальной консистентности ещё не давили на разработку так сильно, как сейчас. Но современная веб-разработка давно ушла от логики «подобрали цвет и забыли». Сегодня интерфейс должен одинаково уверенно жить в светлой и тёмной теме, не ломаться на широком цветовой охвате дисплеев, держать читаемый контраст в веб-дизайне и при этом оставаться удобным для поддержки. Именно поэтому эволюция цветовых моделей стала важной инженерной темой. Сейчас цвета в CSS — это целый набор подходов, через которые проект решает задачи доступности, масштабируемости и удобства разработки. И на этом фоне OKLCH всё чаще рассматривают как следующий логичный шаг: модель, которая лучше соответствует человеческому восприятию и помогает строить более стабильные палитры.

https://habr.com/ru/articles/1024482/

#css #oklch #вебдизайн #дизайнсистемы #фронтенд #hsl #rgb #цветовые_пространства

Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах

Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.

https://habr.com/ru/articles/1024404/

#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд

Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах

Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.

https://habr.com/ru/articles/1024404/

#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд

Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах

Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.

https://habr.com/ru/articles/1024404/

#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд

Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах

Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.

https://habr.com/ru/articles/1024404/

#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд

Мультимодальные модели – грубый и дорогой инструмент

Пока все в погоне за всё более универсальными ИИ-агентами пытаясь создать тот самый AGI по нашему подобию, мне кажется полезным спуститься на уровень ниже и посмотреть на более приземлённую инженерную проблему. Мы неплохо научили модели работать с текстом, кодом, изображениями и инструментами. Мы научили их вызывать функции, научили эти ИИ писать собственные инструменты каждый раз для задач которые повторяются миллионы раз, видеть как мы(фото), думать как мы(рассуждения). Мы научились – дообучать их под новые сценарии через fine-tuning. Но если убрать хайп, остаётся неприятный факт: во многих практических задачах модели по-прежнему работают грубо и дорого. Особенно хорошо это видно на фронтенде. Сегодня у модели есть два типовых способа "увидеть" сайт. Первый – читать код: HTML, CSS, JS, и серверную логику (если вы предоставили модели доступ). Второй – смотреть на скриншоты, а в более дорогом варианте – на видео (хоть и таких решений я не видел, и скорее не видео, а слайд-шоу, но считаю логичным внедрением для некоторых сценариев). И эти оба подхода неудобны. А обучать модель внутреннему представлению через имеющиеся виды зрения – как правильно, – как распознать кнопку итд – дорого, требует ещё больших данных, больше вычислений. А банально небольшое отклонение стиля уже ломает верстку. Да с бэкендом мы можем строить среду в которой благодаря RL обучению модель научится решать задачу. Но как быть с интерфейсом? Фото дает слишком много шума в виде пикселей, а код дает много лишнего шума в виде разметки, скриптов. Когда обычному пользователю: не нужно смотреть на каждый серый пиксель фона кнопки, или изучать все стили, js и html разметку сайта, он видит овал на котором написано "войти" – и понимает что это – кнопка, особенно, если при наведении или нажатии цвет фона кнопки меняется.

https://habr.com/ru/articles/1023916/

#мультимодальные_модели #интерфейсы #вебинтерфейсы #фронтенд #dom #computer_vision #ui #ai_agents

Мультимодальные модели – грубый и дорогой инструмент

Пока все в погоне за всё более универсальными ИИ-агентами пытаясь создать тот самый AGI по нашему подобию, мне кажется полезным спуститься на уровень ниже и посмотреть на более приземлённую инженерную проблему. Мы неплохо научили модели работать с текстом, кодом, изображениями и инструментами. Мы научили их вызывать функции, научили эти ИИ писать собственные инструменты каждый раз для задач которые повторяются миллионы раз, видеть как мы(фото), думать как мы(рассуждения). Мы научились – дообучать их под новые сценарии через fine-tuning. Но если убрать хайп, остаётся неприятный факт: во многих практических задачах модели по-прежнему работают грубо и дорого. Особенно хорошо это видно на фронтенде. Сегодня у модели есть два типовых способа "увидеть" сайт. Первый – читать код: HTML, CSS, JS, и серверную логику (если вы предоставили модели доступ). Второй – смотреть на скриншоты, а в более дорогом варианте – на видео (хоть и таких решений я не видел, и скорее не видео, а слайд-шоу, но считаю логичным внедрением для некоторых сценариев). И эти оба подхода неудобны. А обучать модель внутреннему представлению через имеющиеся виды зрения – как правильно, – как распознать кнопку итд – дорого, требует ещё больших данных, больше вычислений. А банально небольшое отклонение стиля уже ломает верстку. Да с бэкендом мы можем строить среду в которой благодаря RL обучению модель научится решать задачу. Но как быть с интерфейсом? Фото дает слишком много шума в виде пикселей, а код дает много лишнего шума в виде разметки, скриптов. Когда обычному пользователю: не нужно смотреть на каждый серый пиксель фона кнопки, или изучать все стили, js и html разметку сайта, он видит овал на котором написано "войти" – и понимает что это – кнопка, особенно, если при наведении или нажатии цвет фона кнопки меняется.

https://habr.com/ru/articles/1023916/

#мультимодальные_модели #интерфейсы #вебинтерфейсы #фронтенд #dom #computer_vision #ui #ai_agents

Мультимодальные модели – грубый и дорогой инструмент

Пока все в погоне за всё более универсальными ИИ-агентами пытаясь создать тот самый AGI по нашему подобию, мне кажется полезным спуститься на уровень ниже и посмотреть на более приземлённую инженерную проблему. Мы неплохо научили модели работать с текстом, кодом, изображениями и инструментами. Мы научили их вызывать функции, научили эти ИИ писать собственные инструменты каждый раз для задач которые повторяются миллионы раз, видеть как мы(фото), думать как мы(рассуждения). Мы научились – дообучать их под новые сценарии через fine-tuning. Но если убрать хайп, остаётся неприятный факт: во многих практических задачах модели по-прежнему работают грубо и дорого. Особенно хорошо это видно на фронтенде. Сегодня у модели есть два типовых способа "увидеть" сайт. Первый – читать код: HTML, CSS, JS, и серверную логику (если вы предоставили модели доступ). Второй – смотреть на скриншоты, а в более дорогом варианте – на видео (хоть и таких решений я не видел, и скорее не видео, а слайд-шоу, но считаю логичным внедрением для некоторых сценариев). И эти оба подхода неудобны. А обучать модель внутреннему представлению через имеющиеся виды зрения – как правильно, – как распознать кнопку итд – дорого, требует ещё больших данных, больше вычислений. А банально небольшое отклонение стиля уже ломает верстку. Да с бэкендом мы можем строить среду в которой благодаря RL обучению модель научится решать задачу. Но как быть с интерфейсом? Фото дает слишком много шума в виде пикселей, а код дает много лишнего шума в виде разметки, скриптов. Когда обычному пользователю: не нужно смотреть на каждый серый пиксель фона кнопки, или изучать все стили, js и html разметку сайта, он видит овал на котором написано "войти" – и понимает что это – кнопка, особенно, если при наведении или нажатии цвет фона кнопки меняется.

https://habr.com/ru/articles/1023916/

#мультимодальные_модели #интерфейсы #вебинтерфейсы #фронтенд #dom #computer_vision #ui #ai_agents

Мультимодальные модели – грубый и дорогой инструмент

Пока все в погоне за всё более универсальными ИИ-агентами пытаясь создать тот самый AGI по нашему подобию, мне кажется полезным спуститься на уровень ниже и посмотреть на более приземлённую инженерную проблему. Мы неплохо научили модели работать с текстом, кодом, изображениями и инструментами. Мы научили их вызывать функции, научили эти ИИ писать собственные инструменты каждый раз для задач которые повторяются миллионы раз, видеть как мы(фото), думать как мы(рассуждения). Мы научились – дообучать их под новые сценарии через fine-tuning. Но если убрать хайп, остаётся неприятный факт: во многих практических задачах модели по-прежнему работают грубо и дорого. Особенно хорошо это видно на фронтенде. Сегодня у модели есть два типовых способа "увидеть" сайт. Первый – читать код: HTML, CSS, JS, и серверную логику (если вы предоставили модели доступ). Второй – смотреть на скриншоты, а в более дорогом варианте – на видео (хоть и таких решений я не видел, и скорее не видео, а слайд-шоу, но считаю логичным внедрением для некоторых сценариев). И эти оба подхода неудобны. А обучать модель внутреннему представлению через имеющиеся виды зрения – как правильно, – как распознать кнопку итд – дорого, требует ещё больших данных, больше вычислений. А банально небольшое отклонение стиля уже ломает верстку. Да с бэкендом мы можем строить среду в которой благодаря RL обучению модель научится решать задачу. Но как быть с интерфейсом? Фото дает слишком много шума в виде пикселей, а код дает много лишнего шума в виде разметки, скриптов. Когда обычному пользователю: не нужно смотреть на каждый серый пиксель фона кнопки, или изучать все стили, js и html разметку сайта, он видит овал на котором написано "войти" – и понимает что это – кнопка, особенно, если при наведении или нажатии цвет фона кнопки меняется.

https://habr.com/ru/articles/1023916/

#мультимодальные_модели #интерфейсы #вебинтерфейсы #фронтенд #dom #computer_vision #ui #ai_agents

Как я сделал PWA-приложение для заметок и ссылок за вечер (и почему оно работает без интернета)

У каждого из нас есть «чёрная дыра», куда уходят полезные ссылки. Кто-то сохраняет их в «Избранном» браузера, кто-то пишет сам себе в Telegram, кто-то держит десяток вкладок открытыми «на потом». У меня была та же проблема. Я пробовал Notion, Evernote, Google Keep, Obsidian - всё это мощные инструменты, но для простого «сохранить ссылку и не забыть» они часто избыточны. Так родилась идея KylikLink - минималистичного PWA-приложения для заметок и ссылок, которое работает без интернета и не требует регистрации.

https://habr.com/ru/articles/1023144/

#pwa #вебразработка #html #css #javascript #фронтенд #frontend #localstorage #service_worker #заметки

Как я пытался сделать анимацию для игры с помощью ИИ — и чуть не навайбкодил нервный срыв

Привет, Хабр. Я — Андрей Макар-Уваров, Head of Frontend в Surf. Недавно решил проверить одну гипотезу: насколько далеко можно уехать на ИИ в разработке, если взять задачу, в которой ты абсолютный ноль. Как стартовую точку выбрал микро-игру. Идея простая: рыжий кот с фонарём ходит по тёмному лабиринту, находит других животных и передаёт им свет. Например, можно оставить свет зайчику, чтобы он подсвечивал проход, или забрать его и усилить собственный фонарь. Должен был получиться небольшой атмосферный пазл про свет, тьму и управление ограниченным ресурсом. И вот что получилось.

https://habr.com/ru/articles/1021258/

#gamedev #grok #иимодель #игры #разработка_игр #blender #анимация #анимация_и_3d_графика #игростроение #фронтенд

От промпта к мутациям: как я перестал писать тесты руками и собрал команду из 7 AI-агентов

14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента. Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде. Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами. Поехали

https://habr.com/ru/articles/1020066/

#React #тестирование #AI #React_Testing_Library #мутационное_тестирование #Claude_Code #LLM #автоматизация #фронтенд #TypeScript

«Фронтенд умер»? Жаль, что я узнала об этом только после четырех лет учебы

Предлагаю открыть портал в ад и задать вопрос, который сейчас, кажется, витает в воздухе у всех, кто связан с разработкой: фронтенд вообще еще жив? Или логичнее уже сейчас срочно переучиваться, пока через пару лет не пришлось делать это в панике? Я задаю этот вопрос не как человек с десятилетним опытом, стабильной работой и философским спокойствием. Я задаю его как человек, который четыре года учился, чтобы войти в профессию, а вышел на рынок в момент, когда отовсюду слышно одно и то же: IT умерло, джуны никому не нужны, нейросети уже пишут код, а дальше будет только хуже.

https://habr.com/ru/articles/1019196/

#фронтенд #рынок_труда_в_IT #карьера_разработчика #React #JavaScript #нейросети #поиск_работы_в_IT #junior_разработчик #frontend_developer

От статического зоопарка доменов до одного ядра на Next: лендинг тафтинг-студии и перенос в свой boilerplate

Несколько лет назад пришла задача сверстать лендинг для студии тафтинга в Казани —

https://habr.com/ru/articles/1018608/

#фронтенд #быстрый_старт #бизнес #бизнес_студии

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Как мы отслеживаем производительность веб-сервисов, или Дело «Скорости»

Салют, Хабр! Я Паша, вхожу в группу обеспечения производительности интерфейсов. Эту статью мы написали с Сергеем @TrueNort — руководителем группы. В SberDevices её называют командой «Скорость». Под надзором «Скорости» более двадцати веб-сервисов, каждый из которых должен работать быстро и точно. А значит, нужна система мониторинга производительности с гибкими настройками, чуткой реакцией на изменения и оперативными сообщениями о проблемах. В статье расскажем, зачем мы нормируем метрики логарифмами, как скрипт превращает данные из ClickHouse в алёрты и как удобнее отображать данные. Словом, поделимся нашим опытом контроля производительности веб-ресурсов.

https://habr.com/ru/companies/sberdevices/articles/1006020/

#sber #вебресурсы #Grafana #ClickHouse #GigaChat #фронтенд #производительность #Core_Web_Vitals

Stitches закрыт — да здравствует StyleX

История фронтенда хорошо показывает, что инструменты редко исчезают мгновенно. Чаще они проходят понятный цикл: сначала решают конкретную проблему и быстро набирают популярность, потом становятся привычной частью стека, а со временем уступают место следующему подходу. Примерно так развивается и CSS-in-JS. Когда он появился, это выглядело логичным шагом: стили рядом с компонентами, темы, токены и удобная интеграция с React. Со временем стало ясно, что у этой модели есть и ограничения — стили генерируются в рантайме, усложняется SSR, а в больших приложениях начинают накапливаться накладные расходы. Появились попытки сделать CSS-in-JS легче и быстрее. Одной из них стал Stitches: он сохранил удобный DX и заметно сократил рантайм. Но развитие проекта остановилось, а требования к фронтенду продолжают расти. Поэтому всё чаще обсуждают другой подход — перенос генерации стилей на этап сборки. В этой логике и появился StyleX.

https://habr.com/ru/articles/1008446/

#вебразработка #стайлинг #фронтенд #библиотеки #стилизация #styledcomponents #css #sass #css_modules

Отображение Excel в React: экспериментальный прототип с merge и изначальной структурой

Снова на связи я –Дмитрий, React-разработчик, и в этот раз мы поговорим о создании фундамента для дальнейшей разработки. Идея — сделать компонент в реакте, который сможет отобразить файл Excel в обычной HTML-таблице со всеми слияниями ячеек, форматированием, несколькими строками заголовка и полностью сохранённой структурой. Казалось бы, задача простая: берёшь любую библиотеку, читаешь файл и показываешь. На практике всё оказалось гораздо интереснее.

https://habr.com/ru/companies/gnivc/articles/972012/

#excel #react #reactjs #html #frontendразработка #frontend #xlsx #javascript #фронтенд #фронтендразработка

Как React обновляет UI: trigger → render → commit

Когда говорят «React перерендерился» — обычно имеют в виду что-то расплывчатое. Новичкам это слово объясняет всё и ничего одновременно. В официальной документации процесс описан точнее: trigger → render → commit . Давайте разберём, что происходит на каждом этапе — без магии, зато с Fiber, флагами и браузерным пайплайном.

https://habr.com/ru/articles/1016180/

#javascript #react #reactjs #фронтенд #frontend #браузер #render #rerender #commit #fiber

Как починить фронтенд продукта компании за $800B за вечер

ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится. Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача. Мне это надоело и я полез разбираться.

https://habr.com/ru/articles/1005004/

#ChatGPT #Chrome_extension #performance #DOM #React #виртуализация #OpenAI #фронтенд

Как починить фронтенд продукта компании за $800B за вечер

ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится. Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача. Мне это надоело и я полез разбираться.

https://habr.com/ru/articles/1005004/

#ChatGPT #Chrome_extension #performance #DOM #React #виртуализация #OpenAI #фронтенд

Как починить фронтенд продукта компании за $800B за вечер

ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится. Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача. Мне это надоело и я полез разбираться.

https://habr.com/ru/articles/1005004/

#ChatGPT #Chrome_extension #performance #DOM #React #виртуализация #OpenAI #фронтенд

Как починить фронтенд продукта компании за $800B за вечер

ChatGPT умирает на длинных разговорах. Не AI-часть — модель отлично держит тысячи сообщений. Умирает фронтенд. Таб зависает, скролл лагает, иногда браузер просто крашится. Самое обидное — именно длинные разговоры самые ценные. Чем дольше обсуждаешь, тем больше контекста у модели, тем полезнее ответы. А продукт ломается ровно в тот момент, когда начинается максимальная отдача. Мне это надоело и я полез разбираться.

https://habr.com/ru/articles/1005004/

#ChatGPT #Chrome_extension #performance #DOM #React #виртуализация #OpenAI #фронтенд

Как техдолг убивает и спасает проекты одновременно

Технический долг - неизбежная часть любого проекта. С течением времени даже хорошо написанный код может стать сложным для понимания и сопровождения. Часто разработчики, сталкиваясь с чужим или собственным кодом, испытывают отвращение - и только после проверки истории изменений гита понимают, что автором кода являлись они же. Эта статья - не лекция. В интернете полно материалов про технический долг с графиками, квадратиками и теориями. Будем честны: большинство просто игнорирует его. Здесь мы попробуем посмотреть на технический долг так, как он есть на практике - как финансовый инструмент . Как кредитная карта с высоким процентом и мелким шрифтом: ею можно пользоваться, чтобы держаться на плаву, но потеря контроля может стоить проекту слишком дорого. Так и как же им управлять?

https://habr.com/ru/articles/963876/

#чистый_код #разработка #айти #фронтенд #бекенд #backend #frotend #качество_кода #it #информационные_технологии

Минималистичная JavaScript песочница

Основное отличие этой песочницы от других — сжатие и кодирование пользовательского кода непосредственно в URL. Код не хранится на сервере или где-либо ещё. Если у вас есть ссылка, значит у вас есть код. Может возникнуть вопрос, сколько символов можно записать в URL и как много кода таким образом можно закодировать? У разных браузеров максимальная длина URL-строки отличается. Но 2000 символов поддерживают все современные браузеры. В такую строку можно закодировать довольно много кода, причем степень сжатия увеличивается с объёмом кода.

https://habr.com/ru/articles/876252/

#песочница #javascript #фронтенд #фронтендразработка

Пропадающая граница в sticky-таблице: баг CSS-рендеринга, найденный в React-проекте

Всем привет, на связи снова я — Дмитрий, React-разработчик. Сегодня хочу рассказать об интересном баге, который был замечен в большой и сложной таблице. Проблема заключается в том, что в таблице на React с колонками, у которых есть свойство position: sticky , иногда пропадала граница между соседними ячейками по вертикали. Причём проявлялась она не всегда и носит случайный характер. Забавно, что изменение масштаба страницы (Ctrl + колесико мыши) мгновенно возвращает исчезнувший бордер. При этом в CSS все прописано и никуда не исчезает — это чисто визуальный баг рендера.

https://habr.com/ru/companies/gnivc/articles/991636/

#sticky #css #html #react #баги #браузер #фронтенд #фронтендразработка #frontend #frontendразработка

Full-stack в аналитике: почему это будущее Data Science?

Привет. Представьте: вы запилили нейросеть, которая определяет котиков на фото с точностью 99.9% (оставшиеся 0.1% — это когда хомяк притворяется котом). Воодушевлённый результатом, бежите к руководству — а там оказывается, что:

https://habr.com/ru/articles/904376/

#data_science #data_analysis #python #бекенд #фронтенд #ml #javascript

Как из каши импортов сделать сортированный список Frontend

Всем привет! Меня зовут Владимир и работаю джуниор фронтенд разработчиком в одной из лучших компаний:) Сегодня хочу вам рассказать, как можно немного причесать ваш проект чтобы он выглядел более читабельным.

https://habr.com/ru/articles/878638/

#Frontend #react #nextjs #оптимизация #prettier #форматирование_кода #вебразработка #фронтенд