JavaScript *

Всем привет!

Долго я возился с маркдауном в своих проектах и, честно говоря, знатно подгорел. Первая проблема — это вечный выбор библиотеки.

С одной стороны, есть «конструкторы» типа 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 и почему он стал адекватным выбором для кроссплатформенной разработки.

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

Здравствуйте, снова я — Дмитрий, React-разработчик. Все мы видели с вами такие карты, именуемые картойдами, в данном случае — карта России, я взял первую попавшуюся из интернета, для примера.

Привет, Хабр! (И тебе, случайный читатель, который думает, что "код - это магия", а процессор - маленький гномик, который внутри ноутбука читает for i in range(10) и послушно бегает кругами.)

Сегодня разберёмся с вопросом, который в какой-то момент приходит в голову каждому разработчику, а потом быстро вытесняется дедлайном:

Как вообще компьютер “читает” Python или 1С или любой другой язык программирования, если он понимает только 0 и 1? И почему ваш идеальный код иногда превращается в "segmentation fault" / "Неопределённая ошибка" / “Пользователь не найден (хотя он сидит напротив)”?

Вот и мне спустя годы в разработке пришла идея изучить этот ваш старомодный Computer Science и понять вообще, что такое программа и компьютер на самом деле.

Поехали. Будет без хардкора уровня “компилятор за 21 день”, но с понятными аналогиями, для статьи упростил всё до минимума. Реально постарался переварить информацию и выдать её в красивой упаковке. Кстати, в статье будут примеры из двух разных миров Python и 1С, так что будет интересно…

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

Мой личный топ из всех популярных онлайн-маркетов — это Wildberries. Я люблю этот сервис и активно им пользуюсь. Мне кажется, это уже хороший повод посмотреть, насколько он доступен людям с различными ограничениями. Безусловно, это очень популярная платформа в странах СНГ, но это, конечно же, не значит, что она одновременно и доступна на 100%.

Сразу хочу оговориться: я не пытаюсь подчеркнуть какой-то изъян платформы. В конце концов, у каждого продукта свои бизнес-приоритеты, и доступность (если она не обязательна с точки зрения законодательства) — это личное дело каждого бизнеса. К примеру, мой продукт тоже не удовлетворяет всем критериям доступности, да и многие другие, на которых я работал. При том что моя личная аналитика прошлого года показала, что 20% моей пользовательской базы меняют размер шрифта для лучшего восприятия, но не факт, что есть хотя бы один (я бы сказал, его и нет) кто использует продукт, будучи полностью незрячим, со скринридером.

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

Кратко о том, почему я не использую фреймворки, зачем пишу всё с нуля и к чему это привело.

Я написал полноценный SDK для web-приложений как концепт альтернативной ветви развития, если бы web-индустрия пошла по пути игровых движков.

Как Angular Ivy находит зависимости за O(1)? Глубокое погружение в алгоритм резолва: от генерации уникальных ID токенов до битовой магии Блум-фильтров. Разбираем, почему строковые токены замедляют ваше приложение и как работает наследование кумулятивных масок в LView.

Эта история не о строчках кода, а о том, как мы с другом устали смотреть на пустую доску в офисе. Сначала мы сделали свою версию проекта — с партнёрами и погодой, как мы предполагали по возможным требованиям. Потом я создал версию для себя: с котиками из Giphy API, бегущей строкой цитат и анимированной погодой. В этой статье — о том, как из простого желания добавить красок в рабочее пространство родился личный Preloader перед началом работы, и как пустота корпоративного экрана превратилась в доску вдохновения, которая теперь висит фоном на моём мониторе.

Интро

Это история о том, как «кривой» роутер научил меня смотреть на память браузера иначе. Есть вкладка с ИИ-чатом, есть WebSocket/Streaming, есть обычный i5. И есть момент, когда все это превращается в кирпич: вкладка раздувается до гигабайтов, процессор залипает, страница оживает только на пару минут после перезагрузки.

Лид

Проблема оказалась не в нейросетях и не в JS. Виновник — старый домашний роутер, который не вывозил IPv6 и фрагментацию. Итог — застрявшие пакеты, нарастающий буфер в браузере и тысячи незавершенных async/await-машин в памяти.

TL;DR

- Вкладка с WebSocket раздувается из-за сетевых затыков.
- Роутер ломает MTU/IPv6, пакеты зависают, bufferedAmount растет.
- Асинхронные цепочки не завершаются и копятся в Heap.
- Фикс: MTU 1400 + отключение IPv6.
- В коде: мониторинг bufferedAmount, таймауты и AbortController.

Симптом

- Вкладка с ИИ-чатом пухнет до 1–2.5 ГБ.
- CPU уходит в 100%, интерфейс замирает.
- Перезагрузка помогает на 5 минут, дальше все повторяется.

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

Если вы когда-нибудь писали фронтенд на TypeScript и получали в проде Cannot read property 'x' of undefined, — добро пожаловать в клуб!

TypeScript спасает нас от сотен ошибок… но только пока код не запущен. Как только он скомпилировался, типы исчезают, и в рантайме вы снова остаетесь один на один с невалидными данными.

И вот тут начинается: меняется API, формы шлют что угодно, аналитика ломает отчёты, а тесты молчат.

В Островке мы попробовали библиотеку Valibot — легковесный runtime-валидатор, который умеет проверять данные на границах контекстов и при этом остаётся дружелюбным к TypeScript.

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

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

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

Мы разберем три самых полезных метода: map — для преобразования данных, filter — для отбора элементов и sort — для сортировки. Вы поймете, как они работают внутри, и примените знания на практике, создав свои аналоги этих функций. Подробности, как всегда, внутри.