JavaScript *

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

Чтобы не городить глобальные переменные и не писать громоздкие конструкции (что почти всегда ведет к багам), мы посмотрим на еще одну фишку JS.

В предыдущих статьях мы разобрали: функции, их стрелочные записи, методы объектов и даже покорили this. Теперь пора переходить к теме, которая часто пугает на собеседованиях, но на деле оказывается невероятно элегантной — замыканиям.

Представьте: ваши автотесты проходят стабильно, ошибок почти нет, команда довольна. Но со временем тесты стали работать в «стерильных» условиях и перестали отражать реальность. Именно с такой ситуацией мы столкнулись на крупном продукте после трех лет регулярных прогонов. В этой статье расскажем, как мы перешли от «зашитых» констант к системе динамической генерации данных, сделали тесты «сложнее» и в итоге повысили их реальную эффективность в 10 раз.

История проекта началась в прошлом (2025) году. Я преподаю JavaScript в HTML Academy, и когда мне предложили взять поток начинающих разработчиков по Angular, я согласился. Мы успешно прошли базу, но когда дело дошло до HttpClient и обработки данных, я столкнулся с проблемой: студентам сложно понять Observable и реактивный подход, имея в багаже только промисы.

На лекции мне задали резонный вопрос: А где посмотреть актуальные и понятные материалы по RxJS?. Я провел небольшой ресерч и понял, что ниша полупустая: видеокурсы - это долго, документация - сложно, а интерактивной практики почти нет.

Так появился мой open-source проект. В этой статье я показываю честную аналитику за 90 дней: как набрать 1000 пользователей без рекламы, почему провалилась моя любимая фича и как пет-проект превращается в полноценный продукт.

Блокчейн разработка меняется со скоростью света. Решив вникнуть, купил несколько лет назад книгу, но к сегодняшнему дню она уже безнадежно устарела. Инструменты описанные в ней web3.js, Truffle, Ganache, заброшены, подходы и стандарты изменились.

В праздники, дописал и залил в сеть web3 демо-магазин на solidity/ethers.js. Поделюсь ньансами разработки и современными инструментами.

Бывало такое: смотрите вы на красивую страницу интернет-магазина, открываете консоль разработчика (ту самую, по F12 или через правый клик), а там — лес из тегов, который вообще не похож на то, что вы видите глазами?

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

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

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

В данной статье я расскажу, с какими проблемами, связанными с бинарником, столкнулось моё решение при запуске на Arch Linux у моих знакомых, и почему у меня оно работает нормально на Debian 12 и 13. Также я разберу преимущества и недостатки текущей реализации, покажу возможные пути решения и альтернативы, а лучшее решение применю на практике.

Я снова попрошу Сергея и Ивана запустить моё приложение на Arch Linux, чтобы проверить его работу.

Заваривайте чай, доставайте вкусняшки — пора «удобрять почву для выращивания помидоров»! 🍅

Всем привет!

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

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

В 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-разработчик. Все мы видели с вами такие карты, именуемые картойдами, в данном случае — карта России, я взял первую попавшуюся из интернета, для примера.

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

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

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

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

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

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