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

https://isuckatcs.github.io/how-to-compile-your-language/parsing.html

Год назад админ выступал на #HolyJS. Это был потрясающий опыт.
В этом году тоже загляну туда😁

Как и обещал, выкладываю презенташку и кучу полезной инфы для самостоятельного изучения🧐


Дефолтные стили хрома:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css

Глубокая статья о процессе композиции от команды разработчиков Хрома:
https://sking7.github.io/articles/48074838.html

Статья из документации Хрома о работе компонента Chrome Compositor:
https://chromium.googlesource.com/chromium/src/+/master/docs/how_cc_works.md

Ооочень много информации о рендеринге в Хроме - отсюда рекомендую почитать Compositor Property Trees и Life of a Pixel:
https://www.chromium.org/developers/design-documents/chromium-graphics/

Как смотреть слои в DevTools:
https://dermeck.github.io/composite-layers/#:~:text=Show%20Layer%20Borders%20in%20Rendering,the%20layers%20on%20the%20screen.

Гайд по выделению анимации в отдельный слой:
https://web.dev/articles/animations-guide?hl=en
https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count?hl=en

Немного общих статей про CRP
https://web.dev/learn/performance/understanding-the-critical-path?hl=en
https://alistapart.com/article/from-url-to-interactive/

Этап Paint
https://www.smashingmagazine.com/2016/12/gpu-animation-doing-it-right/

Layout Tree
https://web.dev/articles/critical-rendering-path/render-tree-construction?hl=en

Выступил на Саратовском IT-Митапе. Да, мы дождались возрождения Саратовских конференций!
Рассказывал о рендеринге веб-страниц на гарфической карте компьютера.
Уже запланировал второй доклад на митап 12 апреля - на этот раз расскажу про рендеринг видео в браузере.
Приходите😁

https://rutube.ru/video/b39e1ef67ab5a8fed5118081dc085189/?r=plemwd

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

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

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 сделал своё дело и может уходить.