#мемы #фронтенд

🔐 Разбираем модели контроля доступа

1️⃣ DAC (Discretionary Access Control)
🔹 Владелец ресурса сам назначает права (например, доступ к файлу).
🔹 Гибкость — плюс, но риск утечек из-за человеческого фактора.
🔹 Пример: классические UNIX-права (`chmod`).

2️⃣ MAC (Mandatory Access Control)
🔹 Доступ жёстко регулируется системой (госструктуры, военные).
🔹 Использует метки (например, «Секретно»), пользователи не могут менять правила.
🔹 Пример: SELinux, Windows Mandatory Integrity Control.

3️⃣ RBAC (Role-Based Access Control)
🔹 Права выдаются по ролям (админ, модератор, юзер).
🔹 Удобно для бизнес-приложений, но возможен избыточный доступ.
🔹 Пример: корпоративные системы (Active Directory).

4️⃣ ABAC (Attribute-Based Access Control)
🔹 Учитывает атрибуты (роль, время, местоположение, устройство).
🔹 Гибкий, но сложный в настройке и производительности.
🔹 Пример: политики AWS IAM.

5️⃣ FGA (Fine-Grained Authorization)
🔹 Детальный контроль (например, доступ к определённому полю в базе).
🔹 Идеально для микросервисов и API-ориентированных систем.
🔹 Пример: OpenFGA, Google Zanzibar.

💡 Вывод: Выбор зависит от требований — безопасность (MAC), простота (RBAC) или гибкость (ABAC/FGA).

Подробнее: https://www.permit.io/blog/mac-dac-rbac-and-fga-and-access-control

#Security #DevOps #AccessControl

✨ View Transitions API — одна строка CSS, и ваш сайт оживает

Помните, как раньше для плавных переходов между страницами нужен был SPA-фреймворк, React Router и куча анимационной логики? Теперь это делается нативно в браузере. Одной строкой.

View Transition API позволяет создавать кинематографичные переходы между страницами — и в SPA, и (что важнее) в обычных многостраничных сайтах. Браузер сам делает скриншоты старого и нового состояний и анимирует разницу через CSS Animations.

▪️ Для SPA — оборачиваете обновление DOM в document.startViewTransition():

document.startViewTransition(() => {
  updateTheDOMSomehow();
});

▪️ Для MPA (многостраничник) — вообще без JS. Добавляете в CSS обеих страниц:

@view-transition {
  navigation: auto;
}

И всё. Браузер сам подхватит навигацию и сделает плавный переход.

Что можно анимировать: превращение миниатюры в полную картинку, фиксированную навигацию между страницами, перестройку сетки при фильтрации. Работает в Chrome 126+ для MPA, в Chrome 111+ для SPA. Firefox и Safari пока догоняют.

Это один из тех случаев, когда веб-платформа забирает себе то, что раньше требовало библиотек. Как когда-то CSS Grid убил float-сетки — так и View Transitions убивает кастомные page-transition хаки.

🔗 Документация Chrome

#css #frontend #webapi

🎨 CSS научился стилизовать поиск по странице. И это только начало.

В Chrome 144 появился псевдоэлемент ::search-text — теперь можно стилизовать подсветку результатов поиска по странице (Ctrl+F). Раньше жёлтые выделения были железобетонными — браузер решал за тебя. Теперь — два новых псевдоэлемента:

::search-text {
  background: #e0f7fa;
  color: #006064;
}
::search-text:current {
  background: #ff6f00;
  color: white;
}

::search-text стилизует все совпадения, а ::search-text:current — текущее активное. Это часть более широкого семейства Highlight Pseudo-Elements (::selection, ::target-text, ::spelling-error, ::grammar-error), которое CSS развивает последние два года.

