JavaScript *

Принимая архитектурные решения, часто так или иначе приходится идти на компромисс: между качеством и скоростью разработки, сложностью реализации и удобством поддержки, быстротой решения бизнес-задачи и гибкостью. Со временем небольшие уступки накапливаются и проект покрывается легаси. Даже если исправно разгребать техдолг, то в любом случае на достаточно длинной дистанции решения и технологии устареют, и станет невозможно обойтись «генеральной уборкой» — потребуется смена архитектуры.  

В статье расскажу, как мы столкнулись с неизбежной необходимостью переделки веб-плеера RUTUBE — сервиса, который существует с 2006 года, пережил несколько смен команд и парадигм разработки и при этом достаточно большой и высоконагруженный, чтобы нельзя было «просто так взять и всё переписать». 

В этой статье я расскажу, как я для себя понимаю архитектуру десктоп-приложений — и почему в какой-то момент Rust перестал быть «языком, который я когда-нибудь посмотрю», и стал практичным решением.

Сразу оговорюсь: это не попытка доказать, что «Electron — зло», а Rust — «спаситель». Это скорее дневник архитектора, который хотел собрать удобный продукт и по дороге несколько раз наступил на грабли. Некоторые грабли были с подогревом.

Привет! Работа над ядром поисковика rats-search продолжается. Новая версия библиотеки librats (v0.5.3) приносит важные архитектурные улучшения для построения распределенных сетей в условиях NAT и блокировок.

Ключевые изменения:

Унифицированный API (FFI): Завершена интеграция с Node.js. В отличие от фрагментированных реализаций libp2p, librats предоставляет идентичный набор функций для C++, Python, Node.js и Android через FFI.

Эффективный DHT:

Реализован алгоритм Spider для прибегания с сбора announce.

Добавлена поддержка branch-factor и маршрутизации на основе задержек (RTT-routing).

Персистентность: Routing-таблицы сохраняются при перезапуске, что критически важно для связности сети в сложных сетевых условиях.

BitTorrent: Значительный рефакторинг и оптимизация модуля.

Платформы: Windows (x64), Linux (x64), Android (32/64), macOS (x64).

Всем привет!

Пока из каждого утюга рассказывают о различных ИИ-инструментах, агентах и прочих радостях упрощающих жизнь, я хочу рассказать о 11 незаслуженно потерянных фичах в недрах Chrome Devtools. Про фишки ИИ в DevTools рассказывать не вижу смысла, так как в нашем регионе они пока не работают.

Кстати, первая часть тут - тык.

Погнали!

Веб-разработчики нередко воспринимают браузер как «черный ящик», который каким-то чудом превращает HTML, CSS и JS в интерактивные веб-приложения. На самом деле современный браузер — будь то Chrome (на базе Chromium), Firefox (Gecko) или Safari (WebKit) — представляет собой чрезвычайно сложное программное решение. Он управляет сетевыми запросами, разбирает (парсит) и выполняет код, рендерит графику с ускорением на графическом процессоре (GPU) и изолирует контент в отдельных процессах для обеспечения безопасности.

В этой серии статей мы подробно рассмотрим, как устроены современные браузеры, сделав акцент на архитектуре и внутреннем устройстве Chromium, но также отметим ключевые отличия в других браузерах. Мы рассмотрим весь цикл: от сетевого стека и конвейера парсинга до рендеринга с помощью Blink, выполнения JS с помощью движка V8, загрузки модулей, многопроцессной архитектуры, песочниц безопасности и инструментов разработчика. Главная цель — дать понятное и доступное объяснение того, что происходит в браузере "под капотом".

Всем привет! Меня зовут Алексей Золотых, я тимлид команды веб-редакторов в МойОфис. Недавно мы запустили новое шоу АйТир Лист. В каждом выпуске мы берём одну тему из мира разработки и раскладываем всё по тир-листу: от FAIL до GOD.

В пилотном выпуске мы с коллегой — Александром Коротаевым, фронтенд-гуру и энтузиастом креативного кодинга, прошлись по популярным опенсорс-инструментам для фронтенда: от тех, которые пора отпускать, до тех, что стали эталоном. Эта статья — расширенная версия выпуска. Под катом рассказываем, что у нас попало в FAIL, кто выжил на уровне MVP, кого мы поставили в SENIOR и кто, по нашему мнению, заслужил звание GOD.

