JavaScript *

Привет, Хабр!

URLPattern дорос до того, чтобы его можно было использовать как нормальный «роутер без фреймворка». В браузерах API уже поддерживается широким набором движков, а в Node 24 он доступен глобально без импортов. Один и тот же паттерн можно матчить и в Service Worker, и в HTTP-сервере на Node.

URLPattern — это примитив платформы для сопоставления URLам по удобному паттерну. Он матчится по компонентам: protocol, hostname, port, pathname, search, hash. Есть test и exec, named groups и опции вроде ignoreCase. Важный плюс в том, что у нас есть одинаковая семантика в браузере и в рантаймах, которые его тащат из той же спеки.

В Node 24 объект доступен глобально, как URL, без require('node:url'). Сам класс появился в 23.8, в 24-й ветке он отмечен как experimental, но доступ из коробки.

По поддержке в браузерах ситуация здоровая. По Can I use, URLPattern работает в актуальных ветках Chrome, Firefox, Safari, Edge, включая мобильные.

Привет, Хабр!

А вы интересуетесь современными возможностями CSS и HTML? Может, некоторые из вас думают, что нового там ничего не появится или что свежие фишки не поддерживаются браузерами? Это мнение давно устарело. Современные HTML и CSS позволяют реализовывать интерактивные элементы, которые раньше были доступны только с помощью JavaScript. Можно сказать, что границы между разметкой, стилями и программированием постепенно стираются.

На написание этой статьи меня подтолкнуло большое количество новых возможностей в современных HTML и CSS, да и не только современных: некоторые приёмы, о которых знают немногие, поддерживались ещё со времён IE. Многие по привычке используют готовые UI-библиотеки или CSS-фреймворки, опасаясь изучать что-то новое.

Я собрал компиляцию полезных практик и оформил их в сокращённом текстовом виде.

Привет, Хабр! IEEE Spectrum опубликовал ежегодный рейтинг языков программирования за 2025 год. Там много всего интересного, на что стоит обратить внимание. Давайте разберемся, как формируется этот список, какие языки пока что удерживают лидерство, кто теряет позиции и почему, а также как ИИ все (ну или почти все) меняет. Поехали!

React по умолчанию сопряжён со скрытыми издержками. Вот аргументы в пользу более осознанного выбора подходящего фреймворка для конкретной задачи.

React больше не побеждает за счёт своих технических достоинств. Сегодня его выбирают по умолчанию. И именно это «по умолчанию» теперь тормозит инновации во всей фронтенд-экосистеме.

Когда командам нужен новый фронтенд, разговор редко начинается с вопроса: «Каковы ограничения и какой инструмент лучше всего под них подходит?» Чаще всё звучит так: «Давайте возьмём React — его все знают». Такой рефлекс запускает самоподдерживающийся цикл, в котором архитектуру определяют сетевые эффекты, а не техническая уместность.

Многие мои собеседники "стопроцентно" уверяли меня, что сама суть функционального программирования заключается в повсеместном использовании map, filter и reduce; что эти функции превосходят циклы for во всём, настолько, что их нужно запихнуть в каждый возможный язык безо всякого анализа затрат и выгод, потому что выгоды настолько несравненно потрясающие, что затраты просто не могут иметь значения. А само сомнение в этих затратах уже доказывает, что я ничего не понял. Поэтому пора задать главный вопрос: действительно ли именно они (map, filter и reduce) и есть ядро функционального программирования?

К чёрту теорию; давайте посмотрим на практику. Давайте взглянем на реальный проект на Haskell. Я знаю два крупных проекта на Haskell, которые вышли за пределы хаскель-экосистемы и стали полезными программами, которые люди скачивают: xmonad и pandoc. Но xmonad - странная программа: она делает массу привязок к библиотекам C и взаимодействует со всевозможными системными сервисами…Что, конечно, неплохо, как говорится, но из-за этого она не очень типична. А вот pandoc - это чистейший Haskell: парсинг, работа с абстрактным синтаксическим деревом, его трансформация и генерация; т.е., по сути, огромный компилятор для документов. Более «хаскельским» код быть не может. Давайте посмотрим на него.

В этом году я второй раз подряд оказался в списке победителей «Технотекста». Когда вместе с летом прошла первая эйфория, во мне проснулся аналитик. Есть ли закономерность в победах? Что объединяет лучшие статьи на Хабре за последние семь лет? И главный вопрос - существует ли формула успеха, которая позволит покорить эту вершину и в третий раз?

Я вооружился своим парсером, собрал данные по всем победителям с 2018 по 2024 год и готов поделиться результатами. Это моя попытка реверс-инжиниринга победы, и, возможно, она поможет будущим чемпионам.

Привет, Хабр!