Почему это важно? Потому что это философский сдвиг: браузеры отдают разработчикам контроль над вещами, которые раньше были хардкожены. ::target-text позволяет стилизовать фрагменты по scroll-to-text (#:~:text=), ::selection давно работает, а теперь и поиск стал кастомизируемым. Для дизайн-систем и dark-mode тем это спасение — жёлтый хайлайт на тёмном фоне наконец можно починить.

Бонус: Firefox Nightly получил @custom-media — возможность задавать переиспользуемые медиа-запросы как переменные. Адаптивная вёрстка станет ещё чище.

🔗 CSS-Tricks: Styling ::search-text

🏗 Модульный монолит vs микросервисы: что на самом деле важно

Один из самых популярных архитектурных постов последних месяцев на HN (148 апвоутов, 151 комментарий) — статья «Modularity is what truly matters». Автор разбирает вечный холивар монолит/микросервисы и приходит к выводу, который многие чувствуют, но боятся сказать вслух: деление на сервисы — вторично. Модульность — первична.

Ловушка, в которую попадают команды: решают «нам нужны микросервисы», нарезают систему на 15 сервисов, а потом обнаруживают, что 10 из них не могут работать друг без друга. Итог — распределённый монолит: все минусы обоих подходов и ни одного плюса. Сетевые вызовы вместо функций, eventual consistency вместо транзакций, и debug через три сервиса вместо одного стектрейса.

Правильная последовательность:

1️⃣ Разберитесь в домене. Найдите реальные границы — где данные и логика слабо связаны друг с другом.

2️⃣ Сделайте модули внутри монолита. Отдельные папки/пакеты с чёткими интерфейсами и минимумом зависимостей. High cohesion, loose coupling.

3️⃣ Только потом, если конкретный модуль нуждается в независимом масштабировании или деплое — выносите его в отдельный сервис. Осознанно, а не «потому что Netflix так делает».

Хороший тест: если два сервиса всегда деплоятся вместе, всегда падают вместе и не могут обработать запрос друг без друга — это не два сервиса. Это один сервис, которому зачем-то добавили сетевой вызов.

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

🔗 Статья

🧱 Masonry-раскладка: что это, зачем нужна и как скоро забудем про JS-костыли

Откройте Pinterest, Google Images или Unsplash. Видите, как карточки разной высоты плотно укладываются в колонки без пустых дыр — как кирпичики? Это и есть masonry-раскладка (от англ. masonry — кирпичная кладка).

Почему это было болью. CSS из коробки так не умел. Flexbox раскладывает элементы в ряды одинаковой высоты. Grid — по сетке с фиксированными ячейками. А masonry — это когда каждый элемент «прилипает» к нижнему краю предыдущего в своей колонке, независимо от высоты соседей. До сих пор это решалось костылями:

▸ column-count — ломает порядок элементов (они идут сверху вниз, а не слева направо)
▸ JS-библиотеки вроде Masonry.js — работают, но это лишний JS, пересчёт позиций на каждый ресайз, мерцание при загрузке

Что изменилось. CSS Grid Level 3 вводит display: grid-lanes — нативную masonry-раскладку без единой строчки JavaScript. Буквально:

.container {
  display: grid-lanes;
  grid-template-columns: repeat(3, 1fr);
  gap: 16px;
}

Всё. Три колонки, элементы автоматически заполняют пустоты по высоте.

Когда можно использовать. Safari Technology Preview уже поддерживает финальный синтаксис. Firefox экспериментирует с 2020 года. Chrome и Edge обновляют реализации. Через @supports (display: grid-lanes) можно подключать прямо сейчас с фоллбэком на Masonry.js для старых браузеров.

Одна из тех фич, которую ждали 7 лет — и которая сделает тысячи строк JS ненужными.

🔗 Подробнее — WebKit Blog

🚀 JavaScript фреймворки в 2026: куда движется фронтенд

Авторы This is Learning подвели итоги года и наметили тренды на 2026-й. Главная мысль: фокус сместился с производительности на стратегическое мышление. AI доминирует в обсуждениях, но как это влияет на сами фреймворки?

🤖 AI-First подход

Remix 3 (больше не на React!) полностью переосмысливает фулстек-разработку с учётом AI. Создатели делают ставку на уменьшение доменно-специфичного языка — чтобы AI мог генерировать универсальные решения, а не привязываться к специфике фреймворка.

Противоположный подход — React как "последний фреймворк", который AI знает лучше всего из-за огромной базы обучения. Но это ловушка: если мы застрянем на React 2018 года только потому, что AI его лучше знает — у нас проблемы.

🔄 Возврат к изоморфности

Islands и Server Components оказались неудобными для сложных интерактивных приложений. Слишком много границ между сервером и клиентом, слишком много путаницы.

Результат: Isomorphic-First архитектура возвращается. SolidStart, Tanstack Start, SvelteKit добавляют Out-of-Order streaming, Server Functions, Optimistic UI — всё лучшее от серверного рендеринга без архитектурных костылей.

Главный вывод: в 2026-м важнее видение, чем реализация. Фреймворки будут развиваться в сторону простоты для AI и удобства для разработчиков сложных приложений.

🔗 Полная статья

🧮 TypeScript типы как язык программирования — погружение в Turing-complete систему типов

Знали ли вы, что TypeScript Turing-полный? Кто-то уже написал на типах Doom, кто-то реализовал арифметические операции. Но зачем? Чтобы лучше писать типы, думая о них как о программах.

🔧 Дженерики = функции

Типы с параметрами работают как функции — принимают входные типы, возвращают выходные:

// Функция
const identity = (value) => value;

// Тип-функция
type Identity<Type> = Type;

// Более сложный пример
type Crud<Resource extends { id: string | number }> = {
  create: (resource: Omit<Resource, 'id'>) => Resource;
  getOne: (id: Resource['id']) => Resource | undefined;
  update: (id: Resource['id'], data: Partial<Omit<Resource, 'id'>>) => Resource;
}

⚡ Условные типы = if/else

Через extends и тернарный оператор получаем полноценные условия:

type IsNumber<Value> = Value extends number ? true : false;

type InferEventType<T extends Event> = 
  T extends CreateEvent ? "create" :
  T extends UpdateEvent ? "update" :
  T extends DeleteEvent ? "delete" : never;

📦 infer = переменные

Ключевое слово infer позволяет «вытаскивать» части типов:

type First<T> = T extends [infer Head, ...any[]] ? Head : never;
type Result = First<[string, number, boolean]>; // string

Зачем это нужно? Система типов становится мета-языком для описания структуры данных. Вместо дублирования кода вы описываете логику один раз в типах — и TypeScript автоматически выводит все остальное.

Следующий уровень после изучения базовых дженериков — начинать думать типами как алгоритмами.

🔗 Полная статья

"TypeScript умер. И это хорошо."

Пока все спорят о Bun vs Node, произошло кое-что интереснее: JavaScript ES2024+ стал настолько хорош, что TypeScript превратился в костыль. Новые фичи (decorators, pattern matching, pipe operator) плюс современные IDE с AI-автодополнением делают типизацию почти избыточной.

Смотрите: крупнейшие проекты потихоньку мигрируют обратно на чистый JS. DHH выкинул TS из Turbo, команда Svelte тоже отказалась. Даже создатель Deno Райан Даль признался, что сожалеет о встроенном TypeScript. Причина проста: overhead от сборки больше не оправдывает выгоды.

Но вот главное: новое поколение разработчиков, выросшее на JSDoc + современных линтерах, вообще не понимает, зачем нужна отдельная система типов. Когда VS Code с GitHub Copilot подсказывает типы лучше любого .d.ts файла, а рантайм-валидация через zod/joi покрывает реальные кейсы — зачем мучиться с tsc?

TypeScript сделал своё дело и может уходить.

Так вот какие посты вызывают реакцию у аудитории😁

Ладно, вот вам еще одно радикальное мнение. Микросервисы — самая дорогая ошибка IT за 10 лет

Netflix: 1000+ микросервисов, армия из 3000+ инженеров, миллиарды на инфраструктуру.
WhatsApp: монолит на Erlang, 50 разработчиков, 2 млрд пользователей, продали за $19 млрд.

Угадайте, кто эффективнее?

Пора признать неудобную правду: 95% проектов выбирают микросервисы не из-за технических требований, а из-за хайпа. Amazon сам говорит, что переход к монолиту сократил их расходы на 90%. Команда Shopify отказалась от микросервисов ради скорости разработки.

Вот что происходит в реальности: каждый новый сервис — это отдельный CI/CD, мониторинг, логи, безопасность, версионирование API. Дебаг распределённой системы превращается в ад. Одна фича теперь требует изменений в 5 репозиториях вместо одного коммита.

А теперь посмотрите на успешные стартапы 2023-2024: Linear, Notion, Figma — все начинали с монолитов и до сих пор ими остаются. Потому что скорость доставки фич важнее теоретической масштабируемости, которая понадобится не скоро.

Монолит-first — это не регресс, а зрелость. Микросервисы нужны 1% проектов, а используют их 80%.

Нужны ваши реакции!

🤔 Нужны ли ещё бэкенд-разработчики в 2026?

BaaS-платформы, serverless, ORM, которые пишут SQL за тебя, AI, который сетапит API быстрее, чем ты наливаешь кофе. Казалось бы — зачем нам бэкенд-разработчики?

Ответ прост: инструменты абстрагируют сложность, но не устраняют её. Когда стартап гордо заявляет «фронтенд напрямую ходит в Supabase, бэкенда нет» — это работает. До первого инцидента. Потому что убрали не бэкенд — убрали человека, который его понимает. Бэкенд-разработчик — это не тот, кто пишет CRUD-эндпоинты. Это тот, кто проектирует модели данных, которые переживут реальную нагрузку, думает о консистентности, отказоустойчивости и edge cases, и знает, куда смотреть, когда в 3 часа ночи всё ломается под нагрузкой.

Serverless не убил бэкендеров — он их трансформировал. Теперь вместо настройки серверов нужно разбираться в распределённых системах, event-driven архитектурах, observability и расходах, которые тихо взрываются за ночь. AI тоже не заменяет — он убирает скучную часть работы, ту, которую мы и так не любили. А вот понимание бизнес-ограничений, принятие решений в условиях неопределённости и дебаг эмерджентного поведения между сервисами — это по-прежнему задача человека. Бэкенд не исчезает. Он становится невидимым. И чем менее он заметен, тем ценнее люди, которые действительно его понимают.

Dependency hell в 2026: npm install займёт больше времени, чем разработка фичи

В прошлом году средний фронтенд-проект набрал 1,200+ зависимостей. Для сравнения — в операционной системе их меньше.

Хотите добавить кнопку? Установите UI-библиотеку. Она тянет 15 утилит для стилей, которые тянут парсеры, которые тянут валидаторы, которые тянут... Поздравляю, ваша кнопка весит 50MB в node_modules.

А потом начинается магия:

• Пакет A требует lodash@4.x
• Пакет B требует lodash@3.x
• Пакет C вообще переписал lodash и назвал его "lodash-pro"
• npm пытается это всё совместить и плачет
В итоге npm audit показывает 847 уязвимостей, половина зависимостей давно не поддерживается, а обновление одного пакета ломает половину проекта.

Что получается: left-pad не научил нас ничему. Мы всё ещё импортируем целую библиотеку ради одной функции и удивляемся, почему бандл раздулся до размеров небольшой ОС.

Может, пора вспомнить, что иногда 10 строк своего кода лучше, чем зависимость от "ultra-mega-helper-utils-v2"?

🤖 Неудобная правда: ИИ делает джунов бесполезными, а сеньоров — незаменимыми

Все говорят, что AI заменит программистов. Реальность жёстче: он заменит плохих программистов и усилит хороших.

Джун 2024 года: гуглит ошибки, копипастит со StackOverflow, тратит 2 часа на то, что Copilot делает за 30 секунд. Его единственное преимущество — дешевизна — больше не преимущество. Зачем платить человеку за работу, которую AI делает быстрее и без выходных?

Сеньор 2024 года: понимает почему код работает, видит архитектурные проблемы, задаёт правильные вопросы AI и критически оценивает ответы. Он не конкурирует с AI — он использует его как множитель своей экспертизы.

Парадокс: Чтобы эффективно использовать AI для кода, нужно уже уметь кодить. Джунам AI не помогает расти — он помогает им не расти, выдавая готовые ответы без понимания.

Раньше путь был: джун → мидл → сеньор. Теперь: джун → ???

Кто будет сеньорами через 10 лет, если джуны не проходят путь боли и ошибок? 🪦

Vibe Coding: программирование перестало быть про код

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

Сейчас происходит сдвиг. Andrej Karpathy назвал это вайбкодингом — ты описываешь намерение, AI пишет реализацию. Cursor, Copilot, Claude Code — уже не автокомплит, а полноценный со-разработчик.

Что изменилось философски:

🔹 От "как" к "что" — важнее понимать архитектуру и бизнес-логику, чем помнить API
🔹 От написания к ревью — читаешь и проверяешь больше, чем пишешь
🔹 От синтаксиса к семантике — правильный промпт важнее знания фреймворка
🔹 От владения к оркестрации — управляешь инструментами, а не молотком сам

Это не "деградация навыков". Когда-то программисты перекладывали данные в регистрах ассемблера - а писать на высокоуровневом языке считалось детской забавой. Когда-то управляли памятью вручную - потом появился garbage collector. Писали SQL руками — появились ORM. Каждый уровень абстракции освобождал для более важных задач.

Это просто следующий этап закономерного развития. Как мы сейчас не утруждаем себя ручным управлением памятью, так и ручное написание синтаксический конструкций, бизнес-логики и оптимизаций рендера страницы станет все больше выходить из моды. Инженер - это теперь тот, кто строит систему на уровне задач, которые она должна решать, а не как правильно реализовать отписку от таймера на Реакте.

Но разве это не всегда было настоящей сутью инженера?

🎭 ООП в JavaScript — карго-культ, который пора похоронить

Когда Java-разработчик приходит в JS, первое что он делает — тащит классы, наследование и паттерны из Gang of Four. И код превращается в это:

class UserRepository extends BaseRepository {
  constructor(database) {
    super(database);
    this.model = UserModel;
  }
  
  async findById(id) {
    return super.findById(id);
  }
}

// 50 строк обёртки ради одного запроса в базу

А можно было так:

const findUser = (db) => (id) => db.query('users', { id });

// Всё. Одна строка. Тестируется за 5 секунд.

Почему это карго-культ:

1. Классы в JS — синтаксический сахар над прототипами. Вы не получаете настоящую инкапсуляцию (private появился вчера и работает костыльно)
2. Наследование — антипаттерн. Даже в Java давно говорят "composition over inheritance". В JS это критично вдвойне
3. this — мина замедленного действия. Половина багов в "классовом" коде — потеря контекста
Функции — first-class citizens в JS. Используй это. Композиция функций > иерархия классов.