Дисклеймер: мы с большим уважением относимся ко всем упомянутым проектам. Многие из них помогли индустрии вырасти. Но сегодня мы смотрим на них через призму вопроса: что бы мы посоветовали новичку или команде в 2025 году.

Недавно я наткнулась на статью «How Functional Programming Shaped Modern Frontend» и неожиданно поймала себя на мысли: мы уже настолько привыкли к функциональному программированию (ФП) в JavaScript, что забыли, как всё начиналось и почему многие идеи казались почти спасением. Чтобы лучше понять эволюцию, я решила посмотреть, что писали разработчики о ФП во фронтенде 10 лет назад, примерно в 2013-2016 годах.

Контраст получился довольно яркий: от искреннего восторга до постепенного прозрения.

Я решила поделиться своим анализом, основанным на современных наблюдениях и на тех статьях прошлого, где ФП воспринималось как путь к «правильному» фронтенду.

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

Привет, Хабр! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. Сегодня мы поговорим о методах массивов. Если коротко, вы узнаете, как легко и элегантно работать со списками данных, не используя громоздкие циклы. Детали внутри.

Всё началось с внутреннего предложения на работе присоединиться к отделу по развитию и поддержке веб-сайтов (название другое, но это их обязанности, поэтому написал так). Это была одновременно лестная и пугающая перспектива. Возможность работать над реальными проектами манила, но мой опыт в веб-разработке был скорее теоретическим. Я понимал, что для старта мне нужен был собственный, понятный проект, который стал бы началом.

И тут я вспомнил о своей идее сделать сайт для консольной реализации шахмат на Python. Это была сухая игра, написанная на Pygame для двоих программистов, но не для людей, так как её нельзя было запустить на других устройствах. И у меня родилась идея: а что, если превратить этот скелет игры в веб-приложение на JS?

Из минусов было только то, что моя игра написана на языке Python, а для работы мне нужен JavaScript, и я решил, что это не проблема, и начал переписывать готовую логику на новый язык, параллельно добавляя новые функции.

Идея зацепила сразу, представьте: вы переносите свой проверенный, рабочий кейс, у которого вся шахматная логика (проверка ходов, матов и пат) уже работает и ничего нового придумывать не надо, нужно только сделать интерфейс для браузера и все новые идеи (например, таймер).

Веб-разработчики нередко воспринимают браузер как «черный ящик», который каким-то чудом превращает HTML, CSS и JS в интерактивные веб-приложения. На самом деле современный браузер — будь то Chrome (на базе Chromium), Firefox (Gecko) или Safari (WebKit) — представляет собой чрезвычайно сложное программное решение. Он управляет сетевыми запросами, разбирает (парсит) и выполняет код, рендерит графику с ускорением на графическом процессоре (GPU) и изолирует контент в отдельных процессах для обеспечения безопасности.

В этой серии статей мы подробно рассмотрим, как устроены современные браузеры, сделав акцент на архитектуре и внутреннем устройстве Chromium, но также отметим ключевые отличия в других браузерах. Мы рассмотрим весь цикл: от сетевого стека и конвейера парсинга до рендеринга с помощью Blink, выполнения JS с помощью движка V8, загрузки модулей, многопроцессной архитектуры, песочниц безопасности и инструментов разработчика. Главная цель — дать понятное и доступное объяснение того, что происходит в браузере "под капотом".

Реверс-инжиниринг — это трудоемкая и интересная задача, которая поддается не всем. Любой может «скормить» программу декомпилятору, но не у всех хватит выдержки разобраться в хитросплетениях машинных команд. Процесс становится сложнее, если исследование проводится над программой для другого устройства, например телефона с ОС Android.

Звучит сложно. Долгое время и мне так казалось, особенно при создании модов для приложений. Байт-код smali неплох, но писать на нем сложную логику вручную — неблагодарное занятие. Но недавно мне попался на глаза решение для динамического реверс-инжиниринга — Frida.

