JavaScript *

Более 50 % приложений вызывают высокорисковые API браузера, что может быть признаком наличия вредоносного кода. Почти 64 % загружают скрипты с хостов за пределами РФ. Более 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. за сбор ПД с использованием баз данных, размещенных за пределами РФ.

Разбираем результаты исследования безопасности frontend-приложений 3000 крупнейших российских компаний за первое полугодие 2025 года.

История о создании Telegram Miniapp с нуля: боль, костыли и необычные решения.

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

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

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

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

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

Команда JavaScript for Devs подготовила перевод статьи о SolidJS — реактивной UI-библиотеке, которая выглядит знакомо для React-разработчиков, но работает совсем иначе. Автор разбирает ключевые отличия: почему в Solid нет виртуального DOM, как устроены сигналы, эффекты и прокси-хранилища, а также какие привычки из React ломают реактивность. Если вы давно хотели понять, как SolidJS работает под капотом, эта статья — отличный старт.

Angular Signals 101 Это не поверхностный обзор, а полное погружение в мир сигналов. Мы разберем всё: от публичного API до внутреннего устройства планировщика в Zoneless.

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

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

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.

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

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

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

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

Команда JavaScript for Devs подготовила перевод статьи о том, сколько трафика реально выдерживает сайт на Next.js. Автор провёл нагрузочные тесты, сравнил VPS и выделенный сервер, проверил разницу между предрендерингом и SSR и сделал вывод: для сайтов с потенциальными всплесками трафика предрендеринг — спасение, а SSR может стать бутылочным горлышком.

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

С вами снова Дмитрий. В первой части мы с головой окунулись в философию Headless CMS и разобрали, почему Strapi стал глотком свежего воздуха для разработчиков, уставших от рамок монолитных систем. Мы увидели, как контент освобождается от шаблонов, получая возможность жить на любых платформах и устройствах.

Но мощный и гибкий бэкенд - только половина уравнения. Без современного, умного и производительного фронтенда вся эта свобода рискует остаться просто красивой теорией. Где же тот самый «идеальный фронтенд», который раскроет потенциал Headless на все 100%?

Опыты кодирования с ИИ в команде.

Написать эту статью меня сподвигла дилогия уважаемого Александра Антипина aka @alexantipin «Использование нейросетей в разработке игр» и попробовать поделится собственным опытом ИИ — геймдева. Это не совсем геймдев, это про разработку музыкального приложения, осложненное двумя маниакальными идеями: ни строчки кода руками и веб‑прриложение генератор музыки в реалтайм. Сам по себе проект, как законченное приложение, вряд ли представляет интерес, потому что это попытка переосмысления автопилота из другого приложения EtherMusic, тоже написанного ИИ. Там мне так и не удалось победить проблемы производительности на слабых устройствах типа смартфона.

С чего вообще все началось, почему музыка, почему броузер, почему самоделка? Основная идея — помочь приобщить (не научить, а именно приобщить) к музыке людей, которые не умеют играть ни каком инструменте, но музыку любят и хотели бы сыграть что нибудь самостоятельно. Вторая идея — это медитация через музыку. Играя свое настроение сейчас или то, настроение, к которому стремишься, через музыку достичь внутренней гармонии. Ну и третья по счету, но главная по смыслу — помочь своему сыну, у которого музыкальный слух, но который не может слушать музыку. Потеря такого гигантского мира чувств, который дает музыка, больно ранит родительское сердце. Есть идея, что играя сам — научишься не ненавидеть музыку, а возможно, даже и полюбить. Посмотрим. Вдруг получится?

Про что эта статья? Это просто история кодинга вместе с ИИ. Выводы делайте сами. Мне не нужна оценка качества кода и кода в статье не будет. Будет про архитектуру, идеи, взаимодействие и результат.

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

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

Привет, на связи снова я – React-разработчик Дмитрий. Сегодня отвлечемся от теории и разберем конкретный случай и какое решение для него использовалось.

При работе с готовыми UI-библиотеками часто возникает небольшая проблема —  компонент хорош, но его поведение нельзя настроить под требования конкретного случая. Я столкнулся с этим на практике, когда в используемой версии UI Kit не было возможности кастомизировать тексты выводимых ошибок, а бизнес-требования четко задали формулировки.

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

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

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

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

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

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

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

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

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

Привет, Хабр! (И тебе, отчаянный страдалец, зашедший сюда в перерыве между дебагом очередного if (a == b) { return true; } else { return false; }. Мы знаем, ты не виноват, так вышло).

Каждый разработчик хоть раз в жизни прилаживал к своему коду «костыль». Знакомое чувство, правда?

Андерс Хейлсберг — именно этого человека принято считать создателем 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.