JavaScript *

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

С вами снова Дмитрий. В первой части мы с головой окунулись в философию 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.

Белый экран при загрузке SPA — типичная боль. Пользователь открывает приложение, ждёт пока загрузится приложение, а экран пуст. А если качество связи оставляет желать лучшего а размер чанков не может похвастаться оптимизацией(да это отдельная тема для обсуждений, но все же)? Я часто сталкиваюсь с этим в реальных проектах и вот наконец то появилось время и силы сделать так, чтобы у пользователя никогда не было пустоты на экране.

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

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

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

Команда JavaScript for Devs подготовила перевод кейса Shopify о миграции их крупнейших приложений на новую архитектуру React Native. Результат впечатляет: еженедельные релизы не остановились, стабильность сохранилась, а производительность выросла.

Фронтенд-разработка в последние годы стала сложнее. Одностраничные приложения живут часами, пользователи открывают вкладки и оставляют их работать, данные приходят с серверов постоянно. В этом хаосе часто кажется, что главное — чтобы компонент рендерился, а Observable выдавал данные.

Но даже в самом аккуратном коде могут появляться утечки памяти. Утечка памяти возникает, когда объекты, которые больше не нужны, остаются в памяти, потому что на них ещё есть ссылки. Для браузера они живы, сборщик мусора их не трогает.

Для Angular‑разработчика это важно, потому что:

В данной статье рассказывается о личном опыте переезда с JS на TS, как у меня получилось подружить Node.JS с TypeScript без сторонних инструментов.

В этой статье я показываю, как заменить рутинную работу куратора курса простым сценарием в n8n. Всё делается через Google Sheets и Telegram-бота, без строчки кода. Текст написан специально для работников образования и гуманитариев — повторить сможет каждый.

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

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

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

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

Меня зовут Дмитрий Гусаков, я менеджер проектов компании DD Planet. Рад поделиться с вами материалом, который, надеюсь, будет полезен всем, кто следит за эволюцией веб‑разработки и ищет современные подходы к созданию гибких и производительных проектов. Сегодня я расскажу про связку, которая уже стала стандартом для многих команд — Strapi + Next.js. Это не просто инструменты, а целая философия, где скорость, контроль и свобода творчества выходят на первый план.