Frida — это инструмент, который позволяет вживлять небольшой кусок JavaScript-кода прямо в запущенное приложение и менять его поведение. Под катом я расскажу, как работать с Frida, исследовать приложения на телефоне без root-доступа и создавать свои моды.

Недавно UI-библиотека Nuxt UI получила серьёзное обновление — версию Nuxt UI 4. Это принесло два больших изменения. Во-первых, теперь можно использовать Nuxt UI не только с Nuxt, но и с Vue напрямую. Во-вторых, все ранее платные возможности (Pro-компоненты, стартовые шаблоны и Figma UI Kit) теперь полностью бесплатны.

Всё это хороший повод разобраться, как же устроена Nuxt UI, в чём её преимущества и как начать с ней работать.

Первая в мире библиотека Web Components в духе shadcn/ui

Насколько я проверил — это первая подобная библиотека для Web Components. Если ошибаюсь — поправьте в комментах! 🤓

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

Обработка ошибок в JavaScript всегда была немного хаотичной. Получить ошибку легко, но отследить ее первоисточник бывает очень сложно. Именно здесь и приходит на помощь свойство cause.

Зачем запускать тяжелый Fusion 360 или ArtCAM, чтобы просто вырезать фланец или прокладку? Я написал свой CAM-процессор на чистом JavaScript и Three.js, который готовит G-code из DXF за пару секунд прямо в браузере.

В статье разбираем архитектуру легковесного инженерного софта: парсинг DXF, визуализацию траекторий на WebGL, алгоритмы оффсетов и опыт парного программирования с нейросетью.

Видео стало неотъемлемой частью нашей жизни: мы смотрим его на смартфонах, ноутбуках и всё чаще — на телевизорах. Несмотря на то, что видеосервисы традиционно ориентировались на мобильные устройства, за длинным контентом пользователи идут именно на большие экраны, и это подтверждается ростом времени просмотра. Сегодня среднее дневное время смотрения VK Видео на Smart TV достигает 216 минут.

И тут начинается самое интересное: телевизоры — это особый мир со своими капризами и законами. Официальные спецификации обещают поддержку HLS, DASH, 4K, 60 FPS. На практике поддержка функций зависит не столько от новизны модели, сколько от того, как это реализовано у конкретного производителя. В одних устройствах всё работает корректно, в других — частично или вовсе не запускается. Новая модель при этом не всегда гарантирует лучшее воспроизведение видео.

Меня зовут Игорь Горяйнов, я программист в команде веб-технологий Единой видеоплатформы VK. Ниже расскажу, как команда прошла путь от нативных плееров к собственному веб-решению для ТВ, какие задачи пришлось решать и что это дало пользователям.

Привет, Хабр. Я Саша, разработчик, пишу на JS. Ранее я рассказывал о callback-функциях, деструктуризации, операторах и многом другом. Если вы уже успели познакомиться с основами JavaScript, то наверняка вам знакомы такие понятия, как объекты и функции.

В этой статье мы двинемся дальше и соберем эти знания воедино. Я расскажу вам о методах объектов и загадочном слове this. Разберемся, для чего они нужны, как сделать объекты по-настоящему живыми и как избежать частых ошибок. Ну что, начнем. 

Привет, на связи Виктор Степанов, лид одной из core-команд GitVerse. Сегодня хочу поговорить о важном аспекте нашей платформы — пользовательском опыте. А именно о том, как мы разрабатывали тёмную тему для GitVerse. Это был не просто косметический апгрейд, а полноценный инженерно-дизайнерский проект, в котором переплелись эргономика, технические ограничения и, конечно, ожидания пользователей.

В последние годы спрос на 2D/3D-инструменты в веб-сервисах растет довольно стремительно, технологии развиваются, появляются новые подходы и библиотеки — а вместе с ними растёт и путаница: что где использовать, где грань между похожими решениями и почему у разработчиков часто возникают противоположные мнения?

Так что я решила устроить небольшой тест 2D-решений: посмотреть, на что они реально способны, понять, почему результаты местами вызывают большое удивление, и ответить себе (и вам) на вопрос: а WebGPU вообще зачем?

Спойлер: всё далеко не так очевидно, как кажется.