Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик и создатель Web Audio Studio — браузерного инструмента для визуализации и исследования аудиографов на Web Audio API. В этой статье я хочу поделиться историей разработки этого проекта, техническими деталями и особо интересными инженерными вызовами, с которыми я столкнулся в процессе его создания. Кроме того, я выскажу свои мысли о Web Audio API, о том, почему этот стандарт недооценен у веб-разработчиков и что с этим можно сделать (спойлер: во многом ему не хватает хорошего инструментария для разработки и отладки).

Всем привет! Последние несколько месяцев я работаю над пет-проектом — интерактивной образовательной платформой для изучения Web Audio API и принципов обработки и синтеза цифрового звука. На платформе пользователи смогут решать задачи, программируя на JavaScript прямо в браузере. Эти программы выполняются в изолированной среде — песочнице, где пользовательский код не может повлиять на работу самой платформы.

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

Хочу поделиться своим необычным достижением: я стал официальным переводчиком книги издательства O’Reilly. Я перевёл на русский язык книгу Бориса Смуся Web Audio API (O’Reilly, 2013). В процессе работы над собственным образовательным проектом на тему синтеза и обработки цифрового звука, я начал изучать API и наткнулся на эту книгу на английском языке. Сначала я просто её конспектировал, но полезной информации было так много, что постепенно мои конспекты превратились в полноценный перевод. Тогда у меня появилось желание довести работу до конца — чтобы у русскоязычных разработчиков тоже был доступ к этим знаниям. В итоге я смог получить официальное разрешение на публикацию перевода от главы отдела по правам издательства O’Reilly и делюсь переводом с вами.

Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик, и сегодня хочу поговорить о вопросах этики в интерфейсах и ценностях в разработке на примере одного моего недавнего собеседования. Это история о том, почему я отказался внедрять тёмные паттерны и не получил оффер на фронтенд-лида.

Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик, и я часто сталкиваюсь с разработкой веб-интерфейсов с использованием Drag and Drop. В своей предыдущей статье про Drag and Drop я рассказывал про историю появления и развития этого подхода: появившись в первом в мире графическом интерфейсе, Drag and Drop продолжает быть одной из самых актуальных технологий и на сегодняшний день. В этой статье я хочу поговорить об особенностях проектирования дизайна и юзабилити интерфейсов с Drag and Drop. В первую очередь, я буду приводить примеры и говорить об особенностях Drag and Drop в рамках сложившихся практик в современных веб-интерфейсах, но многое из этого будет справедливо и для интерфейсов классических настольных приложений.

Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик, и в последнее время я много работаю над веб-интерфейсами с возможностью перетаскивания объектов методом Drag and Drop. В процессе изучения стандартов и сложившихся лучших практик работы с этим подходом, мне стало интересно разобраться в истории его появления. Копнув поглубже, я выяснил, что Drag and Drop — это один из самых первых способов взаимодействия человека с компьютерной программой. В этой статье хочу рассмотреть историю появления и развития этой технологии.

Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда, а также когда необходимо изолированно протестировать различные пользовательские сценарии. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw, и в ней достаточно много важных обновлений.

Всем привет! Недавно я решал задачу разработки сайта-лендинга для собственного проекта. У лендинга должна была быть админка, то есть данные для его содержимого должны были храниться и редактироваться на сервере. Поэтому я искал современный и мощный инструмент для генерации страниц на основе данных из API админ-панели.

Так я познакомился c подходом SSG (Static Site Generation — Генерация статических сайтов), попробовал его в деле, и хочу рассказать о том, что это такое, зачем может понадобиться SSG-фреймворк и почему Astro — лучший выбор для генерации статических сайтов прямо сейчас.

Привет, Хабр! Меня зовут Александр Григоренко, я фронтенд-разработчик. В основном, занимаюсь разработкой приложений на React, но также постоянно экспериментирую с различными технологиями.

В своей работе я часто создаю собственные или использую уже готовые UI-компоненты. Проблема с такими компонентами заключается в том, что они часто ограничены определённым фреймворком, и их реализация требует написания сложной нестандартизированной логики. В течение долгого времени для базовых UI-компонентов, таких как диалоговые окна, использовались самописные решения, а в тяжёлых случаях и встроенные в JavaScript методы alert(), prompt() и confirm().

Отличная новость в том, что такой компонент можно реализовать с использованием нативного HTML-элемента <dialog>, который встроен в стандарт HTML5 и работает одинаково во всех современных браузерах.

Давайте познакомимся с возможностями <dialog> поближе.