JavaScript *

После интеграции nuxt/i18n в несколько моих проектов я пришел к однозначному выводу: это, безусловно, лучшее i18n-решение для JS-фреймворков.

Его «plug&play» настройка, загрузка пространств имен (namespaces) и встроенная маршрутизация, настоящее удовольствие в работе.

Однако у этого решения есть серьезная проблема: загруженные пространства имен не подвергаются «тришейкингу» (tree-shaking).

Несмотря на то, что JSON-файлы могут загружаться динамически для каждой локали, Nuxt в итоге объединяет их, что означает, что файл locale/zh/about.json загружается на всех страницах.

React — самый популярный фреймворк среди фронтенд‑разработчиков. Его подходы к разработке приложений часто воспринимаются как единственные правильные. Но что, если такие «стандарты» — это не необходимость, а вредная привычка, ломающая Developer Experience?

В статье разберем типичные проблемы Developer Experience в React: избыточный бойлерплейт, сложность управления состоянием и неочевидные оптимизации производительности. Покажем, как эти же задачи решаются в Svelte и обсудим, как смена фреймворка может упростить разработку.

Статья будет полезна разработчикам, которые хотят расширить свой кругозор и критически переосмыслить привычные подходы к фронтенд‑разработке.

Всегда хотел сравнить ИИ модели на чем-то наглядном и с большим творческим потенциалом. Если попросить ИИ решить школьную задачу по математике, то, скорее всего, все справятся на отлично, тут и сравнивать нечего. Если попросить решить более сложную задачу, то уже придется объяснять читателям, кто из ИИ прав, а кто не очень. Создание компьютерной игры по мотивам хита 80-х, да и еще работающей в мобильном и десктоп браузере, кажется идеальной задачей для сравнения современных ИИ моделей. Посмотреть и поиграть в результаты будет и полезно, и весело.

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

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

Сегодня я рассмотрю несколько специализированных сервисов для хостинга фронта, среди которых не будет однотипных VPS. Только узкоспециализированные решения для хостинга сайтов.

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

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии. В этой статье я продолжаю использовать те же принципы и часть терминологии, что и в предыдущей.

Здесь я, в основном, описываю структурирование по правилам методологии. А в следующей статье, напротив, рассмотрю, как можно улучшить структуру проекта, намеренно нарушая правила FSD. Заранее предупрежу, что правила методологии носят рекомендательный, а не обязательный характер. Их назначение — задать направление структурирования, а дальше принимать решения нужно в зависимости от конкретного проекта и ситуации в нём. Строгое же следование правилам может привести к бо̒льшим проблем, чем их нарушение.

Если заметите ошибки — пишите в комментариях!

Привет! Хочу рассказать о своей библиотеке hq-cropper — инструменте для обрезки изображений на чистом TypeScript без единой зависимости.

Когда искал cropper для своего проекта, столкнулся с двумя проблемами. Во-первых, большинство популярных решений тянут за собой кучу зависимостей и весят 100+ KB. Во-вторых, мало кто работает с большими изображениями.

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

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

Всем привет, я сооснователь мессенджера Пачка и отвечаю, в том числе, за маркетинговую инфраструктуру. 

Нам нужно было оперативно увезти наш сайт с Webflow: 500+ страниц, блог и база знаний. При этом возвращать фронтенд-разработку в режим постоянной поддержки сайта мы не хотели. Поэтому рассматривали конструкторы и CMS, но быстро поняли, что это будет работа в минус. Все усилия на переезд лишь вернули бы сайт в рабочее состояние, не дав новых возможностей.

В итоге мы решили вести разработку и поддержку сайта в Cursor. То есть переписать его на NextJS с помощью AI агентов. Такая связка дала понятную модель страниц, быструю доставку статики и ISR для контента, а также возможность отказаться от отдельной CMS за счёт MDX.

В спокойном режиме за два месяца удалось полностью переписать сайт и запустить его в прод. Ниже делимся практическим опытом этого переезда.

Синтаксис Go глазами того, кто последние пять лет писал на TypeScript.

В первой части мы разобрались с философией Go и настройкой рабочего окружения. Теперь к коду. Эта статья про синтаксис и ключевые концепции Go. Не ждите пересказа документации. Будут сравнения, будут подводные камни, будет код.

Если вы работаете с BI‑системами, наверняка сталкивались с ситуацией, когда стандартных визуализаций не хватает. Хочется добавить свой график, который идеально подходит под задачи бизнеса.

В Modus BI такая возможность встроена в саму платформу — вы можете создавать свои плагины визуализаций. В этой статье мы шаг за шагом разберем, как собрать с нуля простой, но гибко настраиваемый прогресс‑бар. Руководство будет полезным для разработчиков, которые хотят самостоятельно создавать уникальные визуализации на базе Modus BI.

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

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

В этой статье мы рассмотрим, как разработать собственный бинарный протокол для приложений на основе Node.js и WebSockets, добавить авторизацию с помощью JWT и изучим преимущества бинарного протокола по сравнению с другими форматами данных.

Привет! Работа над ядром поисковика 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, загрузки модулей, многопроцессной архитектуры, песочниц безопасности и инструментов разработчика. Главная цель — дать понятное и доступное объяснение того, что происходит в браузере "под капотом".

Если JS/TS это динамичный, асинхронный «ассемблер» для веба, построенный вокруг одного потока и цикла событий, то Go это строгий, параллельный «ассемблер» для облака, построенный на простоте, явности и истинном параллелизме.

Многие классические учебные материалы по Go, которые вы можете найти, уже устарели. Официальный документ "Effective Go", написанный в 2009 году, не охватывает ни модули, ни дженерики. Два аспекта, которые являются фундаментальными для современного Go. Аналогично, многие популярные книги, такие как "The Go Programming Language", были написаны до появления дженериков. Этот документ призван стать современной отправной точкой, ориентированной на версию Go 1.25+ и использующей ваши существующие знания JS/TS для ускорения обучения.

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

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

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

Всем привет! Меня зовут Максим Иванов. Сегодня я хотел бы провести небольшой исторический экскурс и объяснить, почему Document Picture-in-Picture — это не просто способ отображать видео в формате «картинка в картинке», а новое и любопытное API, которое потенциально может заменить привычный всем window.open.

Возможность выводить видео в режиме PiP появилась еще в сентябре 2018 года в Chrome 69. С тех пор прошло более семи лет активного тестирования и развития. В 2019 году подобный механизм появился в Safari, а к 2020-му — и в Firefox.

Теперь, когда почти каждый браузер умеет открывать видео в отдельном плавающем окне, возникает логичный вопрос: могут ли браузеры с той же легкостью открывать в отдельном окне интерактивный HTML-контент, а не только видео? И если да, то каким образом? Давайте поговорим об этом ниже.

Идея вот в чем: берем стандартные JavaScript модули (ESM) и делаем их прямыми эндпоинтами для генерации любых текстовых веб-ассетов, таких как HTML-файлы, CSS, SVG или даже JSON или Markdown, используя простое соглашение о именовании исходных файлов и дефолтный экспорт результата в виде строки (JavaScript Template Literal). Проще некуда и чем-то похоже на PHP, верно? Но, что это нам дает?

Давайте разберемся, почему JSDA (JavaScript Distributed Assets) - это то, что может сделать веб-разработку "грейт эгейн", после тысячи поворотов "не туда".