Есть такой интересный компонент в Vue.js и называется он<Suspense>. Он устроен так, чтобы собирать зависимые async-компоненты и показывать единый индикатор загрузки вместо кучи спиннеров. Проще говоря, пока внутренняя часть (слот #default) ещё не готова из-за ожидания данных, показывается запасное содержимое из слота #fallback. Как только все асинхронные зависимости разрешатся – снимаем запасной экран и выводим основное содержимое. По сути, <Suspense> создаёт границу вокруг вложенных компонентов и контролирует их загрузку.

И чтобы всё было безопасно.

Поговорим про CDN, SRI, кэш-отравления, подмены и rsbuild-плагины.

Команда JavaScript for Devs подготовила перевод статьи о том, почему тригонометрические функции стали «most hated» возможностью CSS и как их можно использовать с пользой. Мы разберёмся, что делают sin() и cos(), и посмотрим на практические примеры: от круговых раскладок до затухающих анимаций.

Андерс Хейлсберг — именно этого человека принято считать создателем TypeScript. Инженер-программист, который подарил миру такие языки как: Turbo Pascal, Delphi и C#.
Основным мотивом создания TypeScript было желание решить проблемы, связанные с разработкой крупных и сложных приложений на JavaScript.

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

Основной причиной использования TypeScript является возможность добавления статической типизации к JavaScript. Переменные с статической типизацией имеют тип, который не может быть изменен после их объявления. Это позволяет предотвратить множество потенциальных ошибок.

Эта статья поможет вам создать приложение Express 5 с поддержкой TypeScript.

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

Настоятельно рекомендую писать код вместе со мной. Мы будем использовать подход "Разработка через тестирование" (test-driven development, TDD) для создания REST API, который может стать основой вашего следующего приложения Express.

Так как я не сильно разбираюсь в математике и в геометрии, буду использовать подход графического 3D-программирования, потому что подход, применяющийся там, хорошо подходит и для проецирования четырёхмерных пространств. Поэтому для чтения этого материала рекомендую иметь хотя бы базовые знания о том, как работают матрицы преобразования и как с их помощью точка из трёхмерного пространства преобразуется в точку на экране. Код будем писать на JavaScript с использованием WebGL и библиотеки matrix-gl.

Если вы осваиваете JavaScript, то наверняка знаете об операторах rest и spread. Первый группирует несколько значений, второй - разгруппировывает. Но давайте посмотрим чуть глубже.

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

Тип any в TypeScript по своей сути является злом и небезопасной особенностью встроенной по умолчанию в систему типов языка. Данный тип дает возможность разработчику записать такое значение, которое может быть чем угодно, использоваться где угодно и как угодно вместо любого другого типа данных.

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

Линтеры — это не только важнейший инструмент для поддержания качества кода на высоком уровне, но и важный помощник в борьбе с any. Пакет typescript-eslint содержит несколько таких правил, которые помогают предотвратить небезопасные практики еще до начала компиляции, связанные с типом any. Эти правила обнаруживают как прямые использования any, так и целые паттерны кода, которые незаметно его допускают. В этой публикации мы разберемся с тем, что конкретного делают эти правила, а также рассмотрим несколько полезных способов предотвратить проникновение any в наш код.

Команда JavaScript for Devs подготовила перевод статьи о том, как доминирование React сдерживает развитие фронтенда. Автор утверждает: выбор React «по умолчанию» тормозит инновации, мешает развитию альтернативных фреймворков и превращает всю экосистему в монокультуру.

Привет, Хабр! Мы живем в удивительное время. Попросить LLM написать для нас код стало так же естественно, как гуглить ошибку. Но у этой магии есть предел. Попросите модель написать quickSort, и она справится блестяще. А теперь попросите ее: «Добавь метрики Prometheus в метод processOrder в нашем проекте».

И тут магия рушится. LLM — это гениальный, но страдающий амнезией стажер. Она знает все языки мира, но не имеет ни малейшего понятия о вашем проекте. Она не знает, какой у вас логгер, как вы обрабатываете ошибки и что у вас уже есть готовый MetricsService. В лучшем случае вы получите общий, неидиоматичный код. В худшем — сломаете половину логики.

Стандартный RAG (Retrieval-Augmented Generation) — это как дать стажеру доступ к одному файлу. Полезно, но картину целиком он все равно не увидит. А что, если мы могли бы дать ему не просто файл, а полный доступ к знаниям тимлида-архитектора? Что, если бы LLM могла видеть не просто строки кода, а всю паутину связей, зависимостей и паттернов вашего проекта?

Сегодня я расскажу о проекте code-graph-rag-mcp — это не просто очередной RAG-пайплайн. Это полноценный MCP-сервер, который строит граф знаний вашего кода и дает LLM «архитектурное зрение», превращая ее из простого кодера в настоящего цифрового ассистента.

Команда JavaScript for Devs подготовила перевод статьи о том, как Node.js выжимает максимум из I/O в 2025 году. В ней подробно объясняется цикл событий, порядок фаз и то, как правильно писать код, чтобы серверы оставались отзывчивыми даже под нагрузкой.

Маленькое open source-расширение для Chrome, которое делает поиск работы на hh.ru удобнее: выделяет уже просмотренные вакансии и резюме, чтобы не тратить время на дубли.

Коротко о моих приключениях в процессе написания шахматного бота - какие этапы я прошел, с какими сложностями столкнулся и что получилось в итоге.

Airbnb недавно завершила первую крупномасштабную миграцию кода под управлением LLM: мы обновили почти 3,5 тысячи файлов тестов React-компонентов, переведя их с Enzyme на React Testing Library (RTL). По первоначальным оценкам ручная работа заняла бы 1,5 года инженерного времени, но — используя сочетание передовых моделей и надёжной автоматизации — миграция завершилась всего за 6 недель.

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