Forwarded from FrontEndDev
FM-синтез звука в браузере. Часть 1
Рассмотрим возможности браузеров по синтезу звука. Разберём основы и в качестве практического применения сделаем эмулятор синтезатора Yamaha DX7.
Сложно, сложно
https://habr.com/ru/articles/1052640
Рассмотрим возможности браузеров по синтезу звука. Разберём основы и в качестве практического применения сделаем эмулятор синтезатора Yamaha DX7.
Сложно, сложно
https://habr.com/ru/articles/1052640
Forwarded from FrontEndDev
HTTP получил метод QUERY: зачем понадобился безопасный запрос с телом
В HTTP стандартизировали
https://habr.com/ru/articles/1055310/
В HTTP стандартизировали
QUERY — безопасный и идемпотентный метод чтения, где сложные параметры передаются в теле запроса, а не в URI.https://habr.com/ru/articles/1055310/
Forwarded from Махровый fullstack
Мутанты на проводе или Всевидящий MutationObserver
— Когда мир перестаёт быть реактивным, остаётся только наблюдать —
TL;DR:
Давненько у нас не было фронтовых баек, а пожалуй что вот оно!
👩💻 Уютный мир: ламповый laravel, приятные vue-компоненты, встроенные в шаблоны. Всё живёт в безмятежном неведении надвигающейся катастрофы.
👩💻 Но тут появляется внешний JS-скрипт, который начинает управлять состоянием vue-компонента извне. В частности - открывает попап, а vue-форма внутри должна менять своё поведение.
Должна, но не может!
Классические приемы не работают:🤦♂️
— Пропсы не пробросить - компонент уже смонтирован;
— События не проэмитить - нет родителя;
— Пересоздавать компонент с переносом логики - слишком жирно. Да и внешний скрипт менять нельзя.
Можно было бы отчаяться и уйти из IT на ферму кроликов разводить, но на помощь приходят мутанты-наблюдатели!🐢
Да, MutationObserver - наше спасение. Всевидящее Око Саурона в мире DOM.
Создаём наблюдателя. Теперь он в засаде и зорко наблюдает за всеми изменениями у родителя:
Но что бы наблюдатель был не слишком наблюдателен, ограничим его кругозор через фильтр:
Ну и, конечно, по-джентльменски освобождаем наблюдателя при смерти компонента.
Если состояние меняется вне зоны реактивности компонента - это не приговор.
Мутанты среди нас, и они всегда помогут!❤️
#vue #mutationobserver #javascript #frontend #web #разработка
— Когда мир перестаёт быть реактивным, остаётся только наблюдать —
TL;DR:
Иногда не нужно менять архитектуру. Достаточно наблюдать и DOM сам расскажет, что произошло.
Давненько у нас не было фронтовых баек, а пожалуй что вот оно!
Должна, но не может!
Классические приемы не работают:
— Пропсы не пробросить - компонент уже смонтирован;
— События не проэмитить - нет родителя;
— Пересоздавать компонент с переносом логики - слишком жирно. Да и внешний скрипт менять нельзя.
Можно было бы отчаяться и уйти из IT на ферму кроликов разводить, но на помощь приходят мутанты-наблюдатели!
Да, MutationObserver - наше спасение. Всевидящее Око Саурона в мире DOM.
Создаём наблюдателя. Теперь он в засаде и зорко наблюдает за всеми изменениями у родителя:
const component = el.parentElement as HTMLDivElement | null;
let observer: MutationObserver | null = null;
onMounted(() => {
observer = new MutationObserver(() => {
if (component.classList.contains('popup_active')) {
// наша логика
}
})
observer.observe(component, {
attributes: true,
attributeFilter: ['class'],
});
});
Но что бы наблюдатель был не слишком наблюдателен, ограничим его кругозор через фильтр:
attributeFilter и следим строго за классом.Ну и, конечно, по-джентльменски освобождаем наблюдателя при смерти компонента.
onUnmounted(() => {
observer?.disconnect();
observer = null;
});Если состояние меняется вне зоны реактивности компонента - это не приговор.
Мутанты среди нас, и они всегда помогут!
#vue #mutationobserver #javascript #frontend #web #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
Микрофронтенды в экосистеме Vue 3: практическое руководство для разработчика в 2026 году / Хабр
https://habr.com/ru/companies/simbirsoft/articles/1064080/
https://habr.com/ru/companies/simbirsoft/articles/1064080/
Forwarded from Веб-стандарты (Vadim Makeev)
Шпаргалки по флексам, гридам, anchor positioning и invoker commands. Килиан Валкхоф делится четырьмя CSS-шпаргалками, которые сделал, потому что постоянно забывал синтаксис anchor positioning и
https://polypane.app/blog/cheatsheets-for-flex-grid-anchor-positioning-and-invoker-commands/
grid-area. Каждая — справочник со свойствами и значениями по своей теме, чтобы держать под рукой. Их можно бесплатно скачать в PDF и PNG в формате A5, готовом к печати. #css #learnhttps://polypane.app/blog/cheatsheets-for-flex-grid-anchor-positioning-and-invoker-commands/
Forwarded from FrontEndDev
toast-queue для доступных toast-уведомлений
Лёгкая framework-agnostic библиотека для toast-уведомлений с нормальной доступностью, очередью и прогрессивным улучшением. Она берёт на себя показ, скрытие, позиционирование, лимит видимых тостов и объявления для screen reader, так что в приложении остаётся только вызвать add(). На практике удобно, что можно отправлять как простой текст, так и объект с title, description и action, а поведение настраивается и глобально для очереди, и точечно для каждого тоста.
https://toast-queue.js.org
Лёгкая framework-agnostic библиотека для toast-уведомлений с нормальной доступностью, очередью и прогрессивным улучшением. Она берёт на себя показ, скрытие, позиционирование, лимит видимых тостов и объявления для screen reader, так что в приложении остаётся только вызвать add(). На практике удобно, что можно отправлять как простой текст, так и объект с title, description и action, а поведение настраивается и глобально для очереди, и точечно для каждого тоста.
https://toast-queue.js.org
Forwarded from FrontEndDev
Как сделать SVG-иконки живее с squash and stretch
Разбор приёма squash and stretch для SVG-микроинтеракций. Он помогает сделать иконки и стрелки более естественными и заметными без тяжёлой анимации: можно анимировать path через CSS, а для более широкой поддержки использовать Motion. Практически это даёт более приятный hover-эффект, учитывает prefers-reduced-motion и лучше работает, если вместо обычного state-based hover запускать короткую анимацию по событию.
https://www.joshwcomeau.com/animation/squash-and-stretch/
Разбор приёма squash and stretch для SVG-микроинтеракций. Он помогает сделать иконки и стрелки более естественными и заметными без тяжёлой анимации: можно анимировать path через CSS, а для более широкой поддержки использовать Motion. Практически это даёт более приятный hover-эффект, учитывает prefers-reduced-motion и лучше работает, если вместо обычного state-based hover запускать короткую анимацию по событию.
https://www.joshwcomeau.com/animation/squash-and-stretch/
Forwarded from mefody.dev
<mermaid-element>
Ещё одна полезная библиотека. Брамус собрал кастомный элемент, которому внутрь можно передать синтаксис Mermaid-диграммы — и она нарисуется.
Если не знаете, что такое Mermaid, то это как раз тулза, которая превращает текст вида
в Sequence-диаграмму. И там ещё более 30 разных видов диаграмм, которые мы периодически используем в работе.
https://www.bram.us/2026/09/10/introducing-mermaid-element-a-custom-element-to-display-mermaid-diagrams/
Ещё одна полезная библиотека. Брамус собрал кастомный элемент, которому внутрь можно передать синтаксис Mermaid-диграммы — и она нарисуется.
Если не знаете, что такое Mermaid, то это как раз тулза, которая превращает текст вида
sequenceDiagram
Alice->>John: Hello John, how are you?
John-->>Alice: Great!
Alice-)John: See you later!
в Sequence-диаграмму. И там ещё более 30 разных видов диаграмм, которые мы периодически используем в работе.
https://www.bram.us/2026/09/10/introducing-mermaid-element-a-custom-element-to-display-mermaid-diagrams/
Bram.us
Introducing <mermaid-element>, a custom element to display Mermaid diagrams
Today I learned that CodePen supports Mermaid diagrams — Chris Coyier has a a whole collection with examples here — and I also learned that there is no custom element to easily include these in your markup … so I built one.
Forwarded from amorgunov
Будь осторожнее с SDD
Сейчас идёт пик хайпа SDD (Spec Driven Development). Это подход, при котором написанию кода предшествует создание спецификаций (далее - спек), использующихся основой для агентов при генерации кода. На каждой конференции минимум один доклад об этом, всё больше историй успеха, что всю компанию полностью перевели на Agentic SDLC (простыми словами, процесс разработки с помощью агентов), во многих компаниях начинают добровольно-принудительно внедрять этот подход на основе различных фреймворков (OpenSpec, Superpowers, Spec Kit, gsd и т.д.). Но, на мой взгляд, внедрение ради внедрения ни к чему хорошему не приведёт, а только увеличит time-to-market фичей, ухудшит качество и станет источником появления тонны слоп-текста.
Сразу оговорюсь, что мне очень импонирует SDD, я его очень давно использую, ещё до агентов, да и вы, скорее всего, используете. Перед написанием кода для сложных фичей пишем технические решения, проводим архитектурные встречи и оставляем какие-нибудь артефакты (типа ADR). На их основе декомпозируем большие задачи на более маленькие и пишем код.
С агентами такой подход обрёл новый виток развития, так как именно через спецификацию можно более точно контролировать работу агента. Спеки перенесли в markdown-файлы (рядом с кодом), воркфлоу задаётся spec-driven фреймворками, а агенты делают ровно то, что написано в спеках. Красота. И где-то тут рождаются идеи типа описывать спеки не только верхнеуровнево для сложных фичей, а для каждой задачи. Полгода назад, когда я познакомился с OpenSpec (плагин для агентов, предоставляющий механизм работы по SDD и формированию всех артефактов), я побежал его тестировать на сайд проектах. И оказалось, не всё так радужно, как изначально хотелось бы.
Пройдёмся по основным проблемам:
1️⃣ Многие фреймворки (тот же OpenSpec) генерируют main-спецификации (которые описывают актуальное состояние приложения/сервиса/системы) и транслируют идею, что спецификация становится источником истины, а не код. Не только в момент написания, а на постоянной основе. Получается, либо мы для всех задач (даже супер мелких правок, багов, которые хоть как-то влияют на поведение) заводим спеки (что зачастую нецелесообразно и утомительно), либо у нас появляется два источника правды. Есть даже такой термин, spec drift, который описывает отклонение спецификации от фактической реализации. А неактуальные спеки очень опасны для агентов.
2️⃣ Агенты генерируют тонны текста в спеках, которые нужно ревьювить (в первую очередь автору). Думаю, вы когда-нибудь встречали тикеты в трекере с описанием, которое полностью сгенерировано ИИ (тонны слоп-текста, с которым разбираешься ещё больше, чем с тикетами без описания). Со спеками так же. Их нужно в несколько итераций вычитывать, выпиливать всё ненужное и делать акцент на реально важных вещах. Всё это очень быстро выжирает когнитивный ресурс (2-3 часа подготовки спеки и ты уже никакой). Ещё спеки и от коллег нужно ревьювить, помимо кода. А теперь представьте, что прилетели комментарии с код-ревью или тестирования. Помимо кода, скорее всего, нужно дорабатывать и спеку (которую потом опять отполировывать). И на себе замечаю, что временами начинаешь скипать чтение спек или пробегаться по диагонали, что, конечно же, не ок (как и при код-ревью тысячи строк кода, написанного агентами).
3️⃣ Очевидно, но на больших проектах и по мере роста спецификаций их актуализация будет выедать много токенов и времени работы агента.
Что делать? Послушаем в новом сезоне Podlodka Frontend Crew, которая стартует уже 5 октября. На конференции будет сразу три доклада, затрагивающие тему SDD. Один мельком, почему SDD не работает (я думаю, что причины будут схожи), а два других выступления наоборот - как можно применять этот подход, чтобы было не больно (один о фреймворке Spec Kit от разработчиков github-а). А по промокодуAMORGUNOV вас будет ждать приятный бонус.
Ну и я совсем скоро поделюсь опытом, как решаю эти проблемы, так как сейчас вот это всё тестируем на рабочих проектах.
erid: 2SDnjcYbM5u
Сейчас идёт пик хайпа SDD (Spec Driven Development). Это подход, при котором написанию кода предшествует создание спецификаций (далее - спек), использующихся основой для агентов при генерации кода. На каждой конференции минимум один доклад об этом, всё больше историй успеха, что всю компанию полностью перевели на Agentic SDLC (простыми словами, процесс разработки с помощью агентов), во многих компаниях начинают добровольно-принудительно внедрять этот подход на основе различных фреймворков (OpenSpec, Superpowers, Spec Kit, gsd и т.д.). Но, на мой взгляд, внедрение ради внедрения ни к чему хорошему не приведёт, а только увеличит time-to-market фичей, ухудшит качество и станет источником появления тонны слоп-текста.
Сразу оговорюсь, что мне очень импонирует SDD, я его очень давно использую, ещё до агентов, да и вы, скорее всего, используете. Перед написанием кода для сложных фичей пишем технические решения, проводим архитектурные встречи и оставляем какие-нибудь артефакты (типа ADR). На их основе декомпозируем большие задачи на более маленькие и пишем код.
С агентами такой подход обрёл новый виток развития, так как именно через спецификацию можно более точно контролировать работу агента. Спеки перенесли в markdown-файлы (рядом с кодом), воркфлоу задаётся spec-driven фреймворками, а агенты делают ровно то, что написано в спеках. Красота. И где-то тут рождаются идеи типа описывать спеки не только верхнеуровнево для сложных фичей, а для каждой задачи. Полгода назад, когда я познакомился с OpenSpec (плагин для агентов, предоставляющий механизм работы по SDD и формированию всех артефактов), я побежал его тестировать на сайд проектах. И оказалось, не всё так радужно, как изначально хотелось бы.
Пройдёмся по основным проблемам:
1️⃣ Многие фреймворки (тот же OpenSpec) генерируют main-спецификации (которые описывают актуальное состояние приложения/сервиса/системы) и транслируют идею, что спецификация становится источником истины, а не код. Не только в момент написания, а на постоянной основе. Получается, либо мы для всех задач (даже супер мелких правок, багов, которые хоть как-то влияют на поведение) заводим спеки (что зачастую нецелесообразно и утомительно), либо у нас появляется два источника правды. Есть даже такой термин, spec drift, который описывает отклонение спецификации от фактической реализации. А неактуальные спеки очень опасны для агентов.
2️⃣ Агенты генерируют тонны текста в спеках, которые нужно ревьювить (в первую очередь автору). Думаю, вы когда-нибудь встречали тикеты в трекере с описанием, которое полностью сгенерировано ИИ (тонны слоп-текста, с которым разбираешься ещё больше, чем с тикетами без описания). Со спеками так же. Их нужно в несколько итераций вычитывать, выпиливать всё ненужное и делать акцент на реально важных вещах. Всё это очень быстро выжирает когнитивный ресурс (2-3 часа подготовки спеки и ты уже никакой). Ещё спеки и от коллег нужно ревьювить, помимо кода. А теперь представьте, что прилетели комментарии с код-ревью или тестирования. Помимо кода, скорее всего, нужно дорабатывать и спеку (которую потом опять отполировывать). И на себе замечаю, что временами начинаешь скипать чтение спек или пробегаться по диагонали, что, конечно же, не ок (как и при код-ревью тысячи строк кода, написанного агентами).
3️⃣ Очевидно, но на больших проектах и по мере роста спецификаций их актуализация будет выедать много токенов и времени работы агента.
Что делать? Послушаем в новом сезоне Podlodka Frontend Crew, которая стартует уже 5 октября. На конференции будет сразу три доклада, затрагивающие тему SDD. Один мельком, почему SDD не работает (я думаю, что причины будут схожи), а два других выступления наоборот - как можно применять этот подход, чтобы было не больно (один о фреймворке Spec Kit от разработчиков github-а). А по промокоду
Ну и я совсем скоро поделюсь опытом, как решаю эти проблемы, так как сейчас вот это всё тестируем на рабочих проектах.
erid: 2SDnjcYbM5u
Вы полюбите перегрузку в TypeScript / Хабр
https://habr.com/ru/articles/1096858/
https://habr.com/ru/articles/1096858/
Хабр
Вы полюбите перегрузку в TypeScript
Если вы открыли эту статью, значит, как минимум, слышали о перегрузках в TypeScript, возможно даже пытались их применять, но быстро разочаровались и забросили. Может показаться,...