В CSS давно есть единицы вроде rem, em , но они не всегда хорошо отражают реальные метрики конкретного шрифта. Это особенно заметно в интерфейсах, где важны пропорции текста, иконок, полей ввода и отступов.
Новые корневые единицы rcap, rch, rex и ric как раз решают эту задачу: они позволяют строить размеры не от абстрактного font-size, а от реальных характеристик шрифта корневого элемента <html>.
Перейдем к самим единицам с минимальными примерами:
rcap равен cap height корневого шрифта - номинальной высоте заглавных букв шрифта корневого элемента.
К примеру: rcap может быть полезен для размеров иконок рядом с текстом или логотипов в шапке сайта. Если иконка должна визуально совпадать с высотой заглавных букв, ее можно привязать к rcap, а не подбирать размер вручную.
``` .nav-icon {
width: 1.2rcap;
height: 1.2rcap;
} ``` rch- (root character unit) измеряет ширину символа 0 (ноль),заданную для шрифта корневого элемента <html>.
Как это работает: браузер берет advance measure глифа 0, в шрифте корневого элемента, и это значение становится равным 1rch.
Стоит уточнить что речь идет именно о advance measure-это расстояние, на которое курсор (или печатающая головка) продвигается после отображения символа, до того, как начнет рисоваться следующий символ. Один из самых практичных сценариев для rch — поля ввода, где ширина должна быть привязана к количеству символов. Например, если интерфейс предполагает ввод короткого кода, PIN или номера заказа фиксированной длины, можно задать ширину поля не в px и не в rem, а через rch. Тогда размер будет опираться на реальную ширину символов корневого шрифта.
``` .code-input {
width: 8rch;
padding: 0.5rem 1rch;
} ``` Удобно использовать для элементов, которые должны быть пропорциональны ширине символов основного текста. Например, для ограничения длины строки в статьях или настройки боковых отступов, чтобы они гармонировали с ритмом текста.
rex — корневая версия ex, это x-height шрифта корневого элемента.
rex больше не привязан к конкретному элементу. Это корневая версия ex,он считается не от текущего элемента ,а от корневого элемента html. То есть чтобы точно было понятно rex игнорирует локальные шрифты и всегда смотрит только на глобальный шрифт заданный в html.
Если корневой шрифт, например, 'Georgia', rex всегда будет использовать его метрики, даже если внутри элемента задан другой шрифт
``` html {
font-family: 'Georgia', serif;
font-size: 16px;
}
.button {
font-family: 'Courier New', monospace;
padding: 1rex;
}
```
ric-пожалуй самая не обычная единица про которую хочется сегодня расcказать.
Корневая версия ic, единицы для идеографической метрики в CJK-письменностях. Обычно она соотносится с advance measure символа 水 и полезна прежде всего для китайского, японского и корейского текста. Удобна, когда нужно создать сетку, рассчитанную на иероглифические тексты. Например, поле для ввода на 20 иероглифов.
Единицы rcap, rch, rex и ric описаны в CSS Values and Units Module Level 4. Несмотря на то что спецификация W3C по-прежнему имеет статус Working Draft, сами единицы уже поддерживаются современными браузерами
и могут использоваться в реальных проектах. На практике это уже не эксперимент ради эксперимента, а рабочий инструмент для интерфейсов, где важны именно метрики шрифта корневого элемента, а не только font-size. Особенно ,если вы разрабатываете интерфейсы, где важна точная типографика: лендинги, блоги, сайты с кастомизируемым шрифтом. Для обычных админок разница будет незаметна.
Краткая сводка по css-еденицам :
rch и rex: они понятнее в использовании и хорошо подходят для типографически выверенных интерфейсов, полей ввода и внутренних отступов. rcap полезен там, где нужно соотносить размеры элементов с высотой заглавных букв, например для иконок и логотипов. ric остается более нишевой единицей и в первую очередь нужен в интерфейсах, рассчитанных на CJK-тексты.
На всякий случай для production-проектов: используйте с @Supports или fallback-значениями, так как спецификация ещё не финальная.
Всем привет. Я фронтенд. JS, TS, React, Next.js — стандартный джентльменский набор. Но всегда хотел попробовать геймдев. Руки не доходили. И вот — дошли.
Встал вопрос: какой движок брать?
Unity — мощно, но тяжело и с лицензией пляски. Unreal — это ракетостроение. А Godot я скачал на пробу — и меня затянуло.
Почему Godot для бывшего фронта — зашло:
1. GDScript — как Python, только проще. Забудь про this, bind, бесконечные useCallback. Просто пишешь speed += 5 — и работает.
2. Сцены = компоненты. Делаешь машину → сохраняешь как сцену → кидаешь на карту. Знакомо по React, только визуально и без лишнего бойлерплейта.
3. Сигналы вместо EventEmitter. Всё то же самое, но встроено и не течёт.
4. Бесплатно и открыто. Не надо думать о лицензиях и «когда потребуют деньги». Качай и делай.
5. Физика из коробки. В вебе ты подключаешь библиотеку и молишься. Тут добавил CharacterBody3D — ходит. VehicleBody — машина с подвеской и колёсами. Без танцев с бубном.
Что ломало мозг:
· Нет npm install. Первое время рука тянулась к терминалу.
· Визуальный редактор вместо vim. Но привыкаешь за пару дней.
· Ось Y — высота. Первые объекты улетали в небо, потому что я тыкал y как в вебе.
Что в итоге:
За пару вечеров — работающий персонаж, машина с физикой, посадка/высадка, запуск двигателя. И кайф. Такого кайфа от кодинга у меня давно не было.
Godot — лучший вход в геймдев для веб-разработчика. Просто бери и делай. Никакой магии.
Всю жизнь пилю сайты на React. Лендинги, админки, фриланс. Но с детства была одна мечта — сделать свою игру.
Не ради денег. Ради того самого чувства, когда кто-то запускает твой мир и говорит: «Ого, круто же».
Год думал. Месяц назад начал.
Делаю симулятор российской глубинки. Деревня, старая копейка в гараже, дедова тайна. Без донатных помоек, без «заплати чтобы ускорить». Просто игра, в которую сам бы играл ночами.
Пока есть только прототип: персонаж ходит, машина заводится, можно ездить. Впереди — разборка двигателя по болтам, деревня с живыми соседями и много русского колорита.
Не знаю, взлетит или нет. Но кайфую от процесса как никогда.
Если вам тоже нравится идея — подписывайтесь, буду делиться прогрессом. И критика очень нужна.
Привет! Меня зовут Антон Назаров, я создатель сообщества «Осознанная Меркантильность», кратко — ОМ. В нем мы даем максимум пользы для IT-специалистов на любом этапе карьеры: от тех, кто только вкатывается в сферу, до айтишников, которые хотят пробить зарплатный потолок.
Сегодня разберемся с темой перехода в другое направление IT. Смена направления — стандартная практика для айтишников. Кто-то выгорел на текущей работе, другие хотят больше возможностей, третьи скучают в текущем профиле.
Мы провели масштабный опрос среди подписчиков сообщества. В статье внимательно рассмотрим статистику, узнаем, почему специалисты меняли направления, какие возникали сложности и оправдались ли ожидания.
В исследовании участвовало 1570 человек, из них главные текущие направления среди респондентов: backend, frontend и QA.
Откуда → куда айтишники хотят переходить и почему
Большинство опрошенных думают сменить направление, но не решаются — таких 43%. Еще 34% планируют поменять профиль, а тех, кто уже успешно это сделал, довольно мало — только 3%.
Главные причины решения:
перспективы нового направления — 33%;
размер зарплаты — 25%;
отсутствие роста в текущей специализации — 20%.
Респонденты планируют уходить в backend, ML / DS / NLP, DevOps и продуктовый менеджмент. При этом любопытно, что backend также оказался и среди топ-3 направлений, из которых опрошенные хотят перейти куда-то еще.
Вот какие специализации сегодня кажутся респондентам наиболее перспективным:
ML / DS / NLP — 51%;
backend — 41,5%;
информационная безопасность — 30%;
DevOps — 26%.
Многие айтишники хотят сначала досконально изучить все возможные направления, а потом решить, куда переходить. Такой ресерч может занять так много времени, что исчезает само желание менять профиль.
Мы подготовили лаконичную профориентацию по всем направлениям. Простыми словами объяснили, что предстоит делать на каждой должности и какие навыки понадобятся. Например, нужно ли писать код, придется ли общаться с людьми, какое направление легче / сложнее, и что там по деньгам и количеству вакансий.
Опыт тех, кто сменил направление: какие профили выбирали и чем руководствовались
Чаще всего респонденты уходили из frontend, backend и тестирования. А перекатывались — в backend, аналитику (System, Fullstack, BI) и ML.
Ниже полный список, откуда и куда переходили респонденты, изменившие направление 👇
Backend → DevOps
Swift developer → Sales manager
Frontend → System Analyst
Gamedev → FinTech
Техническая поддержка и ручное тестирование → Нагрузочное тестирование
Frontend → Backend
Android Dev → Fullstack Analytics
Backend → ML-Engineer
Backend → QA
Game Designer → Operations Manager
Backend → QA (в результате человек вернулся обратно в Backend)
Frontend → GO
QA → System Analyst
QA → Backend
Frontend → ML
ML → Backend
iOS → ML/NLP
Frontend → Backend
Frontend → Backend Go
Frontend → AQA
Верстальщик → Frontend
Backend → Gamedev
QA → Backend engineer
System Analyst → Data engineering
Android → Backend
Backend → DevOps
Системное администрирование и архитектура → Информационная безопасность
Аналитик внедрения → BI аналитик
Frontend → Backend → в итоге ML/DS
Backend → Frontend
Desktop → Backend
Маркетинг → Backend
Systems Analyst → Backend
QA Auto → Java developer → в итоге Golang developer
iOS → Backend Go
QA Automation → Project Manager (в результате человек вернулся обратно в QA Automation)
Frontend Developer → Project Manager
Руководитель проектов по внедрению СЭД → QA → в итоге AQA
Analyst → System Analyst
Среди основных причин выделяли:
перспективы нового направления — 22,5%
размер зарплаты — 21%
отсутствие роста — 15%
выгорание — 13%
С выгоранием сталкивается львиная доля айтишников.
Убитый режим, желание просто отдохнуть и ничего не делать хотя бы денек и постоянные мысли об увольнении — всё это спутники эмоционального истощения.
У большинства респондентов переход занял не так уж много времени: 41,5% справились с ним за 3 месяца и меньше. Еще у 32% ушло до полугода на смену направления. 19% пришлось потратить от 6-ти до 12-ти месяцев.
В числе главных сложностей оказались:
Страх и неуверенность — 32%
Необходимость учить новую область с нуля — 21%
Возможность попасть на собеседование и пройти его — 15%
Неожиданные подводные камни, с которыми столкнулись участники опроса:
«Больше ответственности и больше проектируешь фичи».
«Завышенные ожидания от перехода: по факту руководство командой и ответственность не означают высокий доход. Очень много политики и подлизывания, о которых даже не задумываешься при переходе».
«Руководитель выбирает тебя под себя. Если он сменяется — высок риск не ужиться с новым».
Результаты специалистов, которые сменили направления
У большинства респондентов зарплата выросла в половину и больше: об этом рассказали 47% опрошенных. У 21% доход вырос немного, а у 19% он не изменился. Были и те, кто просел по заработку при переходе на новое место — таких 13%.
Соотношение ожидания и реальности после смены направления показывают реалистичные результаты. У 43% опрошенных надежды оправдались на 4 балла из 5, еще у 38% на 5.
Часть респондентов говорит, что ничего бы не стали менять при переходе заново, другие подчеркивают, что стоило бы начать раньше и делать больший упор именно на прохождение собеседований.
Что еще респонденты сделали бы иначе при переходе:
«Анализировал бы рынок заранее, работал 4 года в компании и не наблюдал за рынком, что frontend так переполнен, даже с хорошим резюме, опытом хорошим и подтвержденным через госуслуги откликов не получаешь вообще, нужно было смотреть динамику откликов на вакансию и их количество, вовремя уйти с frontend разработки».
«Больше погружался бы в свой стек, так как тут меньшие усилий по учёбе дают кратно больший результат, нежели начинать с нуля. Сразу бы начал "Волчарить", а не стесняться».
«Больше бы прокачивал скиллы общения с топами, и учился математически считать риски, ибо внезапно, в ИБ это важнее самого ИБ — цифры показать, а не про технологии рассказывать».
Если от смены направления останавливает отсутствие опыта — смотрите большой гайд по накрутке опыта в резюме. Даем пошаговый план действий и ответы на все вопросы на основе тысяч удачных кейсов.
Выводы
Опрос показал: смена направления скоро станет новой нормой рынка. Большинство специалистов либо уже задумываются о переходе, либо активно планируют его. Главным образом из-за желания расти в доходе, получить больше перспектив и выйти из профессионального тупика.
Самыми привлекательными направлениями сегодня выглядят ML / DS / NLP, backend, DevOps и информационная безопасность. Интересно, что backend одновременно остается и одним из самых популярных направлений для входа, и одним из профилей, из которых специалисты хотят уйти. Это говорит о высокой конкуренции, нагрузке и неоднозначности ожиданий от роли backend-разработчика.
Опыт тех, кто уже сменил специализацию, показывает: переход чаще всего реален даже за несколько месяцев. Многие респонденты отмечают, что ожидания от новой роли в большинстве случаев оправдываются, а у значительной части специалистов переход приводит к заметному росту дохода.
Смену направления вполне можно считать эффективным инструментом карьерного роста в IT. Рассказывайте, думали ли вы о переходе в другую специализацию и почему?
Реклама. ИП Назаров Антон Владиславович, ИНН 780542845801
Каждый раз, когда начинаешь новый веб-проект, встаёт один и тот же вопрос: как рендерить страницы? CSR, SSR, SSG — звучит как аббревиатуры из учебника, но на практике именно этот выбор определяет скорость сайта, позиции в поиске и удобство разработки.
CSR — Client-Side Rendering
Сервер отдаёт почти пустой HTML с одним тегом div и большим JS-бандлом. Браузер скачивает JavaScript, выполняет его, делает запросы к API — и только после этого пользователь видит контент.
Плюсы:
Быстрая навигация после загрузки
Богатые интерактивные интерфейсы
Минусы:
Долгая первая загрузка (Time to Interactive)Долгая первая загрузка (Time to Interactive)
Плохо для SEO — боты видят пустой HTML
Требует хорошего интернета у пользователя
Главная проблема CSR — поисковые боты. Googlebot умеет выполнять JavaScript, но делает это с задержкой и не всегда корректно. Яндекс справляется хуже. В итоге страницы индексируются медленнее и хуже.
Когда CSR — правильный выбор:
• Дашборды и админки за авторизацией — SEO не нужен
• SPA с богатой интерактивностью: редакторы, конструкторы, таблицы
• Внутренние инструменты компании
• Приложения, где пользователь авторизован и контент персональный
SSR — Server-Side Rendering
При каждом запросе сервер генерирует готовый HTML с данными и отдаёт его браузеру. Пользователь сразу видит контент — не надо ждать, пока выполнится JavaScript.
Плюсы:
Отличный SEO — боты видят готовый HTML
Актуальные данные на каждый запрос
Минусы:
Нагрузка на сервер при каждом запросе
Медленнее навигация, чем CSR
Нужен сервер — хостинг дороже
SSR — лучший выбор для SEO-важных страниц. Поисковик получает готовый HTML с контентом, мета-тегами и структурированными данными. Индексация быстрее и надёжнее, чем при CSR.
Когда SSR — правильный выбор:
• Интернет-магазины — карточки товаров должны индексироваться
• Новостные сайты и блоги с часто меняющимся контентом
• Страницы с персонализированным контентом (лента, рекомендации)
• Любые публичные страницы, где важен SEO и актуальность данных
SSG — Static Site Generation
HTML генерируется один раз — во время сборки проекта. Готовые файлы раздаются с CDN без участия сервера. Это самый быстрый способ доставить контент пользователю.
Плюсы:
Максимальная скорость
Отличный SEO
Дешёвый хостинг — просто файлы
Высокая надёжность — нет сервера
Минусы:
Данные могут быть устаревшими
Долгая сборка при большом числе страниц
Не подходит для часто меняющихся данных
Когда SSG — правильный выбор:
• Лендинги и маркетинговые сайты
• Документация и справочники
• Блоги и портфолио
• Сайты, где контент меняется редко или по расписанию
Главное про SEO
SEO — это часто решающий фактор при выборе рендеринга. Вот простое правило:
• Страница публичная и должна находиться в поиске → SSR или SSG
• Страница за авторизацией или контент персональный → CSR
• Контент меняется часто → SSR
• Контент меняется редко → SSG
Отдельно про Core Web Vitals — Google учитывает LCP, FID и CLS в ранжировании. SSG и SSR дают лучшие показатели, чем CSR по умолчанию, но и CSR можно оптимизировать через lazy loading, code splitting и prefetching.
Хорошая новость: Next.js позволяет миксовать все подходы в одном проекте. Лендинг — SSG, карточка товара — SSR, личный кабинет — CSR. Именно поэтому он стал стандартом индустрии.
Больше материалов про разработку и запуск своих продуктов — в Telegram-канале @deep_in_prod
Современный Frontend давно перестал быть слоем поверх API. В реальном продукте он решает те же вопросы, что и любая распределённая система: где живут данные, когда они считаются свежими, как пережить задержку сети, что показать при частичном отказе, где провести границу между сервером и клиентом, как не превратить локальное состояние в теневую базу данных.
Проблема в том, что мы всё ещё говорим о Frontend языком интерфейса, хотя строим уже не интерфейс. Мы строим систему доставки смысла пользователю.
Классическая схема была понятной. Сервер собирает страницу, браузер показывает HTML, пользователь кликает ссылку, сервер отдаёт новую страницу. Почти вся сложность жила на сервере: маршруты, права, данные, шаблоны, ошибки.
Потом интерфейсы стали богаче, и мы перенесли часть логики в браузер. Страница перестала быть документом и стала приложением. Браузер начал хранить состояние, валидировать формы, строить маршруты, кэшировать данные, оптимистично обновлять UI. Это дало скорость и интерактивность - и заодно растащило Frontend по нескольким слоям.
Часть живёт на сервере: рендеринг, подготовка данных, проверка прав. Часть - в браузере: интерактивность, ввод, мгновенная обратная связь. Часть - в кэше: CDN, query cache, prefetch, service worker. А часть вообще не выглядит как Frontend: она в контракте API, в схеме данных, в дизайн-системе, в правилах релиза.
Когда всё работает, пользователь видит простую вещь: страница открылась, кнопка нажалась, действие сохранилось. Когда ломается, выясняется, что «кнопка» была последним звеном в длинной цепочке решений.
Кнопка не просто вызывает onClick. Она может запускать optimistic update, инвалидировать кэш, отправлять событие аналитики, менять URL, зависеть от прав пользователя, показывать pending-состояние, откатывать UI после ошибки или повторять запрос.
Это уже не «покрасить кнопку». Это проектирование поведения системы в условиях неопределённости.
Ernest Peixotto (American, 1869–1940)
Компоненты не спасают архитектуру
Когда Frontend стал сложнее, мы нашли удобный ответ - компонентную модель. Разбей интерфейс на части, переиспользуй их, собери экран из маленьких элементов. Сильная идея, но без неё современные интерфейсы было бы трудно поддерживать.
Но компонентная модель хорошо описывает форму интерфейса и плохо описывает поведение продукта. Компонент может быть маленьким, типизированным и красивым, а архитектура всё равно слабой, потому что настоящая сложность живёт между компонентами.
Самая частая ошибка - смешать UI-состояние, серверные данные, процесс сохранения, ошибки и производные значения в одном месте. Тогда форма знает про API, кнопка - про бизнес-правила, таблица - про инвалидирование кэша, а страница хранит копию данных из query cache «на всякий случай». Дальше начинаются исключения, быстрые фиксы, дублирование, страх менять экран и фраза «проще переписать».
Redux, Zustand, React Query, SWR, Signals, Context - ни один инструмент не решит за команду главный вопрос: где источник правды.
Если правда на сервере, Frontend должен уважать сервер и не показывать пользователю фантомное состояние. Если правда в пользовательском вводе, нельзя терять его после refetch. Если правда в URL, состояние должно переживать перезагрузку и передаваться ссылкой. Плохая архитектура начинается там, где источник не выбран: сервер говорит одно, кэш помнит другое, форма хранит третье, URL показывает четвёртое, а компонент делает пятое, потому что «так быстрее».
Near Richmond, Yorkshire (1877)
Где должна жить логика
Главный вопрос: кто за что отвечает, и что произойдёт, когда что-то пойдёт не так.
Возьмём простой сценарий - пользователь переименовывает проект.
Слабая версия: Пользователь жмёт «Сохранить». Форма отправляет PATCH, показывает спиннер. Через 800 мс ответ приходит, спиннер исчезает, имя в форме обновляется. Хорошо. Но в сайдбаре имя меняется ещё через секунду, потому что список проектов перезапрашивается отдельно. А в соседней вкладке, открытой час назад, имя вообще старое. Пользователь видит три разных состояния одной сущности и не понимает, какому верить.
Сильная версия: То же действие. Имя в инпуте меняется мгновенно - здесь источник правды сам пользователь. После сабмита UI сразу показывает новое имя во всех местах: в сайдбаре, в заголовке, в хлебных крошках, но визуально помечает его как ещё не сохранённое (например, приглушённым цветом). Если сервер подтвердил, тогда пометка исчезает. Если вернул ошибку - UI откатывается к старому имени и показывает причину человеческим языком: «нет прав» или «имя уже занято». Список проектов в кэше обновляется по одному правилу, а не по совпадению.
Из этого вытекает несколько практических правил.
Источник правды - один на каждое значение. Если правда на сервере, Frontend читает её оттуда и не хранит копий «на всякий случай». Если правда в URL - фильтры, поиск, выбранная вкладка, она переживает перезагрузку и передаётся ссылкой. Если правда во вводе пользователя, её нельзя потерять при refetch. Дублирование источников - это не ускорение, это будущий баг.
Frontend не решает то, за что не отвечает. Он может скрыть кнопку под роль пользователя, но не должен сам определять, разрешено ли действие. Это решает сервер. Frontend может показать бизнес-правило и объяснить его, но само правило живёт в домене, а не в компоненте. Если правило про деньги, права или статусы случайно осело в JSX, его рано или поздно нарушат.
Кэш это договор, а не оптимизация. Когда мы держим данные в query cache, мы говорим пользователю: «верь этому, пока я не скажу обратное». У договора должны быть условия: сколько данным можно верить, кто их обновляет, когда инвалидировать, что показывать, если они устарели. Быстрый интерфейс не должен быстро врать.
Производительность и ошибки
Производительность часто сводят к Lighthouse, Core Web Vitals и размеру бандла. Метрики полезны, но не объясняют главного.
Пользователь не обязан ждать. Медленный Frontend почти всегда - сумма решений: слишком много клиентского кода, тяжёлая дизайн-система, водопад запросов, дорогой рендер, небрежная гидратация. Это нельзя починить в конце. Это проектируется в начале: что отдать с сервера, что загрузить заранее, что отложить, какой экран остаётся полезным при частичном отказе.
С ошибками то же самое. В продакшене сеть медленная, API отвечает не сразу, сессия истекает, пользователь кликает быстро, данные меняются в другой вкладке. Ошибка валидации должна жить рядом с формой. Ошибка прав - приходить от сервера. Ошибка сети - объяснять, можно ли повторить действие. Ошибка бизнес-правила должно быть написана по-человечески: не «400 Bad Request», а «Нельзя удалить проект, пока в нём есть активные задачи».
Надёжность Frontend - это не отсутствие ошибок в консоли. Это способность интерфейса вести себя предсказуемо, когда мир вокруг неидеален.
A Winter Scene (mid 1640s)
Что отличает сильного Frontend-инженера
Не количество выученных хуков и не скорость написания компонентов. Он понимает границы: где заканчивается серверное состояние и начинается клиентское, где данные можно кэшировать, где нужна мгновенная реакция, а где честный loading, где типы помогают, а где нужна runtime-проверка, где абстракция снижает стоимость изменений, а где делает код мутным.
Он проектирует не только компоненты, но и договоры: между клиентом и сервером, между страницей и компонентом, между системой и пользователем.
Плохая архитектура почти всегда выглядит нормально в первый месяц. Потом она начинает требовать всё больше энергии за всё меньший результат. Переписывать приходится не потому, что React плохой или Vue плохой. Чаще всего в начале никто не ответил на скучные вопросы: что является источником правды, какие данные могут устареть, что пользователь увидит при медленной сети, что произойдёт, если запрос выполнится дважды, какая логика принадлежит домену, а какая - интерфейсу.
Заключение
Frontend больше не тонкая оболочка вокруг API. Он стал местом, где техническая архитектура встречается с человеческим ожиданием. Пользователь не видит server components, query cache, hydration и source of truth. Он видит другое: страница открылась или нет, действие сохранилось или потерялось, ошибка объяснена или спрятана, интерфейс помогает или заставляет сомневаться.
Frontend - это слой доверия. Он отвечает за договор между человеком и системой: нажал - увидел реакцию, сохранил - понял результат, ошибся - понял, как исправить, вернулся - попал туда, где ожидал быть. Хорошая архитектура не убирает сложность. Она кладёт её туда, где её можно понять.
Этой вводной статьёй я хотел поделиться мыслями и начать этот блог. Всем спокойных релизов и поменьше багов в продакшене ❤
Вы же вроде зарплаты хорошие платите? Почему не смогли схантить с рынка JS-кнопкодавов, которые понимают как делать поля ввода так, чтобы при вводе символов оно не тормозило? Или вы нанимаете норм, а потом манагеры им не дают работать и гоняют по созвонам? Или ускорение софта - не целевая работа, а целевая - плодить новые фичи, приносящие деньги? Так ведь эта хрень тормозит так, до новых фич дело даже не доходит. Мы буквально не успеваем зайти в ваше заведение, получаем сразу по морде. Еще немного и знакомые разрабы пойдут создавать свой сайтик для торговли БУ-хламом подобный CraigsList, а про Авито забудут навсегда.
Попробуйте ввести сюда какой-то текст. Одно нажатие клавиши запускает лютейший рассчёт напряжений чугунного моста через Енисей. Количество вычислений, происходящих от одного нажатия клавиши сравнимо со всеми вычислениями, произошедшими при высадке проклятых пендосов на Луну. Вы чо, на каждое нажатие в том же потоке, блокируя его, запросы в сеть в свои тормозные базы отправляете и пузырьковой сортировкой на клиенте процессите 50К строк? Всю эту вашу петушню, пребывающей в интеллектуальной дремоте, напилившую это тормозное поделие, пора уже нешуточно репрессировать.
Почему гугл-то не тормозит при вводе в поиск буковок? У вас поиск серьёзнее гугла? Уметь посылать запросы в сеть в другом потоке/воркере, никогда не блокируя пользовательские потоки - это ваши патлатые сеньёры-архитекты-техлиды так не не научились? А чем они заняты? На работе по созвонам весь день уши дрочат, а дома в сраные компутерные игры наяривают, работать некогда? Может им перестать платить 550 тыр в месяц, ведь на эти деньги они игровые видяхи домой покупают и потом деградируют в танчиках до 5 утра и приходят на работку не выспавшись и отупев. Тут же поделка уровня джуна за 60 тыр в месяц.
В общем, вам надо как-то серьёзно взяться за своих пузатых жирных престарелых техлидов, у которых в голове неиллюзорно насрано толпой бомжей, или возможно их в детстве за гаражами чечены палками шевелили, к коням привязывали за ногу? Прыгыли с гаражей в сугроб, который успел обледенеть? Жгли костры с гептилом? Тяжело понять как можно было так изговнять один сраный элемент ввода.
Я уже молчу про ту шайку гомодрилов, которые умудрились сделать неработоспособным выбор типа сортировки объявлений до тех пор, пока не подгрузится 100500 каких-то JS-оперденей. И даже кеширование не помогает, то есть как будто ты каждый раз жмёшь CTRL + F5, хотя это был просто F5. Мне кажется, на собесе в гугл ваших инженеров, задействованных в проектировании и реализайии фронтенда бы просто из двустволки застрелили и даже хоронить бы не стали, в реку выкинули тела. Ваши JS-кнопкодавы - яркий пример мальчика, совравшего маме в ответе на вопрос "а тебе точно для учёбы" при покупке компутера. Явно без уважения ваши ребята относятся к достижениям в микроэлектронике.
