Обычно FFmpeg используют на сервере, но есть обертки и сборки для браузера, которые позволяют выполнять операции и на фронтенде. Сегодня речь пойдет о ffmpeg.wasm и настройке параметров для односекундной сборки видео, которое после просмотра пользователь может скачать.
В статье покажем, как выглядит решение. Оно подойдет и для бэкенда, но нам пришлось обрабатывать и склеивать ролики именно на клиенте.
На рынке тысяча трекеров привычек. Еще тысяча трекеров зала. И еще сотня приложений для медитаций. Проблема одна: они разрозненны. Данные о том, что я плохо спал, никак не влияют на план тренировок в другом приложении. А медитация живет в вакууме от уровня стресса.
Мы хотели создать LifeOS — единую систему управления собой, которая живет там, где я провожу 90% времени. В Telegram. Никаких впнов, ноушенов и тому подобное не надо.
Но была проблема: стандартные Telegram WebApps часто выглядят... как веб-сайты из 2010-го. Мне нужен был «вайб» Apple: премиальный, темный, с глубокими тенями и, главное, тактильный.
Так появился UltyMyLife. Вот как мы строили архитектуру дисциплины на React.
Интересный факт: Перед тем как релизнуть проект, мы поняли, что нужен полный редизайн, и в итоге потратили еще пару недель.
Привет, меня зовут Саша, и я продолжаю рассказывать о JavaScript тем, кто только взялся за освоение этого языка. В разработке нам постоянно нужны «умные», самостоятельные функции: счетчики, которые знают свое предыдущее значение, обработчики событий с индивидуальными настройками, механизмы для защиты данных.
Чтобы не городить глобальные переменные и не писать громоздкие конструкции (что почти всегда ведет к багам), мы посмотрим на еще одну фишку JS.
В предыдущих статьях мы разобрали: функции, их стрелочные записи, методы объектов и даже покорили this. Теперь пора переходить к теме, которая часто пугает на собеседованиях, но на деле оказывается невероятно элегантной — замыканиям.
Представьте: ваши автотесты проходят стабильно, ошибок почти нет, команда довольна. Но со временем тесты стали работать в «стерильных» условиях и перестали отражать реальность. Именно с такой ситуацией мы столкнулись на крупном продукте после трех лет регулярных прогонов. В этой статье расскажем, как мы перешли от «зашитых» констант к системе динамической генерации данных, сделали тесты «сложнее» и в итоге повысили их реальную эффективность в 10 раз.
Причина такого поведения оказалась в самом фундаменте: автотесты опирались на статичные, «зашитые» данные, созданные еще при первом покрытии кода. Они были разработаны более трех лет назад и для скорости были объявлены в виде констант непосредственно перед кодом теста.
История проекта началась в прошлом (2025) году. Я преподаю JavaScript в HTML Academy, и когда мне предложили взять поток начинающих разработчиков по Angular, я согласился. Мы успешно прошли базу, но когда дело дошло до HttpClient и обработки данных, я столкнулся с проблемой: студентам сложно понять Observable и реактивный подход, имея в багаже только промисы.
На лекции мне задали резонный вопрос: А где посмотреть актуальные и понятные материалы по RxJS?. Я провел небольшой ресерч и понял, что ниша полупустая: видеокурсы - это долго, документация - сложно, а интерактивной практики почти нет.
Так появился мой open-source проект. В этой статье я показываю честную аналитику за 90 дней: как набрать 1000 пользователей без рекламы, почему провалилась моя любимая фича и как пет-проект превращается в полноценный продукт.
Блокчейн разработка меняется со скоростью света. Решив вникнуть, купил несколько лет назад книгу, но к сегодняшнему дню она уже безнадежно устарела. Инструменты описанные в ней web3.js, Truffle, Ganache, заброшены, подходы и стандарты изменились.
В праздники, дописал и залил в сеть web3 демо-магазин на solidity/ethers.js. Поделюсь ньансами разработки и современными инструментами.
Бывало такое: смотрите вы на красивую страницу интернет-магазина, открываете консоль разработчика (ту самую, по F12 или через правый клик), а там — лес из тегов, который вообще не похож на то, что вы видите глазами?
Привет, Хабр! Меня зовут Александр Дудукало, я автор курса по JavaScript. В этой статье мы продолжаем знакомиться с элементами страницы, а именно с DOM. Эти знания вам точно понадобятся в работе с любым проектом. Давайте же больше узнаем, что это за дерево и как с ним работать. Поехали.
В 2026 году обновят JavaScript. Окончательный список изменений сформируется из проектов ECMAScript, достигших 4 этапа к марту. Но многие из них уже на заключительной стадии, а другие готовы и доступны в некоторых браузерах и средах. Под катом — что ждёт разработчиков и какие проблемы будут решены в этом апдейте.
В первой части мы разобрали эволюцию архитектуры React Native. Теперь перейдем к практическим вопросам: как организован процесс разработки и какие платформенные особенности встретятся в работе.
Процесс разработки
Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта.
Bare React Native
Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:
В данной статье я расскажу, с какими проблемами, связанными с бинарником, столкнулось моё решение при запуске на Arch Linux у моих знакомых, и почему у меня оно работает нормально на Debian 12 и 13. Также я разберу преимущества и недостатки текущей реализации, покажу возможные пути решения и альтернативы, а лучшее решение применю на практике.
Я снова попрошу Сергея и Ивана запустить моё приложение на Arch Linux, чтобы проверить его работу.
Заваривайте чай, доставайте вкусняшки — пора «удобрять почву для выращивания помидоров»! 🍅
Всем привет!
Долго я возился с маркдауном в своих проектах и, честно говоря, знатно подгорел. Первая проблема — это вечный выбор библиотеки.
С одной стороны, есть «конструкторы» типа unified, remark и rehype. Штуки мощные, но настраивать весь этот AST-конвейер и систему плагинов — это какой-то оверхед и лишняя сложность, имхо.
С другой стороны, есть @next/mdx, который вроде и ок, но слишком завязан на страницах и вообще не умеет работать на клиенте.
Раньше я обычно выбирал что-то вроде markdown-to-jsx или react-markdown.
DX у них приятнее, работают и на клиенте, и на сервере, весят мало.
Но вот беда: они «из коробки» не переваривают HTML или MDX, и ты снова вязнешь в настройке плагинов. А если добавить туда i18n (типа i18next или next-intl), начинается настоящий ад. Куча if/else в коде, чтобы отрендерить нужный язык, и бандл раздувается до небес. Плюс вечные косяки с front-matter. Ну и до недавнего времени всё это было только для React.
В общем, решил я написать свое решение для intlayer. Чтобы просто работало.
> К слову, за основу я взял форк markdown-to-jsx v7.7.14 (от quantizor), который базируется на simple-markdown v0.2.2 (от Khan Academy).
Когда пилил этот парсер, ставил перед собой такие цели:
- Максимально легкий вес
- Кросс-фреймворковость (React, Vue, Svelte, Angular, Solid, Preact)
- Простая настройка: никаких бесконечных цепочек плагинов
- Поддержка SSR и клиентского рендеринга
- Настройка на уровне провайдера: можно легко прокинуть свои компоненты из дизайн-системы
- Компонентный подход: полный контроль над рендерингом каждой части приложения
Привет! Это второй выпуск Frontend Status — дайджеста по фронтенд-разработке. В выпуске — два десятка материалов: от коротких демо до гайдов и спецификаций.
В подборке — то, чем живёт фронт прямо сейчас: свежий CSS, AI-инструменты (генеративный UI, офлайн-поиск по сайтам, Figma → React), записи (Remotion, ИИ и верстка), апдейты браузеров и платформ (geolocation, Grid Lanes, WebNN, угрозы и учётные данные). Плюс React и Angular, WASM-язык COI, Temporal API и обход блокировок Cursor/Claude через OpenCode.
Всем привет.
В этой статье мы продолжим дорабатывать базовые инструменты для работы с инвестициями и начнем изучать индикаторы.
React Native прошел путь от решения с фундаментальными архитектурными ограничениями до платформы с современным, производительным ядром. В этой статье мы разберем, как работала старая архитектура на основе Bridge, как ее заменили JSI, Fabric и Hermes, и в каких случаях React Native - оптимальный выбор для проекта.
Старая архитектура с Bridge
В основе этой архитектуры лежат асинхронный Bridge. Нативный код и JavaScript работали в отдельных потоках. Общение между ними происходило через Bridge, который передавал сообщения в формате JSON.
В изолированной корпоративной сети с полумиллионом файлов стандартный поиск превращается в рутину. Облачные сервисы недоступны, серверные решения избыточны, а встроенные инструменты ОС не справляются с объёмами и разнородностью клиентов (Windows и Linux).
Мы столкнулись с этой задачей и вместо развёртывания сложной инфраструктуры пошли другим путём: упаковали весь поисковик в один HTML-файл. Фоновая индексация на Python раз в сутки — и сотрудники получают мгновенный поиск по путям прямо в браузере.
В статье разбираем архитектуру решения: как относительные пути решают проблему разных точек монтирования, почему плоский JS-массив оказался эффективнее сложных структур, и как уместить индекс 560+ тысяч файлов в 120 МБ без потери скорости.
Не полнотекстовый поиск, а инструмент для навигации по глубокой файловой структуре, где важная информация закодирована в путях. Работает там, где нельзя поставить Elasticsearch, но нужно быстро находить документы.
В JavaScript есть уникальная особенность, переменную или функцию можно использовать по коду выше, её объявление...
Недостаток знаний часто подталкивает людей к чрезмерно сложным решениям, и рано или поздно это отражается на производительности.
Возьмем content-visibility: auto. Он дает тот же эффект, что и React-Window, но без единой строчки JS и без увеличения размера сборки. Аналогичная ситуация с современными единицами высоты окна (dvh, svh, lvh): наконец-то приведена в порядок "мобильная" высота, которую годами пытались компенсировать через window.innerHeight.
Обе технологии в 2024 году получили более 90% поддержки современных браузеров и полностью готовы для продакшна. Однако мы по привычке продолжаем решать такие задачи с помощью JS, просто потому, что CSS незаметно ушел вперед, пока мы спорили о React Server Components.
Мне кажется, я знаю, как должен быть устроен идеальный электродвигатель, но чтобы это доказать, нужен инструмент. Существующий софт убивал все желание: медленно, дорого или неудобно.
За зимние каникулы мы с Gemini (да, почти весь код написал ИИ) создали свой солвер на WebGPU. Весь софт - это один HTML-файл. Он работает в браузере, считает сетки до 16К в реальном времени и умеет то, чего нет у аналогов.
2026 год на дворе. Нейросети уже пишут музыку, рисуют картины, сочиняют сценарии и даже спорят с вами в комментариях.
А вы всё ещё вручную переписываете for на list comprehension? Пора признать: кодинг тоже изменился. Теперь ваш главный навык – не только знать синтаксис, но и уметь чётко и ясно объяснять задачу тому самому ИИ-напарнику, который уже ждёт в соседней вкладке.
Но как объяснить, чтобы не получилось «ну ты понял»? Как заставить модель генерировать идиоматичный, чистый и работающий код с первого раза? Ответ – в промптах, продуманных, отточенных и готовых к использованию шаблонах.
Мы собрали для вас 10 таких промптов – от перевода кода между языками до рефакторинга и документирования. Ваш ChatGPT теперь станет в разы полезнее.
Погнали разбираться!
В первой части цикла мы разобрались, зачем вообще нужен Capacitor и почему он стал адекватным выбором для кроссплатформенной разработки.
Теперь переходим к самому болезненному и интересному этапу: миграции уже существующего веб-приложения.
